Tabletop is theatre. Run an assumed-breach instead.

A tabletop exercise measures how well your team describes what they would do. That is a real skill and it is not the skill that matters at three in the morning. Everyone in the room knows the answer to "what would you do if you saw suspicious PowerShell", because the question contains its own answer. Nobody in the room is asked whether the alert would have arrived, whether the person on call has the console permissions to act on it, or whether the runbook's first step references a tool that was decommissioned in March.

An assumed-breach exercise asks those questions by putting a real intruder inside the network and declining to tell anyone. It is more work to arrange, and it produces findings a discussion cannot.

Start from a foothold, not from the perimeter

The premise is that initial access has already happened. That is not a concession to convenience; it reflects how intrusions actually go, and it moves the entire exercise onto the part of the timeline where a defensive team can still change the outcome.

Starting position is a scoping decision, and the honest one is usually lower than the client's first instinct. A standard user account on a standard workstation with standard software is the position an attacker reaches after a successful phishing email, and it is the position most estates are least prepared for — because the perimeter absorbed all the investment.

Agree the starting position, the objectives, and nothing else. Resist writing an attack path into the plan. The value of the exercise depends on the operator finding the route that exists rather than walking the route someone anticipated.

Objectives you can actually adjudicate

"Test our detection capability" is not an objective. It cannot be passed or failed and it produces a report full of adjectives.

Objectives should name a specific end state that both sides can verify afterwards without argument:

• Read a named record from a named production database.
• Authenticate to the finance application as a user with approval rights.
• Obtain persistent access that survives a reboot and a password reset of the initial account.
• Move from the workstation network segment into the environment that hosts customer data.

Each of those is binary. Each maps to something the business actually cares about losing. And each gives the defensive team a concrete thing to have prevented, rather than a vibe to have detected.

The rails that make it safe

An exercise inside a live production estate needs constraints that are written down before it starts, because the moment to discuss them is not the moment something goes wrong.

• Written authorisation naming the systems in scope, the window, and the individuals who can call a stop. Signed by someone with the authority to grant it.
• A destructive-action prohibition that is explicit rather than implied. No deletion, no denial of service, no modification of production data. Proof of access is a read, a screenshot, a controlled marker file — never an effect on the business.
• A stop condition and a phone number. Both sides need a way to halt in minutes, and the number needs to be answered by a human who knows what the exercise is.
• A small number of people who know. Usually the CISO, the exercise sponsor, and one technical contact who can confirm an operator's activity is authorised. Everyone else finds out afterwards, which is the entire point.
• Complete operator logging. Every action, timestamped, so a genuine unrelated incident during the window can be separated from the exercise immediately.

That last one is not paperwork. If a real intrusion happens during your exercise window — and it does happen — the ability to say with certainty which activity was yours is the difference between a clean investigation and a very bad week.

If the responders can pass the exercise from memory, you have tested their memory. The interesting failures are the ones nobody rehearsed.

Injects, and when to use them

Sometimes the exercise stalls. The operator establishes a foothold, nothing is detected, and days pass with no defensive activity to observe. That is itself a finding, but it is a finding you can only collect once, and it wastes the remaining window.

An inject is a deliberate, escalating signal designed to give the defensive team something to work with. Start quiet and get louder until someone responds:

1. Behaviour that should trip an existing detection the client believes they have.
2. The same behaviour, repeated and less carefully.
3. Something unambiguous — an alert the vendor's default ruleset ships with.
4. A direct notification to the technical contact, which converts the exercise from detection to response.

Record which rung produced a reaction. The rung number is the finding. A team that responds at step one is in a different position from a team that only responds when told, and both are more useful to know than an exercise that ran silently to completion.

What is worth measuring

Detection rate is the metric everyone asks for and the least useful one, because it collapses to a percentage of a set of activities you chose.

Time-based measures survive scrutiny better, and they compare against the same team six months later:

• Time to first detection. From the first observable action to the first alert that fired. Whether anyone looked at it is measured separately.
• Time to first human triage. From alert to a person opening it. In a lot of estates this is the number that hurts, and it is a staffing and queue-design problem rather than a tooling one.
• Time to correct scoping. From triage to a correct understanding of what the intruder actually has access to. Under-scoping is the most common and most expensive response failure — the team contains one host and the operator retains three.
• Time to containment. From scoping to the access being genuinely severed. Verify this against the operator's own logs rather than the responders' belief.

Alongside the times, record what was never detected at all. That list drives more remediation work than the timings do.

The debrief is the deliverable

Run it jointly, with both sides in the room and the operator's timeline projected next to the defensive team's timeline. Walk them together, in order.

The gaps are visible immediately and nobody has to be persuaded of them. An alert that fired into an unmonitored queue, a detection that existed but was scoped to the wrong estate, a runbook step referencing a decommissioned tool, an escalation that waited on a person who was on leave. These are the findings, and they are all things a tabletop would have answered correctly in theory.

Then re-run it. Not the same path — that only tests whether the specific holes were filled. The next exercise starts from a different position with different objectives, and what you are measuring is whether the times moved. A single exercise is an anecdote. The second one is the first data point.