When the War Room Goes Dark: Why Your Ransomware Rehearsal Needs a Kitchen Table

Every security leader in America has sat through the same ritual. A facilitator distributes a scenario packet, the executive team gathers around a conference table with catered coffee, and someone reads aloud: 'It is 7:42 a.m. on a Tuesday. Encryption is spreading across the file servers.' The room nods. Someone suggests 'activating the IR retainer.' Ninety minutes later, everyone signs a sign-in sheet and returns to their inbox feeling prepared.

They are not prepared. The gap between the exercise and the event is not a matter of degree — it is a matter of kind. Real ransomware incidents do not begin in conference rooms with complete information. They begin at 3 a.m. with a phone call to a personal number, a CISO driving toward the office while fielding questions from a spouse, and a CEO who has not slept and is being texted by a board member who heard something from someone.

The Conference Room Is a Controlled Environment That Will Not Exist

Consider what a typical tabletop provides that a real incident will not:

• Colocation. In the drill, decision-makers are in one room. In the event, your CFO may be on a flight to Denver, your general counsel may be unreachable, and your incident commander may be managing the crisis from a phone hotspot in a parking garage.
• Perfect information flow. Facilitators hand out facts in digestible increments. Attackers do not. They detonate systems, delete backups, and leave your team guessing whether the exfiltration claim in the ransom note is true.
• Emotional neutrality. Nobody in the drill is worried about personal liability, their reputation, or whether they can make their daughter's recital. In the real event, these pressures shape decisions as much as any technical fact.
• An intact communications fabric. The exercise assumes email, Slack, and Teams work. Ransomware crews routinely target identity and collaboration platforms first, precisely to sever coordination.

When we debrief organizations that have lived through actual deployments, the recurring theme is not technical failure. It is decision failure under conditions the tabletop never simulated.

Designing a Lived-In Simulation

A meaningful rehearsal should feel less like a training seminar and more like the first six hours of a real crisis. We recommend what we call a lived-in simulation — an exercise built around constraint, not content.

1. Separate the players physically. Executives participate from their homes or cars, communicating only through the channels that would actually survive an incident: personal cell phones, a pre-established out-of-band bridge, or — for the bold — a dedicated messaging app nobody uses day to day. The friction this creates is the lesson.

2. Degrade information deliberately. Inject the scenario through the channels people actually monitor. A voicemail at an unusual hour. A text thread that fills in slowly. Conflicting reports from two different IT staff members who disagree about the scope. Real incidents are ambiguity engines; the exercise should be too.

3. Introduce the human variables. Halfway through, have a facilitator play the CEO's spouse asking whether they need to come home. Have another play a journalist who has received the extortion email. Have a third play a board member demanding updates every fifteen minutes. These injectors are not theater — they are the actual decision environment.

4. Force the liability conversation. Somewhere in the exercise, present a decision with genuine legal exposure: pay or not pay, notify now or verify first, restore from backups that may be tainted. Require the participants to consult counsel and document their reasoning in real time. The paper trail they fail to create during the drill is exactly the paper trail they will fail to create during the event.

5. Time-box ruthlessly. Give the team four hard deadlines across the exercise. Decision latency under pressure is a measurable metric, and most teams are startled by how long their first critical choice takes.

What the Debrief Should Measure

Skip the satisfaction survey. Instead, score the exercise against five questions:

• How long from first notification to a declared incident commander?
• Did the team successfully move to out-of-band communications, and how quickly?
• Who made the pay/no-pay recommendation, and was counsel actually consulted before it was voiced?
• What decisions were made that no runbook anticipated?
• Where did family obligations, media pressure, or personal fear visibly alter the decision chain?

The last question is the one conventional exercises never ask, and it is the one that matters most. A runbook cannot govern a CEO who is afraid. Only rehearsal can.

The Case for Discomfort

There is a reason organizations resist this format. It is embarrassing. Executives stumble, argue, and reveal how little they know about each other's roles under stress. That embarrassment is the product. A team that has argued about extortion payment authority while a facilitator plays an aggressive reporter is a team that will recognize the moment when it arrives for real.

Ransomware operators study their victims. They know the decision chain — the fatigue, the fear, the fragmented communication — is the softest target in the enterprise. Your exercise program should study it too. Move the rehearsal out of the war room. Put it on the kitchen table, at an inconvenient hour, with the Wi-Fi failing. That is where the incident will actually live.