2 November 2026 · 12 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
Cybersecurity tabletop exercise: how to design one, who to invite, which scenarios to run and what to do with the results
A cybersecurity tabletop exercise walks your leadership and response teams through a realistic incident, in a meeting room, without touching a single system. Done well, it exposes the decisions nobody has made yet: who can authorise a shutdown, when counsel is called, what the SEC disclosure clock means for you. This guide covers design, participants, six scenarios, how tabletops compare with technical exercises, the after-action report, regulatory hooks and cadence.
What a cybersecurity tabletop exercise is
A cybersecurity tabletop exercise is a facilitated, discussion-based simulation in which the people who would manage a real incident work through a scripted scenario, step by step, and decide out loud what they would do. No systems are attacked, nothing is taken offline and no production data is touched. The facilitator presents the situation, releases new information (injects) at planned moments, and asks the participants to make the decisions the scenario forces: isolate or observe, pay or refuse, notify now or wait for facts, who speaks to customers and in what words.
The exercise tests the organisation, not the technology. Incident response plans, crisis communication plans, legal escalation paths, insurance notification clauses and executive authority are all paper until somebody has to use them under time pressure. A tabletop is the lowest-effort way to find out which of them work, which contradict each other, and which assume a person or a system that is not actually available at 2 a.m. on a Saturday. NIST SP 800-84, the US guide to test, training and exercise programmes, distinguishes tabletop exercises (discussion-based) from functional and full-scale exercises (operations-based); the discussion format is the point, not a limitation.
Tabletops come in two grades. An executive tabletop runs two to three hours with the leadership team on strategic decisions, communication and regulatory obligations. A technical or operational tabletop runs with the security, IT and continuity teams and goes deeper into detection, containment, recovery sequencing and evidence handling. Most organisations need both, sharing one scenario so that decisions made at one table are tested at the other.
Who sits at the table
The most common design failure is a room full of security staff. An incident is a business event; the exercise must include the people who will own its consequences.
Executive sponsor and decision-makers
The CEO or a delegated executive with authority to approve shutdowns, ransom decisions, public statements and spending. If the person who would actually decide is not in the room, the exercise produces decisions nobody can act on.
Security and IT leadership
The CISO or security lead, the head of IT or infrastructure, and the people who run identity, endpoints, network and backups. They supply the realism: what can be isolated, how long a restore takes, what the detection stack would actually have seen. An MDR provider's escalation contact should attend where one is part of the response.
Legal, privacy and outside counsel
The general counsel or legal lead, the data protection or privacy officer, and ideally the external breach counsel who would be engaged in a real incident. They own privilege, regulatory notification analysis (SEC, state breach laws, HIPAA, GDPR, NIS2), contractual notice obligations and law-enforcement contact.
Communications
Corporate communications and, where relevant, investor relations and customer success leadership. They draft the holding statement during the exercise, decide on internal messaging and test whether the approved spokesperson and channels exist. Communication failures are the most visible and least rehearsed part of a real incident.
HR and business owners
HR for insider and employee-impact scenarios and for workforce communication; the owners of the business processes the scenario hits (finance for wire fraud, operations for OT disruption, sales for customer-facing outages). They turn 'systems are down' into 'this is what stops, and this is what it costs per hour'.
Finance, insurer and retained responders
The CFO or treasurer for payment authority and liquidity, the cyber insurance broker or carrier contact for notification requirements and panel constraints, and the incident response retainer provider who would be on the first call. Their presence tests whether contract terms and plan agree.
How to design a tabletop exercise
A good exercise is designed backwards from the decisions you want to test. These seven elements, in order, turn an idea into a runnable session.
1. Objectives
Write down three to five things the exercise must answer: can we decide on ransom payment within the first hours; do we know our SEC materiality process; can we notify our regulator within 72 hours with the facts we would actually have. An exercise without written objectives produces a pleasant conversation and no findings.
2. Scenario
Choose a scenario that is plausible for your sector, your technology and your current threat intelligence, and that forces the decisions in your objectives. Scenarios drawn from your own red team or penetration test findings are the most credible, because nobody at the table can say 'that could not happen here'.
3. Injects and timeline
Break the scenario into phases (detection, escalation, impact, external pressure, recovery) and prepare the information releases that move it forward: a ransom note, a journalist's email, a regulator's call, a backup that turns out to be encrypted. Hold a few in reserve for when the discussion settles too comfortably.
4. Roles and scope
Define who plays themselves, who plays external parties (regulator, attacker, journalist, insurer) and what is out of scope. Decide whether participants may consult real plans and contact lists during the session: in a first exercise, allowing them shows whether the documents are usable; in later exercises, withholding them tests memory.
5. Facilitator and observers
The facilitator keeps time, releases injects, prevents the group from solving the scenario by assumption and probes decisions with 'who exactly does that, and how do you know?'. An external facilitator with incident experience is more credible to executives and free of internal politics. Separate observers record decisions and gaps.
6. Timing and format
Executive tabletops run two to three hours; technical tabletops half a day. Longer sessions lose attention, shorter ones never reach the hard decisions. Distributed teams can run well remotely if injects arrive through the channels the team would actually use in an incident.
7. Evaluation criteria
Before the session, define what good looks like for each objective: a decision made within the scenario time, the right person consulted, the regulatory clock correctly identified. Evaluation against written criteria is what turns a discussion into evidence an auditor, insurer or board can use.
Six tabletop exercise scenarios
Each outline is a starting point to tailor to your environment. The value lies in the decisions it forces, listed with each one.
Ransomware with data theft
An affiliate group has encrypted file servers and virtual infrastructure after exfiltrating data, and a deadline is running. Decisions forced: isolate or keep critical services running, engage the retainer and counsel, whether and how to communicate with the attacker, the payment position, restoration priority when backups are partly affected, and SEC and customer notification timing. For the technical side of this scenario, see our ransomware readiness assessment guide.
Business email compromise and wire fraud
Finance has released a six-figure payment to a changed supplier bank account after a convincing email thread; the fraud surfaces when the real supplier chases the invoice. Decisions forced: bank recall procedures and the hours that matter, whether the mailbox compromise is still live, who tells the supplier and the insurer, and whether other invoices were altered.
Supply-chain compromise
A software vendor announces that a signed update shipped with a backdoor, and your organisation installed it on systems that hold customer data. Decisions forced: whether to disconnect a tool the business depends on, how to establish what the backdoor touched, obligations toward your own customers, and whether the event is material for disclosure.
Insider data theft
A departing engineer has copied source code and customer lists to personal storage over several weeks; HR flags it after the resignation. Decisions forced: evidence preservation and privilege, the balance between employment law and investigation, when to involve law enforcement, customer notification analysis, and what the case reveals about offboarding and data-loss monitoring.
Cloud credential exposure
A long-lived access key for your production cloud account was committed to a public repository and has been used from an unfamiliar region. Decisions forced: rotate and risk an outage or investigate first, how to scope what the key could reach, whether logs exist to prove what was accessed, and how to communicate with customers while the facts are still incomplete.
OT or operational disruption
Malware on the corporate network has crossed into the operational environment; a plant, logistics hub or building system is behaving unpredictably and safety is in question. Decisions forced: safe shutdown versus continued operation, who has authority over the plant, when to involve the safety regulator, and whether IT and OT teams share a command structure at all.
Tabletop vs technical simulation vs red team vs full-scale exercise
Each format answers a different question. Organisations that use only one of them develop blind spots in the others. For the specific comparison between a tabletop and a penetration test, our ransomware readiness assessment guide covers it.
| Dimension | Tabletop exercise | Technical simulation (purple team, attack simulation) | Red team engagement | Full-scale or functional exercise |
|---|---|---|---|---|
| What it tests | Decisions, roles, communication, plan quality | Whether specific detections and controls fire against known techniques | Whether a realistic adversary reaches an objective undetected | Whether people, process and technology respond together in real time |
| Systems touched | None | Controlled execution in production or a mirror, with the blue team watching | Production, covertly, within agreed rules of engagement | Production or a representative environment, with real actions taken |
| Participants | Executives, legal, comms, security and IT leadership | Security operations, detection engineering, red team | Red team and a small trusted group; the blue team is not informed | Everyone with an incident role, often including external parties |
| Realism of pressure | Low; discussion-based | Medium; technical, not organisational | High for the defenders; none for executives | Highest; closest to a real incident |
| Output | Decision log, gaps, after-action report | Detection tuning log, coverage against MITRE ATT&CK | Attack narrative, detection timeline, remediation plan | Full after-action report across all functions |
| Typical cadence | Annually for executives; quarterly for technical teams | Quarterly or after major detection changes | Annually or every 18 months | Every one to two years, often regulator-driven |
What to capture, and the after-action report
The exercise is worth exactly as much as the report that follows it. Observers should record these items during the session; the after-action report organises them into owned actions.
- A decision log: every decision, by whom, at what scenario time, on what information, including the decisions the group avoided or deferred
- Deviations from the written plan, with the reason: the plan was wrong, unknown, unavailable or ignored
- Gaps by function: missing contacts, missing authority, missing data (nobody could say which systems hold regulated data)
- Communication artefacts produced during the exercise: holding statement, internal message, customer notice, assessed against tone and legal constraints
- The regulatory clock analysis: which obligations the group identified, which it missed, and how long it took to reach a notification decision
- Third-party dependencies exposed: insurer, retainer provider, cloud or software vendor, MDR provider, law enforcement
- Improvement actions with an owner, a deadline and the objective they serve, tracked to closure before the next exercise
- An evidence package: agenda, scenario, participant list, evaluation against the criteria and sign-off, filed where auditor, insurer or regulator can find it
Regulatory hooks: why tabletops are now expected
In the United States the pressure is explicit. The SEC's cybersecurity disclosure rules, adopted in July 2023, require public companies to disclose a material cybersecurity incident on Form 8-K Item 1.05 within four business days of determining materiality, and to describe their risk management and governance in annual reports under Regulation S-K Item 106. A tabletop is the only realistic way to rehearse that materiality determination. NYDFS 23 NYCRR 500.16 requires covered financial entities to maintain incident response and business continuity plans and to test them at least annually with the staff and management critical to the response. HIPAA's contingency plan standard includes testing and revision procedures (45 CFR 164.308(a)(7)(ii)(D)), PCI DSS v4.0.1 Requirement 12.10.2 requires the incident response plan to be tested at least once every twelve months and CMMC 2.0 Level 2 includes testing the incident response capability (NIST SP 800-171 3.6.3).
CISA publishes Tabletop Exercise Packages (CTEPs) free of charge: scenario documents, facilitator guides and discussion questions across cyber, physical and converged scenarios, including ransomware, insider threat and industrial control systems. They are a sound starting point for a first exercise. NIST SP 800-61 Rev. 3 (2025) aligns incident response with the Cybersecurity Framework 2.0, and NIST SP 800-84 remains the reference for building an exercise programme.
In the EU, NIS2 Article 21(2)(c) requires essential and important entities to have business continuity and crisis management measures, and Article 21(2)(g) requires basic cyber hygiene practices and training; a documented tabletop programme is the most direct evidence of both. DORA Article 11 requires financial entities to test their ICT business continuity plans and response and recovery plans at least yearly, including cyber-attack scenarios, and to maintain a crisis management function with communication plans; Article 25 lists scenario-based tests among the tools of the resilience testing programme. ISO 27001:2022 Annex A controls 5.29 and 5.30 cover ICT readiness for business continuity. One exercise with a well-chosen scenario produces evidence for all of these, provided the report maps findings to the clause.
Cadence, and how HackersHub facilitates tabletop exercises
The working cadence is an executive tabletop once a year, a technical or operational tabletop each quarter or after any major change (new ERP, cloud migration, acquisition, new MDR provider), and a targeted session after every real incident to test whether the lessons were actually absorbed. Rotate scenarios; the business email compromise and insider scenarios usually surface a different set of gaps than ransomware. Track improvement actions between exercises and open the next one with their status; a tabletop programme whose actions are never closed is theatre.
HackersHub designs and facilitates tabletop exercises as part of its red teaming and incident response support work. Scenarios are built from what our red teams and penetration testers find in enterprise environments, so the injects reflect techniques that work against organisations like yours rather than generic headlines. Our facilitators have seen the real version of these incidents from the offensive and the response side, which makes the probing questions credible to an executive audience. The exercise ends with an after-action report that maps every finding to the clauses above and to owned actions, and can be followed by technical validation (a red team, a ransomware readiness assessment or a purple-team session) that proves the fixes hold. Delivery is remote or on site across the EU and the US from Amsterdam, Netherlands.
Frequently asked questions
Related services and guides
- Red teaming services by HackersHub
- Ransomware readiness assessment: what we test
- Incident response retainer: what it covers
- Red team vs blue team: roles and exercises
- What is red teaming? How a red team exercise works
- Purple teaming: how a purple team exercise works
- Managed detection and response
- NIS2 compliance and penetration testing
- DORA penetration testing and TLPT explained
Ready to find out how your leadership team decides under pressure?
HackersHub designs and facilitates tabletop exercises built from real offensive findings, then validates the fixes with red teaming when you are ready. Talk to an expert.