---
name: tabletop_exercise
description: "Design, facilitate, and debrief incident response tabletop exercises: full fictional scenarios with timed injects, word for word facilitation scripts, participant briefs, evaluation rubrics, and after action reports with tracked corrective actions. Use when someone asks to run a tabletop, plan an IR exercise, test an incident response plan, build a ransomware or breach scenario, facilitate a hot wash, or write an AAR."
---

# Tabletop Exercise

## Purpose

A tabletop is a discussion based exercise, not a test people pass or fail and not a live fire drill. People with real roles in a plan sit together, a facilitator presents a fictional incident in stages, and the group talks through what they would actually do. The point is to find gaps in the plan, in decision authority, and in handoffs while nothing real is on fire.

This skill ships the whole packet, not a single note:

- A complete scenario with a timeline of timed injects
- A facilitation script the facilitator can read and adapt
- A participant brief that hides facilitator only material
- An evaluation rubric tied to the stated objectives
- A hot wash guide and an after action report template with owners and retest dates

Frameworks it follows, in plain terms: CISA Tabletop Exercise Packages for package structure (objectives, scenario, discussion questions), NIST SP 800-84 for exercise terminology and types, FEMA HSEEP for design, conduct, evaluation, and improvement planning, and the NIST SP 800-61 incident handling life cycle for scenario phases.

## Workflow

### 1. Scope before you write anything

Collect these inputs. If one is missing, ask once, then proceed with a stated assumption.

- Audience: technical responders, executives, or mixed. Mixed rooms need both a technical track and a decision track in the injects.
- Duration: 60, 90, or 120 minutes of play. Longer is not better. Fatigue kills candor after about two hours.
- Plan under test: incident response plan, ransomware playbook, communications plan, or no formal plan yet. If there is no plan, the objective is discovery, not validation, and the report must say so.
- Risk to rehearse: pick one primary threat (ransomware, business email compromise, cloud account takeover, vendor compromise, insider data loss, destructive malware, major outage with a security cause). One threat per exercise.
- Constraints: real systems are never touched, no real credentials, no real customer data, no contacting outside parties.

Write 1 to 3 objectives. Each objective must be observable in discussion.

Good: "Participants identify who can authorize disconnecting the file servers, and name the backup contact if that person is unreachable."
Weak: "Improve ransomware readiness." You cannot score that from talk.

Use this form: Verb + decision or action + condition. Examples in `references/scenario-library.md`.

### 2. Build the scenario in modules

Structure play as four modules that follow the incident life cycle:

1. Detection and triage (is this real, how bad, who is paged)
2. Containment and investigation (what gets isolated, what evidence is preserved)
3. Business decisions (shutdowns, disclosure, regulators, customers, money)
4. Recovery and closeout (restore order, criteria for clean, what changes after)

For each module write:

- Situation update: 3 to 6 sentences, plain language, only what participants would know at that point. Withhold later facts.
- 2 to 4 injects (see step 3)
- 3 to 5 discussion questions, open ended, each mapped to an objective
- Facilitator notes: what a good answer sounds like, what gap to listen for, and a follow up probe if the room goes quiet or goes too fast

Keep the scenario fictional and internally consistent: named systems, named roles not real people, a clock, and consequences that follow from earlier choices. If participants chose not to isolate a host in module 1, module 2 should show spread. Branch at most twice. A scenario that ignores participant decisions teaches people that decisions do not matter.

### 3. Write injects that force a decision

An inject is a timed, specific development delivered mid play: a message, alert, call, or news item. Every inject needs six fields:

| Field | Meaning |
|---|---|
| Time | Minutes from start, for example T+25 |
| Delivery | Read aloud, handout, slide, simulated email or ticket text |
| From | Who it appears to come from (a role, a tool, a reporter) |
| Content | The exact text participants receive, short enough to read in under 30 seconds |
| Decision forced | The choice it creates, stated in facilitator notes only |
| Objective | Which objective it tests |

Rules for injects:

- One new problem per inject. Stacking three crises at once produces noise, not learning.
- Space injects 10 to 20 minutes apart in a 90 minute exercise. Give the room time to finish a thought.
- Include at least one inject that tests a non technical handoff: legal, communications, an executive, a vendor, or a regulator.
- Include at least one ambiguity inject: incomplete or conflicting information where the correct move is to state assumptions and verify, not to guess confidently.
- Optional: one red herring. If you use one, the debrief must name it and ask how the room handled it.
- Never base an inject on a real recent incident at the organization without the sponsor's explicit approval. That turns learning into blame.

Worked inject set: `references/scenario-library.md`, Scenario A.

### 4. Assign roles and set ground rules

Required roles, named before play:

- Facilitator: presents material, controls pace, asks probes, protects quieter voices. Does not answer the scenario.
- Scribe: captures decisions, open questions, and gaps verbatim in the capture log. Does not play.
- Evaluator(s): score against the rubric in real time. In a small team the scribe and evaluator can be the same person, and the report must note that limit.
- Participants: play their real job roles. If a key role is absent (legal, communications, business owner), assign a stand in and record the absence as a finding risk, because a real incident will face the same gap.
- Sponsor: the person who owns follow up after the exercise. Not always present during play.

Ground rules, read aloud at the start (full script in `references/facilitation-script.md`):

- Fight the scenario, not each other. No blame for gaps found. Gaps found here are the product.
- Work with what the scenario gives you. If information is missing, say what you would check and how.
- Use the real plan if one exists. If you would deviate from it, say so and say why. The scribe records deviations.
- No real systems, no real calls, nothing leaves the room as if it were a real incident.

### 5. Facilitate

Pacing that works:

- 0 to 10 min: welcome, ground rules, objectives, scenario opening brief
- Per module: 15 to 25 min, ending with the facilitator summarizing decisions made so far
- Final 15 to 20 min: recovery choices and what the group would do in the first hour on Monday
- Close play on time, then run the hot wash separately (step 6)

Facilitator moves:

- Ask, then wait. Silence after a question is data. Count to ten before rescuing the room.
- Redirect solution talk back to authority: "Who can approve that, and how long would approval take at 2 a.m.?"
- Redirect technical depth with: "Park the how. Who decides, who is told, and in what order?"
- Pull in silent functions: "We have heard from IT. Legal, what do you need before that statement goes out?"
- When the room invents a capability ("we would just restore from backup"), probe it: "When was that restore last tested, and how long did it take?" Record untested assumptions as findings, not as successes.
- Keep a visible parking lot for out of scope ideas. Do not let them eat module time.

If discussion stalls completely, use a forced choice probe: "You have two options in the next 15 minutes of scenario time: isolate the segment and break the customer portal, or keep it up and risk spread. Pick one and defend it." Then note which they picked and why.

### 6. Capture findings live, then hot wash

The scribe logs every item in four columns: time, decision or observation, objective affected, follow up needed. Vague praise is not a finding. "Comms was good" is not usable. "Comms lead had no pre approved holding statement and drafted one from scratch, taking about 20 minutes of scenario time" is usable.

Hot wash: 20 to 30 minutes, right after play, same room.

Run 6 to 8 questions across four groups, at least one from each, concrete before abstract:

- Operational: What did we actually do first? Where did escalation stall? Which channel would we use if email were down?
- Strategic: Which trade off hurt most? When would we bring in outside help, and who signs that contract?
- People: Where did disagreement surface, and how was it settled? Where did technical and non technical language fail to connect?
- Transfer: What is the first thing to fix on Monday? What should the next exercise rehearse?

Full question bank: `references/debrief-and-aar.md`.

### 7. Write the after action report and improvement plan

Deliver within 5 business days while memory is still fresh. Structure in `assets/aar-template.md`. Each finding uses four parts:

1. Observation: what happened in play, with the inject or time reference
2. Reference: the plan section, policy, or procedure it relates to, or "no documented procedure found"
3. Analysis: why it happened. Root cause, not a person.
4. Recommendation: a specific change, with an owner, a due date, and a retest method

Rate capability per objective as Performed, Partially performed, or Not performed, based only on what was observed in play. Do not rate what the plan says on paper if the room did not do it.

Improvement plan table: corrective action, owner (a named role), due date, validation (document update, drill, or retest in a follow up exercise). Schedule the follow up exercise at delivery time, typically within 6 to 12 months or after major corrective actions close, whichever comes first.

### 8. Validate the packet before delivery

Run the checker on any plan file written in the packet format:

```
python3 bin/plan_check.py assets/exercise-plan-template.md
python3 bin/plan_check.py <your-plan.md>
```

It verifies required sections, counts injects and objectives, checks that every inject has a time, and warns if play time exceeds the stated duration budget. Fix errors before the exercise. Warnings are judgment calls, document why you kept them.

## Output Contract

Deliver one exercise packet containing, in this order:

1. Cover and logistics: title, date, duration, audience, sponsor, facilitator, classification note (fictional scenario, internal use)
2. Objectives (1 to 3) with the capability each one tests
3. Participant brief: opening situation, roles, ground rules, what to bring (the plan). No injects, no facilitator notes.
4. Facilitator guide: module by module script, inject cards with all six fields, discussion questions, probes, expected gaps
5. Capture log: blank table for the scribe
6. Evaluation rubric: per objective, what Performed / Partially / Not performed looks like
7. Hot wash guide: question set for this scenario
8. AAR template: pre filled with objectives and participant list, findings left blank for after play

Keep facilitator material physically or digitally separate from the participant brief. If participants can see upcoming injects, the exercise measures reading, not response.

Files in this skill:

- `references/scenario-library.md`: three complete scenarios (ransomware, business email compromise, cloud vendor compromise) with inject timelines
- `references/facilitation-script.md`: word for word opening, module transitions, stall probes, and closing script
- `references/debrief-and-aar.md`: hot wash question bank, finding writing examples, scoring guidance
- `assets/exercise-plan-template.md`: fill in packet skeleton that passes the checker
- `assets/aar-template.md`: after action report and improvement plan skeleton
- `bin/plan_check.py`: validator for packet completeness and timing

## Operating Rules

1. Fictional scenarios only in the packet. Label them fictional. Never present invented systems, amounts, or events as real incidents.
2. Every factual claim about a standard or framework must trace to a primary source (CISA, NIST, FEMA). If you cannot verify it, cut it or mark it as local practice, not as a requirement.
3. No blame language in any output. Findings describe processes, authority, and documents, not people by name. Participant names appear only in the attendance list.
4. Do not score individuals. Score capability against objectives only.
5. A plan that was never exercised is not "ready". If the exercise is the first test of a plan, the report says so plainly.
6. If a key function (legal, communications, executive decision maker) did not participate, flag every finding that depends on that function as provisional.
7. Keep game language out of the AAR. Points, winners, and leaderboards may help energy in the room. They do not belong in the formal report.
8. Corrective actions without an owner and a date are not corrective actions. List them separately as unassigned recommendations so the gap is visible.
9. Style: plain language, short sentences, no em dashes. Write the packet so a non technical executive and a front line responder can both follow it.