Blog
When not to run a tabletop
A conversation cannot produce a restore time, a detection proof, or a named commander the plan never had. Match the tool to the question before you book the room.
SOC 2 window closes 15 November. Wei L (infra) has never restored prod-db-01. The last backup job is green. Marcus T books a 90-minute ransomware tabletop for 12 October because the team needs to show they tested recovery. At T+40 Priya S says they would restore from object storage. The packet reads "recovery discussed, team aligned." In March the assessor asks for the restore record. There is no measured RTO, no newest-row check, no clean-account copy. There is a meeting.
That is the wrong tool for the question they actually had.
A weak next step reads:
Book a tabletop to cover IR, DR, and detection before the period ends.
A strong one reads:
This week: run the plan self-check and name who isolates prod-db-01. 18 October: restore prod-db-01 into a clean account and record measured RTO against the 4-hour Tier-1 target. 5 November: 90-minute tabletop for isolate, customer notice, and filing decisions. Detection proof is the last 90 days of alert-to-ticket times, not a conversation.
Both spend October. Only the second produces the three artifacts the period asked for. The first costs you the slot: you used the only IR-practice morning of the year on a discussion that cannot emit a restore number, and you still have nothing to hand over for recovery.
Three questions a tabletop cannot answer
Does last night's backup of prod-db-01 restore, and what is the newest row in the copy? That answer is a number from a system you actually restored. A conversation about object storage does not produce it. Put the restore on its own day and fill the free recovery test template: system, environment, measured RTO against the target, and how you checked the data came back usable. A green backup job is not that check. The ransomware split and the seed post on what a tabletop proves versus a DR test are the same line from two angles. This is the booking decision that comes first: if the question is a restore number, do not book the conversation.
Does the EDR quarantine prod-db-01 when encryption starts at 02:14? That answer is whether the rule fired, on which host, at which time. A tabletop can ask who would press isolate, and who would live with payroll at 06:00 if they do. It cannot fire the rule. Detection proof is telemetry and ticket times, or a controlled technical test under change control. Do not spend the room proving a sensor.
Does the IR plan name an incident commander? That answer is a sentence that should already be in the document. If Marcus cannot point to it, stop. Run the free plan self-check this week. A tabletop with unnamed seats is theater: the room invents a commander who does not exist on Tuesday night, and that invention dies when the call ends. The invite-list post is who has to be asked once the plan names them. It is not a substitute for the sentence.
A fourth: you already had the incident
If billing-export-03 actually leaked in August, the next record is a post-incident review, not a restaged tabletop of the same morning. Restaging lets the room rewrite what they would have done. The review records what they did, what the clocks actually were, and which follow-ups still have no owner. Write it in the free post-incident review template while the people who were on the bridge can still name the times. A tabletop of an incident you already lived is a second draft of history.
The question a tabletop is for
Who isolates prod-db-01 at 02:14 when payroll runs at 06:00. Who starts the Northwind 24-hour clock, and who holds the customer draft. Who files, through which portal, when someone reasonably believes. Those are decisions under a clock, with named seats. That is the tabletop.
Hang those injects on a scenario family we actually run. Capture attendance, decisions, and plan-says versus room-did in the free evidence template. It sits with the recovery-test and review formats in the template library. A sample packet shows the finished artifact, including the stall when a required seat is empty.
Even then, the session records that named people practised the call. It does not prove the isolate button works, that the mailer delivers, or that any control is tested. Keep technical proof on the technical path. The packet is evidence of an exercise, never a compliance verdict.
Five minutes to tell
Before you send the invite, name the question in one sentence. Then pick the instrument that can emit the artifact:
- A number from a system (measured RTO, newest row, alert fired): technical test, on its own day.
- A sentence the plan should already contain (who is incident commander, who approves the customer notice): self-check, this week, no meeting.
- An incident you already lived: post-incident review, not a restaged morning.
- A score or a pass: you want a grade. That is the wrong goal. The DART line still holds: the point is to see how the organisation decides under pressure, not to pass or fail the room.
- A named person choosing under a clock: tabletop. Book it. Put a timer on the screen. Write the decision down before the tiles disappear.
If you cannot name the question, you are booking a meeting. Wait until you can.
Bottom line: ask the question first, then book the instrument that can emit the artifact. A tabletop that answers a restore question is not a failed tabletop. It is a morning you cannot get back.