An incident response plan that has only ever been read is a document. One that has been walked through with the people who would execute it is a plan. A tabletop exercise is the walk-through: a facilitated conversation where a scenario unfolds in stages and the team says, out loud, what they would do at each one.
It takes two hours, no technology, and a room with the right people. Here is how to run one that produces real findings rather than a pleasant meeting.
Who is in the room
The exercise fails if it is only IT. Ransomware decisions are made by owners, finance, legal, HR and whoever talks to customers. Invite the people who would actually be on the call at 6 a.m. on the day.
Keep it under ten people. One facilitator runs the scenario and keeps time. One scribe writes down every decision, every question nobody could answer, and every 'I think so' that should have been 'yes'.
- Owner or executive sponsor: makes the pay-or-not and shut-down-or-not calls.
- IT lead or managed service provider: knows what is actually possible and how long it takes.
- Finance: cash, insurance, payroll on a Friday with no systems.
- Operations or the person who knows how the business runs without computers.
- Legal or whoever would call outside counsel, and someone who talks to customers.
A scenario that escalates
Write the scenario as four or five injects, each revealed only after the group has responded to the last. Each inject should force a decision. Vague scenarios produce vague answers; make it specific to your environment, your applications and your busiest day of the week.
Here is a template. Adapt the names and systems to yours.
- Inject 1, 6:40 a.m. Monday: the warehouse supervisor calls the IT lead. The label printers stopped, and the shared drive has files ending in a strange extension. There is a text file called README in every folder. What happens in the next fifteen minutes? Who is called, in what order?
- Inject 2, 7:30 a.m.: the ransom note names a group and demands payment in 72 hours. It claims 400 GB of data was taken. The backup server does not respond to ping. What do you know about your backups right now, from memory, without a system to check?
- Inject 3, 9:00 a.m.: the insurer's hotline has assigned counsel and a forensics firm. Counsel says all communication goes through them. Email is down. How does the team communicate? How are 60 employees told what to do today? What is said to customers who call?
- Inject 4, 2:00 p.m.: forensics reports the entry point was a VPN login from a contractor's account with no MFA, eleven days ago. The immutable cloud backups are intact but the last verified restore test was five months ago. Do you pay? Who decides? What does Tuesday look like?
Running the two hours
Set the ground rules first: nobody is being tested, there are no wrong answers, and 'I do not know' is the most valuable thing anyone can say. The purpose is to find the gaps in a room, not in an incident.
The facilitator reads an inject, then goes around the table asking each person what they would do in their role. Push on every assumption. 'We would restore from backup' gets 'from which copy, who has the credentials, and how long does the first server take'. 'We would call the insurer' gets 'what is the number, and where is it written down'.
- 0:00 to 0:10: ground rules, roles, a two-minute overview of the existing plan.
- 0:10 to 1:30: the injects, roughly fifteen minutes each. Do not let one inject run long; the later ones matter more.
- 1:30 to 1:50: the scribe reads back every open question and gap. The group agrees on an owner and a date for each.
- 1:50 to 2:00: what surprised people. This is where the real findings surface.
What to write down and what to do next
The output is a one-page findings list, not a report. Each finding is a gap, an owner and a date. Typical findings from a first exercise: nobody knew the insurer's hotline number, the backup credentials were only in the IT lead's head, there was no way to reach staff without email, and the pay decision had no named decision-maker.
Fix the findings, update the plan, and schedule the next exercise for six months out with a different scenario: business email compromise, a lost laptop with customer data, a cloud tenant lockout.
- Publish the findings list within a week, while the discussion is fresh.
- Update the incident response plan with the decisions the group made: contact tree, communications channel, decision rights.
- Print the plan. Store copies off the network: the safe, the owner's home, the IT provider's office.
Frequently asked questions
We are a small company. Is this really worth two hours of the owner's time?
The owner is the person who will make the hardest calls during the real thing. Two hours of practice is the cheapest way to make sure those calls are made with information rather than panic.
Should our IT provider run the exercise?
They should be in the room, and they can facilitate if nobody else is comfortable doing it. RackLedge runs tabletops for its clients with a scenario built around their actual systems. An outside facilitator has the advantage of asking the questions insiders assume are answered.
What if the exercise shows we are not ready at all?
That is the point. A tabletop that finds nothing was either not honest or not specific enough. Finding six gaps in a conference room costs an afternoon. Finding them during an incident costs weeks.
Takeaway
Put the right people in a room, walk through a specific scenario in stages, and write down every question nobody could answer. Two hours produces a findings list that improves the plan more than any amount of rewriting it. Then do it again in six months with a different scenario.