Red team vs purple team

A red team typically pursues an agreed objective with limited defender awareness, while maintaining safety and deconfliction communications. Purple teaming emphasises collaboration and rapid validation with defenders. Both can exercise multi-step attack paths; choose the format according to whether the goal is independent response measurement, capability improvement or a combination.

The distinction is collaboration, not technique

Both disciplines use the same tradecraft: the same credential theft, lateral movement and abuse of legitimate administrative tooling. What separates them is the information flow, and that single difference changes everything downstream — who is in the room, what gets measured, what the report says, and what you can do with it on the Monday after.

A red team operates as an adversary would. A small group inside your organisation knows the engagement exists; the security operations centre does not. The operators choose objectives — domain dominance, access to a payment system, exfiltration of a specific dataset — and pursue them while deliberately staying beneath the threshold at which your monitoring would react. Everything they do produces a record, but that record is only compared against your detections afterwards.

A purple team inverts this. Operators and defenders sit together, often literally. An attacker technique is executed, deliberately and in isolation; both sides then look at what reached the SIEM, what the endpoint agent recorded, whether a rule fired, whether an alert was triaged, and how long each step took. If nothing appeared, the gap is diagnosed and a detection is written or tuned on the spot. Then the technique is executed again to confirm the new rule works. The engagement is a sequence of these loops rather than a single campaign.

Red team — one covert campaign, measured at the end

  initial access → establish persistence → escalate
       → move laterally → reach objective → debrief
  SOC awareness:  none, until the debrief
  question:       were we caught, and where could we have been?

Purple team — many open loops, measured continuously

  pick technique → execute → both sides inspect telemetry
       → gap? write or tune detection → re-execute → confirm
       → next technique
  SOC awareness:  full, throughout
  question:       which specific techniques can we see, and how fast?

Side by side

The case for red teaming, on its own terms

A red team answers a question nothing else answers: does the whole machine work when nobody knows it is being tested? Controls, telemetry, rules, analysts, escalation paths, on-call rotas, the decision to pull a host off the network at two in the morning — all of it under load, with no one prepared.

That matters because security failures are rarely failures of tooling alone. An alert fires, is deprioritised, and nobody notices the second one. A playbook references a team that was reorganised a year ago. The analyst who would have spotted it is on leave. None of this appears in a coverage matrix, because none of it is about coverage. It only shows up when the exercise is genuinely unannounced.

Both formats can demonstrate an attack path: a sequence of misconfiguration, excessive permission and trust relationships leading to a defined objective. Purple exercises can execute and replay that sequence openly; red exercises typically preserve limited awareness to examine realistic defender response. A path’s evidential value depends on verified steps and stated assistance, not the exercise label.

The honest limitation is coverage. An operator who finds a reliable path early has little reason to try the other twelve. If Kerberoasting works on the third attempt, nobody learns whether your detections would have caught certificate abuse, or token theft, or a malicious scheduled task. The report is deep and narrow by design. Read as a statement about your overall detection posture, it will mislead you.

The case for purple teaming, on its own terms

Purple teaming is the more efficient instrument when the thing you need is coverage data. Because nothing is covert, no time is spent on evasion, infrastructure or operational security — the overheads that consume a large share of any red team's hours. That time goes into running more techniques instead.

The output is directly actionable, which is its real advantage. A red team report says you did not detect the lateral movement. A purple team session tells you that the process-creation events were present but the rule's command-line pattern missed the variant used, shows you the corrected logic, and demonstrates it firing. One produces a finding; the other produces a working detection and a test case you can re-run after every agent upgrade.

It also builds skill where it needs to live. Analysts who have watched an operator perform a technique recognise it faster in production and understand why the rule reads as it does. That transfer is the quiet, compounding benefit, and the reason we structure purple teaming as a working session rather than a test with an audience.

The limitation is equally real. Techniques run in isolation, announced and without evasion are the easy case. A rule that fires on the clean version may be trivially bypassed by an operator who changes a parameter, renames a binary, or routes the same action through a different API. Purple teaming measures whether you can see something — not whether you would, against someone actively trying not to be seen, while your analysts are handling three other incidents.

Which one do you actually need

The decision is usually settled by a handful of concrete triggers rather than by strategy.

Choose purple teaming if any of these are true. You have deployed an EDR or SIEM within the last eighteen months and have never verified its coverage with live technique execution. You migrated platforms, changed vendors, or consolidated tooling, and inherited rules whose provenance nobody can explain. A previous red team or penetration test reported that nothing was detected, and you need to know which specific techniques to cover first. Your detection rules were written from vendor templates and have never been tested against the actions they claim to catch. You have analysts who have never seen the techniques they are meant to recognise. Your identity estate is the primary concern, in which case pair the session with an Active Directory assessment so that configuration weaknesses and detection gaps are mapped together rather than separately.

Choose red teaming if any of these are true. You have exercised detection coverage already and want to know whether the response process holds up unannounced. A board, regulator or insurer has asked for an end-to-end demonstration rather than a coverage report. You need to justify investment in a specific control and require a demonstrated path to make the argument. You are confident in prevention and detection and want that confidence tested adversarially. You have a specific threat model — a named actor type, a specific data set, a specific crown-jewel system — and want to know whether that objective is reachable.

Choose neither yet if you have unpatched internet-facing systems, no asset inventory, flat internal networks or widespread local administrator rights. Both exercises will find those immediately, and you will have paid an adversary-simulation rate for a vulnerability scan. A scoped penetration test first is cheaper and faster at establishing that baseline.

The common buyer mistake

The mistake specific to this pairing is buying a red team as a first test of detection, and then treating the result as a verdict on the security team.

It happens for understandable reasons. Red teaming is the more legible purchase: a narrative, a clear pass or fail, and it briefs well upwards. So an organisation that has just deployed monitoring commissions one to validate the investment. The operators reach their objectives largely unobserved, because nobody had yet verified which techniques the new tooling actually surfaced. The report is accurate and almost entirely predictable — senior operator time spent establishing something purple teaming would have shown in more detail, with fixes attached.

The damage is usually organisational rather than technical. The finding becomes evidence that the SOC failed, when the actual failure was sequencing — measuring an untested capability by its worst-case outcome. Defenders become reluctant to support future exercises, which is precisely the opposite of what either discipline is for.

The inverse mistake exists too, and is less costly but still real: running purple team sessions indefinitely, accumulating an impressive coverage matrix, and never testing whether that coverage survives contact with an adversary who is actively evading it. Coverage is a proxy for detection. It is a good proxy, and it is not the thing itself.

How they fit together over a programme

Over a two- or three-year horizon the two disciplines form a cycle, and the order matters more than the ratio.

Build coverage first, through purple team sessions against the techniques most relevant to your estate — identity abuse if you are Active Directory-centric, control-plane abuse if you are cloud-native, and in practice both. Each session leaves behind tested rules and reproducible test cases. Re-run those after every tooling change; detection decays silently, and a saved test case is cheap.

Once relevant telemetry and response have been exercised, an independent red team can add evidence about adaptation, evasion and operational response. Outcomes remain uncertain: the operators may succeed, be stopped or encounter a coverage limitation. Record each result without assuming in advance that some controls will be evaded.

Feed the result back. Every evaded detection from the red team becomes the agenda for the next purple session, now with a precise target. That session hardens the specific variant, the test cases are added to the regression set, and the cycle repeats at a higher level each time. The red team's detection timeline is the input; the purple team's rules are the output; the next red team tests whether the output held.

Underneath both sits ordinary assurance work, keeping the exploitable surface small so that adversary simulation spends its time on tradecraft rather than on unpatched edge devices. Skip that foundation and both exercises simply rediscover hygiene problems a cheaper instrument would have caught.

If you want to see how we document a detection timeline and a coverage matrix before committing to either, get the report — it shows the artefacts themselves rather than a description of them.