Tabletop Exercises That Are Not a Wasted Afternoon

Illustration for: Tabletop Exercises That Are Not a Wasted Afternoon

I once sat through a ninety minute ransomware tabletop in which everybody agreed with everybody else. The facilitator read a scenario, each person described what their team would do, the notes recorded that the response was strong, and the report went to the audit committee saying the organisation had tested its incident plan. Nothing was learned, nothing changed, and the exercise was genuinely worse than not running one, because it manufactured confidence.

A good tabletop is not a presentation of your capability. It is a controlled way of finding out where your decisions break, in front of the people who can fix them. This post is about designing one that does that.

What a tabletop is actually for

The purpose is not to test knowledge. Nobody in the room needs to prove they know what ransomware is. The purpose is to test decisions, and specifically the decisions that are hard because the information is incomplete and the clock is running.

Three things go wrong in real incidents far more often than technical failure. Nobody is sure who has authority to make a call. Nobody knows what they are allowed to say to customers. And nobody notices that a regulatory clock started forty minutes ago. A tabletop that does not put pressure on those three things is not testing anything that matters.

The corollary is that the scenario is only a vehicle. What you are exercising is authority, information flow and the point at which somebody has to commit to a decision they may later have to defend.

The three formats people confuse

The word exercise covers a ladder of very different activities, and buying the wrong rung wastes money.

A tabletop is the highest value rung for the lowest risk, which is why it is the one worth doing well. It is also the only rung that reliably includes the people outside technology, and those are usually the people whose decisions dominate the outcome.

Design the scenario for your organisation

Generic scenarios produce generic answers. “A ransomware attack occurs” invites everybody to describe their standard process. The exercise only bites when the scenario is specific enough that the standard process does not obviously apply.

Three design rules do most of the work.

Make it plausible for you. Use your actual systems, your actual suppliers, your real customer names if the room can be trusted with them. A scenario built on the platform your business genuinely depends on produces different conversation from one built on a fictional company.

Make it uncomfortable rather than impossible. The failure mode at one extreme is a scenario so mild that the plan obviously covers it. At the other extreme is a scenario so catastrophic that the room gives up and jokes about it. Aim for the middle, where the plan half covers it.

Build in the ambiguity. Real incidents begin with partial and contradictory information, and the most valuable thing a tabletop can reproduce is that fog. Start with a symptom rather than a diagnosis. “Three users report their files will not open” is a better opening than “you have been hit by ransomware”, because the first one makes the room decide when to declare.

Injects, and why the timing matters

An inject is a new piece of information introduced part way through. Injects are what separate a tabletop from a discussion, because they force the room to revisit decisions it has already made.

Diagram of a tabletop exercise timeline with injects introduced at intervals

Injects arrive on the facilitator’s schedule rather than the room’s. Each one is designed to stress a specific decision rather than to add drama.

The useful injects are the ones that create pressure in a direction the plan does not anticipate.

The last two are the ones that most often expose something genuinely new, because they cross from the technology response into commercial and operational territory that the incident plan usually does not cover.

Who is in the room

A tabletop populated entirely by the security team tests the security team, which is rarely where the gaps are. The room should contain whoever will actually be involved.

That normally means an executive with authority to spend money and stop trading, the service owner for whatever is affected, technology and security leads, communications, legal or data protection, and someone from customer facing operations. Six to ten people is the workable range. Above a dozen, the quiet people stay quiet and the exercise becomes theatre with a bigger audience.

Two roles matter more than the rest.

The facilitator runs the clock, delivers the injects and keeps the room in the scenario. This person should not be the person who wrote the plan, and ideally should not be the person who owns the response, because both have an interest in the exercise going well.

The scribe records decisions, the time they were made, and the gaps as they surface. Without a dedicated scribe the output degrades into a vague recollection, and the value of the whole afternoon lives in that record.

The observer trap

Inviting senior observers who do not participate changes the room. People perform rather than deliberate, and the awkward admissions that make a tabletop valuable stop happening. If a senior person is in the room, give them a role in the scenario. If they only want to watch, send them the findings instead.

Run it against the clock

Time pressure is the active ingredient. Without it, the room reasons its way to a good answer that it would never reach at 2am with three other things happening.

Compress the timeline deliberately and say so at the start. A useful convention is that ten minutes of exercise represents an hour of incident, announced clearly so nobody spends the session arguing about realism. Then hold the room to it. When somebody says they would consult the legal team, ask who, on what number, and what they would do if that call is not returned within the compressed window.

The single most useful facilitator question is “by when?”. It converts intentions into commitments, and commitments are what expose the gaps.

Two hours is usually right. Ninety minutes of scenario, thirty minutes of structured debrief, and a hard stop. Exercises that overrun lose the people whose diaries matter most, and those are usually the people holding the authority you are trying to test.

Capture output that survives the week

The exercise is worthless if the findings evaporate. The debrief should happen immediately, while the room is still assembled, and should answer four questions.

1. What decisions did we make, and who made them?
2. Where did we hesitate, and why?
3. What did we assume that we have never verified?
4. What are we changing, who owns it, and by when?

Everything in the fourth answer becomes a tracked action with a named owner and a date, in whatever system your organisation already uses. Actions that live only in an exercise report are actions that do not happen.

Then update the plan itself the same week. A tabletop that produces a report but no change to the document has tested the plan and then left it in the state it failed in.

Feed the risk register

Findings that cannot be fixed cheaply belong on the register rather than in a report appendix. “We have no agreed authority to stop trading” is a governance risk with an owner. “Restoration of the order platform takes three days against a four hour objective” is a quantified gap that belongs in front of whoever funds the remediation. An exercise that feeds the register is an exercise that keeps paying out long after the afternoon ends.

The honest counterarguments

Tabletops are easy to pass and therefore prove little

There is real force in this. A room of capable people talking about what they would do is not evidence that they would do it, and no tabletop substitutes for a technical test of whether the restore actually works. The defence is that tabletops test a different layer, which is decision making, and that layer fails in real incidents at least as often as the technology does. Run both, and do not let either stand in for the other.

The scenario is never the incident you get

Correct, and it does not matter as much as it seems. The value is not in rehearsing a specific sequence, it is in establishing who decides, what the thresholds are and how information moves. Those transfer across scenarios. What does not transfer is a room that has never had to make the call at all.

It is a lot of senior time

Two hours from eight senior people is a real cost, and it should be justified rather than assumed. The honest framing is that this is the cheapest possible rehearsal of decisions that will otherwise be made for the first time under maximum pressure, with a regulator’s clock running. Priced that way it is usually an easy argument, and if your organisation genuinely cannot find the two hours, that reluctance is itself a finding worth reporting.

Common mistakes

Running it as a quiz. If the facilitator knows the right answer and is waiting for the room to say it, the exercise is a training session in disguise. Tabletops should have questions the facilitator genuinely cannot answer.

Letting the technology conversation dominate. Engineers will happily debate containment for an hour. That is a valid discussion and it is not what the room is for. Park it and push the scenario forward.

No consequences for delay. If the room can take as long as it likes to decide, it will decide well and slowly, which is not the behaviour under test.

Testing the same scenario every year. Ransomware is a legitimate first exercise and a poor third one. Rotate through supplier failure, insider misuse, prolonged loss of a building and a data breach with no technical compromise at all, because the last of those is the most common and the least rehearsed.

Writing the report and stopping. The report is not the product. The changed plan, the tracked actions and the register entries are the product.

Where to start

Pick your most plausible incident, not your most dramatic one. Write a one page scenario with a symptom rather than a diagnosis, plus four injects and the times they land. Book two hours, invite eight people including at least three from outside technology, and appoint a facilitator who did not write the plan.

Then run it, and judge the exercise by a single measure. If nothing surfaced that somebody in the room did not already know, the scenario was too kind and the next one needs to be harder. A tabletop that ends in mild embarrassment has done its job, and it is a great deal cheaper than finding the same gap on the day it counts.