Incident Response & Disaster Recovery Exercise — 2026¶

One session, three checklist rows. This covers the annual incident-response test (row 59, CC7.4), the first database restore test (row 60, CC7.5, S-412) and the annual DR tabletop (row 66, CC9.1). It runs the real procedures, and the restore is performed live, not on paper.

The point is to find what doesn't work. The BC/DR plan (§8) says it plainly: a test that surfaces nothing was not really a test. Write down every hesitation, every "I'm not sure how we'd do that", and every step that relied on one person's memory.

1. Logistics¶


Length	90 minutes
Facilitator / scribe	Olaf Jacobson (ISM). Reads the injects and keeps the timeline
Participants	Thomas Picauly (recovery lead), Alessandro Cardinali (communication deputy)
Observer (optional)	Andrea Cardinali (CyberSquad), as internal auditor. Observes, does not play
Needs	AWS console access for Thomas (`SoonDevDatabaseAccess` and RDS restore rights), the BC/DR plan, the incident response procedure, the breach notification procedure, a shared doc for the timeline

2. Before the session starts (T-15 min): the live restore¶

Thomas starts a real point-in-time restore into a throwaway instance, so the timings are measured rather than guessed. It runs in the background while the scenarios are played.

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier rds-soon-soon-prod \
  --target-db-instance-identifier rds-soon-soon-restoretest-2026 \
  --use-latest-restorable-time \
  --db-instance-class db.t4g.medium \
  --no-publicly-accessible \
  --region eu-west-1

Record: command issued at ____ ; instance available at ____ ; data verified at ____. Verification = row counts on the three largest tables, the newest record's timestamp, and one lookup a customer would recognise. Screenshot each step with the date visible. Delete the instance after the session and note the time here: ____.

3. Scenario A — incident response (35 min, row 59)¶

Grounded in the September 2026 pentest: single-factor password login (#4) and account enumeration (S-608).

Inject 1: Monday 09:10. CloudWatch shows /auth/session/login failures jumping from ~20/hour to 4,000 in the last 30 minutes, from roughly 300 IP addresses. - Who sees this, and how? Does any alert fire today, or does someone happen to look? - Is this an incident yet? Who declares it, where, and at what severity (P1–P4)?

Inject 2: 09:40. A customer admin (a contact centre, 400 agents, password logins) writes to Intercom: three agents report "someone changed my availability". Their session history shows logins from countries they have never been to. - Contain: where do we block the attacking IPs? The API is not behind Cloudflare (S-426), so the Cloudflare WAF can't help. What can? - Can we revoke all sessions for those three users right now? For the whole tenant? How, exactly? (Compare S-376.) - Do we force a password reset, and how do we tell the users?

Inject 3: 11:00. Logs show the attacker viewed the schedules, leave dates and absence types of about 60 employees in that tenant. - Is this a personal-data breach? We are the processor: who do we notify, how fast, and with what? Walk the breach notification procedure; its clock starts at awareness. - What do we tell the customer today, and what do we still not know? - What goes in the incident register, and who closes the incident?

4. Scenario B — disaster recovery (35 min, row 66)¶

Tests BC/DR plan §4, steps 0–7, and the §7 deputy arrangement.

Inject 1: Wednesday 14:20. A migration merged at 13:52 had a bug. Sentry shows a spike of errors on shift assignment queries, and two customers report empty schedules for next week. shift_assignments rows for all tenants since 13:52 are damaged. - Declare, and start the timeline. Is the cause still active? Do we take the app offline, and how, exactly, in a way the whole team knows?

Inject 2: 14:35. Thomas is on a flight until 19:00 and unreachable. - Olaf is the deputy for database recovery (§7). Could Olaf do the restore now, from the plan alone? Where would he get stuck?

Inject 3: 14:50. Thomas is back in reach (the flight was cancelled). - Choose the recovery point: point-in-time to 13:51, not last night's snapshot. What happens to the valid writes made between 13:52 and the moment we stop writes? - Restore to a new instance. Use the live restore's real timing (§2) for the estimate. - Cut-over: exactly how does the application get repointed? Which secret, which service, which redeploy? Who has done that before? - Communicate: status page, email, and the breach procedure (integrity and availability of personal data). What's the message at 15:00, and at 17:00? - Are we inside the RTO of 8 hours and the RPO of 24 hours? What would the real data loss be?

5. Minutes (fill in during the session)¶

Date: ____ Start / end: ____ / ____ Attendees: ____

Timeline¶

Time	Scenario / inject	What was decided or done	By

Measured restore (row 60)¶

Step	Time	Duration
Restore command issued		—
Instance available
Data verified
Total		against RTO 8 h
Recovery point achieved		against RPO 24 h

What worked¶

-

What did not work, or relied on one person's memory¶

-

Actions¶

#	Action	Owner	Due	Linear
1

Sign-off¶

Exercise conducted as described; the findings above are complete and actions are tracked.

ISM: ____________________ Date: ________

Change log¶

Version	Date	Author	Change
0.1	2026-09-29	ISMS	Exercise pack for checklist rows 59, 60 and 66. Scenarios drawn from the September 2026 pentest and BC/DR plan §4 and §7. Minutes to be completed in session and approved by the ISM.