How to Run a Cyber Tabletop Exercise: A Planning Guide

A tabletop exercise (TTX) is a structured conversation about a bad day that has not happened yet. A facilitator walks a group of decision-makers through a realistic incident, releasing new information in stages, and the group talks through what they would do, who they would call, and what they would need. Nothing is attacked, no system is touched, and nobody is being tested. What gets tested is the plan, the process, and the coordination between the people who will actually be on the call when it happens for real.

This guide covers the whole lifecycle of a single exercise, from the first conversation with a sponsor to the follow-up after the report. The other guides in this series go deeper on each step: roles, facilitation, writing injects, scoring and the after-action report.

Why run a tabletop at all

Incident-response plans are written in calm conditions by a few people. Incidents happen under pressure, at inconvenient hours, and involve people who have never read the plan. A tabletop closes that gap cheaply. Typical things a first exercise surfaces:

• Nobody is sure who has the authority to take production systems offline.
• The out-of-band contact list is stored on the file server that the scenario just encrypted.
• Legal, communications and IT each assume someone else notifies the regulator or the insurer.
• The cyber-insurance policy requires using a panel incident-response firm, and nobody knows which one.
• Backups exist, but nobody has timed a full restore of the systems that matter most.

None of these require a sophisticated attacker to discover. They require an hour in a room with the right people and a good scenario.

Frameworks recognise this. NIST SP 800-84 describes tabletop exercises as a discussion-based way to validate IT plans, and the HSEEP methodology used across US emergency management provides a common structure for designing, conducting and evaluating them. Many regulations and standards also expect incident-response capabilities to be tested periodically, which a documented tabletop can help evidence.

Discussion-based vs operational exercises

A tabletop sits at the lighter end of the exercise spectrum. Knowing where it fits helps you set expectations with the sponsor.

Start with tabletops. They expose the organisational gaps that would make a functional exercise chaotic, and they cost almost nothing beyond people's time.

Step 1: Agree the purpose with a sponsor

Every exercise needs an executive sponsor: someone senior enough to protect the time of participants and to make sure findings are acted on. Before writing anything, agree three things with them:

1. Why now. A new plan, a recent near-miss, an audit finding, a board request, a regulatory change. The reason shapes the scenario.
2. Who the exercise is for. A technical response team, an executive crisis team, or a mixed group. Mixing is possible but harder to facilitate well.
3. What success looks like. Usually "we found and fixed the gaps", not "we did well". Say this out loud early; it changes how people behave in the room.

Step 2: Write objectives before the scenario

The most common planning mistake is to start with an exciting scenario and bolt objectives on later. Do it the other way round. Objectives drive which injects you write, who must attend and what evaluators look for.

Good objectives are specific and observable. Aim for three to five.

Each objective should map to at least one inject and one evaluation criterion. If an objective has no inject that forces the group to address it, it will not be tested.

Step 3: Choose the scenario

Pick a scenario that is plausible for your organisation, not the most dramatic one available. Useful inputs are your risk register, recent incidents in your sector, your threat intelligence and the objectives you just wrote. The scenario library on this site gives you ready-made starting points:

• Double-extortion ransomware tests crisis leadership, backups and ransom decisions.
• Business email compromise tests finance controls and is a good first exercise.
• Data breach and regulatory notification tests legal, privacy and communications under deadlines.

Tailor names of systems, business services and teams to your environment. Realism is what keeps participants engaged, and generic scenarios invite generic answers.

Step 4: Decide who is in the room

A tabletop with too few participants misses the hand-offs that fail in real incidents; one with too many turns into an audience. For a single room, 8 to 15 players is a practical range, plus the exercise staff. The roles guide explains each role in detail. At minimum you need:

• A facilitator who owns the room and the clock.
• A scribe who captures decisions, questions and gaps verbatim.
• Players who hold the real decision rights: incident lead, IT operations, security, legal, communications, and a business owner for the affected service.
• Optional evaluators or observers who watch against the objectives.

Invite deputies as well as primary role holders. Incidents happen during holidays, and deputies are often the ones who learn the most.

Step 5: Build the timeline

Six to eight weeks is comfortable for a first exercise; experienced teams can do it in three. A typical plan:

Keep the scenario details confidential to the planning team. Players should know the date, duration and general purpose, but not the scenario itself.

Step 6: Prepare the materials

You will need:

• The facilitator guide: objectives, the full inject list with expected discussion points, timing, and optional curveball injects.
• Player handouts: the starting situation and each inject on a separate page or slide, released one at a time.
• Realism artifacts: a mocked-up EDR alert, a ransom note, an email from a journalist, a message from the regulator. Keep them clearly fictional and harmless.
• Reference material players would normally have: the incident-response plan, contact lists, the crisis communication plan and relevant playbooks.
• A capture template for the scribe and evaluators.

A simple planning file keeps everything in one place:

exercise:
  name: "Q3 executive tabletop"
  date: "2026-10-15"
  duration_minutes: 150
  sponsor: "Chief Operating Officer"
  facilitator: "IR lead"
  scenario: "ransomware-tabletop-scenario"
objectives:
  - id: OBJ-1
    text: "Declare severity and activate the crisis team within 30 min of exercise time"
  - id: OBJ-2
    text: "Agree the decision owner and criteria for isolating the virtualisation platform"
  - id: OBJ-3
    text: "Confirm who approves external statements and in what order"
participants:
  players: [CIO, CISO, General Counsel, Head of Comms, COO, IT Ops lead]
  staff: [facilitator, scribe, evaluator]
logistics:
  room: "Board room + video bridge"
  materials: [handouts, IR plan, contact list, capture template]
  confidentiality: "TLP:AMBER — share within participating teams only"

Step 7: Run the day

A reliable agenda for a 2.5-hour exercise:

The facilitation guide covers how to keep discussion moving, handle dominant voices and use time compression.

Step 8: Close the loop

An exercise without follow-up is theatre. Within one to two weeks, circulate a draft after-action report that lists strengths, areas for improvement and recommendations. Turn recommendations into an improvement plan with a named owner and due date for each item, and schedule the re-test: often the next tabletop, focused on the same weak spots.

Track the improvement plan the way you track any other risk remediation. The value of the exercise is measured by what changed afterwards, not by how the day felt.

Common planning mistakes

• Scenario first, objectives never. The exercise becomes a story instead of a test.
• Too many injects. Eight to ten well-chosen injects beat twenty rushed ones. Leave time for discussion.
• Missing decision-makers. If the person who can authorise shutting down a service is absent, the key decision gets deferred and never tested.
• Fighting over realism. Players who argue that "this could never happen here" are often right about a detail and wrong about the point. Adjust details in planning so the scenario survives contact with experts.
• Grading people. Evaluate capabilities and plans, not individuals, or people will stop being candid. See scoring tabletop exercises.

Related

• Roles in a tabletop exercise
• Designing tabletop injects and the MSEL
• Scenario library and 20 tabletop exercise examples
• Tabletop exercise template and 100+ discussion questions
• How often to run a tabletop exercise
• Glossary: tabletop exercise, inject, hotwash