How to Run a Ransomware Tabletop Exercise

Why ransomware first

Ransomware combines several kinds of pressure that other incidents don't always have all at once: a hard deadline (the ransom note), genuine uncertainty (is data actually stolen, or is that a bluff?), and a decision that touches nearly every part of the organization — IT, legal, finance, communications, and leadership all have a stake. That makes it an unusually good first exercise: it forces your team to practice cross-functional coordination under time pressure, which is the actual skill you're building, more than any specific technical response.

1. Scope it before you schedule it

Decide who needs to be in the room before you pick a date. At minimum, you want someone who can speak for IT/security, someone who can make business continuity calls (often an executive or operations lead), and someone who understands your legal and notification obligations — even if that's an outside counsel relationship rather than in-house staff. If any of those roles will be played by a stand-in during the exercise, say so up front so participants don't confuse rehearsal with reality.

Pick a duration that matches your team's experience. If this is anyone's first tabletop, 60 minutes is plenty — you're building the habit of structured thinking under pressure, not testing every possible branch. Teams with a few exercises under their belt can handle 90 to 120 minutes with more injects and more ambiguity.

2. Write (or adapt) a believable opening briefing

The best ransomware openings are mundane on purpose: a few employees can't open files, IT hasn't confirmed scope yet, nobody remembers clicking anything suspicious. Resist the urge to open with the ransom note already visible — the early, ambiguous phase is where most real organizations actually struggle, because it's not obvious yet that this is "the big one."

3. Build injects around decisions, not technology

A common mistake is writing injects that are really just technical trivia ("what port does the malware use?"). Good ransomware injects force a decision with a real tradeoff:

• Backups might be affected — do you wait to confirm, or start manual workarounds now?
• The ransom note threatens to leak stolen data — who even has authority to consider that, and what do they need to know first?
• A customer is asking questions before you have an official statement — what do front-line staff say right now?

Six to ten injects is usually the right range. Fewer than six and you don't cover enough ground; more than ten and discussion gets rushed just to get through the material.

4. Facilitate for decisions, not for "correct answers"

There often isn't a single right call — whether to pay, when to notify, how fast to restore from backups all involve real tradeoffs that depend on facts your team won't fully have. Your job as facilitator is to make sure a decision actually gets made, that someone owns it, and that the group can articulate why. If the group is stuck debating hypotheticals, introduce the next inject to move things forward — you can always circle back in discussion.

5. Keep a live decision log

Assign a dedicated note-taker before you start. Every time the group makes a real decision, log the time, what was decided, who made the call, and the one-line reason why. This log becomes the spine of your after-action report — without it, you'll be reconstructing the exercise from memory.

6. Debrief while it's fresh

Spend the last 10-15 minutes capturing what worked, what didn't, and one or two concrete fixes with owners and dates. A tabletop that doesn't produce at least one assigned action item was a discussion, not an exercise.

A note on realism

Keep the technical detail at the level of business decisions, not attacker tradecraft. You don't need (and shouldn't include) real exploit techniques or malware behavior to make a ransomware exercise realistic — the pressure comes from the decisions, not the technical specifics.