Run a ransomware tabletop yourself
Two hours, no consultant required. A tabletop everyone passes has told you nothing: the output is the list of questions nobody could answer, each with a name against it.
By Parminder Kumar Sharma · · 8 min read
What a tabletop is for
Not to prove you would cope. To find out where the plan is wrong while it is cheap to fix.
A tabletop that everyone passes has told you nothing. The useful outcome is a short list of things nobody could answer, and a named owner for each.
Two hours, four phases
- 15 minSet the scene
- 75 minRun the injects
- 25 minDebrief
- Within 48hWrite it up
Before the day
Decide what you are testing
Not "our ransomware response". Something specific: whether we can decide to disconnect, who authorises paying, whether we can operate with the ERP down for a week. A scenario without a target decision becomes a discussion.
You should see: One sentence naming the decision you want to watch people make.
Invite the people who decide, not the people who know
Technical staff usually know what to do. Tabletops fail on authority, not knowledge: who can take the site offline, who talks to the regulator, who signs off on a payment. If none of those people are present you are testing the wrong thing.
You should see: At least one person in the room can authorise spending money and stopping operations.
Write the scenario against your actual estate
Generic scenarios produce generic answers. Use your real system names, your real suppliers, your real backup arrangement. It takes an hour and it doubles the value.
You should see: The scenario names systems your organisation really runs.
Set the rules out loud
No blame, no gotchas, and it is fine to say "I do not know". You want the gaps, and people conceal gaps when they think they are being marked.
You should see: Everyone understands this is not an assessment of them.
Who is in the room, and who must not be
The attendance list decides more about the outcome than the scenario does.
Roles, and what each one is there to discover
| Role | There to answer | The gap they usually expose |
|---|---|---|
| Incident lead | Who is running this, and who takes over at 2am | There is no second name, so the plan assumes one person never sleeps |
| Technical lead | What is actually affected, and how do we know | Detection tells us something happened, not what it reached |
| Legal or DPO | What must be reported, to whom, by when | The clock started at detection and nobody noticed |
| Communications | What do we tell staff, customers, the regulator | No approved holding statement exists, so drafting begins under pressure |
| Executive sponsor | Who can authorise a shutdown, a payment decision, or a public statement | Their phone is the single point of failure and it is on silent |
Two roles that should not be in the room. Anybody who would not be involved in a real incident, because their presence makes the exercise a briefing. And anybody senior enough that their arrival stops people admitting what they do not know, unless that person is explicitly there to be tested alongside everyone else.
The injects
Deliver these one at a time. Do not hand out the whole scenario at the start: the value is in people reacting to partial information, because that is what an incident is.
Injects that work
- Backups exist but the restore is estimated at nine days.
- The finance director asks whether we can just pay.
- A journalist calls the switchboard.
- The domain admin account used by the attacker is your monitoring service account.
- A supplier says their systems are affected too.
Injects that waste time
- Highly technical detail nobody in the room can act on.
- Anything that has one obviously correct answer.
- Scenarios that require imagining a completely different organisation.
- Twists that exist to catch people out rather than to test a decision.
Run it with a clock visible
Announce elapsed time periodically: "it is now 14:00 on day one". Time pressure is what makes a tabletop resemble an incident, and it surfaces the decisions people avoid.
You should see: Decisions are being made under time pressure rather than discussed at leisure.
Write down every 'we would need to check'
That phrase is the exercise's actual output. Each one is a thing that is not written down anywhere, and each one costs hours during a real incident.
You should see: A visible list growing on a whiteboard as the exercise runs.
The failures that repeat, and what they look like on the day
Across exercises the same five things surface, and knowing them in advance means you can build injects that reach them rather than hoping.
The backup nobody has restored. Everybody knows backups exist. Almost nobody knows how long a restore takes, whether it has been tried this year, or whether the backup system itself uses the same credentials as the thing that was encrypted.
The contact list inside the encrypted system. Phone numbers in a spreadsheet on the file share, the incident plan on the intranet, the supplier contract in the document management system. All unreachable, at exactly the moment they are needed.
The clock nobody started. Reporting obligations run from awareness rather than from confirmation. Groups routinely spend the first hour establishing what happened, then discover the regulatory clock has been running throughout.
The decision with no owner. Whether to shut down a production system to contain spread is a business decision made under time pressure with incomplete information, and in most organisations nobody has been told it is theirs to make.
The recovery order nobody agreed. Which system comes back first is a question with a right answer that depends on the business, and it is almost never written down before the day somebody has to choose.
Running it without it becoming a meeting
The most common failure is not a bad scenario. It is a room that discusses the scenario instead of responding to it, and the facilitator is the only person who can prevent that.
Four rules that hold the exercise in the right register.
Ask what they do, never what they would do. The conditional tense invites policy recitation. "What do you do now" gets an action; "what would you normally do" gets a description of the runbook, which is the thing being tested rather than the answer.
Make them find the artefact, not name it. When somebody says the contact list is on the file share, ask them to open it. Half the value of the exercise is discovering that the artefact everybody referenced cannot be reached.
Keep the clock visible and running. Put the elapsed time on a wall. It changes the conversation more than any inject, because it makes the cost of deliberation legible while it is happening rather than in the debrief.
Let silence happen. When nobody answers, the finding is that nobody owns it. Filling that silence yourself is the single easiest way to lose the most valuable result of the day.
How often, and at what cost
Annually is the answer most organisations give and it is usually too rare to build anything. Twice a year, with the second one shorter and narrower, holds far better: the first exercise finds the gaps and the second finds out whether anybody closed them.
The cost is the room, not the preparation. Five to eight people for ninety minutes, plus perhaps half a day of your own time writing injects that reach the failures above. Where an external facilitator is worth paying for is the first one, because somebody inside the organisation cannot credibly let a silence sit when the person not answering is their manager.
Do not run it as part of another meeting, and do not run it on a day when the executive sponsor can only attend the first twenty minutes. Both convert an exercise into a briefing, and a briefing finds nothing.
The debrief, which is the point
Ask what surprised people, before asking what went well
Start with surprise rather than performance. It gets honest answers, and it avoids the meeting turning into mutual reassurance.
You should see: At least three genuine surprises named.
Convert every gap into an owner and a date
A gap without a name is a gap that will still be there at the next exercise. This is the step that turns a tabletop from an event into an improvement.
You should see: No item on the list reads 'the team' or 'ongoing'.
What good looks like
Take this with you
A tabletop that was worth the two hours
- Someone with authority to spend money and stop operations was in the room.
- The scenario used your real system, supplier and backup names.
- Injects were delivered one at a time, under a visible clock.
- At least three things nobody could answer were written down.
- Every gap has a named owner and a date, not a team and an intention.
- The write-up exists within 48 hours and is dated.
- Somebody has diarised the next one.
- Nobody was blamed for anything, and people said so afterwards.
Verified
Written 5 August 2026. Control references are to ISO/IEC 27001:2022 Annex A; numbers and short titles are identifiers and no standard text is reproduced.
