Playbook · tabletop

The first time your team runs the plan shouldn’t be during the breach.

Most incident-response plans are written, signed off, and never tested until the day they’re needed, which is the worst possible day to discover they don’t work. A tabletop exercise fixes that for the price of one well-run meeting. Here’s everything you need to run your first one, including a complete scenario you can use today.

Why an hour buys so much

A plan on paper is just an assumption.

Your incident-response plan says the right things. It names the steps, the contacts, the escalation path. On paper it’s flawless. The trouble is that paper never panics, and a real morning does. Pressure is where the gaps show: the contact who left last year, the backup nobody’s ever restored, the regulatory deadline nobody can quite remember.

A tabletop is a controlled way to apply that pressure before an attacker does. You sit your decision-makers in a room, hand them a realistic incident, and watch them work the problem out loud. No live systems are touched. Nothing real breaks. But the assumptions break, and that’s exactly what you want. In a meeting, the cost of being wrong is a slightly awkward silence instead of a front-page story.

What you’re actually running

A discussion, not a fire drill.

A tabletop is a discussion-based walkthrough. People talk through what they’d do as a scenario unfolds in stages. The facilitator describes events, the players make decisions, and a scribe captures where things go wrong. It runs on a conference table, not a keyboard.

What it is
  • A talk-through of decisions under a realistic scenario
  • A test of people, plans and ownership
  • Run in a meeting room, no systems touched
  • Designed to surface gaps cheaply and safely
What it isn’t
  • A technical drill on live or test systems
  • A red-team engagement or a penetration test
  • A pass/fail exam to grade individuals
  • Useful without an honest debrief afterwards

If you want to test whether your defences actually hold, that’s a different exercise: a red team or a live IR drill. A tabletop tests whether your people and your plan hold. Start here; the technical drills come once you know the humans are ready.

Set it up · the room

Three kinds of people in the room.

A tabletop needs a facilitator to run it, players to make the calls, and an evaluator to write down what happens. Keep the player group to the people who’d genuinely make decisions on the day. Spectators dilute the pressure.

Runs the game

Facilitator

One person runs the room. They read the injects, keep time, push the team off easy answers, and make sure quiet people get heard. They don’t play a part and they don’t solve the problem. Their only job is to keep the pressure on. Pick someone who can chair a meeting and isn’t afraid to interrupt the CEO.

Make the calls

The players

The people who would actually make the calls in a real incident. IT and security for the technical reality. Legal for breach-notification and liability. Comms for what you say and when. An executive sponsor who can authorise spend, downtime and a public statement. HR if staff data is in play. Eight is plenty; twelve is a crowd.

Keeps score

The evaluator

A scribe who isn’t playing. They write down every decision, every assumption, and, above all, every moment someone says “I assumed someone else owned that.” Those gaps are exactly what you’re there to surface. Give them the debrief template before you start and let them fill it as the exercise runs.

Set it up · the prep

Most of the value is in the setup.

A good tabletop is mostly preparation. An hour of thought beforehand turns a vague chat into a sharp test. Here’s what to lock down before anyone walks in.

01Set one objective

Don’t test everything. Pick a single goal: “Can we contain ransomware and notify the regulator inside the deadline?” A tight scope produces a useful debrief. A sprawling one produces a vague feeling that things went badly.

02Brief the players, not the plot

Tell people the date, the duration, the roles and the rough theme. Never share the injects in advance. Surprise is what exposes the gap between the plan on the shelf and the plan in people’s heads.

03Put the real artefacts on the table

Bring the actual incident-response plan, the call tree, the cyber-insurance policy, and the contact list. The exercise is partly a test of whether those documents survive contact with a bad morning. Often they don’t.

04Choose a believable scenario

It should map to a threat you genuinely face and to systems you genuinely run. A ransomware drill for a company with no critical on-prem systems wastes everyone’s time. Match the scenario to your business.

Set it up · the ground rules

Four rules that make it worth doing.

State these out loud before the first inject. They separate a real test from a comfortable meeting where everyone agrees the plan is fine. Timing: 60 to 120 minutes for the whole thing, injects plus debrief.

01Ban “we’d just…”

The fastest way to ruin a tabletop is the phrase “we’d just restore from backup” or “we’d just call the vendor.” Make people prove it. Who has the credentials? Where’s the runbook? Is the contact still employed here? If the answer is a shrug, that’s a finding.

02Make the call

No deferring, no “we’d escalate that.” In the room, the person whose job it is decides, out loud, now. Watching someone struggle to make a hard call under mild pressure tells you exactly how it goes under real pressure.

03No phones to the real world

Nobody actually pages the on-call engineer or emails the regulator. The facilitator plays every outside party. Keep it sealed so the exercise stays an exercise.

04Time-box hard

Sixty to ninety minutes of injects, then a debrief while it’s fresh. Two hours is the ceiling. Past that, fatigue sets in and people start agreeing just to end the meeting.

The ready-to-run scenario

Deal the ransomware morning, round by round.

A fictional scenario you can run today. Swap in your own systems, departments and regulator. Scroll to deal each round; the team works it before the next card lands. Don’t skip ahead. The escalation is where it gets real.

Tabletop · “Ransomware Morning”
Players
6–8, plus 1 facilitator & 1 scorekeeper
Play time
90 min, then 30 for the debrief
You’ll need
IR plan · call tree · insurance policy · contact list
Win condition
Reach “recovered” with every hard call owned, in daylight, not at hour 70.
Round 108:14 · Tue

The first signal

The situation

It’s 08:14 on a Tuesday. The IT service desk has had four calls in ten minutes from the finance team: files on the shared drive won’t open, and a few people are seeing a text file on their desktop they don’t recognise. A SOC analyst notices that backups to the secondary site failed overnight. Nothing is officially “down.”

◆ Your move

Is this an incident, and who gets to say so? Decide who has the authority to declare. Does this morning meet that bar yet, or is it still a help-desk ticket? Whoever owns that decision: make the call now, out loud.

Round 208:40

It’s spreading

The situation

By 08:40, three more departments report the same thing. The text file is a ransom note. It names your company, claims 600 GB of data has been copied out, and gives a payment address with a 72-hour countdown before “publication.” The file-encryption is moving across the network. Your EDR console shows it jumping between hosts.

◆ Your move

Do you pull systems offline and eat the downtime? Containment means disconnecting segments, killing VPN, maybe taking the whole network dark, and stopping the business while you do it. Who authorises that, and who absorbs the revenue hit? Decide the containment action and the person who signs off.

Round 309:20

Who do you have to tell

The situation

You’ve confirmed it’s real and you’ve started isolating. The ransom note’s claim of data exfiltration looks plausible: there’s outbound traffic in the logs from two nights ago. Among the affected file shares is one holding customer records and another with employee payroll data.

◆ Your move

Who gets notified, and in what order? Walk the list out loud: legal counsel, the cyber-insurer (before you touch anything, since the policy may require it), the regulator, affected customers, law enforcement. Get the sequence right. Calling the insurer after you’ve hired your own forensics firm can void the cover.

Round 411:30

The clock and the leak

The situation

It’s now 11:30. A journalist emails your press inbox: “We understand you’ve suffered a ransomware attack and customer data is affected. Do you have a comment?” At the same time, your legal lead reminds the room that if personal data is confirmed breached, the regulatory notification clock may be as short as 72 hours from the point of awareness.

◆ Your move

What do you say, to whom, and when? Draft the holding line for staff, for customers, and for the press. Three different audiences. Decide who is the single named spokesperson. And start the regulatory clock: when did “awareness” begin, and who owns hitting that deadline?

Round 5Day 1 · PM

The ransom question

The situation

Forensics confirms the backups were encrypted too. The attacker reached them first. Restoration from clean backups will take an estimated nine days. The attacker, via their portal, drops the demand to a “discount” if you pay within 24 hours and provides a sample of stolen files to prove they have them.

◆ Your move

Do you pay? Put it on the table properly. Who decides, and is it even legal to pay, given sanctions rules on certain groups? What does your insurer say? What does paying actually buy you, and what doesn’t it? There’s no clean answer. Make the team sit in it.

Round 6Day 3

Recovery and the morning after

The situation

It’s day three. You’ve contained the spread and you’re rebuilding from the one offline backup set that survived. The journalist has published. Customers are calling. An executive asks the question every executive asks: “When are we back to normal, and how do we make sure this never happens again?”

◆ Your move

What does “recovered” mean, and who declares it? Define the criteria for normal operations. Then decide the three things you’ll change because of this, and who owns each one, with a date. An incident you don’t learn from is just damage.

Recovered?

Define what “recovered” means and who declares it, then leave with the three things you’ll change, each with one named owner and one date. An incident you don’t learn from is just damage.

The hard questions

What every tabletop should answer.

If you walk out of the room with honest answers to these, the hour paid for itself. If any answer is a shrug or a “someone deals with that,” you’ve found exactly what the exercise was for.

01

Who has the authority to declare an incident, by name, not by job title?

02

At what point do we disconnect systems, and who signs off on the downtime?

03

What’s the notification order: insurer, legal, regulator, customers, law enforcement?

04

What’s our regulatory clock, when does it start, and who owns hitting it?

05

Who is the single spokesperson, and where are the holding statements kept?

06

Do we have offline, tested, restorable backups, and who has actually restored from them?

07

What does the cyber-insurance policy require us to do first, and who’s read it?

08

Where is the incident-response plan, and does anyone outside IT know it exists?

09

Who is our retained forensics and IR firm, and how fast can we reach them out of hours?

10

What’s our position on paying a ransom, decided now, in daylight, not at hour 70?

Run the debrief

No debrief, no exercise.

This is where tabletops live or die. Run the debrief immediately, while the discomfort is still fresh and nobody has rationalised the gaps away. Twenty to thirty minutes, four columns, one honest conversation. Then write it up and send it within two days.

01What worked

Name the decisions that were fast, clear and correctly owned. These are the muscles to protect. Be specific: “Legal knew the notification deadline cold” beats “comms went well.”

02What broke

Every moment of hesitation, confusion or “I thought you had that.” Don’t soften it. The whole value of the hour is in this column. A finding hidden to spare feelings is a finding you’ll meet again for real.

03The gaps

The things that simply weren’t there: a missing runbook, an out-of-date call tree, no offline backup, no agreed ransom stance, a spokesperson who’d never drafted a statement. List them plainly.

04Owner and deadline

Every gap gets one named owner and one date. Not a team, not “IT,” not “Q3.” A person and a day. A debrief without owners is a list of complaints.

The test of a good debrief is simple. A week later, can someone point to a thing that changed because of the exercise? If yes, it worked. If the report sat in a folder, you ran a meeting, not a drill.

Run your own

The checklist, start to finish.

Print this. Work top to bottom. You can run a genuinely useful first tabletop with nothing more than the people, a room, and ninety minutes you’ve actually protected.

  • Pick one objective and one believable scenario that maps to your real systems.
  • Name your facilitator, your players, and your evaluator, and confirm they’ll attend.
  • Block 90 minutes plus 30 for the debrief. Protect it like a board meeting.
  • Gather the real artefacts: IR plan, call tree, insurance policy, contact list.
  • Write or adapt 4–6 escalating injects. Don’t share them in advance.
  • Set the ground rules out loud at the start: no “we’d just,” make the call, time-box.
  • Run it. Let people struggle. The discomfort is the lesson.
  • Debrief while it’s fresh: what worked, what broke, the gaps, owners, deadlines.
  • Send the findings within 48 hours, with owners and dates attached.
  • Put the next tabletop in the calendar before you leave the room.
Go deeper

Where to take it next.

Once you’ve run one, these are the references worth your time. The first gives you pre-built scenario packages; the others are the authoritative guidance on running exercise programmes and handling incidents for real.

Talk to an expert