The message looks like it came from your managing director: a short note about a supplier payment, sent from a familiar address at 8:40 on a Tuesday. Your finance manager replies. Twenty minutes later, an invoice redirect is in motion and money is leaving the account. Who do you call first? Is the bank's fraud line saved anywhere? And if the attacker also locked the file server, who restores yesterday's data?
Most small businesses answer those questions with a shrug. Not because the team is careless, but because nobody has had the conversation out loud. A tabletop exercise is that conversation, run on purpose. No downtime, no consultants, no software licenses: a room, a scenario, and ninety minutes of your team's attention.
Start With One Scenario You Actually Fear
You do not need a catalogue of disasters. Pick one plausible event that would hurt, and commit to it. For most small organisations, the shortlist looks like this: ransomware on the file server during a busy week, a business email compromise that redirects a supplier payment, a stolen laptop with customer data on it, or a trusted employee leaving with access they should not have had.
Choose by likelihood and pain, not by drama. A ten-person accountancy practice does not need to rehearse a nation-state attack; it needs to rehearse a locked payroll folder two days before payday.
Then write a one-page scenario spine: what happens, in what order, and what the team discovers. Keep it vague enough that people have to make decisions rather than recite a script.
Assign Roles Before You Need Them
During a real incident, chaos usually comes from unclear ownership rather than missing technology. Decide now who holds each hat, and write the names down. In a small business one person will hold two or three of these roles, which is fine — as long as everyone knows which hat is on.
- Incident lead: runs the response, makes the call, decides when to escalate.
- Scribe: keeps a timeline of what happened, who was told, and what was decided. This is the most underrated role in the room.
- Technical lead: isolates systems, checks backups, preserves evidence.
- Communications: handles staff, customers and suppliers, with one approved message.
- Business liaison: talks to the bank, the insurer and your lawyer, and keeps the owner informed.
If a role has no name against it, that is your first finding — before the exercise even starts.
Write Injects, Not a Script
An inject is a piece of new information you hand the team every ten to fifteen minutes. It keeps the pressure on and stops the discussion from drifting into abstraction. Read it aloud, then stay quiet and let them work.
- 09:05 — A second machine shows the same alert. Your antivirus console is only visible from one laptop, which is currently encrypted.
- 09:20 — Last night's backup job failed. The previous successful backup is four days old.
- 09:35 — A long-standing customer calls to ask why your invoices are bouncing.
- 09:50 — A journalist has emailed asking for comment.
- 10:05 — Someone remembers that the shared admin password is written in a notebook in the office.
Base each inject on something true about your setup. The best ones come from the awkward details everyone knows but nobody has fixed.
Ground Rules That Keep the Room Honest
The exercise only works if people speak plainly. Say this at the start, and mean it:
Nothing said in this room gets anyone in trouble. We are testing the plan, not the people.
A few practical rules help. The facilitator does not solve the problem or answer technical questions — if someone asks whether the backups work, the answer is "you tell me". Participants describe what they would do and to whom, out loud, as though it were real. Keep it timeboxed, with a short break at the halfway mark. And if the conversation turns into an argument about who owns a system, write it on the parking list and move on; that argument is a finding, not a failure.
The Debrief Is Where the Value Is
Run a hotwash immediately after, while memories are fresh, then write it up within two days. Ask four questions: what went well, what surprised us, what could we not do, and what are the first three things we will fix?
Turn the answers into a one-page action list with an owner and a date for every item. Common outputs are refreshing a contact card that lives offline as well as in email, testing a restore rather than assuming it works, writing a holding statement for customers, and confirming the bank's fraud reporting process. Do not try to fix everything at once. Three finished items beat twenty good intentions.
Where an incident would trigger notification duties to customers, regulators or insurers, confirm the specifics with your lawyer or insurer rather than relying on a colleague's recollection. That is exactly the kind of question the exercise is designed to surface, and it is worth resolving calmly in advance.
Make It a Habit, Not a One-Off
One exercise teaches you where the gaps are. Two a year keeps the plan alive. Rotate the scenario so the same assumptions do not go untested, and rotate who leads it so the responsibility is not concentrated in one person. As the team gets comfortable, add a twist: a key person is on holiday, the internet is down, or a supplier is the one who leaked the data.
Your First 90 Minutes, Mapped Out
- Book the slot and invite six people or fewer. Smaller groups talk more honestly.
- Name the incident lead and the scribe before anyone walks in.
- Read the scenario, then deliver the first inject within ten minutes.
- Keep to time, log decisions, and park side arguments.
- Hold a twenty-minute hotwash straight afterwards.
- Circulate the action list within two days, with owners and dates.
- Put the next exercise in the calendar before people leave the room.
Start with one scenario, one page, and one afternoon. You will learn more about your readiness in ninety minutes than in a year of good intentions.
Photo: Sora Shimazaki / Pexels
