How to run a tabletop exercise that finds real problems

A tabletop exercise is a facilitated discussion of a realistic incident, run to find out where your plan breaks before an attacker does. Most organisations run one because a framework requires evidence of testing - and produce an exercise where everyone agrees the plan works. That satisfies the auditor and teaches you nothing.

What a good exercise is trying to find

• Decisions nobody owns. Who authorises taking production offline? Who approves paying a ransom? Who speaks to the regulator?
• Information that does not exist when you need it - an out-of-date asset inventory, no data flow map, unknown backup age.
• Contact failures. Out-of-hours numbers, escalation to executives, reaching your cyber insurer or external counsel.
• Assumptions that do not hold - "we would restore from backup" when nobody has tested a restore of that system.
• Notification clocks that cannot realistically be met with the current decision path.

Who should be in the room

An exercise with only the security team tests only the security team. Include:

• Incident commander and technical responders
• Executive decision-maker with real authority
• Legal and privacy
• Communications
• Business or service owner for the affected system
• HR, where the scenario involves an insider
• A scribe whose only job is the timeline

The single most valuable participant is the executive who can actually authorise downtime or disclosure. Without them, the exercise stops at "we would escalate" - which is exactly the point where real incidents stall.

Scenario design

Pick something plausible for your environment and uncomfortable enough to matter:

• Ransomware encrypting a core system, with backups of uncertain age.
• Credential compromise of an administrator, discovered a week after the fact.
• A supplier breach where your data was in their environment.
• Personal data exposed publicly, starting the notification clock.
• An insider exfiltrating data before resigning.
• A vulnerability in your product being actively exploited against customers.

Avoid the sophisticated-nation-state scenario. It produces fatalism rather than actionable findings.

Use injects to create pressure

Release information progressively rather than describing the whole incident up front. Real incidents unfold with partial, sometimes wrong, information:

1. T+0 - an alert, ambiguous. Is this an incident?
2. T+30 min - a second system affected. Severity changes.
3. T+2 hrs - evidence of data access. Notification clocks start.
4. T+4 hrs - a journalist calls. Who speaks?
5. T+8 hrs - the initial technical assessment turns out to be wrong.

That last inject is the most useful and the most neglected. Teams rarely rehearse revising a conclusion under pressure.

Facilitation that works

• Ask "what do you do now" rather than "what does the plan say".
• Require specifics - names, systems, timeframes - not "we would engage the relevant team".
• Let silences sit. The pause when nobody knows who decides is the finding.
• Do not rescue participants. Discomfort is the product.
• Keep it blameless - the plan is on trial, not the people.

Records that count as evidence

Auditors want proof the exercise happened and drove change:

• Date, duration, scenario summary and participant list with roles.
• The timeline of decisions taken.
• Gaps identified - the most important section. An exercise reporting no gaps looks like theatre.
• Actions with owners and due dates.
• Evidence those actions were completed - and ideally retested in the next exercise.

Key takeaways

• An exercise with no findings was not testing anything.
• Include the executive who can actually authorise downtime or disclosure.
• Use staged injects, including one that invalidates an earlier conclusion.
• Record gaps and completed actions - that is what makes it evidence.