GLBA Safeguards Rule — Control Overview
Scope: how Eli's security program maps to the FTC Safeguards Rule (16 CFR Part 314), which Title IV institutions and their service providers are expected to meet for student financial information. Last reviewed: 2026-07-12. Status: working control-and-gap map, not a completed GLBA program assessment. Target or partial controls are labeled below (see ../inputs/decisions.md §6).
Why GLBA applies
The Department of Education incorporates the FTC Safeguards Rule into the Title IV Program Participation Agreement. An institution handling student financial aid data must maintain a Safeguards-compliant information-security program, and must ensure its service providers do the same. Eli is built to slot into that program as a service provider, not to replace the institution's own obligations.
This document tracks the Safeguards Rule's required elements (16 CFR 314.4(a)–(i)).
314.4(a) — Qualified individual
Gap. A qualified individual has not been formally appointed. The proposed security contact in ../inputs/decisions.md §4 is still marked for confirmation.
314.4(b) — Risk assessment
Partial / draft. The architecture, security self-assessment, and HECVAT gap matrix inventory risks across Supabase, Vercel, subprocessors, sessions, and the AI pipeline. They are not a formally approved GLBA risk assessment, and no evidenced annual-review cadence exists yet.
314.4(c) — Safeguards to control identified risks
| Required safeguard (314.4(c)) | How Eli implements it | Evidence |
|---|---|---|
| (1) Access controls | Repository controls include signed sessions, broad-product roles/institution scoping, Beta2 signed session/capability isolation, same-origin checks, and route-specific rate limits. Coverage and deployed operation must be verified for the assessed service; do not infer “every mutation” from this summary | lib/session-token.ts, lib/security.ts, rbac-model.md, Beta2 security assessment |
| (2) Data inventory & classification | Documented in architecture-diagram.md (what PII lives in which table) | architecture-diagram.md |
| (3) Encryption in transit and at rest | Application configuration sets HSTS and security headers. Current TLS scans plus provider encryption/key-management and backup evidence must be attached for the assessed deployment. App-layer field encryption of PII is not implemented | next.config.ts, decisions.md §6 |
| (4) Secure development practices | TypeScript throughout, CSP with object-src 'none' / frame-ancestors 'none', no client-side secrets, fail-closed webhook auth, CI on every PR | next.config.ts, lib/security.ts |
| (5) Multi-factor authentication | Roadmap. Supabase email/password today; MFA is a planned addition for production pilots | decisions.md §6 |
| (6) Secure disposal | Code can compute a case purge-eligible date and policy drafts describe target disposal. The 90-day job is limited to PII-free product telemetry; production case/document/audit/log/backup purge and evidence remain gaps | lib/retention.ts, data-retention-deletion.md |
| (7) Change management | Repository history and automated checks exist; no formally approved change policy, reviewer-evidence requirement, emergency path, or complete release evidence is attached | repo workflow |
| (8) Monitoring of authorized users | Partial. Review actions and agent runs are hash-chained; separate record-read/access and security-event logging is not implemented. Sentry configuration is present but deployed monitoring evidence is not attached | lib/audit-hash.ts, sentry.server.config.ts, decisions.md §6 |
314.4(d) — Testing / continuous monitoring
Partial / gap. Sentry is configured with sendDefaultPii: false and the app emits structured error lines. Continuous-monitoring operation, alert ownership, log-drain retention, annual vulnerability assessment, and independent penetration testing have not been evidenced. The repository assessment is internal, not an independent pen test.
314.4(e) — Personnel / security awareness
Gap. Formal personnel security responsibilities, screening where applicable, and recurring security-awareness training must be established before production student data.
314.4(f) — Oversight of service providers
Partial. Subprocessors are inventoried (Anthropic, Supabase, Vercel, Sentry, Resend, Twilio, Vapi) with intended functions and exposure documented in draft materials. Executed agreements, due-diligence evidence, ongoing monitoring, and GLBA-specific contractual flow-down have not been reviewed or attached.
314.4(g) — Keep the program current
Target state. Review this control set and the formal risk assessment at least annually and on material change. No completed annual cycle is claimed.
314.4(h) — Written incident-response plan
See incident-response.md.
314.4(i) — Annual report to leadership
Gap. No formal qualified-individual annual report has been completed. Establish the owner, reporting template, evidence register, and governing-body recipient.
Honest summary
The repository contains meaningful technical safeguards, including signed sessions, RLS migrations, institution scoping, transport headers, and hash-chained workflow actions. Their deployed operation and coverage still require evidence. Access-event logging, formal ownership and risk assessment, provider oversight, MFA, independent testing, recurring training, annual reporting, app-layer field encryption, and production deletion evidence remain gaps. This document is preparation for review, not a claim of GLBA compliance.