Incident response plan (draft)

Sign-off: approved by [Kyle] on [date], second reader [Dan] on [date]; recorded in approvals.md. Review yearly.

Draft for LM-3 and ORG-25, 27 Oct 2026. Owner: Kyle. A security incident here means anything that does or could expose, change or lose SCOPE customer data, or take SCOPE down: a leaked key, a lost laptop, a wrong person seeing another site's records, a deleted table, a vendor breach.

(An "incident" in SCOPE the product is a workplace safety event. This plan is about the other kind.)

Roles

Role	Who	Backup
Incident lead: decides severity, runs the response, keeps the log	Kyle	Dan
Technical lead: contains and fixes	Dan	Kyle
Customer contact: sends the notices	Kyle	Business lead
Counsel: notice obligations, regulators	[ORG-36]

On-call: Kyle and Dan, each the other's backup, as set out in the On-call section of the BC/DR plan (NP-6). Contact numbers are in the vault, not in this file.

Severity

Level	Example	Start within
1, critical	Customer data seen by someone who should not have it; a production key leaked publicly; SCOPE down for every customer	1 hour, any day
2, high	A key leaked privately; a lost laptop with a session open; one feature down; a vendor reports a breach	4 hours
3, low	A failed attack with no access; a policy breach with no data involved	Next working day

Steps

1. Report. Anyone who sees something tells the incident lead at once, and within 1 hour of noticing; by phone for a level 1. Do not discuss it in a customer channel.
2. Log. The lead opens an incident record in docs/compliance/evidence/<year>/, with a line in the control calendar log (or in the compliance platform, if one is chosen): time found, who found it, what is known. Every later step is added with its time.
3. Contain. Typical moves, from the dashboards: revoke sessions (rotate the Supabase JWT key), rotate the leaked key, remove a person's access, take a Vercel deployment down or roll it back, pause a Supabase project. Preserve logs before changing anything that would erase them.
4. Assess. Which customers, which records, which people; was data read, changed or lost. The audit columns and the append-only trails (incident_event, training_event, and the others listed under DB-4) show who changed what.
5. Notify. If customer data was exposed: tell each affected customer within the contract window (24 to 72 hours, set by counsel in the DPA, VN-5), in writing, with what happened, what data, what we have done and a contact. Counsel decides on regulators and individuals.
6. Recover. Restore from backup if data was lost (the BC/DR plan); confirm the fix holds.
7. Review. Within 10 working days: what happened, why, what changes. Changes become tracked items (a risk register line or a readiness item). Close the record.

Tabletop exercise (ORG-25)

Once a year, and once before the Type I: one hour, Dan and Kyle, one scenario walked through these steps. Suggested first scenario: the demo password and the Supabase publishable key are posted in a public forum on a Saturday. Record who attended, what was found and what changed; that record is the evidence.