Ransomware Readiness: Running Tabletop Exercises That Change Outcomes
Most ransomware plans have never been tested under decision pressure. A well-designed tabletop finds the gaps before an attacker does.
Nearly every enterprise has a ransomware plan. Very few have tested whether the plan survives contact with the decisions it demands — who declares the incident, who talks to regulators, who decides whether to pay, and how the business operates for the two weeks recovery actually takes.
Tabletop exercises are the cheapest way to find that out. Done badly they are a compliance photograph. Done properly they reliably surface findings that change budgets.
Design the scenario for realism, not drama
Effective scenarios reflect how these attacks now unfold: initial access weeks earlier through a third party or stolen credentials, quiet data exfiltration, then encryption timed for a Friday evening or a holiday. Include double extortion — the data is already gone, so recovery from backup does not resolve the disclosure threat.
Ground it in your actual estate. Name the real systems, the real vendors, and the real people. Generic scenarios generate generic findings.
The decision points that matter
- Declaration. Who has authority to declare a major incident at 2am, and how quickly can they be reached?
- Containment trade-off. Who authorises shutting down production systems or disconnecting a site, knowing the revenue cost?
- Payment. Who decides, what is the legal position, is there sanctions exposure, and does insurance participate in the decision?
- Notification. What are the regulatory clocks, when do customers hear, and who signs the external statement?
- Recovery sequencing. Which systems come back first, and who arbitrates between business units competing for the same restoration capacity?
- Manual operation. How does the business ship, invoice, and serve customers with core systems down for ten days?
Facilitation that produces findings
Run it in three timed phases — detection and triage, escalation and decision, recovery and communication — with injects that escalate: a journalist calls, the backup restore fails partway, a customer's data appears on a leak site, an employee posts about the outage.
Two facilitation rules matter more than the scenario. First, ask "show me" rather than accepting "we would": if someone says the contact list is available, make them retrieve it. Second, forbid assumed capability — if backup restoration speed at full scale has never been measured, record it as an unknown rather than accepting an estimate.
Findings that recur
| Finding | Why it matters |
|---|---|
| Backup restoration never tested at full scale | Recovery time objectives are assumptions, not capabilities |
| Backups reachable with production credentials | Attackers destroy them before encrypting |
| Contact lists only in encrypted systems | The team cannot assemble itself |
| No documented payment decision authority | Hours lost while executives establish who decides |
| Unclear notification clocks | Regulatory exposure compounds the incident |
| No manual business process | Revenue loss exceeds the technical damage |
The backup finding is the most consequential. Immutable, credential-isolated backups plus a measured full-scale restore test are worth more than most detection spending, because they change the negotiating position entirely.
Convert findings into funded work
Close the exercise by assigning every gap an owner, a remediation action, and a date, then report to the executive sponsor with two numbers: measured recovery time versus the business's stated tolerance, and the estimated revenue impact of that gap. Framing resilience investment against a quantified downtime cost is far more persuasive than a maturity score.
Then re-run within twelve months using a different scenario. Readiness decays as staff, vendors, and architecture change.
Frequently asked questions
What is a ransomware tabletop exercise?
A facilitated simulation where leadership and technical teams work through a realistic attack in real time, making the decisions an actual incident would demand and exposing gaps in plans, authority, and recovery capability.
How often should we run one?
Twice yearly — one executive-focused and one technical — plus an extra run after major changes to architecture, vendors, or leadership.
What do teams usually discover?
Untested restoration at scale, backups reachable with production credentials, contact lists inside encrypted systems, undocumented payment authority, and no manual business process.
Who should attend?
Executive decision-makers, IT and security, legal, communications, finance, and at least one operational business leader. Technical-only exercises miss the decisions that cost the most time.