How to Run a Ransomware Tabletop Exercise
Part of our guide: Ransomware & incident response
Most businesses discover the holes in their ransomware plan at the worst possible moment — during a real attack. A tabletop exercise is the cheap insurance against that: you gather the right people, walk through a realistic scenario out loud, and find the gaps while it’s still hypothetical. You don’t touch a single system. Here’s how to run one.
What a tabletop exercise is
It’s a guided, discussion-based walkthrough of an incident. Someone presents a scenario (“it’s Monday, 7 a.m., staff can’t log in and there’s a ransom note”), and the group talks through exactly what they’d do — decision by decision. The goal isn’t to “pass.” It’s to surface the questions nobody has answered yet.
Who to involve
Keep it small but cross-functional. For most businesses that’s the owner or a senior leader, whoever runs IT, someone from finance, and someone who’d handle communications. The mix matters — ransomware is a business crisis, not just an IT problem. If you have an incident response plan, bring it; if you don’t, this exercise will show you why you need one.
A simple scenario to use
It’s Monday morning. Staff can’t access email or the shared drive. A note on several screens demands payment in cryptocurrency within 72 hours or the data is published. Your backups are… you’re not actually sure.
Inject a few complications as you go: the bookkeeper’s laptop is also affected; a client emails asking why their portal is down; a journalist calls.
The questions to work through
Walk the group through each, and write down every “we don’t know”:
- Who’s in charge? Who declares an incident, and who makes the call on big decisions?
- First moves. Do we isolate systems? Who actually knows how — and after hours?
- Backups. Do we have them, are they offline/immutable, and have we ever tested a restore? (See the step-by-step ransomware guide.)
- To pay or not? Who decides? Have we taken legal and law-enforcement advice?
- Insurance. Do we have cyber coverage, and what does the policy require us to do first? (Calling the wrong vendor can void it — see why claims get denied.)
- Communications. What do we tell staff, customers, and possibly regulators — and when? Under PIPEDA, a breach of personal data may trigger reporting.
- Outside help. Who do we call for forensics and recovery, and is that arranged before the incident?
How to run it well
A few facilitation tips keep the session useful instead of awkward:
- Pick a facilitator to present the scenario, keep time, and stop the group from solving everything at once.
- Make it blameless. The point is to find gaps in the plan, not to fault people. Say so up front, or no one will admit what they don’t know.
- Timebox it to about 90 minutes to two hours — long enough to go deep, short enough that busy people show up.
- Designate a scribe whose only job is writing down every “we don’t know” as it surfaces.
- Resist fixing live. Note the gap and move on; solving it in the room derails the scenario.
Capture the gaps — that’s the whole point
Every “we don’t know” is a finding. Turn each into an action item with an owner and a date: write the plan, test a restore, confirm the insurer’s hotline, pre-arrange an incident response retainer. The exercise only pays off if the gaps get closed.
Write it up in a short after-action report — a one-page list of what worked, what didn’t, and the action items with owners and dates. Review it at the next tabletop so you can see what actually got fixed; a finding with no owner is just a worry you’ve written down.
Do it again
Run a tabletop at least once a year, and after any major change (new systems, new staff in key roles). The second one is always calmer than the first — which is exactly the point.
The takeaway
A two-hour conversation now is far cheaper than learning these lessons live, with the clock running and your data on the line. If you’d like, we can facilitate a tabletop for your team and help you close what it uncovers — get in touch.