What Is a Tabletop Exercise? The Complete Guide
What is a tabletop exercise? A clear definition, how a cyber TTX runs before, during and after, who attends, what it tests, formats, frequency and pitfalls.
A tabletop exercise (TTX) is a facilitated, discussion-based session in which the people responsible for handling a crisis talk through a realistic scenario, step by step, to test their plans, roles and decisions. Nothing is attacked and no system is touched. A cyber tabletop exercise applies the same format to an incident such as ransomware, a data breach or a business email compromise.
The point is not to win. The point is to find the gaps (unclear authority, missing contacts, assumptions nobody has checked) while finding them is cheap, and to fix them before a real incident finds them for you. This guide explains how a tabletop works from first planning conversation to improvement plan, and links to deeper guides and ready-to-run scenarios on this site.
Tabletop exercise meaning, in one paragraph
The name comes from military and emergency-management practice, where planners gathered around a table with a map and moved pieces through a scenario. Today the "table" might be a meeting room, a video call or a set of phones, but the core is unchanged: a facilitator presents a situation, releases new information in stages called injects, and asks the group what they would do. A scribe records decisions and open questions. Afterwards the group holds a hotwash, and the organiser writes an after-action report with an improvement plan. See the short glossary definition if you need a one-liner for a slide.
How a tabletop exercise works: before, during and after
Before: planning (typically three to eight weeks)
- Agree the purpose with a sponsor. Why now, who the exercise is for, and what success means. Success is "we found and fixed gaps", not "we looked good".
- Write three to five objectives. Specific and observable, for example "confirm who approves taking the ERP system offline and on what criteria".
- Choose a scenario that serves the objectives. Plausible for your organisation beats dramatic. The scenario library is a good starting point.
- Build the injects and the MSEL, the master scenario events list that sequences what happens, when and to whom. The guide to designing injects covers this in depth.
- Invite players and staff, send a short pre-read (plan, ground rules, logistics, but not the scenario), and do a dry run.
The full planning timeline is in how to run a tabletop exercise.
During: the session itself
A typical two-and-a-half-hour session looks like this:
| Segment | What happens |
|---|---|
| Welcome and ground rules | No-fault environment, not a test of individuals, use your real plans, the scenario is artificial but assume it is real |
| Starting situation | Facilitator reads the opening scenario; players confirm their roles |
| Module 1: detection and escalation | Two or three injects; the group decides severity and who to call |
| Module 2: containment and decisions | Injects force trade-offs: shut down or keep running, involve law enforcement or not |
| Module 3: communications and recovery | Media, regulators, customers, restoration priorities |
| Hotwash | What worked, what did not, top fixes |
The facilitator's job is to keep discussion moving, draw out quieter voices, and push past "we'd handle it" to "who, how, with what". The facilitation guide goes into technique.
After: turning talk into change
Within one or two weeks, the organiser circulates a draft after-action report: strengths, areas for improvement, and recommendations linked to the objectives. Each recommendation becomes a line in an improvement plan with an owner, a due date and a way to verify it is done. The next exercise re-tests the weak spots. An exercise without this step is theatre.
Who is in the room
The roles guide covers each role in detail. In summary:
| Role | Responsibility |
|---|---|
| Sponsor | Senior owner who protects time and ensures findings are acted on |
| Facilitator | Runs the room and the clock; releases injects; asks the questions |
| Players | People with real decision rights: IR lead, IT operations, security, legal, privacy, communications, business owners, executives |
| Scribe | Records decisions, times, open questions and gaps |
| Evaluators (optional) | Observe against objectives and capability targets |
| White cell / controllers (optional) | Play outside parties: the insurer, a regulator, a journalist, the attacker |
Eight to fifteen players is a practical range for one room. Invite deputies: incidents happen during holidays, and deputies often learn the most.
What a tabletop tests, and what it does not
Being clear about scope avoids disappointment and misleading conclusions.
A tabletop tests:
- Whether roles, responsibilities and decision rights are clear, including out of hours.
- Whether escalation paths and contact lists actually work.
- How technical, legal, communications and business teams coordinate and hand off.
- Whether plans and playbooks are usable under pressure, or only readable in calm conditions.
- How the group handles hard decisions: taking production offline, notifying regulators, responding to extortion.
- Awareness of external dependencies: insurers, incident-response retainers, cloud providers, suppliers.
A tabletop does not test:
- Whether your technical controls stop an attacker. That is the job of penetration testing and red teaming.
- Whether a restore actually completes in the time people claim. Only a real restore test tells you that.
- Individual performance. Grading people makes them stop being candid; evaluate capabilities and plans instead, as described in scoring tabletop exercises.
A good tabletop often generates actions to run those other tests: "we assumed a four-hour restore; nobody has timed one" is a finding that leads to a restore drill.
Discussion-based vs operations-based exercises (HSEEP)
The US Homeland Security Exercise and Evaluation Program (HSEEP), maintained by FEMA, sorts exercises into two families. NIST SP 800-84, the NIST guide to test, training and exercise programmes for IT plans, uses a compatible view.
| Family | Types | What participants do | Where a cyber tabletop fits |
|---|---|---|---|
| Discussion-based | Seminars, workshops, tabletop exercises, games | Talk through plans, policies and decisions | Here: the tabletop is the core discussion-based exercise |
| Operations-based | Drills, functional exercises, full-scale exercises | Perform real actions, often in real time with real systems | The next step once plans and roles are stable |
Discussion-based exercises are cheaper, safer and faster to organise. They expose organisational gaps that would make an operations-based exercise chaotic. Most programmes start with tabletops and add drills and functional exercises as they mature.
Common tabletop formats
| Format | Audience | Focus | Typical length |
|---|---|---|---|
| Technical | SOC, IR, IT operations, cloud and platform engineers | Triage, containment options, evidence, credential resets, restore sequencing | 2–4 hours |
| Executive | CEO, COO, CFO, general counsel, communications, sometimes the board | Business impact, regulatory clocks, public statements, extortion decisions | 90 minutes to 2 hours |
| Cross-functional | Mixed technical and business leaders | Hand-offs between teams, decision rights, communications flow | 2.5–3 hours |
| Sector or regulatory | Teams subject to specific rules (health, finance, critical infrastructure) | Notification duties, patient safety, operational resilience | 2–3 hours |
Mixed groups are the most revealing, because most failures happen at hand-offs, but they are harder to facilitate. A common approach is to compress the technical opening into a briefing for executives ("at 23:30 the IR lead declared a Severity 1 incident") and spend the time on decisions only they can make.
Delivery can be in person, remote or hybrid. In-person sessions produce better discussion; remote sessions are easier to schedule and closer to how many real incidents are handled. If you run remote or hybrid, the site's free live exercise runner lets the facilitator release injects to players' phones with a join code, collect decisions and export the after-action report.
Example scenarios to start with
Pick a scenario that fits your risks and your audience. All of these have full, ready-to-run pages:
- First exercise, mixed audience: business email compromise or phishing and session hijacking.
- Crisis leadership: double-extortion ransomware.
- Legal and privacy: data breach and regulatory notification.
- Cloud teams: cloud access key leak or identity provider takeover.
- Suppliers: software supply-chain compromise or third-party vendor breach.
- Sector-specific: hospital ransomware or an OT/ICS plant intrusion.
For about twenty scenario ideas with the decision each one forces, see tabletop exercise examples.
Benefits of tabletop exercises
- Cheap gap-finding. The main cost is a few hours of people's time. The findings (a contact list stored on the server that just got encrypted, nobody authorised to shut down production at night) would be expensive to discover during a real incident.
- Clear decision rights. Exercises force the question "who decides?" and usually produce a written answer.
- Muscle memory for the plan. People who have walked through the plan once find it faster the second time, especially under pressure.
- Relationships before the crisis. Legal, communications and the SOC meet each other in a calm setting instead of on a midnight bridge.
- Evidence for regulators, auditors and insurers. Many frameworks expect incident response and continuity capabilities to be tested. PCI DSS v4.0, for example, requires the incident-response plan to be tested at least once every 12 months, NIS2 asks for policies and procedures to assess the effectiveness of risk-management measures, which include incident handling, and DORA requires financial entities to test their ICT business continuity plans. A documented exercise with an after-action report is practical evidence.
- Better plans. Plans that have been exercised get shorter, clearer and more honest.
How long and how often
How long. Most cyber tabletops run two to four hours including a 20–30 minute hotwash. Executive sessions work best at 90 minutes to two hours with a tightly scoped scenario. Under an hour rarely leaves room for real decisions; beyond four hours, attention drops.
How often. A reasonable baseline:
| Audience | Suggested frequency |
|---|---|
| Core incident-response team | Quarterly, rotating scenarios |
| Cross-functional crisis team | Twice a year |
| Executive team or board | Once or twice a year |
| After a material change | Within a few months of a new plan, acquisition, major migration or new regulatory obligation |
Treat frequency as a programme decision rather than a one-off. The follow-up of one exercise should feed the design of the next.
Common mistakes
- Scenario first, objectives never. The exercise becomes an entertaining story that tests nothing specific. Write objectives first.
- Too many injects. Eight to ten well-chosen injects beat twenty rushed ones. Discussion is where the value is.
- Missing decision-makers. If the person who can authorise a shutdown is absent, the key decision is deferred and never tested.
- Fighting the scenario. "That could never happen here" is often right about a detail and wrong about the point. Fix details in planning with a technical reviewer so the scenario survives contact with experts.
- Grading individuals. People stop being honest, and honesty is the product.
- Asking closed questions. "Would you call legal?" gets "yes". "Who calls legal, how, and what do you tell them?" gets a real answer. See the tabletop exercise questions bank.
- No follow-up. Findings without owners and dates change nothing.
- Running the same scenario forever. Rotate threats and audiences so the whole response is exercised over a year.
Getting started this month
- Pick one sponsor and one audience.
- Write three objectives based on your biggest worry or a recent near-miss.
- Choose a foundational scenario from the library and tailor system names and teams.
- Use the tabletop exercise template to lay out objectives, roles, agenda and the MSEL.
- Book two and a half hours, run it, hold the hotwash, and publish the improvement plan within two weeks.
Related
Frequently asked questions
What is the purpose of a tabletop exercise?
The purpose is to test plans, decision rights and coordination before a real incident does it for you. A facilitator walks the people who would handle a crisis through a realistic scenario, and the group discusses what it would do. The output is a list of gaps, such as unclear authority, missing contacts or untested assumptions, turned into an improvement plan with owners and dates.
What does TTX stand for?
TTX stands for tabletop exercise. The abbreviation is common in emergency management, the military and cybersecurity. A cyber TTX is a tabletop exercise built around a cyber incident, such as ransomware, a data breach or a compromised identity provider, and is usually run to test an incident-response plan and the crisis team that uses it.
Who should participate in a cyber tabletop exercise?
Invite the people who hold real decision rights during an incident: the incident-response lead, IT operations, security, legal or privacy, communications, and the business owner of the affected service. Executive sessions add the CEO, COO or CFO. Add a facilitator, a scribe and optionally evaluators. Eight to fifteen players is a practical range for one room.
Is a tabletop exercise a drill?
No. Under HSEEP, a tabletop is a discussion-based exercise: participants talk through their response and nothing is actually done to systems or people. A drill is operations-based: participants perform a specific task for real, such as restoring a server from backup or calling everyone on the contact list. Both are useful, and tabletops usually come first.