Guide

How to Run a Ransomware Tabletop Exercise

A step-by-step guide to running a ransomware tabletop exercise for a small team: how to set the scenario, who to involve, and what to do with what you learn.

By SecureBusinessHub Editorial, International cybersecurity desk — 2026-07-27 · 6 min read

A ransomware tabletop exercise is a practice run of your incident response plan: your team sits down, walks through a realistic ransomware scenario step by step, and makes the same decisions they would need to make during a real attack, without any actual systems being touched. It usually takes an afternoon, costs nothing beyond that time, and is the single fastest way to find out whether the plan you wrote actually works.

This exercise is a rehearsal for the plan described in our incident response plan template and for the recovery steps in our ransomware survival guide. If you have not written either yet, start there first; a tabletop exercise tests a plan, it does not replace having one.

Why small businesses skip this, and why that is a mistake

Most owners who have written an incident response plan consider the job done. The plan exists, it is saved somewhere everyone can find it, and that feels like enough. It usually is not. Plans are written calmly, at a desk, with time to think, and read very differently under pressure. A phone number that turns out to be disconnected, a step that assumes access to a system that is itself down, or a role assigned to someone who left the company last spring: none of these show up until someone actually tries to follow the plan.

A tabletop exercise finds these gaps in a low-stakes afternoon instead of during a genuine crisis. It also does something a written plan cannot: it gets your team used to making fast decisions together under a simulated version of the pressure a real incident brings, so the first time they do it together is not also the first time it counts.

Setting up the exercise

Keep it small and practical. Invite everyone named in your incident response plan, plus anyone whose job would genuinely be affected, such as whoever handles customer communication or billing. For a team of around ten people, that is usually three to six participants: more than that and the exercise turns into a meeting instead of a rehearsal. Block out ninety minutes to two hours, and pick someone to facilitate who is not also playing a role in the response, so they can steer the scenario and keep time rather than getting pulled into the decisions themselves.

Run it away from anyone's normal workday distractions if you can. The value comes from people actually thinking through the decisions, not from ticking a box, and a facilitator interrupted every ten minutes by an unrelated phone call gets much less out of the session.

Building the scenario

A good scenario is specific and realistic rather than abstract. Instead of "there has been a ransomware attack," write something closer to: it is 9:40 on a Tuesday morning, an employee reports that files on the shared drive have a strange new extension and a text file demanding payment has appeared in several folders. Give the facilitator a short script of what happens next as the group responds, called injects: new information released a few minutes apart to keep the exercise moving and to test how the plan handles surprises, such as "the IT contractor does not answer their phone for the first fifteen minutes" or "a customer calls asking why they cannot reach your website."

Base the scenario on something plausible for your actual business rather than a generic worst case. A firm that relies heavily on email should include an inject where email itself is affected. A business with an on-site server should include the physical detail of walking to that server room. The closer the scenario sits to how your business actually operates, the more the exercise will expose real gaps rather than hypothetical ones.

Running it

The facilitator presents the opening scenario and asks the group what they do first, then follows their incident response plan step by step, releasing the prepared injects at intervals. The job is not to catch people out. It is to ask, at each stage: what does the plan say to do here, and can we actually do it right now with what we have?

• Walk through the plan's stages in order: identify, contain, eradicate, recover, review.
• At each stage, ask who is responsible and confirm they know it is them.
• Test contact details out loud: does anyone actually know the insurer's phone number, or is it filed somewhere nobody has opened in a year?
• Note every point where the group hesitates, disagrees, or has to guess. Those are the gaps the exercise exists to find.
• Keep a simple written log of issues as they come up, rather than trying to remember them for later.

Resist the urge to solve every problem the moment it surfaces. If the group realizes halfway through that nobody knows how to restore from the offsite backup, write that down and keep going. Fixing it properly is a task for after the exercise, not a detour in the middle of it.

What to do with what you learn

The exercise is only worth running if the gaps it finds get fixed. Go through the issue log within a few days, while it is still fresh, and update the incident response plan directly: correct the phone numbers, reassign the role nobody could actually fill, and add the step someone assumed existed but did not. A plan that gets revised after every exercise stays useful. One that gets tested once and never touched again just documents problems instead of solving them.

Repeat the exercise at least once a year, and sooner after any major change to your team or systems. Vary the scenario each time. A team that has only ever practiced one specific version of an attack can be caught off guard by a slightly different one, even if the underlying response should be identical.

A simple exercise for a ten-person company

For a business around that size, a workable exercise runs like this. Invite the owner, whoever handles IT (in-house or a contractor on the phone), and whoever would field customer questions, three or four people in total. Set aside ninety minutes. Use the Tuesday-morning scenario above, adapted to name your actual systems and your actual backup setup. Release four or five injects over the session: the IT contact being briefly unreachable, a customer asking about a delay, a question about whether to pay the ransom, and confirmation that a backup from two days earlier appears usable.

By the end, you should have a short, specific list: which contact details were wrong, which step in the plan nobody could actually complete, and which decision the group was unsure who should make. That list, not a sense of having done the exercise, is the actual output. Fix it, and the next real incident starts from a plan that has already survived a dry run.

Where this fits

This exercise tests the plan described in our incident response plan template and prepares your team for the recovery steps in our ransomware survival guide. If you want a structured starting point for the plan you are testing, our editable policy template pack includes an incident response playbook built for small businesses.