GuideRisk & Resilience
How to run a tabletop exercise that tests decisions, not slide decks
To run a tabletop exercise, set two or three objectives tied to your incident and continuity plans, invite the people who would actually make the decisions, and walk them through a realistic scenario with timed injects that force choices under pressure. Close with a hot wash in the room and an after-action report whose findings have owners and deadlines. The exercise tests decisions, roles and communication, not technical controls.
On this page
- What a tabletop can prove and what it cannot
- Matching the exercise format to what you need to learn
- Eight steps from objectives to a closed after-action report
- Four hypothetical scenario outlines and the decision each forces
- Regulatory-clock injects worth scripting
- Facilitation that keeps the room honest
- Why tabletop exercises fail to change anything
- Building an exercise program across the year
- Questions and answers
- Sources
What a tabletop can prove and what it cannot
A tabletop exercise is a facilitated discussion of a hypothetical incident. Participants talk through what they would do as the situation unfolds, using their real plans, contacts and authority. It reveals whether people know their roles, whether decision rights are clear, whether the plan matches reality and whether communication works across legal, communications, technology and the business.
It cannot prove that backups restore, that detection works or that an attacker would be stopped. Those need technical tests: restore drills, functional exercises and red team assessments. Treating a smooth tabletop as evidence of technical resilience is one of the commonest mistakes in exercise programs. ColdAI's risk practice treats scenario exercises and crisis simulations as part of its resilience testing step, alongside red team assessments for the technical side1.
Matching the exercise format to what you need to learn
- If
This is the team's first exercise, or the executive team is new.
ThenRun a discussion-based tabletop with a familiar scenario and generous pacing.
The aim is to surface role confusion and plan gaps without making people defensive.
- If
Plans are mature and the team has exercised before.
ThenAdd timed injects, incomplete information and a regulatory deadline.
Pressure exposes the decisions a calm walk-through hides.
- If
You need to know whether systems can actually be recovered.
ThenSchedule a functional exercise or restore test instead, and keep the tabletop for decisions.
Discussion cannot show whether a backup restores within the recovery objective.
- If
The audience is the board.
ThenKeep it short and strategic: risk appetite, ransom stance, disclosure and who speaks publicly.
Boards decide on principles; operational detail belongs to the response team.
Eight steps from objectives to a closed after-action report
Set objectives and success criteria
Write two or three objectives tied to specific plans, such as testing the escalation path from the security operations center to the executive team, and define what good looks like for each.
Choose participants
Invite decision-makers and their deputies: executives, legal, communications, IT and security, the business service owners and, where useful, a critical supplier.
Write the scenario
Base it on a plausible threat to a real business service. Keep it technically credible but not so detailed that discussion turns into troubleshooting.
Script timed injects
Each inject adds information or pressure: a journalist's call, a ransom note, a regulator's question, a supplier going silent. Map every inject to an objective.
Brief observers and a note-taker
Observers watch for specific behaviors tied to the objectives; the note-taker records decisions, timings and open questions verbatim.
Facilitate the session
Set ground rules, introduce injects on schedule, ask who decides and on what basis, and park technical rabbit holes for later.
Run the hot wash
Before people leave, ask what went well, what was unclear and what they would change. First impressions fade within a day.
Write and track the after-action report
Turn observations into findings, each with an owner, a deadline and a link to the plan or control it changes, and report progress to the sponsor.
Four hypothetical scenario outlines and the decision each forces
All four are invented for illustration. Adapt them to your own services and threats.
| Scenario | Opening situation | Escalating inject | Decision under test |
|---|---|---|---|
| Ransomware on the order system | Orders stop; screens show a ransom note | Attackers claim stolen customer data and set a deadline | Pay or not, who decides, and what to tell customers |
| Deepfake voice payment fraud | Finance receives a call in the CFO's voice approving an urgent transfer | A second call pressures the clerk to bypass the callback check | Whether controls hold, and how fraud is escalated and reported |
| AI agent acting outside its permissions | An operations agent issues refunds far above policy | Social media notices and posts screenshots | Who can switch the agent off, and how to reverse its actions |
| Cloud provider regional outage | Core applications in one region become unavailable | The provider gives no restoration estimate | Fail over, run manually or wait, and what customers are told |
For the AI agent scenario, use your AI incident response plan as the plan under test.
Regulatory-clock injects worth scripting
These force notification decisions while facts are incomplete, which is exactly when real teams struggle.
Facilitation that keeps the room honest
State at the start that the exercise is no-fault: it tests the plan and the organization, not individuals. Then hold people to real behavior. When someone says "we would call the lawyers", ask who exactly, using which number, and what they would ask. When the most senior person answers every question, redirect to the person whose role it actually is.
Pace the injects so that the room has to decide before it feels ready, but not so fast that discussion collapses. Keep a visible parking lot for technical questions and side issues. Observers should not join the discussion; their value is in noticing who hesitated, where decisions stalled and which assumptions nobody challenged.
Why tabletop exercises fail to change anything
Scenario too comfortable
Early signalParticipants agree with the plan at every step and finish early.
MitigationAdd incomplete information, a deputy instead of the usual decision-maker, or a conflicting regulatory clock.
Exercise as theater
Early signalAnswers are rehearsed and the scenario was shared in advance.
MitigationShare objectives, not injects, and use an outside or cross-team facilitator.
Findings without owners
Early signalThe same gaps appear in next year's exercise.
MitigationAssign every finding an owner and deadline, and open the next exercise by reviewing them.
Technical drift
Early signalHalf the session is spent debating log sources.
MitigationPark technical questions and schedule a separate functional test.
Building an exercise program across the year
One exercise is a snapshot. A program builds capability: start with discussion-based tabletops, add timed injects and suppliers as plans mature, and connect them to functional and technical tests. Rotate scenarios across threats and business services, and include AI-era events such as synthetic media fraud and autonomous agent failures, which the hub's insight on crisis management in an AI-accelerated world argues are already changing how crises unfold1.
NIST SP 800-84 sets out how to design, develop, conduct and evaluate test, training and exercise events for IT plans2. CISA's Tabletop Exercise Packages provide customizable scenarios, discussion questions and templates, including an after-action report, that are useful starting points even outside the US public sector3.
Questions and answers
How long should a cyber tabletop exercise last?
Long enough to reach the decisions your objectives target, and no longer. Executive sessions often work best as a focused half day or less, because senior attention fades and their decisions are few but weighty. Operational team exercises can run longer and go deeper. Planning takes far more time than the session itself, so budget for scenario writing, inject scripting and the after-action report.
How often should we run tabletop exercises?
Run them regularly enough that lessons carry over and new staff are exercised, and after significant changes such as a new executive team, a major system migration, an acquisition or a new regulatory obligation. Many organizations combine a recurring executive exercise with more frequent operational ones. Regulated entities should also check whether their sector rules or certifications set specific testing expectations.
Should the board take part in a tabletop exercise?
Yes, but in a session designed for its role. The board decides on principles such as ransom stance, disclosure, risk appetite and who represents the company publicly, and should understand how management will escalate to it. A short, strategic exercise works better than inserting directors into an operational session, where their presence can inhibit open discussion.
When is an outside facilitator worth it?
When the internal facilitator would be exercising their own plan, when senior participants outrank everyone on the security team, or when you want scenarios informed by incidents elsewhere. An outside facilitator can challenge executives more freely and observe without a stake in the outcome. Internal facilitators work well for frequent operational exercises once the format is established.
Sources
- Risk and Resilience capability: resilience testing and crisis management insight — ColdAI
- NIST SP 800-84: Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities — National Institute of Standards and Technology · checked 10 October 2026
- CISA Tabletop Exercise Packages — Cybersecurity and Infrastructure Security Agency · checked 10 October 2026
- Directive (EU) 2022/2555 (NIS2 Directive), Article 23 — EUR-Lex · checked 10 October 2026
- Regulation (EU) 2016/679 (General Data Protection Regulation), Article 33 — EUR-Lex · checked 10 October 2026