How to Run a Ransomware Tabletop Exercise
A ransomware tabletop is the cheapest way to find out whether your organization can actually respond to an attack — before an attacker forces the test. This guide shows you how to run a credible one end to end: set objectives, get the right people in the room, write staged injects that feel real, facilitate the discussion, capture the gaps, and turn them into an after-action report leadership will fund.
In plain words
Running a ransomware tabletop exercise means walking your leadership and response team through a simulated attack as a facilitated discussion — no production systems are touched. You set two or three objectives, gather the people who would really make the decisions (IT, security, legal, comms, an executive, plus your insurer and IR retainer), and release the crisis in stages: detection, spread, data-extortion, the ransom demand, a backup-restore test, and media or regulator pressure.
A facilitator runs the clock and delivers the injects while separate evaluators note every stalled decision, missing contact and untested backup. The output is an after-action report — prioritized findings, each with a named owner and a target date. CISA’s tabletop packages (CTEPs) and NIST SP 800-84 are solid, free starting points to adapt.
Step by step
- 1
Set objectives and scope
Decide what the exercise must prove before you write a word of scenario. Pick two or three concrete objectives — for example, "validate that we can declare an incident and reach legal and the insurer within an hour," or "test whether we can restore a critical system from backup without the production environment." Define the scope: which business units, which systems, which decisions are in play, and explicitly what is out of bounds. CISA's tabletop exercise packages (CTEPs) and NIST SP 800-84 both stress that objectives drive the design — a tabletop with no measurable objective produces a pleasant chat and no findings.
- 2
Assemble the right participants
A ransomware event is a business crisis, not an IT ticket, so the room needs more than engineers. Invite IT and security operations (who see the technical reality), legal (breach-notification obligations, privilege, ransom-payment legality), communications (internal, customer and press messaging), an executive sponsor who can actually authorize decisions, and — crucially — your cyber-insurer contact and incident-response retainer firm, because they are decision-makers in a real event and must be in the rehearsal. Finance and HR often belong too. Keep the group small enough to have a real conversation; split a very large organization into a core group plus observers.
- 3
Write a realistic scenario with staged injects
Build the scenario as a timeline of injects — new pieces of information released in sequence — rather than one static prompt. A credible ransomware arc moves through: initial detection (an EDR alert or a user reporting encrypted files on a share); spread and scope discovery (more hosts, a domain controller, a backup server touched); data-exfiltration extortion (the attacker claims to have copied sensitive data and threatens to leak it); the ransom demand itself (amount, deadline, payment mechanics); a backup-restore test (do the backups exist, are they clean, how long does restore actually take); and external pressure (a journalist calls, a regulator deadline looms, customers start asking). Draw the technical details from real tradecraft so they feel authentic, but keep the numbers and facts you assert accurate — do not invent statistics to add drama.
- 4
Assign a facilitator and evaluators
Separate the two roles. The facilitator runs the clock, delivers injects, keeps the discussion moving and stays neutral — they are not there to solve the incident. Evaluators (sometimes called data collectors) watch against the objectives and the organization's own plans, noting where a decision stalled, a role was unclear, a document could not be found, or an assumption proved false. NIST SP 800-84 describes this facilitator-plus-evaluator structure; keeping them distinct is what turns a discussion into findings you can act on.
- 5
Run the discussion inject by inject
Deliver the first inject, then ask the room open questions: What do we do now? Who makes this call? What do we need that we do not have? Let the participants work the problem using their real plans and tools — the point is to surface how the organization would actually behave, not to recite the runbook. Resist the urge to rescue the group when they get stuck; a stall is a finding. Move to the next inject when the current one has been worked through or when the clock says so. Keep the "ransom demand" and "pay or not" discussion grounded: note the legal, sanctions and insurer considerations rather than treating it as a yes/no.
- 6
Capture decisions, assumptions and gaps in real time
Have a dedicated scribe record every decision made, every assumption the group relied on, and every gap exposed — a missing contact, an out-of-date playbook, an untested backup, an unclear approval authority, a tool nobody could log into. Tag each gap to the objective it threatens and to an owner area. Capturing this live, while the context is fresh, is far more reliable than reconstructing it afterward from memory.
- 7
Write the after-action report with owners and timelines
Within a week, convert the captured notes into an after-action report (an AAR, sometimes an improvement plan in CISA terminology): a short narrative of how the exercise went, the strengths observed, and a prioritized list of findings. Each finding gets a named owner, a concrete corrective action, and a target date — a finding with no owner and no date will not get fixed. Share it with leadership, track the actions to closure, and schedule the next exercise so the program improves rather than resetting each year.
Draft the incident-response playbook your tabletop will test — roles, decision points, escalation and communications — in a guided, browser-based lab, so the exercise exposes gaps in the plan instead of the absence of one.
Related
Build the incident-response playbook this exercise is designed to stress-test.
Ransomware readiness scorecardScore where your ransomware defenses and recovery stand before you run the exercise.
Ransomware payment decision toolWork through the legal, sanctions and insurer factors behind the pay-or-not inject.
How to build an IR playbookThe companion guide to writing the plan your tabletop puts under pressure.
NIST CSF toolkitMap your Respond and Recover gaps back to a framework leadership recognizes.
Frequently asked questions
What is a ransomware tabletop exercise?
It is a discussion-based rehearsal in which leadership and the response team talk through a simulated ransomware incident, guided by a facilitator who releases information in stages (injects). Nobody touches production systems — the value is in surfacing how the organization would decide and coordinate under pressure, exposing gaps in plans, roles and assumptions before a real attacker does.
Who should be in the room?
More than IT. A good ransomware tabletop includes security operations, IT, legal, communications, an executive who can authorize decisions, and your cyber-insurer and incident-response retainer contacts, because they are real decision-makers during an incident. Finance and HR often belong too. Keep the active group small enough for genuine discussion and seat anyone else as observers.
How long should it take?
A focused ransomware tabletop typically runs two to four hours including a hot-wash discussion at the end, though a complex scenario across many stakeholders can take a full day. Planning and scenario development take longer than the exercise itself. Budget time afterward to write the after-action report while the discussion is still fresh.
What makes a scenario realistic without being alarmist?
Stage it as a timeline of injects that mirror real ransomware tradecraft — initial detection, spread, data-exfiltration extortion, the ransom demand, a backup-restore test, and external pressure from media or regulators. Ground the technical details in how these attacks actually unfold, but keep every fact and figure you assert accurate. Invented statistics undermine the credibility of the whole exercise.
Should we rehearse the decision to pay a ransom?
Yes — but as a structured discussion of the factors, not a simple yes or no. The inject should force the group to weigh legal and sanctions exposure, insurer involvement and coverage conditions, the realistic likelihood of data recovery, and the separate extortion threat to leak exfiltrated data even if you can restore. The goal is to establish who decides and what inputs they need, so a real event is not the first time these questions are asked.
Where can I find trustworthy templates?
CISA publishes tabletop exercise packages (CTEPs), including ransomware-focused situation manuals and facilitator materials, that you can adapt. NIST Special Publication 800-84 provides the underlying guidance on building a test, training and exercise program — objectives, roles, conduct and after-action reporting. Both are free and widely accepted as starting points; tailor them to your own environment rather than running them verbatim.
What should come out of the exercise?
A prioritized after-action report. It records what went well, the findings (missing contacts, stale playbooks, untested backups, unclear authority), and for each finding a named owner, a concrete corrective action and a target date. Tracking those actions to closure — and running the next exercise to confirm they worked — is what turns a one-off rehearsal into an improving program.