Cybersecurity Tabletop Exercises: Crisis Simulation

A cybersecurity tabletop exercise is a discussion-based crisis simulation: the team sits around a table (physical or virtual), a facilitator presents an incident scenario that unfolds in phases, and participants have to decide, out loud and against the clock, what they would do at each step. No production system is touched, no exploit is launched and no technical tool is tested. What gets tested are the decisions, the coordination and the response plans for a real attack. This article explains what a tabletop actually is, how it differs from Breach and Attack Simulation (BAS) and red team, how to design a ransomware or data-breach simulation, and which concrete testing duties NIS2 and DORA impose.

Key takeaways on cybersecurity tabletop exercises

• It is a discussion exercise, not an execution one: it tests decisions and plans, not systems.
• The reference frameworks are NIST SP 800-84 and CISA's CTEP packages, backed by ISO 22398.
• It runs at two levels: the crisis committee (management) and the technical incident response team.
• It differs from BAS (automated and technical) and red team (a live adversary) by being conversational.
• NIS2 and DORA both treat it as a mandatory piece of the testing programme and crisis management.

What a cybersecurity tabletop exercise is

A tabletop, or TTX (tabletop exercise), is a facilitator-led discussion exercise in which a group walks through a hypothetical incident scenario to validate its response procedures and its ability to make decisions under pressure. NIST SP 800-84 (Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities) classifies this kind of test as discussion-based, alongside seminars, workshops and games, and separates it from operations-based exercises (drills, functional and full-scale exercises), which do mobilise real systems and staff.

The point is that in a tabletop nothing is executed for real. When the facilitator announces that "the file server is encrypted and a ransom note has appeared", nobody restores a backup or isolates a host: the relevant participant explains what they would do, with which tool, who they would notify and within what deadline. That format has a huge advantage over technical tests: it lets you rehearse the most fragile part of any incident response, which is coordination between people, without any risk to operations and at low cost. Agencies such as CISA publish ready-to-use packages (the Cybersecurity Tabletop Exercise Packages, or CTEPs), and ISO 22398 offers guidelines to design and evaluate exercises systematically.

Tabletop, BAS and red team: three different tests

These three tests are often blurred together in commercial proposals, yet they answer different questions and do not replace one another.

Breach and Attack Simulation is an automated platform that fires techniques mapped to MITRE ATT&CK against the environment to check, continuously, whether the EDR, the SIEM and the controls detect and block them. It is a technical, repeatable test, but it says nothing about whether the CEO would know who to call. The red team, in turn, emulates a real attacker pursuing a specific goal (exfiltrating data, reaching a critical system) while evading detection. The tabletop competes with neither: it sits one layer above and tests the human and organisational muscle those tools never touch. The ideal is to combine them, and this is where a purple team approach fits well, because a good tabletop often grows out of the lessons of a prior offensive exercise.

The two levels: crisis committee and technical team

A serious simulation does not address the same audience across the whole organisation. It helps to distinguish two kinds of tabletop, with different goals and pace.

The executive tabletop brings the crisis committee together: general management, the CISO, legal, communications, the data protection officer (DPO) and, depending on the sector, compliance and operations. Here the discussion is not about which command to run but about business decisions: whether to pay a ransom, when and how to notify the authority and the affected parties, what to tell customers and the media, when to trigger the cyber-insurance policy and when to halt a production line. The goal is for those decisions to have been thought through before midnight on the day of the incident, not during it.

The technical tabletop targets the incident response team and the blue team. Here the script goes into detail: which evidence is captured first while respecting the order of volatility, how a segment is isolated without losing telemetry, which SIEM rules would confirm the scope, and how to coordinate with the DFIR provider. The best programmes chain both levels into the same scenario: the technical team works on containment while the committee decides on communication, and both discover, in real time, where the flow of information between them breaks.

How to design a simulation: scenario, injects and roles

Scenario and objectives

Everything starts by defining two or three measurable objectives (for example, "verify that the crisis committee is convened in under 60 minutes" or "check that the correct notification deadline is identified"). From there you build a believable scenario anchored in real threats. A good 2026 scenario is not generic: it starts from a plausible vector, such as the exploitation of a known vulnerability listed in CISA's KEV catalogue (think of a critical flaw in a perimeter device or a mail server, in the style of Microsoft Exchange's CVE-2026-42897), and escalates from there towards the objective of the exercise.

Injects and script

The scenario advances through injects: messages the facilitator introduces in phases to make the crisis evolve. Each inject forces a new decision. For technical injects it helps to map the attacker's simulated activity to MITRE ATT&CK (for example, T1486 Data Encrypted for Impact for the encryption or T1567 Exfiltration Over Web Service for double extortion), so the team relates what it sees to concrete tactics and techniques. A phased ransomware script might look like this:

• T+0 min. The SOC detects anomalous executions of vssadmin delete shadows across several endpoints.
• T+25 min. Ransom notes appear; an actor such as Akira or LockBit demands payment and threatens to publish data.
• T+60 min. A journalist contacts communications, claiming to hold a sample of the data.
• T+120 min. The primary backup is listed as encrypted; only one unverified offline copy remains.

Exercise roles

A well-built tabletop assigns clear roles: the facilitator drives the session and launches the injects, one or more evaluators observe and note against the objectives, a data collector logs times and decisions, and the participants respond from their real function. It is also worth rehearsing out-of-band communication, because in a real incident corporate email or Teams may be compromised, and the committee should not coordinate over the same channel the attacker controls.

Testing duties under NIS2 and DORA

Simulations have stopped being an optional good practice and become a regulatory expectation. NIS2 (Directive EU 2022/2555) requires, in Article 21, risk-management measures that expressly include incident handling, business continuity and crisis management. Exercises are the natural way to evidence that those measures exist and work, and a tabletop should rehearse the directive's notification deadlines in particular: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. Rehearsing that clock cold avoids discovering, on the day of the attack, that nobody knows who signs off the communication to the CSIRT.

In the financial sector, DORA (Regulation EU 2022/2554) is more explicit. Its digital operational resilience testing programme (Articles 24 to 27) includes, among the testing tools in Article 25, scenario-based testing and the testing of business continuity and response and recovery plans, in addition to threat-led penetration testing (TLPT) for significant entities at least every three years. A tabletop sits squarely in that part of the programme, and DORA insists that management be involved, which is exactly what an executive tabletop puts to the test. In Spain, the Esquema Nacional de Seguridad also provides for running exercises within its operational measures. All of this layer connects with the cyber resilience assessment, which is where the simulation results are translated into metrics.

Metrics and the after-action report

The value of a tabletop is not in the day of the exercise but in what happens afterwards. During the session you measure indicators such as time to convene the committee, time to the first containment decision, adherence to notification deadlines and the quality of decisions against a ransomware scenario. At the end you run a hot wash and, over the following days, write an After-Action Report with findings, plan gaps and improvement actions with owners and dates. Without that report and its follow-up, the simulation stays an anecdote.

Frequently asked questions

How does a tabletop differ from a functional exercise or a red team?

A tabletop is a discussion exercise: you talk about what you would do, without touching systems. A functional exercise mobilises real resources (for example, actually restoring a backup), and a red team executes a live attack against the environment to measure detection. The tabletop is the cheapest and the lowest-risk of the three, and it usually serves as the starting point before moving up to operations-based tests.

How often should a tabletop be run?

The usual recommendation is at least one or two per year at the executive level and more often at the technical level, plus repeating it whenever something relevant changes: a merger, a critical deployment, a change in the executive committee or a recent incident that leaves lessons worth rehearsing. Under DORA, the cadence is part of the documented testing programme.

Who should take part in a crisis simulation?

It depends on the level. The executive tabletop brings together management, the CISO, legal, communications and the DPO, because the decisions are business and compliance ones. The technical tabletop brings together the response team, the blue team and the DFIR provider. Mature programmes connect both in the same scenario to test the handover of information between the technical room and the committee.

Does a tabletop help meet NIS2 or DORA?

It is a necessary piece, but not sufficient on its own. It helps evidence the incident and crisis management measures NIS2 requires, and it fits the scenario-based testing in DORA, provided it is documented with objectives, participants, findings and an improvement plan. Compliance rests on the whole testing programme, not on an isolated exercise.

Next step

A tabletop only delivers value if the scenario is believable, the facilitator is demanding and the after-action report turns into concrete actions. At Secra we design crisis simulations tailored to your sector and threat profile, coordinate the executive and technical levels in the same scenario, and deliver an After-Action Report with metrics and a prioritised improvement plan. If you want to know how your organisation would respond to a ransomware today, tell us the context and we'll prepare the first exercise.