Tabletop exercises (ready to run)
Two scripts, one hour each, for the yearly exercises the plans require: incident response (ORG-25, LM-3; CC7.3 to CC7.5) and disaster recovery (ORG-24, AV-3; CC9.1, A1.3). Draft 28 Oct 2026. Run both before the Type I. Free first: no facilitator or tool needed, only the two owners, these pages and the plans.
How to run one. The facilitator (whoever did not write the scenario) reads each inject aloud
and stops. The team says what it would do, using only the plan. Write down every point where
the plan was silent, wrong or slow. Those notes, with the date and who attended, are the
evidence: save the filled record to docs/compliance/evidence/<year>/ and log it in the
control calendar.
Exercise 1: a leaked key on a Saturday (incident response)
Plan: incident-response-plan.md.
| Time | Inject | Questions the plan must answer |
|---|---|---|
| Sat 10:00 | A client's IT contact emails: a forum post contains a SCOPE login URL, a demo password and a Supabase publishable key | Who receives this on a Saturday? How is it acknowledged, and how fast? What severity is it? |
| Sat 10:20 | The key is the client's production key, not the demo's | Does severity change? Who decides? What is the first containment step, and who can do it with which account? |
| Sat 11:00 | The auth logs show 40 failed sign-ins from one address in the last hour, and one success as a supervisor | How do we see that (where are the logs, how far back)? How do we end that session and lock the account? |
| Sat 13:00 | The supervisor account read 300 incident records, some with injury details | Is this a notifiable breach? Who decides? What is the client notice window in the contract, and who writes the notice? |
| Mon 09:00 | The client asks for a written account | What goes in it, and from which records? What changes so it cannot recur? |
Gaps to look for: a second person reachable at weekends; keys that can be rotated without a deploy; whether sessions can be revoked centrally; where 12 months of logs live (LM-1).
Exercise 2: a migration drops a column on a Tuesday (disaster recovery)
Plan: bc-dr-plan.md.
| Time | Inject | Questions the plan must answer |
|---|---|---|
| Tue 07:30 | A release applies a migration; CI was green | What did the change process check, and what could it not? |
| Tue 12:00 | A supervisor reports that every investigation's root cause is blank since this morning | How is it confirmed? Is it an incident, a bug or both? Who is told? |
| Tue 12:30 | The migration dropped and re-added the column; four and a half hours of writes since then are good | Restore the whole database to 07:29 and lose the morning, or restore a copy and pull back one column? Who decides, against which RPO? |
| Tue 13:00 | The restore into a new project is running | How long will it take (has it ever been measured? AV-1)? What do drivers do meanwhile (the offline DVIR)? How is the client kept informed? |
| Tue 17:00 | Data is back | How is it proved complete? What goes in the record, and what changes in the release process? |
Gaps to look for: whether PITR is on (AV-2); a measured restore time; whether a migration can be rolled back; who may run a restore on a client project.
Record
| Field | Exercise 1 | Exercise 2 |
|---|---|---|
| Date | ||
| Attended | ||
| Facilitator | ||
| Where the plan was silent or wrong | ||
| Changes agreed, with owner and date |