Tabletop exercises: planning, running and learning from them
In short: A tabletop exercise walks a team through a pretend incident around a table, so gaps in the plan show up before a real attack does. Good exercises have clear goals, a believable scenario, a neutral facilitator and an action list that someone actually follows up.
What a tabletop exercise is
A tabletop exercise (often shortened to TTX) is a guided conversation about a made-up incident. Nobody touches a keyboard. Instead, a facilitator describes a situation, and the people who would really respond talk through what they would do, who they would call and what information they would need.
It is the cheapest way to test an incident response plan. Plans written in a quiet week often assume things that are not true: the on-call number is out of date, nobody knows who can authorise taking the payroll server offline, or the backup restore has never been timed. A tabletop exposes those assumptions in a safe room. NIST SP 800-84 describes tabletops as one part of a wider test, training and exercise programme, alongside functional drills and full-scale simulations.
Planning the exercise
- Set two to four objectives. For example: "Confirm who decides to isolate a site" or "Test how we notify the regulator within the legal deadline."
- Choose the audience. A technical tabletop suits the SOC and IT teams. An executive tabletop focuses on business decisions, legal duties and communication. Mixing both in one session often bores half the room.
- Pick a scenario that fits your real risks. Ransomware, a compromised email account, a cloud storage leak or a supplier breach are common choices.
- Agree the ground rules. It is a no-blame session, the scenario is fictional, and "I would check the runbook" is a valid answer if the runbook exists.
- Book the right people and a scribe. The scribe captures decisions, questions and gaps as they happen.
Writing the scenario and injects
An inject is a new piece of information released during the exercise: an alert, a phone call from a journalist, a message from the IT provider. Injects move the story forward and force decisions. Keep each one short and plausible, and give the facilitator optional extra injects in case the group finishes early or goes off track.
| Good practice | Common mistake |
|---|---|
| Scenario based on your own systems and suppliers | Hollywood plot with no link to your environment |
| Decisions with no obvious right answer | Questions with one textbook answer |
| Time pressure built into injects | Unlimited time to discuss every point |
| Neutral facilitator who asks "who does that?" | Facilitator who lectures or answers for the group |
Running the session and capturing improvements
The facilitator reads each inject, then asks open questions: What do you know now? Who needs to be told? What would you do in the next hour? Encourage quieter participants, and gently stop anyone who solves everything alone. Ninety minutes to two hours is enough for most groups.
Finish with a hot wash: a short, immediate debrief on what went well and what did not. Within a week, write an after-action report listing findings, each turned into an action with an owner and a due date. Typical actions include updating contact lists, writing a missing runbook, clarifying who has authority to pay for outside help, and pre-drafting customer messages (see communication and legal duties).
Tip: the exercise only has value if the actions are completed. Track them like any other risk item and check progress at the next tabletop.
Practice
What is an inject in a tabletop exercise?
Why is a hot wash held straight after the exercise?
Your tabletop finds that nobody knows who can authorise shutting down a site. What should the after-action report contain?
Key takeaways
- A tabletop is a discussion-based test of your incident response plan.
- Set clear objectives and match the scenario to your real risks and audience.
- Injects add new information and pressure so decisions have to be made.
- Hold a hot wash, then write an after-action report with owned actions.
- Repeat the cycle and check that earlier actions were completed.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.