Tabletop exercises and what a good one reveals

Why do most tabletops reveal nothing?

Because they are structured as a walkthrough rather than a test. A facilitator narrates a scenario, each function describes what it would do, everyone agrees the plan is sound, and the session ends on time. Nothing is discovered because nothing was in doubt: participants are describing intentions, and intentions are not what fails during an incident.

The composition of the room is the second problem. Exercises run by the security team for the security team test technical knowledge, which is rarely the constraint. What fails in real incidents is the interface between functions, so an exercise without legal, communications, a senior decision-maker and the person who actually carries the on-call phone cannot exercise the thing most likely to break.

The third is the absence of injects. Real incidents arrive as a sequence of partial and sometimes contradictory information, and the difficulty is deciding under that uncertainty. An exercise that presents the full picture at the start has removed the actual challenge and replaced it with a description of the solution.

What does a good scenario look like?

It is drawn from your architecture and it starts with too little information. A strong opening is a single ambiguous signal: a supplier says one of their staff accounts was compromised and it had access to your system; an employee reports a payment instruction change that finance has already actioned; a detection fired on a build server three days ago and was closed as benign. Each of those forces the room to establish scope before deciding anything.

It should contain at least one decision with a genuine cost, so that participants have to weigh business impact rather than recite process. Isolating the system that runs payroll on the day payroll runs. Taking a customer-facing service offline during trading hours. Deciding whether to notify a client before you know the extent. If every decision in the exercise is free, the exercise is not testing judgement.

And it needs a non-technical branch, because the response to a real incident is only partly technical. Introduce a journalist enquiry, a customer asking directly whether their data is affected, or the discovery that the insurer requires notification and specific approved providers. This is the section where organisations reliably find out they have no process at all.

Base it on your own architecture rather than a generic template, because the value comes from the specifics. Name the actual service, the actual supplier, the actual cluster. A scenario that says a critical server is affected produces generic answers; one that names the system finance depends on at month end produces an argument about who may take it offline, and the argument is the point of the session.

Which exercise type tests what?

Different formats surface different failures and the cheap ones do not substitute for the expensive ones. Running the same discussion-based session annually will keep confirming what it confirmed last year.

Who has to be in the room?

An executive who can authorise spend and accept downtime, legal counsel or whoever instructs them, someone who speaks to customers, the person who actually holds the on-call phone rather than their manager, and a platform engineer who can say what is technically possible. Any exercise missing the first two is a technical rehearsal, and it will end without discovering the authority gap that will dominate the real event.

Invite the suppliers you depend on for response, at least occasionally. If a managed detection provider, an incident response retainer or a hosting partner is part of your plan, an exercise that assumes their behaviour rather than testing it is assuming the least verified part of the process. Providers will often join a session, and how they answer is itself informative.

Keep the group small enough for everyone to speak, and appoint two roles explicitly: a facilitator who is willing to withhold information and press for decisions, and a scribe who records decisions, questions nobody could answer, and the exact moment the room got stuck. The scribe's notes, not the facilitator's summary, are the deliverable.

One rule makes the session honest: nobody may answer for an absent colleague. When the response to a question is that a particular person would handle it, the finding is that the process depends on one individual who is not here, and writing that down is worth more than the answer they would have given. Single points of dependency surface faster in an exercise than anywhere else.

What do serious exercises consistently expose?

Authority gaps first, almost every time. The room agrees on the technical action and then discovers that nobody is certain who may approve taking a revenue-generating system offline at night, or that the named person has left, or that the process requires a committee that cannot convene until morning. This is the finding that most improves real response and it costs nothing to fix once identified.

Then contact data and dependency assumptions. Numbers that ring an extension in an empty office, an out-of-hours rota that has not been updated, a backup process everyone believes is tested, and a recovery plan that depends on a system in the affected environment. Container estates add their own version of this: teams frequently find that nobody present knows how to preserve a compromised pod without deleting it, or that the cluster's audit logs are retained for days rather than months.

Finally, the external process. Who notifies the insurer and within what period, whether forensic providers must come from an approved panel, which regulator applies and on what clock, and who is permitted to speak to a customer or a journalist. These are the questions that turn a technically competent response into a well-handled incident, and they are consistently the least rehearsed.

How do you run a useful one this month?

Book ninety minutes, invite eight people including at least one executive and one lawyer, and prepare one scenario with three injects, each delivered as a short paragraph handed over at the moment it arrives. Give nobody the scenario in advance. Write the injects so that the second contradicts an assumption made in response to the first, which is where the real learning happens.

Finish with twenty minutes of open review while everyone is still present, and press specifically on the moments where the room paused. Those pauses are the findings. Close with a list of owned actions, each with a name and a date, and no more than about six of them, because a list of thirty will be a list of thirty next year as well.

Then measure the next exercise against that list. The single most useful comparison in this discipline is how many of the previous exercise's actions were completed before the following one, because it distinguishes an organisation that is learning from one that is documenting. It also stops the exercise from becoming an annual event that produces a report and no change.