The gap between having an incident response plan and being able to respond is the gap a tabletop exposes. Nothing else finds it as cheaply. A first tabletop needs a room, ninety minutes, a scenario with a spine, and a chair willing to let things get slightly uncomfortable.
This runbook is for the person organising and chairing that first exercise. It assumes no budget, no external facilitator and no prior exercise culture.
What a tabletop is, and is not
A tabletop is a structured conversation: a scenario unfolds in stages, and the people in the room say what they would actually do, with the plan open in front of them. Nobody touches a keyboard. It is not a test with a pass mark, not a surprise drill, and not a technical simulation. The output is a list of things that did not work on paper, found while they were still cheap to fix.
Say this out loud at the start. The moment the room believes individuals are being graded, they stop saying “honestly, I would not know who to call” and the exercise loses the only thing it was for.
Four decisions before you book the room
- Scope: one scenario, ninety minutes, done well. A first exercise should not attempt the full plan. Pick one incident type and run it deep enough to hurt slightly.
- Audience: response team or leadership, not both first time. Mixing hands-on responders and executives in a first exercise makes both perform for the other. Run the response team first; run leadership later with a decision-focused variant of the same scenario. Once both have had one exercise, combined sessions work well.
- Scenario: your most plausible bad day. Ransomware through a phished credential is the default for good reason, but pick what genuinely fits your risk register: a compromised finance mailbox, a critical supplier outage, a stolen laptop with the wrong data on it. Realism does more for engagement than drama. The scenario should be recognisably your organisation: your systems by name, your actual working patterns.
- Roles: a chair and a scribe, never combined. The chair runs the scenario, keeps time and pushes on soft answers. The scribe writes down every gap, assumption and “we would need to check” without joining the discussion. The scribe’s notes are the entire product of the day.
Building the scenario: a spine and injects
Write the scenario as a timeline with four or five stages, called injects. Each inject adds new information and takes something away. The craft is in the taking away.
A worked example, ransomware via phished credential:
- Inject 1, Tuesday 07:40. The service desk gets three calls: files will not open and there is a strange text file on the finance share. The IT lead is on leave, abroad.
- Inject 2, 08:30. Encryption confirmed on two servers. The ransom note names a group and a 72-hour deadline. Question to the room: who has been told by now, and who should have been?
- Inject 3, 10:00. The backup server is unreachable. Also, someone checks: the attacker had a week of quiet access first. What else do we now have to assume?
- Inject 4, 13:00. A journalist emails the press office asking about “reports of a cyber attack”. Separately, legal asks whether personal data is involved, because a regulatory clock may already be running.
- Inject 5, day 2. The group’s leak site lists your name with a sample file. Payment discussion, insurer position, customer communications.
Between injects, the chair asks the same few questions: what do you do now, who decides that, what does the plan say, and what do you need that you do not have. Every hesitation is a finding, not a failure.
Two design rules. First, remove a person or a system you normally rely on; the absence is where the learning lives. Second, include at least one inject that is not technical, because the hardest parts of real incidents are communications, decisions and regulators.
Chairing on the day
- Open with the contract. No grades, no blame, phones down, what is said stays in the room, and the plan is what is being tested, not the people.
- Keep to the clock. Fifteen to twenty minutes per inject. When discussion circles, land it: “so the answer today is we do not know; noted, moving on.” The scribe writes it down and the exercise continues.
- Push past the comfortable answer once per inject. When someone says “we would restore from backup”, ask how long a restore of that system actually takes and when it was last tested. When someone says “comms handles that”, ask which named person and whether they know. One level of “how, exactly” is where the findings are.
- Watch for the quiet expert. Somewhere in the room is a person who knows why the confident answer is wrong and is not saying so. Ask them directly.
- Close with each participant naming one thing. One gap that worried them, or one thing they will fix. It takes five minutes and converts the room from audience to owners.
The write-up: one week, one page or two
The exercise decays fast. Within a week, produce a short report from the scribe’s notes: scenario in three lines, what worked, findings, and actions. Every action needs an owner and a date or it is a wish, not an action. Five to ten findings is normal for a first exercise; more is common and fine.
Typical first-exercise findings, so you know you are in good company: contact lists out of date, nobody sure who can authorise shutting down a revenue system, backup restore times unknown, no out-of-band comms channel, insurer notification requirements unread, the plan itself stored somewhere that would be encrypted.
Send the report to everyone who was in the room and to whoever owns the risk register. Then, and this is the part most first exercises miss, book the second exercise before the glow fades: six months out, different scenario, and start it with a review of whether the last exercise’s actions actually closed.
One-page checklist
One scenario, ninety minutes. Response team first, leadership separately. Scenario from your own risk register, written as four or five injects, each removing something you rely on, at least one non-technical. Chair and scribe, never combined. Open with the no-blame contract. Time-box injects, push one level past comfortable answers, ask the quiet expert. Close with one named thing per person. Write up within a week: findings, owners, dates. Book the next one immediately, and start it by checking the actions from this one.
Practitioner Runbooks are working documents, not standards. Spotted something that does not match how it works in your environment? Email hello@incidentresponse.com and we will improve it, credited to you.