Running tabletop exercises that find real gaps
A good tabletop is uncomfortable. If everyone leaves feeling reassured, the scenario was too kind or the facilitator flinched at the decision that mattered.
By Piotr Zenon Żabrowski · Published · Updated
Design
01Pick a plausible scenario
Drawn from your own architecture and threat model. Generic ransomware stories produce generic answers.
02Set the objective
One or two decisions you want to test — for example, who authorises taking a customer-facing service offline.
03Write injects, not a narrative
Timed information drops, including at least one that is wrong, because real incidents include bad information.
04Invite the deciders
Legal, communications, a business owner and an executive. A technical-only tabletop tests the wrong layer.
05Facilitate for decisions
Keep asking who decides, by when, and on what evidence. Do not accept 'we would investigate'.
06Capture gaps as owned actions
Each gap leaves the room with an owner and a date, or the exercise was theatre.
The gaps this reliably finds
- Nobody knows who can authorise taking production offline.
- The notification clock starts later than the regulator would accept.
- Contact details and out-of-band communications are stale or unavailable.
- Backup restoration has never been timed against the stated recovery objective.
- Provider and vendor escalation paths are unknown or unowned.
- Evidence would be destroyed by the first containment action people propose.
- The AI-specific playbook (if one exists) has never been through a scenario, so decisions like 'who can disable a customer-facing agent' get invented live.
Frequently asked questions
How often?
Twice a year for the core team, annually with executives, plus a short one after any significant architecture change.
Should it be announced?
Tabletops, yes — the goal is learning, not surprise. Unannounced testing belongs to technical exercises, not decision exercises.
How does this fit regulatory testing requirements?
It closes the gap between an existing test-and-exercise programme (structured around something like NIST SP 800-84) and a regulatory requirement to test resilience under DORA or NIS2. A tabletop on its own satisfies neither regime fully — DORA expects a broader digital operational resilience testing programme, and NIS2 expects tested incident-handling procedures — but a well-run tabletop is usually the cheapest evidence that the procedures behind both actually work under pressure, and its outputs feed directly into the required testing record.
Related
Incident response
IR lifecycle aligned to NIST SP 800-61r3 and CSF 2.0, cloud and identity playbooks, detection coverage and post-incident learning that changes controls.
Incident readiness
Incident response plan review, cloud and identity playbooks, tabletop exercises and detection coverage assessment.
IR playbooks that work
A playbook structure built for 03:00 use: decision points, containment options with trade-offs, evidence steps and the exact notification clocks under DORA, NIS2 and GDPR.
Tabletop facilitation guide
Printable facilitation guide for a 90-minute security tabletop exercise: preparation, injects, decision probes and follow-up.
CISO advisory
Security leadership support for organisations without a full-time CISO: strategy, roadmap, board reporting and vendor decisions.
Deleting model data
Why trained data is hard to remove from LLM weights, and how incident responders should contain, replace and test an affected model.