Why most tabletop exercises fail

Somewhere in the country this week, a leadership team will sit down for a tabletop exercise. A facilitator will put a slide up that says “You’ve been hacked.” Someone will read the scenario aloud. Everyone will go round the table and say what they think they’d do. The notes will be written up. The board pack will say the incident response plan was exercised. And absolutely nothing about how that organisation would behave in a real incident will have changed.

That’s not a tabletop exercise. That’s a meeting with a scenario attached.

Kieren Lovell, who spent a career watching people under pressure before he took the CISO chair, put it more bluntly on our podcast: “A lot of tabletop exercises become discussion workshops.” A slide deck at the front of the room, a circle of “well, this is what I think we’d do,” and almost no decision-making in it.

The frustrating part is that the idea is sound. Rehearsing an incident before it happens is one of the few things in security that has a good evidence base behind it. The military does it every day. Emergency services do it every day. Cyber does it once a year, badly, and then wonders why the real thing goes so wrong.

It goes wrong because of four habits. Every one of them feels like good practice. Every one of them quietly removes the thing that makes rehearsal work.

HABIT ONE: YOU TELL EVERYONE IT’S COMING

The calendar invite goes out three weeks in advance. It has the date, the time, the room, and quite often the theme. “Ransomware tabletop, Thursday 2pm, Boardroom 2.” People do their pre-reading. Someone digs out the plan.

You have just tested nothing.

The first question a real incident asks is not “what’s your plan?” It’s “can you find the people who are supposed to execute it?” Who has the out-of-hours numbers? Are they current? Does the escalation route in the document actually reach a human being on a Sunday? You cannot find that out if everyone is already in the room with a coffee.

Kieren refuses to give a theme or a start time. “Because I want to know: does that emergency SOP of where I contact you actually bloody work?” At Cambridge, it didn’t. Half the team turned up at the old HQ and half at the new one, because two versions of the same document were in circulation. He calls that a good learning outcome. He’s right. You only get it if you don’t warn everyone first.

What to do instead. Fix a window, not a date. Tell the leadership team that at some point in the next month an exercise will start, and that it will start the way a real one does: with a phone call, a message, a ticket, not a meeting request. The first fifteen minutes of your exercise should be about whether the right people can be reached and assembled. If that part goes badly, congratulations. You’ve found the finding.

HABIT TWO: YOU DISCUSS INSTEAD OF DECIDE

This is the one that turns an exercise into a workshop. The facilitator reads an inject. Then the room talks about it. “I suppose we’d want to get legal involved at this point.” “We’d probably notify the regulator.” “I think comms would draft something.” Nobody actually does any of it. Nobody owns a decision. The conversation drifts to what the policy says, and everyone leaves having agreed that the policy is broadly fine.

In a real incident, the conversation is not the work. The decision is the work. Do we take the payment system offline now, knowing it will cost us the afternoon’s trade, or wait for confirmation? Do we tell customers today or tomorrow? Who tells the CEO, and what exactly do they say?

The thing people fear is making the wrong call. Kieren’s view: “It doesn’t matter if you make a bad decision. It matters if you make no decision. If you make the wrong decision, you’ll quickly know about it, and you can rectify.” An organisation that has rehearsed deciding under pressure will make a bad call at 10am and correct it by 10.20. An organisation that has only rehearsed discussing will still be discussing at lunchtime.

What to do instead. Every inject ends with a decision that has a name on it and a time limit. Not “what would we do?” but “what are we doing, who is doing it, and it’s decided in four minutes.” Write the decision down before the next inject lands. Then, in the debrief, look at the decisions rather than the discussion. Which ones were slow? Which ones bounced between three people because nobody knew they owned it? That’s your plan telling you where it’s broken.

HABIT THREE: YOU MAKE IT REALISTIC INSTEAD OF HARD

Everyone asks for a scenario tailored to their own organisation. Our systems, our suppliers, our sector, our specific flavour of ransomware. It feels rigorous. What it usually does is hand the exercise to the two or three people in the room who understand the technology, while everyone else watches.

Most incidents don’t fail on technical grounds. Kieren again: “most incidents you have, it’s because the technical team can’t talk to the management. The management can’t talk to the command. Legal can’t understand each other… you end up splintering into silos.” A hyper-realistic scenario rehearses exactly the thing that wasn’t the problem, and lets the actual problem, the communication between people who don’t share a vocabulary, go untested.

His counter-intuitive fix is a ridiculous scenario. Something none of them have a playbook for. “It gets you into a good situation if you’re practising an exercise where all of you haven’t a clue. Because then you’re all at a loss.” Now nobody can hide behind expertise. The room has to work out who’s in command, how information flows, and how a decision gets made when the plan doesn’t cover it. Which is what a real incident feels like, because the real incident never matches the plan either.

What to do instead. Rehearse the principles before you rehearse the playbook. Command, communication, clear messaging. If you’re early in your maturity, use a scenario that sits slightly outside anyone’s comfort zone so that the whole room is genuinely improvising. Save the bespoke, sector-specific runbook rehearsal for when the basics already hold. The plot is not the point. What the room does when the plot goes sideways is the point.

HABIT FOUR: NOTHING PUSHES BACK

The last habit is the quietest one. In most tabletops, whatever the room says, the facilitator accepts. “We’d isolate the affected servers.” Good. Next inject. “We’d issue a holding statement.” Great. Moving on. The scenario proceeds on rails regardless of what anyone decides, the clock never runs, and by 3pm the incident is neatly resolved because the agenda said it would be.

A real incident doesn’t accept your answer. It reacts to it. Isolate the servers and finance can’t run payroll tomorrow. Issue a holding statement and a journalist rings the front desk twenty minutes later with a question it didn’t cover. Wait for more information and the attacker publishes a sample. Every decision creates the next problem. That’s what pressure actually is: not a scary slide, but consequences arriving faster than you can process them.

Kieren’s model for this is the choose your own adventure book. “Press the red button, page 42. You are screwed.” Real time. Real escalation. Media injects. Then learn from the impact. If a tabletop can’t be failed, it isn’t a test. It’s a read-through.

What to do instead. Design the exercise so that decisions have consequences and delay has a cost. If the room dithers, something gets worse. If they choose badly, the next inject reflects it. Put a clock on the wall and mean it. And write the debrief around what happened as a result of their decisions, not around whether they said the things the policy expects them to say.

THE MEETING TEST

There’s a simple way to tell which one you’ve been running. Ask yourself: at any point, did anyone in that room feel behind? Did anyone have to make a call they weren’t sure about, with people waiting on them, with the situation moving before they’d finished? Did anything go wrong that wasn’t on the slide?

If not, you had a meeting. A useful one, maybe. But you didn’t test resilience, because resilience is what’s left when the plan runs out and the pressure doesn’t.

You don’t rise to the occasion in a real incident. You fall to the level of your preparation. Four habits are keeping that level lower than it looks in the board pack. All four are fixable this quarter.

If you want to try the fixed version without buying anything: we’ve put together a free Run Your Own Tabletop pack. One scenario, one hour, no consultant, no slides. It’s built around decisions with time limits, and it’s the cheapest way to discover that three people in your leadership team each assumed somebody else was calling the insurer.

If you want the pressure to be real: CMD is our cyber resilience tabletop exercise platform. It doesn’t announce itself. It rings people’s actual phones. Decisions branch, delay costs, and nothing in it runs on rails. It’s what a tabletop looks like when you take all four habits out.