Blog
The ransom note is a decision. The restore is a test.
On 29 September, more than 100 people from 40 Alabama water utilities ran a tabletop on the Cahaba. How to keep the ransom-note calls in the room and put the restore of prod-db-01 on a different day.
On 29 September 2026, more than 100 people from 40 Alabama water utilities sat at the Cahaba River pumping station for two days. WBRC reported a tabletop hosted by Central Alabama Water and CISA. Cameron Holly, the utility's CTO, said they will never get an unbreakable posture. Chad Smith, the state CISO, said the point is muscle memory for how you respond. Nick Sellers of Auburn's McCrary Institute put the other half in the same sentence: training what you do when a bad thing happens, and how you get back online quickly.
That last clause is where most ransomware rooms go wrong. The first half is a decision exercise. Getting prod-db-01 back online is a restore, and a conversation about backups is not one.
What the ransomware room can actually decide
A weak inject reads:
Discuss ransomware recovery and whether you would pay.
The room says it would isolate, restore from backup, and consult legal on payment. An assessor who later reads the packet cannot tell who would have isolated prod-db-01, whether last night's backup was even reachable, or who is allowed to refuse a ransom. The sentence would also be true of a team that has never opened the backup console. That is what it costs: on a real night Priya S isolates at 02:31, the restore job fails at 04:10, and payroll still posts at 06:00 from a host nobody took down.
A strong inject reads:
T+18. EDR flagged encryption on prod-db-01 at 02:14. Priya S can isolate it from the network in about four minutes. The last backup job Priya can see finished at 23:40 and has never been restored into a clean account. Payroll posts from prod-db-01 at 06:00. Dana K is on the bridge and has not been asked about payment. Isolate now, keep it up for payroll, or isolate and accept that restore is unknown. Name the choice, the owner, and the clock. You have four minutes of exercise time. Do not restore anything from this room.
Both produce a meeting. Only the second produces a containment decision someone who was not in the room can check. Payment is a later inject. Restore is a later day. The injects post is the same rule with a different choice at the end of it.
Put the restore on a different day
A weak line in the packet reads:
The team confirmed backups would be restored and RTO would be met.
That sentence is a claim about a system nobody touched. A reader treats it as a restore record. When the real restore of prod-db-01 takes nine hours, the packet becomes the thing you have to explain.
A strong line reads:
T+22. Priya S isolated prod-db-01 and snapshotted the volume. The room could not name a restore path that meets the 4-hour Tier-1 RTO. Follow-up owned by Wei L: restore prod-db-01 from object storage into a clean account; record measured RTO against the 4-hour commitment. Not run in this session.
That is the shape of our sample packet: isolation four minutes in, then a gap at twenty-three minutes that the 4-hour RTO could not be substantiated, with a restore rehearsal as the action. Copy the split. The conversation belongs in the tabletop record. The restore belongs in the free recovery test template, which asks for the system you actually restored, the measured RTO against the target, and how you checked the data came back usable. A clean exit code from the restore tool is not that check.
The seed post on what a tabletop proves versus a DR test is the general line. This is the ransomware version of it: the ransom note, the isolate button, and the payroll clock live in one room. prod-db-01 coming back lives in another.
Payment is a later inject, on its own clock
Do not bury pay inside recovery. A payment call is a named person, a policy sentence, and a clock. If anyone would pay, the proposed CIRCIA window for that payment is 24 hours from disbursement: a different form from the incident filing. The filing-clock post walks that split. In the room, write who would be asked, what the policy actually says, and that no payment was made from the exercise.
Ransomware with exfiltration is one of the scenario families we actually run. Hang the isolate inject, the payment inject, and the customer-notice inject on that family. Leave the restore off the exercise path.
What to write down
The artifact that travels is the same shape every time:
- Isolate decision. Who took prod-db-01 down, at what time, against which facts, including if they left it up for payroll.
- Backup status as known in the room. Last job seen, last restore actually run, and that this session did not run one.
- Payment. Who would be asked, what the policy says, and that nothing was paid.
- Restore follow-up with an owner. System, environment, and the record format you will fill when you actually restore it.
That is the decisions and gaps fields in our free evidence template, and it sits with the recovery-test format in the template library. If the plan cannot name who isolates, who is asked about payment, or which host is Tier-1, stop and run the free plan self-check before you book the room.
Practising the isolate call does not prove the backup restores, that the 4-hour RTO holds, or that a payment policy would survive a real note. Those are technical and legal tests. The packet records that named people practised the ransomware decisions under a concrete scenario, and that you kept the restore on its own day.
Bottom line: isolate on a clock, write down that restore is unknown, and run the restore as a restore. A note that backups would be restored is not evidence of a recovery.