← Trust centerWorking document · gaps declared inline

Incident Response Policy

What this is. Eli's written incident-response plan. It satisfies the FTC Safeguards Rule requirement for one (16 CFR 314.4(h)). It names the incident lead, what counts as an incident, the response phases, and the notification clock to the institution.

What this is not. An exercised plan. No tabletop has been run, there is no on-call rotation, and there is no automated alerting threshold policy. Contact and SLA values come from ../inputs/decisions.md §4 and are marked (confirm) until the security contact finalizes them.

Last reviewed: 2026-06-26.


1. Roles

RoleWhoResponsibility
Security contact / incident leadPatrick McGovern, pwmcgovern@gmail.com, 203-843-5608 (confirm)Owns triage, decisions, and institution notification
Institution contactThe pilot's designated aid-office / IT contactReceives notification, coordinates institution-side response

2. What counts as an incident

Any confirmed or reasonably suspected event affecting the confidentiality, integrity, or availability of institution or student data: unauthorized access, credential compromise, data exfiltration, a sub-processor breach affecting Eli's data, or a vulnerability being actively exploited.

3. Phases

  1. Detect. Sources: Sentry alerts, structured error logs (Vercel log drain), sub-processor breach notices, or a report from staff/the institution.
  2. Triage & contain. The incident lead begins triage without undue delay, target within 24 hours of detection: assess scope, identify affected institutions/data, and contain (revoke sessions/keys, rotate secrets, disable affected access). Sessions can be invalidated by rotating AUTH_SECRET; sub-processor keys (Anthropic, Resend, Twilio, Vapi, Supabase service role) can each be rotated independently.
  3. Eradicate & recover. Remove the cause, patch, restore from a known-good state, verify integrity (including the audit-trail hash chain, which detects any tampering of case records).
  4. Notify. See §4.
  5. Post-incident review. A written root-cause and corrective-action record; feed lessons back into the risk assessment (GLBA 314.4(g)).

4. Notification SLA to the institution

On confirming a breach involving an institution's data, Eli notifies that institution's contact without undue delay, target within 72 hours (confirm). The notice includes: the nature of the incident, the data involved, the remediation taken or in progress, and a point of contact.

This is Eli's contractual commitment to the school. It is separate from any statutory breach-notification duty the institution itself carries (for example under state law or its ED obligations); Eli's job is to give the school what it needs to meet those duties on time.

5. Evidence & forensics

The tamper-evident audit trail (lib/audit-hash.ts) provides a verifiable record of every case action; a broken hash chain is itself a detection signal. Sentry retains error/event data for 90 days. Relevant evidence is preserved for the duration of an investigation regardless of the normal log-retention window.

6. Sub-processor incidents

If a sub-processor (Anthropic, Supabase, Vercel, Sentry, Resend, Twilio, Vapi) reports a breach affecting Eli's data, Eli treats it as an incident under this policy and applies the same notification SLA to affected institutions.


Roadmap

Eli does not run a formal on-call rotation, an automated alerting threshold policy, or a tabletop-exercise cadence today. Each is planned as the team grows.

Source of truth: trust-packet/02-security/incident-response.md in the repo.

Next: Third-party servicer position →