How to run an incident response tabletop exercise
A practical guide for small teams: who to invite, how to write the scenario and injects, how to run the session, and what to put in the after-action report.
A tabletop exercise is a discussion-based rehearsal of an incident. Your team sits together, a facilitator walks through a realistic scenario in stages, and everyone talks through what they would do. Nothing is touched in your systems. The goal is to find gaps in your plan while it is cheap to fix them.
Why it is worth an afternoon
- You find the gaps before an attacker does.Who can take a server offline? Who calls the insurer? Where is the plan printed if email is down?
- It is often expected.PCI DSS (requirement 12.10.2) expects the incident response plan to be reviewed and tested at least every 12 months. HIPAA includes testing and revision of contingency plans as an addressable specification, and cyber insurers and SOC 2 auditors commonly ask for evidence of testing.
- It builds the habit.Teams that have rehearsed make calmer, faster decisions in a real incident.
Before the session
- Pick one scenario that matters to you.Ransomware on a file server, a compromised email account, a lost laptop with customer data, or a supplier breach are good first choices.
- Set two or three objectives.For example: confirm who decides to disconnect systems, test how we reach staff without email, check when we must notify customers.
- Invite the right people.IT or security, a decision-maker from leadership, someone for legal or compliance, and someone for communications. Five to ten people is enough.
- Write the injects.Injects are the updates you reveal in stages, each with two or three questions.
- Book 60 to 90 minutesAnd choose a facilitator who will not also be answering the questions.
Example injects for a ransomware scenario
| Time | What the group learns | Questions to ask |
|---|---|---|
| Start | The help desk gets three calls: files on the shared drive will not open and have a new extension. | Who is told first? What do you do in the first 15 minutes? |
| +20 min | A ransom note appears on several machines. Backups for the file server last ran two days ago. | Do you disconnect systems? Who decides? Who contacts the insurer? |
| +40 min | A journalist emails asking whether you have been attacked. | Who answers? What can be said, and what cannot? |
| +60 min | Evidence suggests customer data was copied before encryption. | Which laws or contracts require you to notify, and by when? |
Running the session
- Open with the ground rules: this is a no-fault discussion, and "I don't know" is a useful answer.
- Reveal one inject at a time, and let the group talk before moving on.
- Keep a note-taker separate from the facilitator. Record decisions, open questions and gaps.
- Watch the clock, but do not rush a useful argument. That is where the gaps show up.
- Close with a quick round: what went well, and what would have gone wrong.
The after-action report
The report is what turns a meeting into evidence. Keep it short and specific.
- Date, scenario, participants and objectives.
- A timeline of each inject with the decisions made.
- What went well.
- Gaps found, each with an owner and a due date.
- Which plans or policies need updating as a result.
Then follow up on the actions. A report with no follow-up is the most common weakness auditors and insurers point out.
Free resources
CISA publishes Tabletop Exercise Packages with ready-made scenarios, including ransomware, phishing and insider threats. NIST Special Publication 800-84 describes how to plan and run exercises for IT plans.
Useful links
General information, not legal advice. Laws, contracts and provider processes change; check the linked sources for current details.