Field Note: Preparing for a Ransomware Tabletop

Decide which decisions you want to test, then build the scenario backward from them. A tabletop that starts with a dramatic storyline and ends with a slide of lessons learned tests the facilitator’s script, not the organization.

Ransomware is a reasonable thing to rehearse. Verizon’s current Data Breach Investigations Report found ransomware in 48% of the breaches in its dataset. The exercise has a narrower job than that headline. It shows, before an attacker does, whether the people with authority know what to do, in what order, with what information, and with which systems missing.

1. Pick two or three objectives

More than three objectives turns the session into a survey. Choose decisions that are hard and consequential.

• Who can order systems isolated or shut down, and how fast can they decide with incomplete information?

• How does the team communicate when email, chat and the identity platform are unavailable?

• In what order are services restored, and who settles conflicts between business units?

• What triggers legal, privacy, insurer and regulator notification, and who decides?

• What happens if backups are damaged, or if the attacker claims to hold stolen data?

Write each objective as a decision plus a way to observe it. “The incident commander decides on isolation within the time set in the plan” can be assessed. “Improve coordination” cannot.

2. Put the right people in the room

Appoint a facilitator, a scribe and an observer who play no role. The scribe records each decision, who made it, what information they had, and when.

3. Do the pre-work and treat gaps as findings

Collect the real documents before the session: the incident response plan, the contact tree with out-of-band numbers, the list of critical services and their dependencies, backup architecture with measured restore times, identity architecture, insurance terms, and third-party contacts.

CISA’s #StopRansomware Guide advises keeping basic response and communications plans, including hard-copy or offline versions, and testing backups for availability and integrity. Check your own materials against those basics.

Some gaps will surface here: an outdated phone list, a restore nobody has tested, an offline plan nobody can locate. Record them as findings. Do not spend exercise time rediscovering them.

4. Build the scenario around your environment

Pick an entry path your organization could realistically face. CISA’s guide groups ransomware initial access into internet-facing vulnerabilities and misconfigurations, compromised credentials, phishing, precursor malware, advanced social engineering, and third parties and managed service providers. Choose the one that fits your estate. A scenario that begins in a system you do not run teaches nothing. CISA also publishes ready-made tabletop exercise packages that can seed a scenario.

Then add the pressures that make real incidents hard.

• Data theft as well as encryption, with a claim that data will be leaked.

• Identity systems affected, so normal communication and access cannot be trusted.

• Backups targeted. CISA’s response checklist lists backup-impairing commands among the signs to hunt for.

• Conflicting demands from business units about what to restore first.

• Outside questions from a customer, a regulator or a journalist before you have answers.

Build the scenario as a timeline of injects. Each inject should force a decision. The table below is a hypothetical template. Replace the events with ones that match your own systems.

5. Set facilitation rules

• Keep the discussion on decisions. If the room starts designing a new architecture, park it.

• Time-box each inject. Real incidents do not wait for consensus.

• Hold information back. Players work with what they would know at that point, not the full storyline.

• Do not accept “we would call someone” as an answer. Ask who, how, and what the contract says.

• When the plan fails, record the gap and carry on. Fixing it live consumes the session.

• Include one change the plan did not anticipate.

6. Decide the outputs before you start

Produce a short after-action record within days. It should list the decisions taken and their timing, the gaps found with a severity, an owner and due date for each fix, and a date to re-test.

NIST SP 800-61 Rev. 3 frames incident response as part of cybersecurity risk management under CSF 2.0 and aims to improve preparation as well as response and recovery. NIST SP 800-84 gives guidance on designing, conducting and evaluating test, training and exercise events. Use both to plan a cycle rather than a single event: a tabletop first, then technical recovery tests for the findings it raises.

Where tabletops go wrong

• Too many objectives.

• An IT-only room, with no business owner, legal or executive present.

• A scenario too gentle to cost the team its identity systems or its backups.

• No scribe, so nobody can reconstruct the decisions afterward.

• Findings with no owner and no date.

• Treating the tabletop as proof of recovery. A tabletop tests decisions and coordination. It does not prove systems can be restored. That takes a technical recovery test.

Use this note to test resilience under realistic disruption: choose the decisions, build the scenario from your own environment, and leave with owned, dated findings.

Sources

• CISA — #StopRansomware Guide

• CISA — Tabletop Exercise Packages

• NIST — SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile

• NIST — SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities

• Verizon — Data Breach Investigations Report