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 — · 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.

NIS2 requirements: the second regime to know about

Data protection law is not the only European regime a business gets asked about. The NIS2 directive sets baseline cybersecurity and incident-reporting obligations for organisations in a defined list of sectors, and it is the source of most of the security questions that now arrive attached to contracts. The two regimes cover different ground: data protection law governs personal data and what people can ask you to do with it, while the NIS2 requirements govern the security and resilience of network and information systems, whether or not personal data is involved. A single incident can engage both, on separate clocks, to separate authorities.

The directive applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet above ten million euros. That size rule puts most small businesses outside its direct scope, and the honest answer for a ten-person company is usually that the directive does not regulate it. What the size rule does not do is keep the requirements away, because one of them is supply chain security: organisations inside scope are expected to consider the security practices of their direct suppliers, and the way that expectation shows up in the world is as a questionnaire in your inbox.

The measures the directive names are a reasonable checklist for any business, which is why they are worth knowing even when they do not apply to you directly. They cover risk analysis and written security policies, incident handling, business continuity and backups, supply chain security, secure development and vulnerability handling, basic cyber hygiene and training including for management, encryption and access control policies, and multi-factor authentication. Reporting is staged and fast for the organisations it covers: an early warning within twenty-four hours of becoming aware of a significant incident, a fuller notification within seventy-two hours, and a final report within one month.

Because the directive is national law in each member state rather than a single rulebook, the details of scope, thresholds and reporting differ by country. For a fuller explanation of the instrument itself, see our guide to what the NIS2 directive is, and for the supplier side of the supply chain obligation, our walkthrough of vendor risk assessment. The reporting clocks that run alongside data protection deadlines are covered in data breach notification requirements.

Frequently asked questions

Does NIS2 apply to a small business?

NIS2 generally applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet total above ten million euros. Most smaller businesses fall outside its direct scope, unless a member state has specifically designated them or they sit in one of the size-independent categories such as DNS service providers or trust service providers. Being outside scope does not stop the directive reaching you through customers who are inside it.

What is the difference between GDPR and NIS2?

GDPR governs personal data: what you may collect, why you may hold it, and what rights people have over it. NIS2 governs the security and resilience of network and information systems in specific sectors, whether or not personal data is involved. One incident can engage both regimes at once, on separate reporting clocks and to separate authorities.

How long do you have to report a data breach?

Under the European model, a personal data breach is reported to the supervisory authority without undue delay and, where feasible, within seventy-two hours of becoming aware of it, and affected individuals are told without undue delay where the risk to them is high. Organisations in scope of NIS2 carry a separate obligation: an early warning within twenty-four hours, a fuller notification within seventy-two hours, and a final report within one month.

Does a small business need a data protection officer?

Under GDPR a data protection officer is required where the organisation is a public authority, where its core activities involve regular and systematic monitoring of people on a large scale, or where its core activities involve large-scale processing of special category or criminal offence data. Most small businesses meet none of those tests and are not required to appoint one, though naming someone internally as the contact for privacy questions is worth doing regardless.

What should a small business do when a client's security questionnaire asks about NIS2?

Answer what you actually do rather than what you think the client wants to hear. The questions usually cover written security policies, incident handling and how fast you would notify them, multi-factor authentication, access control when staff join and leave, backup and recovery arrangements, and which of your own subprocessors touch their data. Gaps are common, and disclosing one with a date for closing it lands far better than an answer that does not survive the follow-up question.

Do these rules reach a business based outside the EU?

They can. GDPR reaches organisations outside the EU that offer goods or services to people in the EU or monitor their behaviour, and other regions have their own regimes with their own triggers. NIS2 obligations follow the sectors and the member states that transpose it, but its supply chain expectations travel through contracts, which is how they reach suppliers anywhere in the world.

Related reading