Ransomware Tabletop Exercise: How to Test Your Response Before It Happens

Most organisations discover the gaps in their ransomware response at the worst possible time: when ransomware is actually running. By then, the decisions about who has authority to shut down systems, whether to pay, who communicates with stakeholders, and how to access backups are being made under conditions of high stress, incomplete information, and public scrutiny. A tabletop exercise does not recreate those conditions perfectly, but it comes closer than anything else most organisations will do.

A well-designed ransomware tabletop exercise surfaces gaps that the incident response plan glossed over. It is not enough to have a plan that says "activate the incident response team." The exercise asks: who activates them, how, when it is 2am on a Saturday, when the person whose number is in the plan is unavailable? These are the questions that determine whether a response goes well or badly, and they only get asked properly when you simulate the scenario.

Designing the Scenario

The scenario should be specific enough to force real decisions but flexible enough to be adapted as the exercise progresses. A generic "ransomware hit us" scenario does not produce the same quality of discussion as one that specifies which systems are affected, what data is at risk, and what the initial detection signal was. Specificity forces participants to engage with the actual constraints of their environment rather than responding to an abstract situation.

A starting scenario template that works well in our facilitation experience: It is Friday afternoon. A help desk ticket reports that a user cannot access their files and is seeing a ransom note. Within the next 30 minutes, two more similar tickets arrive from different departments. The initial investigation suggests the affected systems are in the finance network segment. Remote access is currently available. Backups were last tested six weeks ago. The board meets on Monday.

This scenario immediately raises questions about scope determination, communications timing, backup viability, and stakeholder management under time pressure, all before a decision to shut down anything has been made.

Structuring the Exercise

Tabletop exercises run best with a facilitator who is not a participant. The facilitator's role is to advance the scenario, inject new information at key points, probe assumptions, and ensure that all decision-making dimensions are covered. Exercises that are run by the CISO or IT manager who is also a participant often lose focus on the communication and decision-authority dimensions because the technical response dominates the discussion.

Structure the exercise in phases that mirror an actual incident:

• Detection and initial triage: who is notified, by what mechanism, and what decisions do they make with incomplete information?
• Containment decision: what is the threshold for shutting down systems, who has authority to make that call, and what is the process when that person is unavailable?
• Business continuity: what manual processes exist, which are genuinely viable, and how long can the organisation operate without affected systems?
• External communication: when are customers, suppliers, regulators, and media notified, by whom, and with what message?
• Recovery sequencing: in what order are systems restored, what is the clean-state verification process, and who authorises return to production?
• Payment decision: if raised, who has authority, what is the legal framework, and what conditions would need to be met?

Injections That Reveal the Real Gaps

Scenario injections are pre-planned events that the facilitator introduces at specific decision points to test how the response adapts. Good injections reveal assumptions that the plan did not make explicit. Examples that consistently surface useful findings include: the incident response retainer contact is not responding; a journalist calls the main office number; backups are confirmed intact but the recovery process will take 72 hours; the attacker contacts a senior executive directly via personal email; a second threat actor appears to have accessed the environment independently.

Each injection should generate discussion about who decides, who communicates, and what the decision criteria are. Where participants cannot answer those questions quickly, that gap is a finding. The goal is not to catch people out; it is to identify the specific places where the plan is underdeveloped or where authority and process are unclear.

After the Exercise: Turning Findings Into Improvements

The output of a tabletop exercise is only valuable if it produces concrete changes. Document every gap and assumption failure identified during the exercise, prioritise them by likelihood of impact in a real event, and assign remediation actions with owners and deadlines. Common findings from ransomware tabletops include: no documented out-of-band communication channel for when email is unavailable; unclear authority for the containment decision; backup recovery times not validated; no pre-approved legal advisor for ransom decision scenarios; media communication process not defined.

We recommend running a ransomware tabletop at least annually and after any significant change to the IT environment or the business. The first exercise is always the most revealing; subsequent exercises should incorporate the gaps identified previously to confirm they have been addressed.

Cyberlinx designs and facilitates ransomware tabletop exercises as a standalone service and as part of our IR retainer offering. To discuss running an exercise for your organisation, contact us at info@cyberlinx.com.au.