← Trust centerWorking document · gaps declared inline

Incident Response Policy

Last reviewed: 2026-06-26. Status: current. Contact and SLA values are from ../inputs/decisions.md §4 and are marked (confirm) until Pat finalizes them.

This document satisfies the FTC Safeguards Rule requirement for a written incident- response plan (16 CFR 314.4(h)).


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

A formal on-call rotation, an automated alerting threshold policy, and a tabletop- exercise cadence are established as the team grows. Stated here as in-progress rather than implied as operational today.

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

Next: Third-party servicer position →