Status and scope
A SOC 2 Type II report is an independent attestation over a defined review period. Morrow does not present this readiness page as an issued SOC 2 report, certification, seal, or audit opinion.
It is a procurement-facing control packet.
The packet explains the system, the trust criteria being mapped, the current controls, and the evidence that can be supplied during review.
Plain status: Morrow is maintaining SOC 2 Type II readiness materials and can provide current architecture, access, backup, incident, privacy, and change-control evidence during security review.
A final Type II report should only be described as available after a qualified auditor issues it.
System description
Morrow is a Chrome extension for Canvas. The extension runs beside the instructor's course and uses the instructor's existing Canvas session.
It reads or writes course data as that user and removes student-identifying details before AI use.
Morrow stores de-identified reports and alignment evidence in cloud storage for audit continuity.
Trust criteria map
Morrow organizes readiness evidence around the AICPA Trust Services Criteria categories commonly used for SOC 2 work. The table below is a review map, not an auditor's opinion.
| Trust Services Criteria | Morrow interpretation | Current readiness posture |
|---|---|---|
| Security | Protect the extension, backend, account records, and de-identified report storage from unauthorized access. | Least-privilege browser permissions, account-backed access, Proxy checks before AI-bound requests, cloud storage boundaries, and change review are the primary controls. |
| Availability | Keep account services and stored evidence reasonably available for authorized users. | Cloud-backed report continuity is part of the product posture; uptime commitments require customer-specific agreement language. |
| Processing integrity | Ensure reports, audit trails, and proposed course changes are complete, reviewable, and approved before write actions occur. | Course-changing work is approval-gated, logged, and tied to the instructor's Canvas session rather than hidden server-side mutation. |
| Confidentiality | Limit access to sensitive account, report, and institutional review materials. | Student-identifying details are filtered before AI and excluded from Morrow storage; report access is bound to authorized account context. |
| Privacy | Handle personal information consistently with the privacy policy and contractual commitments. | The privacy posture centers on data minimization, Proxy stripping identifiers before AI-bound text leaves the browser, no telemetry, and clear subprocessors for account/billing infrastructure. |
Control posture
The readiness packet focuses on controls a reviewer can inspect rather than vague assurances. Current control families include:
- Access control: account authentication, role-aware customer access, and no storage of Canvas passwords.
- Permission control: Chrome Manifest V3 host and API permissions are mapped to product behavior and documented in plain language.
- Data minimization: Proxy strips student-identifying details before AI calls and before Morrow cloud report storage.
- Change approval: Morrow proposes course changes for user approval; it does not silently mutate a course.
- Auditability: generated reports and alignment evidence are stored so teams can reconstruct what was reviewed and when.
- Incident response: customer notice, investigation, containment, and remediation procedures belong in the contract packet and questionnaire response.
- Vendor oversight: account, billing, storage, and AI-provider boundaries are identified so customers can route their own review correctly.
| Control | Owner | Public status | Evidence summary |
|---|---|---|---|
| SEC-01 Browser extension permissions | Security | Documented | Chrome API and host permissions are mapped to reviewer-readable product purposes. |
| SEC-02 Account and access boundary | Security | Documented | Morrow separates the Canvas session, the customer's AI account, and Morrow account services. |
| PI-01 Approval-gated course changes | Product | Documented | Course-changing work is proposed for user approval before it writes to Canvas. |
| CONF-01 Student-identifier minimization | Privacy | Documented | Proxy strips or substitutes direct student identifiers before AI-bound text leaves the browser. |
| PRIV-01 Retention and deletion posture | Privacy | Documented | The privacy policy explains stored account/report data, retention, and rights request paths. |
| AV-01 Evidence continuity | Security | Readiness | De-identified reports and alignment evidence are stored for account recovery and export continuity. |
Evidence packet
For a security review, Morrow can package evidence in a form the reviewer can follow without reverse engineering the product. The packet should include the following artifacts when requested:
| Artifact | Purpose | Public status |
|---|---|---|
| Security overview | System boundaries, Chrome permissions, student-data handling, and backend posture. | Available publicly. |
| Privacy policy | Data collection, storage, retention, student-data posture, and subprocessors. | Available publicly. |
| DPA overview | Controller/processor roles, categories of data, security measures, deletion, breach notice, and transfers. | Available for review; signed terms require customer packet. |
| HECVAT response brief | Higher-ed risk questionnaire alignment and customer-specific workbook areas. | Public brief available; workbook available on request. |
Readiness status
An issued Type II report requires a defined audit scope, review period, control owners, operated controls, and independent testing by a qualified auditor.
Until an auditor issues that report, the accurate public label is readiness material, not a SOC 2 report, certification, seal, or audit opinion.