← All guides

Cybersecurity tabletop exercise: the 2026 guide

October 5, 2026 · 8 min read · Also in Spanish

What a tabletop exercise is, what SOC 2, ISO 27001, NIST, PCI DSS, NIS2 and DORA expect, and how to run one that leaves real evidence.

A tabletop exercise is a rehearsal of a cybersecurity incident in which the people who would have to respond make decisions about a realistic scenario, without touching any systems. It's the cheapest way to find the gap in your response plan before an attacker does.

This guide covers what it is, what the main frameworks and regulations expect, and how to run one that leaves real evidence instead of a feeling that "it went well".

What it is (and isn't)

A tabletop isn't a technical test: nobody restores backups or attacks the network. It's a rehearsal of decisions: who decides what, with what information, and how fast.

There are two broad formats:

  • Guided discussion. A facilitator presents the scenario and the group talks it through. It's easy to organise, but the outcome depends on who talks most, and it leaves little evidence.
  • Decision-based simulation. Each participant answers concrete questions for their role, against a time limit, and the situation evolves from what was decided. It takes a little more preparation and leaves a decision log.

For an executive team the second format is more useful: it forces decisions, not just opinions.

What frameworks and regulations expect

Almost every security framework expects an incident response plan that has been tested. A few examples:

  • PCI DSS v4.0, requirement 12.10.2: review and test the response plan at least once every 12 months.
  • ISO/IEC 27001 (Annex A 5.24 to 5.27): plan incident management, assess events, respond and learn from them. Auditors usually ask for evidence the plan was exercised.
  • NIST: CSF 2.0 organises response into the Respond and Recover functions; SP 800-61 covers incident handling and SP 800-84 how to design exercises.
  • SOC 2 (CC7.4 and CC7.5): respond to and recover from incidents; testing the plan is the usual way to show it.
  • NIS2: requires incident handling, business continuity and crisis management measures (Article 21), and training for management bodies (Article 20).
  • DORA (EU financial sector): requires ICT business continuity plans to be tested at least once a year.

An exercise doesn't certify anything on its own; your auditor decides what satisfies a requirement. But without a documented exercise, it's hard to show the plan works.

How to run one in eight steps

  1. Set the goal. One or two questions you want answered, such as "do we know who decides to stop operations?".
  2. Pick a scenario that's credible for your company. Ransomware, a data breach, deepfake fraud, a compromised supplier, or a DDoS outage with extortion. Use your systems and your regulators.
  3. Pick the participants. For an executive exercise: CEO, CISO, CFO, legal and communications. For a technical one, the response team.
  4. Write the events and the questions per role. Two to four events, each with concrete questions and realistic options. No option should be obviously right.
  5. Set the rules. No blame, a time limit per decision, and private decisions before discussion so nobody just follows the most senior person.
  6. Run it. Present each event, let people decide, reveal the answers and discuss the differences. Make the next situation depend on what was decided.
  7. Debrief. What worked, what didn't, which decision nobody wanted to make, and what information was missing.
  8. Write the report and the action plan. Every gap with an owner and a date.

What to measure

A good exercise leaves data, not just impressions:

  • Decision time per role and per event.
  • Missed or late decisions: questions nobody answered in time.
  • Disagreements: where executives chose differently without knowing it.
  • Impact: how each decision affected continuity, security, legal exposure, trust and recovery.
  • Control coverage: which framework controls were exercised, which showed a gap, and which weren't touched.

How often

At least once a year, and after big changes: a merger, a new critical system, a change in the executive team, or a real incident. Change the scenario every time; one they already know teaches nothing new.

Mistakes that waste the hour

  • A script that never changes. If decisions have no consequences, the group stops taking them seriously.
  • No executives. A tabletop with only IT doesn't test the decisions that matter.
  • No record. What wasn't written down with a time isn't evidence.
  • A report nobody reads. The debrief has to end in tasks with owners.

Critios is a platform for running this kind of exercise with your executive team: private decisions per role, revealed all at once; escalations that follow what the team chose; and a report with the decision log and control coverage for SOC 2, NIST, ISO 27001, PCI DSS, NIS2 and DORA. Try the demo or simulate your crises with us.

Run this exercise with your team, free.

We facilitate the first session with your executives and send you the report.