How to run a tabletop exercise people take seriously

A tabletop exercise is ninety minutes, a room, a scenario and a set of questions. It costs almost nothing and it routinely finds gaps that no amount of tooling would have surfaced.

It also goes wrong in a completely predictable way. Somebody presents a scenario, somebody else describes what the plan says should happen, everybody agrees the plan is good, and the session is recorded as complete. Nothing was learned, because nothing was tested.

The difference between the two is almost entirely in how the questions are asked.

Who needs to be in the room

Smaller than people expect, and wider than security.

You need whoever would actually make the decisions. That means security, an infrastructure or platform person who can say what is technically possible, somebody from legal or compliance who knows the reporting obligations, a communications person, and at least one executive with the authority to take a production system offline.

Six to eight people. If it is twenty, nobody speaks honestly and the loudest opinion wins. If security is the only function present, you have not run an incident exercise, you have run a security meeting.

The ninety minute shape

The last fifteen minutes are the output. Everything before it exists to generate that list.

Start ambiguous, not dramatic

The most common design mistake is opening with a confirmed breach. Real incidents almost never start that way, and beginning there skips the hardest decision in the whole sequence, which is whether this is an incident at all.

A better opening looks like this.

It is Tuesday, 16:40. A finance colleague mentions in passing that a supplier changed their bank details last week and it felt slightly off at the time. Separately, your monitoring flagged an unusual login from a country where you have no staff on Sunday night. It was reviewed and closed as probably fine.

Then ask one question. What happens next, and who does it?

Sit in the silence. The silence is the finding.

The three escalations worth using

Whatever scenario you pick, these three pressures reliably expose real gaps.

The authority question. The decision that would help requires taking a production system offline during business hours. Who can authorise that, what if they are unreachable, and how long does finding out take?

The evidence question. Somebody proposes rebuilding the affected host to restore service. Ask what is lost if you do, who decides whether to image it first, and whether anyone in the room has that authority. This one catches almost every organisation the first time.

The outside question. A journalist emails asking about a rumour, or a large customer asks directly whether they are affected. Who answers, what are they allowed to say, and who signs it off?

What to write down

Not a report. One table, filled in during the last fifteen minutes while everyone is still in the room.

For each thing the group could not answer cleanly, record the question, the owner and a date. Four or five entries is a good outcome. If you finished with none, the scenario was too easy or the room was too agreeable, and it is worth running again with a harder one.

Then, and this is the part that gets skipped, put the dates in a calendar and check them. An exercise that produces a list nobody revisits is an expensive way to feel prepared.

Running it more than once

Once a year is the common cadence and it is not enough to build any real muscle. Two or three shorter sessions work better than one long annual production, partly because people stay honest when the exercise is routine rather than an event.

Vary who leads it. When the same person always writes the scenario, the scenarios drift toward the areas that person already thinks about, and the blind spots stay blind.

The NIST guide to computer security incident handling is a solid structure for the underlying process, and MITRE ATT&CK is useful for building scenarios grounded in behaviour that actually occurs rather than in imagination.

Why this is worth an afternoon

We run DFIR engagements and the pattern is consistent. The organisations that come through an incident well are rarely the ones with the most sophisticated tooling. They are the ones where a handful of decisions had already been made, calmly, months earlier, by people who took ninety minutes to think about it.

We wrote about the shape of the incident that actually arrives in the incident you will actually have. A tabletop is the cheapest way to find out whether you are ready for that one rather than the one in the plan.

Common questions

How long should a tabletop exercise be

Ninety minutes is enough for a scenario with two escalations and a proper wrap up. Longer sessions lose the room, and shorter ones tend to stop before the uncomfortable questions arrive. Two or three short sessions a year beat one long annual one.

Who should facilitate a tabletop exercise

Someone who is not going to be a participant, because a facilitator who also has decisions to make in the scenario will steer it. Rotating the facilitator between sessions helps, since scenarios otherwise drift toward whatever the same person already worries about.

What is the difference between a tabletop and a simulation

A tabletop is a discussion of decisions with no systems touched. A simulation exercises the real technical response. Tabletops are cheaper, find decision and authority gaps faster, and are the right place to start.

How do we stop it becoming a blame exercise

Say at the start that unknowns are the purpose and that finding one is a success. Then make sure the first person who admits they do not know something is thanked visibly, because the rest of the room is deciding in that moment whether to be honest.