What is a cybersecurity tabletop exercise?

A cybersecurity tabletop exercise is a facilitated discussion in which the people who would actually run an incident work through a realistic scenario out loud, making the decisions they would have to make, while somebody records what they decided and what the plan did not cover. It runs about 3 hours. Nobody touches a keyboard. That last part surprises people more than anything else about it.

What actually happens in the room?

One scenario goes up on one screen. Everyone works the same problem at the same time.

The facilitator introduces a situation, usually mundane at first. An alert, an odd email, a call from a customer. The room decides what to do. Then the situation develops, whether or not the room handled the first part well, and they decide again. That cycle repeats until the exercise reaches its end state, which is typically somewhere in the messy aftermath, well past the moment of containment.

The standard definition is worth reading because it is blunter than most people expect. NIST describes a tabletop exercise as one where personnel meet in a classroom setting or in breakout groups to discuss their roles during an emergency and their responses to a particular emergency situation, adding that a tabletop exercise is discussion-based only and does not involve deploying equipment or other resources (NIST Special Publication 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, 2006).

Discussion-based only. That is the whole format in two words.

The alternative, in the same document, is a functional exercise, which puts people into a simulated operational environment and has them actually perform their duties (NIST Special Publication 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, 2006). That is a different, larger and more expensive thing, and it is not what a carrier is asking about when it asks whether you tested your plan.

Why do people expect something technical?

Because the word exercise sounds like it should involve doing something.

Told they are getting a tabletop exercise, participants routinely assume their technical staff will be at a keyboard, logged into the security tooling, pulling logs while everyone else watches. It has to be explained, usually more than once, that this is a conversation. One scenario, one screen, everyone in the room working the same problem out loud.

The expectation is understandable and it is worth correcting early, because a room that arrives expecting a technical test sends the wrong people. You get two engineers and nobody who can authorise a payment, approve a public statement or call a lawyer. Those are the decisions the scenario is built to force, and if the people who make them are not in the room, the exercise measures nothing.

What does a three-hour agenda look like?

Block	Time	What it is for
Framing	15 minutes	Ground rules, what is in scope, and that nobody is being assessed personally
Scenario opens	30 minutes	The first decision, usually about whether this is even an incident
Escalation	45 minutes	Pressure increases. Notification and containment decisions collide
The hard turn	30 minutes	The inject nobody prepared for. Usually a disclosure or third-party question
Post-incident	30 minutes	What now. This is where most rooms come apart
Hot wash	30 minutes	What did we learn, said out loud, while it is fresh

Three hours is not arbitrary. Under two and the post-incident phase gets cut, which is the phase that generates the useful findings. Over four and the room stops concentrating, which produces polite answers instead of real ones.

What does an inject look like?

An inject is a single new piece of information introduced into a running scenario to force a decision. Here is one, in full, from a ransomware scenario about ninety minutes in:

A journalist has emailed your general enquiries inbox. She says she has been sent a directory listing that appears to contain your client file names, and asks whether you have suffered a data breach. She has a deadline in four hours. Your forensic provider has told you they will not be able to confirm the scope of exfiltration for at least three days.

That inject does not test anybody’s security knowledge. It tests four things at once: whether anyone knows who speaks to media, whether legal has been engaged, whether the room understands that “we do not know yet” is a legitimate public position, and whether anyone can say what the firm’s obligations are when a journalist knows before the regulator does.

Rooms rarely handle it well the first time. That is the point of running it in a conference room rather than for real.

How does a room usually behave?

Pace depends almost entirely on who is in it.

A room with something to prove, or one running its first exercise, decides fast and on instinct. Somebody answers quickly, the group follows, and they move on. A room that has done this before decides slowly. It waits for a second source, asks who else has seen the alert, and wants a second pair of eyes before committing.

Neither is wrong, and the difference is not competence. It is familiarity. The fast room is not reckless, it simply has not yet learned which of its assumptions are load-bearing. Watching the two behaviours is one of the more useful things a facilitator can report, because it tells you something about how the organisation will behave at two in the morning that no document will.

Who should be in the room?

Between 6 and 12 people, and never fewer than 5. Below that floor the disagreements that make the exercise valuable never surface, because nobody present holds a different instinct from whoever spoke first.

Seats go by what somebody decides, not by their title. Somebody who can authorise spending without asking anyone. Somebody who owns the technical response. Somebody who can speak for the business to customers. Legal, or whoever calls legal. And whoever would actually answer the phone at two in the morning, who is frequently not the person the plan names.

The pair a room falls back on is legal counsel and communications, together. Technical and executive participants both defer to that pair once a scenario turns towards disclosure, and if neither is present the room stalls at exactly the point the exercise was built to reach.

When a compliance function drives the request, it usually arrives as a list of names rather than a list of things to test. That is a useful signal in itself: the requirement being satisfied is about participation, which is exactly what an after-action report records by role.

What does it produce?

A written after-action report, and that is the part that matters afterwards.

The report records the scenario, who was in the room, the decisions they made, what held up, what did not, and recommendations with an owner against each one. Where the exercise is facilitated by somebody independent of your response, it also carries an attestation confirming the session took place.

A self-run exercise produces everything on that list except the last item, and for a lot of purposes that is completely fine. If your reason for running one is to get better, run it yourself. If your reason is that somebody has asked you to evidence it, the difference between your own account and an outside party’s confirmation is the whole question.

What is it not?

It is not a penetration test. It is not a red team. It is not an audit, and nobody passes or fails.

It is also not a training session, though people learn from it. Training tells people what to do. An exercise finds out what they would actually do, which is a different question and usually a more uncomfortable one.