What should actually happen in a ransomware tabletop exercise?

A ransomware tabletop is a structured conversation, not a performance. Nobody wins by guessing the facilitator’s preferred answer. The exercise is useful when leaders discover which decisions they can make, which facts they will lack, and which recovery assumptions have never been tested.

CISA describes cyber exercises as a way to evaluate or develop an incident response plan and provides tabletop exercise packages for scenarios including ransomware. A mid-market company does not need an elaborate simulation to get value. It does need the right people and a scenario tied to its operations.

Prepare the room before the incident

Include the people who would carry real authority and work: an executive decision maker, IT and security, operations, finance, legal or outside counsel, human resources, communications, and a customer-facing leader. Add key providers where useful, but do not let a managed service provider answer for the company.

Give participants the current incident plan, contact list, insurance notice requirements, system priorities, and recovery assumptions in advance. Do not secretly test whether they can recall documents they have never seen. The exercise is testing the plan and the organization.

Set boundaries. The discussion is not a technical penetration test or a forum to assign fault. Capture gaps without trying to solve every one in the room.

Start with an ordinary discovery

Use a plausible opening: employees cannot access shared files, an endpoint tool reports encryption activity, and a ransom note appears on several devices. Avoid movie-style clues and detailed malware trivia.

Ask what happens in the first thirty minutes. Who has authority to disconnect networks or stop production? How will the team communicate if company email is untrusted? Who calls the insurer, counsel, and incident response provider? Who starts an event log?

The facilitator should press for names and methods. “We would notify leadership” is incomplete. Which leader, through what channel, using which contact list, and who does it if the primary person is traveling?

Introduce uncertainty. The team should not know immediately whether backups are clean, data left the company, or the attacker still has access. Real incident decisions happen before the full picture is available.

Make operations part of the incident

A ransomware scenario is not only an IT outage. Describe what the systems mean to the business.

Can the plant run safely without electronic work instructions or quality records? Can a distributor release orders if inventory is uncertain? Can a service company dispatch technicians and later reconstruct billable work? Who decides whether manual operation is acceptable?

Ask operations to define minimum viable service. Which line, branch, or customer process comes first, and why? What paper or offline procedures exist? How long can they be used before error and reconciliation risk becomes too high?

This often exposes a mismatch between the system recovery list and the order in which the business can restart. An application may technically run while identity, network, data, or a third-party integration it needs remains unavailable.

Force the difficult decisions

As the scenario advances, introduce credible developments: evidence that files may have been taken, a backup job showing unexpected changes, customer calls about missed shipments, or a threat to publish data.

The team should discuss who decides on outside notifications, operational shutdown, restoration sequence, public statements, and any negotiation. Legal counsel should guide legal obligations based on the facts and relevant jurisdictions. The tabletop should not invent a universal notification deadline or treat payment as a simple financial calculation.

The FBI states that it does not support paying ransom because payment does not guarantee data recovery and encourages the criminal model, while recognizing that executives must evaluate their options. It encourages victims to report incidents. See the FBI ransomware guidance. A company should discuss this issue with counsel, law enforcement, its insurer, and qualified response professionals before an incident, not make up a policy under pressure.

Test recovery claims

Ask the team to choose a restore point and sequence. Then question the dependencies. How is the backup administrator authenticated if the domain is compromised? Where are clean installation media and configuration records? Who can validate restored ERP or production data? What evidence is required before a network segment reconnects?

CISA’s StopRansomware Guide includes prevention practices and a response checklist. A discussion can evaluate the plan, but it cannot prove that a backup restores. Pair the tabletop with technical recovery tests at another time.

Do not announce that everything is recovered at the end. Carry the scenario into the awkward period when some systems are back, manual transactions must be reconciled, passwords are changing, and customers want firm dates.

End with ownership

Reserve time for an immediate review. Ask what surprised participants, which decision lacked an owner, which contact or document was missing, and which assumption needs a technical test.

Turn findings into a short action register with an owner and due date. Distinguish urgent gaps, such as an unusable emergency contact list, from longer work such as redesigning network segmentation. Assign one person to update the incident plan and schedule a follow-up review.

Avoid a report that congratulates the team for participating and then lists dozens of generic recommendations. The exercise succeeded if it changed a real plan, clarified authority, or triggered a recovery test.

EdgePoint can facilitate a tabletop when an independent moderator would let internal leaders participate fully. Whether run internally or with help, keep the scenario close to your systems and customers. The best exercise leaves the room a little uncomfortable and the company more prepared.