Status and use
EDUCAUSE describes HECVAT as a higher-education vendor assessment toolkit for measuring vendor risk, with a comprehensive questionnaire covering cybersecurity, privacy, IT accessibility, compliance, and AI.
Morrow uses this page as a public response brief so institutions can triage the product before requesting an institution-specific workbook packet.
Plain status: Morrow can support a HECVAT review. This public page is not the workbook itself; it is a reviewer-readable brief aligned to the current HECVAT 4.1.6 family and the Morrow trust center.
Company and product profile
| Product | Morrow for Canvas, a Chrome extension that helps instructors and academic operations teams audit, improve, and document Canvas course quality. |
|---|---|
| Primary users | Instructors, instructional designers, LMS administrators, accessibility reviewers, compliance teams, and academic operations leaders. |
| Deployment model | Browser extension plus a minimal Morrow account backend for sign-in and subscription status only; reports and evidence stay in the browser. |
| LMS scope | Current public site positioning is Canvas-focused. Canvas remains the customer's learning management system and course source of truth. |
| AI model | Bring-your-own AI account. The customer's or instructor's ChatGPT/OpenAI account receives redacted prompts under that account's settings. |
Architecture
Morrow is intentionally narrow: it runs in the user's browser, talks to the Canvas course the user authorizes, and uses the user's AI account for generation.
Morrow cloud services store account data and subscription status only.
- Browser extension: Chrome Manifest V3 package with documented API and host permissions.
- Canvas boundary: requests run through the user's existing Canvas session and roles.
- AI boundary: outbound prompts are redacted before leaving the browser.
- Morrow backend: account sign-in and subscription status only, nothing else.
- Customer responsibilities: Canvas account governance, role assignments, institution AI policy, and exported-file retention.
Privacy and AI
Morrow's privacy posture is built around data minimization and local filtering. The product does not need to store raw rosters to perform its job.
It reads the course context needed for the user's request, removes student-identifying details before AI, and keeps a local audit trail so teams can show what changed later.
| HECVAT concern | Morrow response brief |
|---|---|
| Student data | Student-identifying details are filtered locally and are not stored in Morrow's cloud evidence layer. |
| AI training | Morrow does not train models on customer course data. AI processing uses the customer's or instructor's own provider account and settings. |
| Telemetry | The public privacy posture states no analytics, no ping, no telemetry, and no surveillance-style usage tracking. |
| Reports and evidence | Generated reports and alignment evidence are created and stored locally in the browser; they are not uploaded to Morrow's backend. |
Security controls
HECVAT reviewers need to see whether a vendor can explain its security model in concrete operational terms. Morrow's current public controls are:
- Named Chrome permissions with documented product purpose.
- Canvas requests made through the user's own Canvas role and session.
- No storage of Canvas passwords by the extension or Morrow backend.
- Local redaction before AI requests and before cloud evidence storage.
- Approval-gated course writes with evidence of proposed and approved changes.
- Trust-center documents for security, privacy, accessibility, DPA posture, and SOC 2 readiness.
Accessibility
Morrow treats accessibility as part of academic quality, not a separate procurement checkbox. The product helps identify accessibility issues in Canvas course content.
Morrow's own interface is being documented through a VPAT / ACR process.
- Public accessibility page available for product positioning and current commitments.
- VPAT / ACR evidence available publicly for initial review.
- Formal per-criterion VPAT matrix can be packaged when required by procurement.
- Generated reports should remain readable, structured, and usable for compliance teams.
Workbook-specific details
A completed HECVAT workbook should be tied to the customer's required format, contract terms, and deployment assumptions. The public brief keeps those customer-specific details separate:
- Formal uptime commitments or support SLAs.
- Final named subprocessor list attached to the customer agreement.
- Institution-required breach notice timing and notification route.
- Any customer-specific data residency, retention, or deletion terms.
- Whether the customer treats OpenAI/ChatGPT as customer-managed AI or asks Morrow to route AI differently.
- Final SOC 2 report status, if the contract requires an issued attestation rather than readiness evidence.
| HECVAT area | Public status | Brief response | Workbook detail |
|---|---|---|---|
| Product profile | Covered in public brief | Morrow for Canvas, target users, deployment model, LMS scope, and AI account model are described. | Institution-specific vendor identifiers, contract contacts, and purchasing terms. |
| Architecture | Covered in public brief | Browser extension, Canvas boundary, AI boundary, backend purpose, and customer responsibilities are separated. | Deployment diagram and customer-specific environment assumptions. |
| Privacy and AI | Covered in public brief | Data minimization, Proxy filtering, AI training posture, telemetry posture, and de-identified evidence storage are summarized. | Institution-specific AI-use terms and subprocessor attachment. |
| Security controls | Covered in public brief | Permission rationale, Canvas session boundary, password posture, approval-gated writes, and trust center materials are listed. | Formal incident notice, audit-log samples, uptime commitments, and control evidence samples. |
| Accessibility | Evidence linked | Accessibility statement and VPAT / ACR evidence are public for initial review. | Per-criterion ACR rows if required by procurement. |
| Workbook-specific details | Separated from public brief | Customer-specific workbook details are separated from the public brief. | Required HECVAT format, contracting route, deadlines, and deployment assumptions. |