A Tabletop That Fails Is Working

Exercises · July 18, 2026 · 9 min read

The tabletop exercise has an unusual failure mode among security activities: it can go smoothly and be worthless, and the smoothness is what conceals the worthlessness.

The recognisable version runs like this. A scenario is circulated in advance. A facilitator reads a situation. Participants describe what they would do, in the conditional tense, and each description sounds sensible because nothing prevents it from sounding sensible. Someone says “we’d escalate to the crisis team”. Someone says “we’d bring in the forensics retainer”. The session ends on schedule, a report notes strong engagement, and the organisation has learned nothing it did not believe two hours earlier.

An exercise that produces no failure has not tested anything. Designing for failure — deliberately, in a way that is safe to fail in — is the whole craft.

Test decisions, not knowledge

The first design error is building the scenario around a technical puzzle. How did they get in, what is this malware, which log would show it. Those questions have answers, someone in the room usually knows them, and the exercise becomes a quiz.

The scenario should instead put a decision in front of the room that has no comfortable answer, and that someone present will genuinely have to make one day.

Take the business platform offline on partial evidence, or leave it running and accept possible spread. Pay, or refuse, when the recovery estimate is longer than the organisation can survive. Notify early, with an incomplete picture and the risk of being wrong in public, or wait for confirmation and be later than a regulator expects. Disclose to a customer whose data may — may — be involved.

Each of these forces the two things the exercise exists to test: judgement under uncertainty, and clarity about who has the authority to make the call.

Withhold, and compress

Real incidents are characterised by a shortage of information and a surplus of time pressure. An exercise briefing that hands everyone a complete picture at the start has removed both.

Information should arrive as injects, in fragments, some of them contradictory, some of them later retracted. The retraction is important — being told at minute forty that the earlier report was wrong is an accurate simulation of a real Tuesday, and the room’s reaction to it is informative.

Time should compress. Not to create theatre, but because a decision that takes the room ninety minutes to reach in a comfortable meeting room is a decision the organisation cannot make at three in the morning. The facilitator’s most useful sentence is “you have four minutes, and then the call happens without you”.

The three failures worth finding

Well-run exercises surface problems that fall into three recurring classes.

Authority. Nobody knows who can decide. The room agrees on what should happen and then discovers that the person with the mandate to authorise it is unavailable, undefined, or believes it is somebody else’s call. This is the most common finding and the one with the cheapest remedy: write down, in advance, who can take the business offline, who can authorise emergency spend, who can speak publicly, and who deputises for each of them.

Dependency. The thing you need is inside the thing that is broken. The incident response plan is on the file share that has been encrypted. The contact list is in the directory nobody can authenticate to. The bridge runs on the collaboration platform that has been isolated. Multi-factor enrolment is administered from a console reachable only through the compromised domain. These are discovered almost exclusively through exercises, because normal operation never removes the dependency.

Information. The decision hinges on a fact nobody can supply. How much data is on that system. Which customers are affected. Whether backups of the specific dataset are recent and tested. How many hosts run the vulnerable component. Whether the third party has access to that environment. A question the room cannot answer in an exercise is a question they will not answer in an incident, and it is often a more valuable finding than anything about the scenario itself.

Stop the imaginary control

The most important facilitator discipline is refusing to accept a capability that has not been demonstrated.

When a participant says “we’d pull the endpoint telemetry and see”, the correct response is: for how many hosts, going back how far, and who has the access to run that query at two in the morning? When somebody says “we’d restore from backup”, the response is: which backup, how long does the restore take for that system specifically, and when was it last tested end to end?

Rooms are optimistic about their own tooling in a consistent direction. Left unchallenged, an exercise records a control as working when what it recorded was a belief about the control. Every “we’d just —” deserves one polite “show me”, and about half of them do not survive it.

The right people, including the awkward ones

An exercise attended only by the security function tests the security function, which is rarely where incidents go wrong.

Real decisions in a serious incident involve executives who will authorise disruption, legal counsel on notification and privilege, communications on what gets said and when, the operations people who actually hold the console access, and often a supplier or an insurer whose contract terms shape the options. Each of them brings a constraint the security team did not know about, and the collision between those constraints is the substance of the exercise.

Two roles are worth specifically including because they are usually absent: the person who would actually type the commands rather than the manager who would direct them, and someone from the business function whose service is being disrupted, who can say out loud what four hours of downtime costs.

The output is a list, not a report

A narrative report of the session is almost worthless a month later. What survives is a short list, in three parts.

Actions, each with a named owner and a date. Questions nobody could answer, recorded verbatim, with someone assigned to go and find out. And decisions the organisation made in the room that it wants to hold to in advance — the pre-commitments about payment, disclosure and shutdown thresholds that are far easier to reason about calmly than during the event.

Then, and this is the part that almost never happens: run the same scenario again in six months. Not a new one. The same one. If the authority question has been resolved, the dependency broken and the unanswerable question answered, the room will move through the first half quickly and reach a new failure. That new failure is the return on the previous exercise, and it is the only evidence that the last one did anything at all.