HECVAT — Vendor Security Assessment
Target instrument: HECVAT 4.1.6 (the EDUCAUSE Higher Education Community Vendor Assessment Toolkit), the version checked on the EDUCAUSE site on the review date. HECVAT 4 uses one workbook whose START HERE answers route the provider to the applicable tabs.
Last reviewed: 2026-07-13.
Current artifact status: there is no release-ready workbook. A prior internal workbook predates the current Beta2 security, retention, accessibility, upload, deletion, and audit-signing changes and is stale; do not share it. Regenerate from the official 4.1.6 template, inspect every populated range, scan formulas, and render every sheet before external use. Even after regeneration it remains a partially populated pre-submission draft—not a completed HECVAT response, institution evaluation, EDUCAUSE approval, security certification, counsel opinion, or independent attestation. EDUCAUSE listed 4.1.6 as current on 2026-07-13; re-check the live page before each submission.
How to use this folder
This README.md is a preparation aid, not an answer bank that can be copied without review. Use it with the Beta2 [response/gap matrix](../../../docs/beta2/hecvat-response-gap-matrix.md). For one defined order form and deployed data flow, an accountable owner must confirm each answer, replace every pending field, identify active Subprocessors, and attach current deployment and external-assurance evidence. The institution completes its own evaluation tabs.
"Start Here" routing inputs
| Question | Answer |
|---|---|
| Solution type | Cloud-hosted SaaS web application |
| Deployment model | Proposed cloud SaaS/managed-service boundary on Vercel with configured application data in Supabase; confirm the exact pilot deployment |
| Personal or institutional data? | Yes for a contracted evaluation pilot because the institution's de-identified files remain institutional data. Student PII and raw FTI are prohibited in the public demo and are not approved by this packet |
| Uses AI/ML? | Yes at the product level. The deterministic Beta2 wedge calculations do not invoke a model; inventory any enabled AI feature separately |
| Hosting/data regions | Pending deployment-specific provider evidence and contractual confirmation |
Company & system overview
- Product: Eli, a financial-aid operations and compliance platform offered as software or a managed service. Beta2 demonstrates deterministic SOR, R2T4, and SAP workflows; the broader product also contains AI-assisted features.
- Architecture / data flow: see
../../02-security/architecture-diagram.md. - Current public-demo boundary: synthetic fixtures by default. Beta2's optional custom-CSV path accepts only the published schema after a fixed uploader attestation that the files are de-identified. That attestation and Eli's pattern checks do not independently prove de-identification. Student PII, FAFSA/ISIR files, credentials, documents, free text, and raw FTI are prohibited.
Data & privacy
- Data classes / inventory:
../../02-security/architecture-diagram.md(PII inventory). - Encryption: application headers require HTTPS/HSTS; retain a current deployed TLS scan and provider encryption/key-management evidence before answering the official control questions. App-layer field encryption is not implemented.
- Retention / disposal:
../../02-security/data-retention-deletion.mdstates proposed periods and current gaps. The implemented 90-day purge is limited to PII-free product telemetry and still needs deployed execution/alert evidence; no end-to-end production case/document/audit/log/backup purge is evidenced. - Isolation: repository migrations and application scoping support the broad product, and Beta2 has signed session/capability isolation. Neither is represented as completed production multi-tenant assurance without deployment-specific negative-access and database-policy evidence (
../../02-security/rbac-model.md). - FERPA / FTI:
../../01-privacy/ferpa-position.md,../../04-regulatory/fti-fa-ddx-boundaries.md.
Access control
- Roles, session security, CSRF/same-origin, rate limiting, segregation of duties:
../../02-security/rbac-model.md. - MFA: roadmap.
Application & infrastructure security
- Security headers / CSP / HSTS:
next.config.ts. - Secure SDLC: TypeScript, PR review + CI, fail-closed webhook auth, no client secrets.
- Monitoring: Sentry (
sendDefaultPii: false) + structured logging. - Audit: hash-chained records, with a server-verifiable HMAC for Beta2 exports. These are tamper-evident within their stated server trust boundary, not immutable, independently timestamped, publicly signed, or evidence of durable retention.
AI governance (HECVAT 4 domain)
Preparation material is in ../../00-overview/ai-governance-memo.md. Before an official response, create a deployment-specific inventory of each model/provider, purpose, fields transmitted, prompt/output or embedding storage, retention, training/evaluation use, monitoring, and human authority. The draft DPA prohibits training on Institution Data, but a draft promise is not proof of an active provider's terms or runtime behavior.
Incident response
../../02-security/incident-response.md (written plan; notification SLA to the institution).
Candidate Subprocessor inventory — active status must be confirmed
This is a product-wide inventory, not an order-form-specific schedule. Do not mark a provider active, or claim the exposure below occurs, until deployment configuration and contracts are checked. Remove inactive providers from the official response.
| Sub-processor | Function | Data exposure | Notes |
|---|---|---|---|
| Anthropic / AI gateway | If enabled: model inference | Fields explicitly sent for an enabled feature | Not used by deterministic Beta2 wedge calculations; confirm gateway/provider, terms, retention, and training/evaluation behavior |
| Supabase | If configured: database, storage, auth | Exact tables/objects for the assessed deployment | Confirm active services, regions, roles/policies, encryption, backups, and deletion evidence |
| Vercel | Hosting / compute / cron | Requests and application data processed by deployed functions | Confirm regions, logs/request capture, security settings, retention, and provider evidence |
| Sentry | If enabled: error/performance monitoring | Minimized error metadata | Confirm DSN/activity, scrubbing, access, regions, and retention; do not send Institution Data by default |
| Resend | If enabled: transactional email | Approved address and message content | Not authorized for evaluation-only Beta2 unless separately scoped |
| Twilio | If enabled: SMS | Approved phone number and message content | Not authorized for evaluation-only Beta2 unless separately scoped |
| Vapi | If enabled: voice workflow | Approved call audio/transcript and metadata | Not authorized for evaluation-only Beta2 unless separately scoped |
Supporting documentation status (be honest here)
HECVAT 4 reviewers will ask for evidence behind the answers. Current state:
| Artifact | Status |
|---|---|
| Data-flow diagram | Available (../../02-security/architecture-diagram.md) |
| Sub-processor list | Available (above) |
| AI governance policy | Available (../../00-overview/ai-governance-memo.md) |
| Incident-response plan | Available (../../02-security/incident-response.md) |
| HECVAT 4.1.6 workbook | Pending regeneration and verification — prior internal workbook is stale and must not be shared |
| SOC 2 report | Roadmap — not yet started |
| Independent penetration test | Roadmap — not yet performed |
| MFA | Roadmap |
| Accessibility assessment | Pre-verification template only — automated, keyboard, responsive, and assistive-technology results remain pending |
| VPAT / ACR | Not available; no accessibility certification or conformance claim |
The defensible posture is to lead with evidence at its tested scope and the gap matrix. Do not give reviewers a workbook until it has been regenerated and fully verified. Name the official HECVAT response, counsel review, deployment evidence, accessibility work, SOC 2, independent penetration test, and MFA as incomplete until their artifacts exist.