R05 — Exercise Design & Purple Team Operations

Volumes 01 through 04 built the machine. This volume puts people in front of it and turns it into something an organisation runs — a repeatable exercise that produces a score, a report, and a decision.

An exercise is not a demo. A demo shows the range works. An exercise measures how well a team, or a set of controls, performs against a defined adversary, produces evidence, and yields a number that means the same thing next quarter as it does today. If the only output is "that was cool," you ran a demo.

Match the format to the question. Tabletop, assisted tabletop, live purple team, full simulation — with the progression that actually works: run the tabletop first, always. It is cheap, it surfaces the obvious gaps, and it gets participants fluent before you spend range time. The mistake is jumping straight to the live purple team because it is the impressive one.

Scenario authoring. Start from a real threat, not a technique list — "test our Kerberoasting detection" is a technique; a commodity ransomware crew gaining access through an exposed service and escalating through the AD misconfigurations you know you have is a scenario, and it exercises Kerberoasting along the way in the sequence the technique actually gets used. The technical spine is an ordered ATT&CK path mapped to your corpus and emulation, with the predicted detection outcome per step taken from R04's coverage matrix — that prediction is what makes the result meaningful. Difficulty is a dial: the same scenario runs loud or quiet, and a team that catches the loud version and misses the quiet one has learned exactly where its detection depends on the adversary being careless.

Roles, including the solo-operator collapse — running this alone, you are white cell and red and observer, the blue team is the R04 stack and its triage layer, and the exercise measures the controls rather than the humans. Entirely valid, provided the report is honest about which was tested.

Injects — technical, information, decision and pressure — pre-authored with trigger conditions, because an inject list with no triggers is a script and an exercise with no inject list is chaos.

The two metrics that carry the exercise. Time-to-detect measures whether you see it; time-to-contain measures whether seeing it mattered. Plotted per scenario step they produce a three-way split that says precisely where to invest: sensors and detections where TTD fails, process and automation where TTC fails. Scoring must be defined before the exercise, not after — a score computed differently each time is a feeling with a decimal point.

Evidence capture as a role, not an afterthought, and a five-section after-action report structured to survive contact with an executive.

The tabletop-to-live bridge is the chapter that sells the work. Run the scenario as a discussion, record what the team believes it would catch, then run it live and compare. The gap between "we'd catch that" and the actual time-to-detect is the organisation's own words measured against reality — and that delta, quantified, is what turns an exercise into budget.

Closes with running a quarterly programme rather than an event, six worksheets and a readiness checklist.