Most Tabletop Exercises Are Theatre

I've sat through a lot of tabletop exercises. Run a fair number too. Most of them were a waste of a Thursday afternoon.

Not because the scenario was bad. Not because the facilitator was bad. Because everybody in the room already knew how it was going to end. The plan gets pulled up on the screen. Somebody reads the ransomware inject. Everyone nods. IT says they'd isolate the segment. Legal says they'd assess notification obligations. Comms says they'd prepare a holding statement. Ninety minutes later there's a findings report with three medium-severity gaps and a recommendation to update the contact list.

Then the report goes into the binder that gets shown to the auditor and the insurer. Job done.

That's not an exercise. That's a rehearsal for a play where nobody gets hurt.

The numbers say you're not ready, and you know it

You don't have to take my word for it. Sygnia surveyed 600 senior security leaders earlier this year, and 73% said they would not be fully ready if a significant attack landed tomorrow. Three-quarters of them had been hit at least once in the previous twelve months. So this isn't a crowd guessing at a hypothetical. They've seen it and they still don't feel ready.

Two more numbers from the same survey are the ones I'd put in front of a board. Ninety percent expect trouble coordinating stakeholders during a major incident. And 89% say executive or board involvement in readiness work is limited.

Read those together. The people who will have to make the hard calls during a breach are the ones least likely to have practiced making them. And the security team knows it.

Meanwhile IBM's 2026 report puts the global average breach at $4.99 million, with ransomware now showing up in 39% of incidents, up from 34% the year before. The bill is going up and the practice isn't.

Why the exercise fails

A typical tabletop tests three things: whether the plan exists, whether people can read it, and whether the facilitator can fill ninety minutes.

A real incident tests whether the CEO will authorize a ransom payment at 2 a.m. with incomplete information. Whether the CFO knows which bank contact to call when payroll is in 36 hours and the ERP is encrypted. Whether anyone in the room can tell the difference between "we've contained it" and "we've stopped seeing alerts." Whether the board chair can be reached, and what they're going to say when they are.

None of those show up in a plan-walkthrough. They can't. A plan is a document. An incident is a series of decisions under pressure with bad information and a clock running.

So the exercise tests the document and skips the decisions. Then the organization files the result as evidence of readiness. That's how you get 73%.

There's a second failure, and it's structural. Most tabletops are built and run by the security team, for the security team, with executives invited as observers. The technical people practice their part. The executives watch. Then during the real thing, the technical people execute fine and the executives freeze, argue, or go around them. Guess which one ends up in the post-incident review as "communication breakdown."

Who's actually being tested

Flip it. The security team doesn't need to practice isolating a host. They do that in real life. The people who need to practice are the ones who've never had to decide anything during an incident.

That means the exercise should be uncomfortable for the executives, not the analysts. If your CEO leaves a tabletop feeling good, it wasn't a tabletop. It was a briefing.

I want the CEO asked a question they can't answer and given four minutes to answer it anyway. I want the CFO handed a wire instruction from the threat actor and told the negotiator needs a decision. I want the general counsel discovering, in the room, that the cyber insurance policy requires the carrier's approved IR firm and nobody knows who that is. I want the head of HR finding out that the incident started with a contractor account nobody offboarded.

Not to embarrass anyone. To surface the actual decision points before they cost real money.

If you're small, this applies more, not less

A 40-person company with an MSP doesn't get a pass here. It gets less margin for error.

The enterprise version of this problem is executives who don't practice. The SMB version is an owner who assumes the MSP has it handled and an MSP who assumes the owner will make the call. Neither has said that out loud. So on the day, the MSP is waiting for authorization to take systems down and the owner is waiting for the MSP to fix it. Both are waiting. The encryption isn't.

If you run an MSP, run the tabletop with your client's owner in the room and make them decide something. It's the cheapest sales tool you'll ever use, and it might save the account. If you're the owner, ask your MSP what they'll need from you in the first hour of a ransomware incident. If the answer is "nothing, we've got it," that's the wrong answer. They need a decision-maker, and it's you.

What a real one looks like

Some things I insist on when I run these now. None of them are complicated. Most organizations skip all of them.

No plan on the screen. Participants can have it, but the exercise doesn't walk it. If the plan is any good, people will reach for it on their own. If they don't, that tells you something the walkthrough never would.

Injects arrive with missing information, and the facilitator doesn't fill it in. "We think it's ransomware. We're not sure how many systems. Backups status is unknown." Decide anyway. Real incidents don't wait for clarity.

Time pressure is real. Fifteen minutes to a decision, then the scenario moves on with whatever they chose or didn't. Indecision has consequences in the script. If nobody authorized the shutdown, the encryption spreads.

Someone plays the outside world. A reporter with a deadline. A major customer's CISO who's heard rumours. A regulator asking for the notification timeline. These are the pressures that actually shape executive behaviour during a breach, and they're the ones every tabletop leaves out.

The board is in the room, or at least the chair is. Not observing. Playing. If the board chair has never been in a simulated call where management asks for authority to pay, the first time will be the real one.

And the findings report is about decisions, not documents. Who decided what, how long it took, what information they wanted that they didn't have, and where two people thought they each had authority for the same call. Those are the gaps that matter. "Contact list out of date" is a footnote.

The honest caveat

A good tabletop doesn't make you ready. It makes you less unready. There's a difference, and anyone selling you the first one is overpromising.

You can rehearse decisions but you can't rehearse the fear, and fear changes people. The executive who was decisive in the exercise may stall when it's their name on the disclosure. That's fine. The exercise can't guarantee good behaviour. What it can do is make sure the first time your leadership team argues about paying a ransom, it's in a conference room and not on a bridge call with the negotiator listening.

Also, once a year isn't enough if anything changed. New CEO, new ERP, acquisition, major cloud move. Any of those resets the clock. The plan you tested in January describes an organization that doesn't exist by June.

The bottom line

If your last tabletop produced a report and a warm feeling, you paid for theatre. Look at who was sweating in that room. If it was the security team, the exercise pointed the wrong way.

Put the executives in the chair. Take the plan off the screen. Withhold the information. Run the clock. Make the board chair say yes or no to something. Then write down what happened.

Smaller exercise. Meaner one. And it's the only version that will tell you anything you don't already know.