Purple team

The format is simple and the discipline is what makes it work. Pick a set of techniques relevant to your estate. For each one, the offensive side executes it in a controlled way, announcing what and when. The defensive side then checks three separate things, in order: was the activity recorded anywhere, did anything fire, and did the process produce a response.

Those three answers are different failures with different owners. Not recorded is a telemetry gap, fixed by a log source or an agent. Recorded but silent is a detection engineering gap, fixed by content. Fired but nothing happened is a process gap, fixed by staffing, runbooks and authority, and no product will fix it.

When a detection is missing, it is written during the exercise, and then the technique is executed again to confirm the new rule fires and does not flood the console. That build-and-verify loop is the whole value: an exercise that produces a list of gaps and no verified detections has produced a report, which the organisation already has plenty of.

Everything is mapped to MITRE ATT&CK so the output is a list of technique identifiers with a tested state against each, which is comparable across exercises and legible to people who were not in the room.

The most common failure is running one before there is anything to measure. If telemetry is not collected and no detection content exists, the exercise produces a long list of nothing detected, which was already known and did not need two teams for a week. The prerequisite is a defensive capability worth testing.

The second is running it as a covert exercise by another name. The moment the defensive team is not told what is happening, it becomes a red team, and the collaborative loop that produces detections disappears. Both formats are valuable and they are not the same exercise. Deciding which one is being bought, and being honest about why, is a conversation worth having properly.

The third is stopping at the alert. A rule that fires in a laboratory and a rule that survives contact with production volume are different objects. A detection that is not tuned gets disabled within a month for noise, and the exercise’s output quietly becomes zero. Verification has to include a period of running against real traffic.

The fourth is the ownership vacuum afterwards. An exercise generates a backlog of detection content. If nobody owns that backlog, the same gaps appear in the next exercise, and organisations conclude that purple teaming does not work when what did not work was the follow-up.

From the offensive side, the temptation to demonstrate sophistication is worth resisting. The techniques that matter are the ones used against organisations like this one, executed the way they are actually executed, including the boring parts. A novel technique that nobody uses produces an interesting afternoon and no risk reduction.

Three terms used loosely, including by people selling them. Two are roles and one is a way of working.

The point of the third column is that it is not a team you hire. It is what happens when the other two stop working in sequence and start working in the same room. Some organisations do maintain a permanent function that runs these exercises, but the value is the way of working rather than the job title.

Buying it as a product. It is an exercise format that requires your own defenders to participate. A supplier can bring the offensive half and the methodology; they cannot bring your blue team.

Running it once. Estates change, rules break silently on upgrades, and coverage decays. The cadence matters more than the depth of any single exercise.

Measuring by techniques executed. The number that counts is detections verified, and how many survived thirty days in production.

Skipping the response question. A fired alert that nobody acted on out of hours is a failure, and it is the failure most likely to be quietly recorded as a pass.

Excluding the identity plane. Most modern intrusions are visible in identity logs first. An exercise limited to endpoint technique tests the sensor you already trust.

Start from your own threat picture rather than from the whole matrix. A dozen techniques that match how organisations in your sector are actually attacked will produce more usable content than fifty chosen for coverage.

Record three states per technique, not one, and keep them separate: telemetry present, detection fires, response occurred. Reporting a single pass or fail hides which of the three failed, and they go to different owners.

Write the detection in the room, then execute again to verify. Then let it run against production traffic and check a month later whether it is still enabled, because that is the real test of whether it was tuned.

Keep the artefacts. The technique, the exact command or action, the telemetry it produced, the rule written, and the verification result. That record is what makes the next exercise a comparison rather than a repetition, and it is what you show an auditor who asks how you know your monitoring works.

Feed the output into the SIEM backlog with an owner and a date, and review it before the next exercise rather than during it.

The deliverable is a table of techniques with the three states recorded against each, plus the detections written during the exercise and their verification result. That table is directly useful as audit evidence, because it answers the question auditors ask about monitoring, which is not whether you have a tool but how you know it works.

We write the untested remainder explicitly as untested rather than leaving it blank, since a blank cell is read as covered by whoever sees the document next. And we record response outcomes with times, since the gap between an alert firing and a human acting is usually the largest number in the report and the one nobody had measured.

Where an organisation has never run one, the honest recommendation is often to start with detection engineering rather than with an exercise, because there has to be something to verify.

This format sits alongside the covert half of the adversarial exercises we run with clients, and for most organisations it produces more improvement per day spent.

Is a purple team a permanent team? Usually not. It is a way of working that an organisation runs as recurring exercises with its existing defenders and an offensive capability, internal or external. Some large organisations staff a permanent function to run them, which is a scale decision rather than a definition.

What is the difference between a purple team and a red team? Visibility and objective. A red team tries to reach a goal without being detected, and the defenders are not told. A purple team announces every action so that both sides can check the telemetry, the detection and the response together, and improve them on the spot.

How often should we run one? Quarterly is a workable cadence for most organisations, plus a session after any significant platform change, because upgrades break detection content silently and nothing reports the breakage.

What do we need before running one? Log sources being collected, some detection content in place, and defenders available for the duration. Without those, the exercise measures the absence of a capability, which you can establish far more cheaply.