Running your first tabletop exercise
How to test an incident plan with your own people in half a day, without touching a single system.
A tabletop exercise is a facilitated discussion in which the people who would handle a real incident walk through a realistic scenario under time pressure. Nothing touches your systems. It tests decisions, roles and the plan, and it ends in a report of gaps, each with an owner and a date.
Updated · 9 minute read
What a tabletop exercise is, and what it is not
A tabletop is a discussion under time pressure. A facilitator plays out a scenario in stages, and the people in the room decide what to do at each one. Nothing touches your systems, nobody is graded, and the output is a list of gaps in the plan.
A technical test checks whether a control works. A tabletop checks something different: whether people know who decides, who to call, and where the plan is when the network is down. Those are the questions that go unanswered on the night.
Plans fail in ordinary ways. The plan is saved on the file server that has just been encrypted. Nobody knows who may authorise shutting the ERP down on a Thursday night. The IT manager is on leave and the deputy was never named. The retained incident response firm was discussed and never contracted. The insurer's hotline is in a policy document nobody can open.
None of that is found by reading the plan at a desk. It is found by walking through a bad night with the people who would be awake for it. That is all a tabletop is, and it is why the first one is usually the most useful.
Who must be in the room
The people who would decide in a real incident: leadership, IT, finance, HR, communications, and legal where you have it. If only IT attends, you have tested IT, not the organisation. Most of the decisions an incident forces are not technical ones.
Taking the ERP offline stops dispatch, and that is a business decision. Telling customers is a communications and legal decision. Notifying the insurer is usually finance's. Deciding whether personal data was involved, and who must be told, sits with whoever owns data protection. An exercise with only IT in the room cannot reach any of those decisions, so it cannot find the gaps in them.
Two more people are needed who do not take part. The facilitator runs the scenario and releases the injects. The observer records what happens. If the person who wrote the plan facilitates, they will find it hard to probe their own gaps, which is one reason a first exercise often goes better with a facilitator from outside the team.
- Leadership: who may take a service offline, and who speaks for the company
- IT: what can be isolated, what the backups can actually restore, who the suppliers are
- Finance: payments, the insurer, and anything that moves money during the incident
- HR: staff communication, and personal data about employees
- Communications: customers, partners and anyone outside who asks
- Legal, where you have it: contracts, regulators and what may be said in writing
Build the scenario from your own systems
Use your own systems, suppliers and calendar. A scenario set on your ERP, your IT support company and your busiest dispatch night feels real to the people in the room. A textbook scenario lets them talk in generalities. Realism comes from detail, not from attacking anything.
Start from an incident that is likely for you and that crosses departments. Then set it at a bad time: a Thursday night, the start of a holiday, the day before a large dispatch. Name the real systems and the real suppliers, and put the incident where it hurts most.
Decide in advance which decisions the scenario must force: who declares an incident, who may isolate a system, who calls the retained responder, who tells the insurer, and who decides whether personal data was involved. Every one of those becomes an inject.
Keep the facilitator's version of the scenario to the facilitator. The people in the room should learn what is happening at the pace they would learn it on the night, one update at a time, and often with incomplete information.
If you have no written plan yet, you can still run the exercise. It will show you what the plan has to answer, and the after-action report becomes the plan's first draft outline.
Writing injects that force decisions
An inject is a timed update to the scenario that forces one decision. Release one every fifteen to twenty minutes. Write each so the room has to choose, not only discuss: isolate or not, call the insurer or not, tell customers now or later.
One decision per inject keeps the record clean. An inject that asks three things at once gets one answered and two forgotten, and the observer cannot tell which was which.
Make them escalate. The first inject is ambiguous: a user reports odd behaviour, or a supplier emails about a changed account. Later ones make things worse and make them public. Include one that lands on someone who is not there, because the decision maker who is travelling is exactly what the plan's deputies are for. Include one from outside: a customer, a partner or a journalist asking what is going on.
| Field on the inject card | What to write |
|---|---|
| Time in the scenario | When this happens in the story, for example Friday 07:30. |
| What happens | The update itself, in the words the room would actually hear it. |
| Who it lands on | The role that receives it first. |
| The decision it forces | One decision, stated as a choice. |
| What a good answer contains | For the facilitator and the observer only: what the plan says should happen. |
The observer's sheet
One person does not take part and only records three things for each inject: who decided, how long it took, and what they needed but did not have. That sheet is the raw material of the report. Without it, the debrief runs on memory and on the loudest voice.
What they needed but did not have is the most valuable column. It is a phone number, a contract, a password held by one person, or the authority to act. Each entry in it is a gap in the plan.
The observer also notes decisions made by the wrong person, and decisions nobody made. A pause in which everyone looks at each other is a finding, and it should be written down with the time it lasted.
| Column | What goes in it |
|---|---|
| Inject | Its number and time in the scenario. |
| Who decided | Name and role, or "nobody". |
| How long it took | From the inject to the decision. |
| What was missing | Information, a contact, a document or authority. |
| Gap or action | What the plan needs, in one line. |
The hot debrief and the after-action report
Debrief straight after the last inject, while it is fresh: what worked and what did not. Then write the after-action report, with each finding given an owner and a date, and update the plan. A report without owners is a list of observations that will still be true next year.
Keep the hot debrief short and specific. Three questions carry it: what went well, what slowed us down, and what would we change in the plan. The observer's sheet keeps it anchored to what happened rather than what people remember.
The after-action report follows. It records the scenario, who took part, the timeline of decisions, each finding, and the action raised against it with an owner and a date. Keep the scenario and injects as an exercise pack, so the next exercise can reuse the method with a different incident.
Exercise at least once a year, and again after a major change such as a new ERP, a merger or a new IT supplier. Use a different scenario each time.
Three starter scenarios
Start with an incident that is likely for you and that crosses departments. Three work well for a first exercise: a changed supplier bank detail, ransomware on the ERP, and a lost laptop holding personal data. Each forces decisions that sit outside IT.
Pick one. A first exercise with one scenario, run well, teaches more than three run in a hurry.
| Scenario | The decisions it forces |
|---|---|
| A changed supplier bank detail | An email from a known supplier's address asks for payment to a new account, and a payment has already gone. Who calls the bank, and how fast. Who verifies with the supplier on a number you already had. Whether a mailbox has been compromised, and who looks. |
| Ransomware on the ERP | The ERP server is encrypted late on a Thursday, with a dispatch run due on Saturday morning. Who may take it offline. How long a restore actually takes, and whether anyone has tried one. Whether the production network is reachable from the office network. When the retained responder and the insurer are called. |
| A lost laptop holding personal data | A laptop with customer or employee records is left in a taxi. Whether it was encrypted. Whose data it held. In Saudi Arabia, whether SDAIA must be notified within 72 hours of becoming aware, and who decides that the clock has started. |
The half-day agenda, as a checklist
A first exercise fits in half a day: a short brief, two rounds of injects with a break between them, a hot debrief, and a close that assigns owners. The timings below are a template to adjust, not a rule.
Book the room and the people first; the scenario is easier to write than a free morning is to find. Send nothing about the scenario in advance beyond the date, the purpose and who is attending.
- The plan printed, if you have one, and the offline contact sheet
- The observer named, with the sheet ready
- The scenario and injects written and held by the facilitator
- Deputies briefed for anyone who cannot attend
- Phones at hand, so people can show where the numbers they would call are kept
- A date agreed for the after-action report
| Block | What happens |
|---|---|
| Brief, 15 minutes | The rules: nobody is graded, and "I do not know" is a useful answer. Introduce the observer. |
| Scenario opens, 5 minutes | The first inject, deliberately ambiguous. |
| Injects, round one, 60 minutes | One inject every fifteen to twenty minutes, each forcing one decision. |
| Break, 15 minutes | The facilitator and observer compare notes, and adjust round two if the room has gone off course. |
| Injects, round two, 60 minutes | The incident escalates and goes public: customers, the insurer, a regulator clock. |
| Hot debrief, 30 minutes | What worked, what slowed the room down, what the plan should change. |
| Close, 15 minutes | Each gap named with a proposed owner, and the date for the report. |
Questions about a first exercise
Can we run it ourselves?
Yes, and this guide is written so you can. A facilitator from outside the team helps in two ways: the person who wrote the plan finds it hard to probe its gaps, and people say "I do not know" more readily to someone who does not manage them.
Do we need a written plan first?
It helps, but it is not required. Without a plan, the exercise shows what the plan has to answer, and the after-action report becomes its outline.
How often should we exercise?
At least once a year, and after a major change such as a new ERP, a merger or a change of IT supplier. Use a different scenario each time.
Can it run by video call?
Yes. The facilitator releases injects on a timer and the observer keeps the same sheet. Keep the group small enough that everyone speaks, and agree at the start that decisions are said aloud, not typed in a chat.
Does a tabletop touch our systems?
No. It tests people, decisions and the plan. Realism comes from using your own systems and suppliers in the story, not from doing anything to them.
Related
Incident response planning
The plan, the playbooks and a facilitated tabletop exercise with an after-action report.
Read moreSaudi regulationPDPL readiness
The personal data side of a breach, including SDAIA's 72-hour notice.
Read moreServiceSecurity policies and governance
The incident response policy the plan and the exercise sit under.
Read moreITF ConsultBusiness continuity, ITF Consult
ISO 22301, where exercising plans is part of the system.
Read morePart of one system
Every division keeps records to the same standard, so the second one you need works the way the first one did.
Run the first one with a facilitator
We build the scenario from your systems and suppliers, run the injects, keep the observer's sheet and write the after-action report.