Red Team vs Blue Team vs Purple Team: Build or Buy

Most organisations argue about red, blue and purple teams as if they were three products to buy, when they are three functions with very different prerequisites, costs and outputs. A blue team defends every day; a red team tests that defence by behaving like an adversary; a purple team makes the two work together so each finding becomes a tuned detection. This guide is a staffing and operating model decision guide: what each function is for, what it needs before it pays off, which parts to build in house and which to buy, and how to measure whether the mix is working. It is written for security leaders, SOC managers and offensive security leads. For engagement mechanics, read the Red Teaming Guide and the Purple Teaming Guide; this page does not repeat them.

Key takeaways

The blue team is not optional. Every organisation has one, even if it is two engineers and a managed detection provider; red and purple work only pay off when there is a defence able to absorb findings.
Red teaming answers one question well. It shows whether a realistic adversary can reach a business objective and whether you would notice, and it needs a working SOC and incident process to be worth the money.
Purple teaming is a way of working, not a third department. Most organisations get it by scheduling joint sessions between offensive testers and detection engineers, not by hiring a purple team.
Build the defence, buy the offence early. Small and mid-sized organisations usually staff blue internally and buy red team and facilitated purple team services; an internal red team makes sense only at scale or under continuous regulatory testing.
Measure detection, not trophies. Track technique coverage, time to detect and time to fix gaps; a red team report full of domain admin screenshots with no remediation tracking is wasted spend.

Short answer: red, blue and purple in one table

The US Committee on National Security Systems glossary (CNSSI 4009-2022, reproduced in the NIST CSRC glossary) defines a red team as a group "authorized and organized to emulate a potential adversary's attack or exploitation capabilities" against an enterprise, with the objective of improving security by demonstrating the impact of successful attacks and what works for the defenders. The same glossary defines the blue team as the group responsible for defending the enterprise's information systems by maintaining its security posture, including against mock attackers under rules overseen by a neutral white team. Purple team has no equivalent formal definition in that glossary; in practice it means red and blue working openly together on agreed techniques.

Function	Core question	Defenders aware?	Main output	Cadence	Typical owner
Blue team	Can we prevent, detect and respond to attacks today?	They are the defenders	Detections, triage, incident response, hardening	Continuous	SOC, detection engineering, incident response, platform security
Red team	Can a realistic adversary reach our critical functions, and would we notice?	No, only a small control team	Attack narrative, detection and response timeline, remediation plan	Periodic engagements, often annual	Offensive security lead or external provider
Purple team	Did we see each technique, and how do we close the gap?	Yes, working together	Tuned or new detections, tracked gap list	Days per exercise, monthly or quarterly	Detection engineering lead with red operators
White or control team	Is the test safe, legal and in scope?	Knows the test is running	Authorisation, deconfliction, escalation decisions	Per engagement	CISO delegate, risk and legal

TIBER-EU, the European framework for threat intelligence-based ethical red teaming, formalises the same split with five parties: the blue team (staff of the tested entity, tested without advance knowledge), a threat intelligence provider, the red team testers, a small internal control team that alone knows the test is underway, and the authority's TIBER cyber team. TIBER-EU stresses that results are not a pass or fail verdict. For the regulated variant, see the Threat-Led Penetration Testing Guide.

Blue team: threat model, architecture and failure modes

Threat model: everything. The blue team carries the real adversary every day: commodity phishing (ATT&CK T1566), exploitation of internet-facing services (T1190), abuse of valid accounts (T1078) and the rest. It cannot choose its scenarios, which is why it needs others to test its blind spots.

Architecture in words: telemetry sources (endpoint, identity provider, cloud control plane, network, SaaS audit logs) feed a SIEM or data lake; detection engineers write and version rules; analysts triage alerts; incident responders contain and recover; platform and identity teams harden. NIST SP 800-53 places the monitoring side in SI-4 System Monitoring and CA-7 Continuous Monitoring, and the response side in IR-4 Incident Handling. See the SOC Guide and Detection Engineering Guide.

Failure mode, alert volume: analysts drown in untuned rules and stop investigating low-fidelity alerts, which is exactly where a red team hides.
Failure mode, coverage by assumption: a rule exists in the SIEM, but the log source behind it stopped sending months ago. Only testing proves the rule fires.
Failure mode, identity blind spot: endpoint telemetry is rich, while service account, API key and OAuth token use is not logged or not reviewed.

Controls that prove it works: log source health monitoring, a detection catalogue mapped to ATT&CK, incident response testing under IR-3, and regular exercises from the other two colours.

Red team: threat model, architecture and failure modes

Threat model: a named or composite adversary, chosen from threat intelligence, pursuing a business objective such as payment fraud, access to customer data or disruption of a critical service. The red team picks the path; the blue team does not know it is coming. NIST SP 800-53 covers this as CA-8(2) Red Team Exercises, an enhancement of CA-8 Penetration Testing, with CA-8(1) requiring an independent testing agent or team.

Architecture in words: a small group of operators with attack infrastructure (domains, redirectors, command and control) segregated from production, a threat intelligence input that defines scenarios, a control team that authorises and deconflicts, and a reporting phase that replays the timeline with defenders. Rules of engagement, legal authority and emergency stop procedures are mandatory; see the Red Team Rules of Engagement Template.

Failure mode, too early: the red team reaches the objective in days because basic hygiene is missing. The report says what an ordinary penetration test or vulnerability scan would have said, at several times the price.
Failure mode, trophy report: screenshots of domain admin, no detection timeline, no owner per finding. Nothing changes.
Failure mode, burned trust: defenders feel ambushed, results are disputed, and the SOC learns to distrust the offensive team rather than learn from it.
Failure mode, unsafe scope: social engineering or production actions without legal sign off, or a test that triggers a real incident response with external parties.

Controls that make it pay: a mature enough blue team to measure (see prerequisites below), a control team with authority to pause, a mandatory replay or purple closure session, and remediation tracked to closure.

Purple team: threat model, architecture and failure modes

Threat model: a defined list of techniques, usually drawn from threat intelligence or replayed from a red team engagement, executed openly so defenders can watch telemetry, alerts and response for each one. TIBER-EU publishes separate purple teaming guidance for how purple teaming is managed in the testing or closure phase of a test.

Architecture in words: a red operator, a detection engineer and an analyst in the same session; a test case library (often built from emulation plans such as the MITRE Center for Threat-Informed Defense adversary emulation library, whose micro emulation plans the project says "can be executed without a red team"); and a gap tracker that links each missed technique to a detection ticket. See the Purple Team Exercise Plan Template.

Failure mode, theatre: sessions run, results are applauded, and no rule is written afterwards because nobody owns the backlog.
Failure mode, cherry picking: only techniques the SOC already detects are tested, so coverage looks perfect.
Failure mode, no regression: a detection is tuned once, then breaks after an agent upgrade or log pipeline change and nobody notices.

Controls that make it pay: a written test plan with expected telemetry per technique, a single owner for the detection backlog, and automated regression of passed tests between sessions, for example with Breach and Attack Simulation (BAS).

Stealth versus collaboration: the central trade-off

The real choice between red and purple is how much the defenders know. Stealth measures what will happen on a real bad day, including people and process; collaboration maximises learning per hour.

Dimension	Covert red team	Assumed breach or announced red team	Purple team
Realism of detection and response	Highest: real triage, escalation and decision making	Medium: defenders may be alert to the test window	Low by design: defenders are watching
Learning per day of effort	Low during the test, high in the replay	Medium	Highest: each technique is discussed and fixed in the room
Coverage breadth	Narrow: one or two attack paths	Narrow to medium	Broad: dozens of techniques per session
Risk to operations and trust	Highest: needs strong control team	Medium	Lowest
Best evidence for	Board and regulator assurance on end-to-end resilience	Lateral movement and escalation exposure	Detection coverage improvement

A common pattern is to combine them: run a covert engagement, then a structured replay where the red team re-executes its steps with the blue team watching. That replay is purple teaming, and it is where most of the value of the red team is realised.

Maturity prerequisites: when each function starts to pay

Use the Offensive Security Programme Maturity Model and SOC Maturity Model for a full assessment. As a rule of thumb:

Stage	Blue team state	Worth doing now	Not yet
Foundational	Basic logging, no 24x7 monitoring, few custom detections	Vulnerability management, annual penetration test, small purple sessions using micro emulation plans	Covert red team
Developing	SIEM with core sources, managed or in-house monitoring, incident playbooks	Quarterly purple team, assumed breach exercise, BAS for regression	Full scope covert campaigns with physical and social engineering
Defined	Detection engineering function, catalogue mapped to ATT&CK, tested incident process	Annual objective-based red team with purple closure, continuous purple sprints	Internal red team headcount, unless scale demands it
Managed and optimised	Measured coverage, regression testing, threat intelligence driving priorities	Internal red team, regulator-led threat-led testing, continuous automated red teaming

The test is simple: if you already know the red team will win in a week because of unpatched internet-facing systems, flat networks or shared admin passwords, spend the money on fixing those first. NCSC makes the same point about penetration testing in general: a test shows only that systems were free of known issues on the day of the test, and checking whether defined controls function is not a good use of testing effort.

Build versus buy, function by function

Function	Build in house when	Buy when	Hybrid pattern
Blue team monitoring and response	You need context on your own business, systems and identities; you run 24x7 at scale	You cannot staff 24x7; you need breadth fast	Internal detection engineering and incident lead, managed detection and response for out-of-hours triage
Detection engineering	Almost always: it encodes your environment	Only to bootstrap content	Vendor and community rule content, tuned and owned internally
Red team	You run continuous campaigns across a large estate, or need operators with deep internal knowledge	You need independence (CA-8(1)), regulatory acceptance, or one or two engagements a year	Small internal offensive team for assumed breach and purple work, external provider for covert annual engagements
Purple team facilitation	You have red operators and detection engineers already	You need an outside facilitator for independence or to start the practice	External facilitator for the first sessions, then internal ownership
Control team	Always internal	Never	External legal advice for scope and authority

Independence: an internal red team knows the environment too well and may share blind spots with defenders who sit next to them. Rotate external providers periodically even when an internal team exists. For sourcing, see the Red Team Services buyer's guide and the Red Team Services RFP Template.

Skills: red operators, detection engineers and incident responders are different career tracks. See the Red Teamer Career Guide and Blue Team Certifications Guide.

Cost drivers and organisation size

Cost is dominated by people time, on both sides. External red team cost scales with active testing weeks, the number of scenarios and critical functions, physical and social engineering scope and jurisdictions. Internal cost that is easy to forget: control team time, blue team time in replays, and the engineering time to fix what is found.

Small organisations (no dedicated SOC): invest in blue capability first, often through a managed provider. Add a facilitated purple day once or twice a year using public emulation plans. Skip covert red teaming.
Mid-sized organisations: an internal detection engineering lead, quarterly purple sessions with an external or part-time internal operator, and an annual objective-based red team with a mandatory replay.
Large and regulated organisations: internal blue and detection engineering at scale, an internal offensive team running assumed breach and purple sprints, externally sourced covert engagements, and threat-led testing where a regulator requires it.

Worked scenario: a mid-sized insurer deciding its mix

A 2,000-person insurer has an in-house SOC of six analysts, a managed provider for nights, two detection engineers and an annual penetration test budget. The board asks for "a red team". The decision runs like this:

Assess the blue baseline: the detection catalogue maps to 40 percent of the techniques in the insurer's top three threat profiles, and identity provider logs are collected but no rules use them. A covert red team would mostly confirm these known gaps.
Run two purple quarters first: an external facilitator runs four one-day sessions on the priority techniques, focusing on valid account abuse and cloud control plane activity. The detection engineers own every gap ticket.
Add regression: passed test cases are scheduled weekly in a BAS tool so detections do not silently break.
Commission the red team in month nine: objective-based, one scenario (fraudulent payment instruction), assumed breach start, control team of three, external provider for independence.
Replay and close: a two-day purple replay within weeks of the end of testing; each step is marked detected, partially detected or missed, and the missed steps enter the same backlog.
Report to the board: coverage before and after, time to detect in the red team, and remediation closure rate, not a pass or fail.

Result: the insurer buys the red team it was asked for, but only once it can learn from it, and keeps headcount growth on the blue side.

Detection and measurement

Pick metrics that show the defence improving, not the offence winning.

Technique detection coverage: percentage of prioritised ATT&CK techniques with a tested, firing detection (tested in the last 90 days, not merely written). See the SOC Detection Coverage Health Check.
Time to detect and time to respond in red team exercises: from first red action to first alert, and from alert to containment decision.
Purple gap closure rate: percentage of missed techniques with a deployed detection within an agreed window, for example 30 days.
Detection regression rate: share of previously passing tests that fail on re-run, a sign of log pipeline or agent drift.
Remediation closure for red team findings: findings closed or risk accepted by a named owner within the agreed window.
Analyst escalation accuracy: whether red team activity that did alert was triaged correctly or closed as benign.

Where identity fits

Red teams routinely reach their objectives through credentials rather than exploits: harvested passwords, over-privileged service accounts, long-lived API keys in code repositories and OAuth tokens granted to SaaS integrations. Make non-human identity abuse an explicit scenario and an explicit purple test set, and confirm the blue team logs and alerts on service account and token use, not only on human sign-ins. See the Detection Engineering for Non-Human Identities Guide.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	CA-8, CA-8(1), CA-8(2)	Penetration testing, independent testers, red team exercises
NIST SP 800-53 Rev 5	SI-4, CA-7, IR-3, IR-4	Blue team monitoring, continuous monitoring, incident response testing and handling
NIST CSF 2.0	ID.IM-02	Improvements identified from security tests and exercises
NIST CSF 2.0	DE.CM-01, DE.AE-02	Monitoring and analysis of adverse events: what red and purple work tests
CIS Controls v8.1	Control 18 Penetration Testing; Control 17 Incident Response Management	Testing programme and the response capability it exercises
TIBER-EU	Blue team, red team, control team, threat intelligence provider	Formal role model for threat intelligence-based red teaming
MITRE ATT&CK v20	For example T1078, T1190, T1566	Common language for scenarios, test cases and coverage

Common failure patterns

Buying a red team to compensate for a weak blue team: the money would have bought more detection capability than the report delivers.
Creating a purple team department: a separate team that owns neither attacks nor detections becomes a reporting layer; make purple a shared process between existing teams.
No replay after a covert engagement: defenders never see what they missed, so the same gaps reappear next year.
Internal red team never rotated with outsiders: it optimises for the defences it already knows.
Scoring the red team on objectives reached: it incentivises the offence to win rather than to teach; score both sides on gaps found and closed.
Ignoring non-human identities: a scope limited to user phishing and endpoints misses the service account and token paths attackers actually use.

Decision checklist

Does the blue team have reliable logging, a detection catalogue and a tested incident process? If not, fund that first.
Is the question "would we detect this technique" (purple) or "can an adversary reach this objective end to end" (red)?
Do you need independence for a regulator, auditor or board? If so, buy the red team externally.
Do you have enough work for full-time operators all year? If not, do not hire an internal red team.
Who owns the detection backlog that purple and red findings feed?
Is there a control team with authority to pause the test and legal sign off for the scope?

Practitioner checklist

Document which colour answers which question, and publish it so leadership stops asking for "a red team" by default.
Baseline detection coverage against your top threat profiles before buying offensive work.
Name a single owner for the detection gap backlog fed by red and purple results.
Require a purple replay in every red team contract and schedule it before the engagement starts.
Automate regression of passed test cases between human sessions.
Include service account, API key and OAuth token abuse in red scenarios and purple test sets.
Rotate external red team providers on a fixed cycle, even when an internal team exists.
Report to the board on coverage, time to detect and closure rate, never on pass or fail.

Red Team vs Blue Team vs Purple Team: Which Functions to Build, Buy or Skip