How to run a tabletop exercise: a step-by-step guide

Most tabletop exercises fail before they start. Not dramatically — they just get planned as a meeting, run as a presentation, and end with everyone agreeing it was "useful" while nothing changes. The difference between that and an exercise your team still references months later is not budget. It's structure.

Here is the structure, in seven steps.

What a tabletop exercise is (and isn't)

A tabletop exercise is a conversation-based simulation of an incident: a scenario unfolds over a fixed time window, events ("injects") arrive on a schedule, and participants respond in their actual roles — deciding, escalating, and communicating as they would in reality. Nobody touches production systems.

It is not a presentation about an incident, not a quiz about the incident response plan, and not a penetration test. Technical tests answer "can we be breached?" A tabletop answers the question that determines how bad a breach gets: "can we respond?"

Step 1: Define what you're testing

"Practice incident response" is not an objective; it's a hope. Pick one or two specific questions:

• Does our escalation path work outside office hours?
• Do we recognize a notifiable incident, and does the 24/72-hour clock start on time?
• Can communications and legal produce a holding statement while containment is running?

The objective determines everything downstream — the scenario, the roles, and what the debrief measures.

Step 2: Choose the scenario

The scenario must be able to fail against your plans. Generic scenarios produce generic conversations. Strong scenarios are grounded in your actual environment: your business systems as targets, your security tooling as the detection source, your industry's regulators on the phone.

For a first exercise, ransomware is the right default (see the FAQ). For repeat exercises, rotate: data breach, supply-chain compromise, insider threat — each stresses different roles.

Step 3: Cast roles and assign a facilitator

Everyone plays their real role: the SOC analyst plays the SOC analyst, the CISO plays the CISO. Two rules matter:

• At least one decision-maker must participate. An exercise where every hard call is "escalated to someone not in the room" trains nothing.
• The facilitator doesn't play. They run the clock, deliver injects, answer "what would the system show?" questions, and observe for the debrief.

Roles you can't staff are traditionally just dropped — which quietly deletes the most interesting interactions. This is where AI role-players change the format: the missing CISO, legal counsel, or comms lead can be played by an agent that responds in character, so the humans present still experience the full team dynamic.

Step 4: Write the injects and timeline

Injects are the events that drive the exercise: the first alert, the ransom note, the journalist calling, the regulator asking questions. Good inject design:

• Escalates. Start ambiguous (an odd alert), end existential (production down, press calling).
• Targets roles. Each inject lands with the role that owns it — the SOC gets the alert, comms gets the journalist.
• Arrives incomplete. Real incidents are fog. Don't hand the team the full picture in inject one.
• Includes the clock. Build the notification deadlines into the timeline so the team has to decide when something becomes reportable.

A 60-minute exercise carries 8–12 injects comfortably. This is the step that traditionally takes consultants weeks; it's also the step AI generation collapses to minutes, because the injects can be derived directly from your scenario, org profile, and policy documents.

Step 5: Run the session

Practical rules that keep the session sharp:

• Real time, real channels. Run it in a chat environment, not around a table with one person narrating. Written responses create the transcript you'll need later.
• No pausing the incident. If the team is stuck, that's a finding, not a problem to fix mid-session. The facilitator can hint — privately.
• Stay in character. Decisions are made by the role that owns them, in the first person. "I'm isolating the file servers now" beats "I guess IT would probably isolate something."
• Let silence happen. When nobody acts, the incident escalates. That pressure is the exercise.

Step 6: Debrief while it's fresh

The debrief is where the exercise becomes worth its time — run it immediately, not next week. Cover three questions per role:

1. What did you do well? (Keep doing it.)
2. What did you miss or do late? (The plan-vs-reality gaps.)
3. What did the plan fail to tell you? (The document findings — often the most valuable.)

Score against the plan, not against perfection. A team that deviated from a bad procedure and improvised something better has produced a document finding, not a failure.

Step 7: Report and assign follow-up

The output of an exercise is a short report — findings, scores, missed steps — plus follow-up actions with owners and dates. This is also your compliance evidence: under NIS2 Article 21, the debrief report is exactly the effectiveness-assessment documentation auditors ask for.

Then schedule the next exercise before everyone leaves. The single biggest predictor of a strong response capability is not the quality of any one exercise — it's the cadence.

The mistakes that flatten exercises

• The walkthrough disguised as an exercise. Reading the IR plan aloud with the team nodding is documentation review, not practice.
• The omniscient scenario. If inject one explains the whole attack, there are no decisions left to make.
• The room full of spectators. Twelve people watching three people talk trains three people.
• No consequences. If wrong decisions don't change the scenario, the team learns that decisions don't matter.
• The debrief that never lands. Findings without owners are observations. Six months later, the same gaps reappear.

Run the seven steps with a cadence, and the exercise stops being an event and becomes what it should be: routine practice for the worst day your team will have.