Purple teaming: testing whether your detections actually fire

A red team engagement answers "could we be compromised?" - a question whose answer is almost always yes. A purple team answers something more useful: which specific detections fired, which did not, and why. It is cheaper, repeatable, and for most organisations a better first investment.

What it actually is

Offensive and defensive working together rather than in opposition. The offensive side executes a specific technique; the defensive side watches to see whether telemetry captured it and whether an alert fired. Where it did not, they fix it and re-run immediately.

The feedback loop is the point. In a red team the gap between action and learning is weeks; in a purple team it is minutes, and the fix is validated on the spot.

Why it beats a red team for most organisations

• Coverage. A red team follows one path to its objective and tells you nothing about the fifty techniques it did not use. A purple team can walk a broad set deliberately.
• Cost and repeatability. It can be run internally, regularly, without a large engagement budget.
• It produces fixes, not findings. The output is tuned detections rather than a report.
• No wasted stealth. Red teams spend much of their effort avoiding detection, which is expensive and teaches you little if the answer is that you had no detection to avoid.

Buy a red team when your detection capability is mature enough that being beaten is genuinely informative. Before that, purple teaming answers the question you actually have.

Running an exercise

1. Pick techniques deliberately - drawn from threat intelligence about what actually targets your sector, not the whole ATT&CK matrix.
2. Agree scope and safety - what may be executed, on which systems, with what stop conditions.
3. Execute one technique at a time, with the defenders watching live.
4. Record three outcomes per technique: was the telemetry present, did a detection fire, did the response work.
5. Fix and re-run immediately where something failed.
6. Keep the results as a coverage baseline you can re-test after platform changes.

The three failure modes you will find

• No telemetry. The action left no trace you collect - the most fundamental gap, and it requires a logging change rather than a detection change.
• Telemetry but no detection. The data was there and nothing looked at it. Cheapest to fix.
• Detection fired, response failed. The alert went to an unmonitored queue, or nobody knew what to do with it. Most common in organisations that bought tooling without process.

Distinguishing these matters, because they have completely different remediations and different owners.

Making it routine

The highest-value version is not an annual event but a regular, small cadence - a handful of techniques each month, plus re-testing after any significant platform change. Detections break silently when a log source changes or a tool is upgraded, and only deliberate re-testing finds that.

Key takeaways

• It answers which detections failed, not merely whether you can be beaten.
• Separate the three failure modes - telemetry, detection, response.
• Run it small and often, and re-test after platform changes.
• Buy a red team once being beaten is genuinely informative.