Purple teaming is a collaborative security exercise in which offensive testers (the red team) and defenders (the blue team) work side by side, running real attacker techniques one at a time to prove whether detection fires and to fix it when it does not. The need is measurable: across more than 338 million attack simulations in the first half of 2026, 58% were logged somewhere in the defender's stack but only 14% raised an alert (Picus Blue Report 2026). Purple teaming exists to close that gap one technique at a time.
Quick answer: A purple team exercise runs an agreed list of MITRE ATT&CK techniques against your real systems while your SOC watches its own consoles. Each technique is scored as blocked, alerted, logged only or no telemetry, detection is tuned during the exercise, and the techniques are re-run to prove the fix. Buy one when you know you have detection gaps and someone who can change rules; demand per-technique results, the detection content itself and a re-test in the SOW. Stingrai runs purple teaming with certified penetration testers working alongside your analysts, quoted against your technique list and environments.
What is purple teaming?
Purple teaming is a way of working in which the red team and the blue team share the plan: the red team announces and executes adversary techniques against agreed systems, the blue team records what its tools did with each one, and both tune detection together until the technique is reliably caught.
It is not a third team you hire. The colours describe roles. Red attacks, blue defends, and purple is what happens when they stop treating the exercise as a contest and start treating it as measurement. The output is not a story about reaching domain admin. It is a per-technique record of what your stack blocked, what alerted, what merely logged and what left no trace.
Red team | Blue team | Purple team exercise | |
|---|---|---|---|
Who it is | Offensive operators emulating a named adversary | Your SOC, MDR and detection engineers | Both, on a shared bridge |
Question answered | Could an adversary reach the crown jewels unstopped? | Are we seeing and stopping what is happening? | Does detection fire on this technique, and which sensor carried it? |
Defenders told? | No, only a small control group knows | Not applicable | Yes, the technique list is shared in advance |
Unit of measurement | Objective reached, time to detect per stage | Alerts, cases and response times | Per-technique outcome, telemetry source and rule state |
Operator adapts to | Evade detection | Not applicable | Expose the detection threshold |
Primary output | Attack narrative and detection timeline | Incidents handled and closed | Outcome matrix, detection content and re-test evidence |
Blind spot | Rarely says which log source you lacked | Cannot measure what it never sees | Says nothing about whether gaps chain into an objective |
It is also not a penetration test (no CVSS-scored finding inventory), not a breach and attack simulation subscription (a BAS platform replays a fixed catalogue and never watches your analyst miss something), not a tabletop (real techniques produce real telemetry) and not a stealth-scored red team (getting caught is a successful outcome).
Purple team vs red team: which one to buy
They are sequential, not competing. A red team engagement tells you where you are blind; a purple team exercise closes the blindness and proves the fix; the next red team tests whether the new content survives an operator trying not to trip it. The full definition of red teaming, and how it compares with penetration testing, is in what is red teaming.
Buy a purple team exercise when:
You already know you have gaps. A prior red team or penetration test left whole stages nobody saw; a second covert test would rediscover them at a higher price.
Your SOC is new or newly tooled. New SIEM, migrated EDR or a fresh MDR contract: default rule packs have never met your build or your identity provider.
You outsource detection and have never verified escalation. A per-technique record of what your MDR called, silently closed or escalated late is contract leverage.
You need to defend a detection budget. "We alerted on 9 of 26 tested techniques, and 7 misses were missing telemetry rather than missing rules" moves money in a way that "we need more coverage" never does.
Buy something else when servers forward no logs and endpoints carry no EDR, when nobody can change a rule inside the window, or when your real question is whether someone could reach the crown jewels, which is a red team scoped against objectives and crown jewels. If your internal network still produces basic findings, start there: 92% of internal network findings in Stingrai's own testing data were High or Critical, and 56.9% were outdated or unpatched software (State of Penetration Testing 2026).
What changed for purple teaming in 2025 and 2026
Purple teaming moved from good practice to a written step in regulated testing, and the matrix it is measured against changed twice in twelve months.
Change | Date | What it means for your exercise |
|---|---|---|
TIBER-EU revised to specify purple teaming as mandatory (ECB, 11 February 2025); its guidance sets the closure-phase exercise "no later than ten weeks" after active red team testing ends (TIBER-EU Purple Teaming Guidance) | February 2025 | Book the purple team window when you book the red team |
DORA TLPT closure: blue team and testers replay the test and "conduct a purple teaming exercise on topics jointly identified" (Delegated Regulation (EU) 2025/1190, Article 12(5)) | In force 8 July 2025 | For EU financial entities in TLPT scope, purple teaming is part of closure, not an extra |
DORA TLPT fallback: a red team test that cannot safely continue may, as a last resort and with the TLPT authority's prior validation, continue as a "limited purple teaming exercise", counted towards the 12-week minimum (Article 11) | In force 8 July 2025 | The test plan needs a documented switch-over |
ATT&CK v18 replaced technique detection notes with Detection Strategies and Analytics and deprecated Data Sources (MITRE ATT&CK v18) | 28 October 2025 | Map detection content to a Detection Strategy |
ATT&CK v19 split Defense Evasion into Stealth (TA0005) and a new Defense Impairment tactic (TA0112) (MITRE ATT&CK v19) | 28 April 2026 | A technique list with one "defence evasion" column was built against an old matrix |
Picus Blue Report 2026: prevention 69%, logging 58%, alerting 14%, post-compromise actions blocked 37% (Help Net Security summary) | August 2026 | The cheapest gains are techniques already logged that nobody alerts on |
ATT&CK v20: Enterprise has 15 tactics, 227 techniques, 479 sub-techniques, 703 Detection Strategies and 1,770 Analytics (MITRE ATT&CK v20) | 13 October 2026 | Coverage percentages quoted against older counts are out of date |
The number that matters is the 44-point distance between 58% logged and 14% alerted: most adversary activity is already recorded somewhere and never reaches a human, which is cheap to fix once you know which techniques sit in the gap. For the regulatory frameworks themselves (DORA TLPT, TIBER-EU, CBEST and OSFI I-CRT), see the DORA TLPT readiness playbook.
How a purple team exercise runs, phase by phase
Phase | What happens | Elapsed |
|---|---|---|
Threat profiling and technique selection | Pick relevant threat groups, derive an ATT&CK-mapped technique list, agree environments and targets | 3 to 5 days, pre-engagement |
Rules of engagement | Test accounts, excluded techniques, abort criteria, cloud provider testing policy, deconfliction contact and code word | 2 to 3 days, pre-engagement |
Telemetry baseline check | Confirm agreed hosts and identities actually report to SIEM and EDR before anything is tested | Half a day, day one |
Execution, run one | Each technique executed, announced and timestamped; the SOC records what its console shows | 2 to 5 days |
Live gap classification | Every miss labelled with a failure mode while the context is fresh | Concurrent |
Detection engineering | Content written or amended, false positive impact assessed, change approved and deployed | 3 to 10 days |
Execution, run two | Same techniques re-executed, plus variants, to prove content fires and is not brittle | 1 to 2 days |
Report and handover | Outcome matrix, telemetry attribution, content pack, coverage view, retro-hunt queries | 5 to 7 days |
Score four outcomes, not two. Detected and not detected is useless. Insist on blocked (a control prevented the action), alerted (a human was told), logged only (evidence exists in your platform but nothing raised a hand) and no telemetry (no observable your stack could ever have used). Those four states point at four different budget owners.
Give every miss a failure mode. The five in the table below are not interchangeable: a missing sensor, a log filter or ingestion licence cap silently dropping events, missing content, a rule written against a command string instead of a behaviour, and an alert that fired but was suppressed or never triaged. That last one is a process failure, not a detection failure, and most reports quietly mislabel it.
What to measure: the detection metrics that matter
A purple team report should carry the same handful of metrics every cycle, computed the same way, so the next exercise shows a trend rather than a new opinion.
Metric | How to compute it | What it tells you |
|---|---|---|
ATT&CK technique coverage | Techniques tested and detected (blocked or alerted) divided by techniques tested, at sub-technique level | How much of the threat-relevant list you can actually catch; never divide by the whole matrix |
Detection rate by state | Share of tested techniques in each of the four outcome states | Whether the problem is controls, content, telemetry or process |
Telemetry coverage | Techniques with any telemetry (blocked, alerted or logged only) divided by techniques tested | Whether the data exists before anyone writes a rule |
Time to detect | Median minutes from the technique's UTC execution timestamp to alert creation | Whether alerts arrive in time to matter |
Time to acknowledge | Median minutes from alert creation to a human (in-house or MDR) acting on it | Whether escalation works, including out of hours |
Fix rate | Missed techniques in run one that alert in run two, divided by techniques missed | Whether the spend changed anything |
Variant resilience | Variants detected divided by variants run for each tuned technique | Whether new content is durable or matches one exact command |
A worked example (illustrative numbers). Thirty techniques are tested in run one: 5 blocked, 7 alerted, 10 logged only and 8 with no telemetry. Technique coverage is 12 of 30, or 40%; telemetry coverage is 22 of 30, or 73%. The ten logged-only techniques are the cheap fixes, because the data is already there. Detection engineers write content for 8 of them, and log engineering enables a missing source for 2 no-telemetry techniques, which then get content too. Run two scores 5 blocked, 17 alerted, 2 logged only and 6 no telemetry: coverage rises to 22 of 30 (73%), telemetry coverage to 24 of 30 (80%), and the fix rate is 10 of 18 missed techniques (56%). Quoted the same way next year, those three numbers are the board metric.
Technique selection and the ATT&CK coverage trap
Nobody exercises the whole matrix. A three to five day window covers roughly 15 to 40 techniques properly, meaning with variants and re-runs, out of 227 techniques and 479 sub-techniques in Enterprise ATT&CK v20 (MITRE ATT&CK v20). Any proposal claiming full matrix coverage in a week is describing a script.
Select on threat relevance, not volume: take two or three groups credible for your sector and geography, pull their technique sets from the ATT&CK Groups pages and the Center for Threat-Informed Defense adversary emulation library, then cross-reference your own incident history and ISAC reporting. Selection is covered in which threat group to emulate by industry.
Weight toward the middle of the chain. Initial access is heavily covered by mail and web filtering and usually has a different control owner; detection goes quiet in credential access, discovery, lateral movement, persistence, stealth, defense impairment and exfiltration. For a Windows and Entra ID estate, mapped to ATT&CK v20:
Tactic | Representative techniques worth exercising |
|---|---|
Credential Access (TA0006) | LSASS memory (T1003.001), Kerberoasting (T1558.003), MFA request generation (T1621), cloud instance metadata API (T1552.005) |
Discovery (TA0007) | Domain account discovery (T1087.002), domain trust discovery (T1482), cloud service discovery (T1526) |
Lateral Movement (TA0008) | Pass the hash (T1550.002), pass the ticket (T1550.003), Windows Remote Management (T1021.006), SMB admin shares (T1021.002) |
Persistence (TA0003) | Scheduled task (T1053.005), Windows service (T1543.003), additional cloud credentials (T1098.001) |
Stealth (TA0005, Defense Evasion before v19) | Process injection (T1055), system binary proxy execution (T1218) |
Defense Impairment (TA0112, new in v19) | Disable or modify tools (T1685, formerly T1562.001) |
Command and Control (TA0011) | Web protocols (T1071.001), DNS (T1071.004) |
Exfiltration (TA0010) | Exfiltration to cloud storage (T1567.002), exfiltration over the C2 channel (T1041) |
Sub-technique granularity is non-negotiable. "T1003 detected" is not a finding: which sub-technique, on which host role, carried by which sensor.
The heatmap trap. A vendor arrives at kickoff with a green ATT&CK matrix derived from what your EDR vendor claims to cover. That is assumed coverage, never executed against your build with your tuning applied, and it is the most common way a purple deliverable becomes decorative. Insist on three tested states at minimum: tested and detected, tested and missed and not tested. Nothing unexecuted may be shown as covered, and every covered cell must trace to a timestamped entry in the execution log. The scoring games are broken down in grading ATT&CK coverage claims.
Then ask how the vendor avoids brittle content: Summiting the Pyramid scores analytics on how hard they are to evade, and a rule matching the exact command an operator typed is not durable.
The deliverables to demand in the purple team SOW
Write these into the SOW as named artefacts with acceptance criteria, not marketing bullets.
Deliverable | What it must contain | Red flag |
|---|---|---|
Per-technique outcome record | Technique and sub-technique ID, target host or identity, UTC timestamp, outcome (blocked / alerted / logged only / no telemetry), time to alert, time to acknowledgement | Outcomes reported per tactic, not per technique |
Telemetry source attribution | The named sensor or log source that carried each detection, and the one that should have carried each miss | "EDR detected it" with no event or source named |
Detection content pack | Rules in a portable format such as Sigma plus the platform-native version, with field mappings, exclusions and known false positive sources, each mapped to an ATT&CK Detection Strategy | Vendor retains rules as proprietary IP |
Before-and-after re-test | The same techniques re-executed after tuning, with new outcome and new time to alert | Re-test priced as a separate engagement |
Coverage view with tested state | Three tested states minimum, plus an explicit list of what was never tested and why | Two-colour heatmap delivered at kickoff |
Gap classification and owner | Each miss labelled with its failure mode and owning team: log engineering, EDR policy, detection engineering, SOC process or the MDR contract | Every gap labelled "tune the SIEM" |
Response and process observations | Alert to acknowledgement time, whether a playbook existed, whether containment was attempted, whether out-of-hours escalation worked | Report stops at alert generation |
Execution log and retro-hunt queries | Timestamps, host and account names, defender-level technique parameters, plus queries that find historical instances | Summary tables only |
Three do the heavy lifting: telemetry attribution turns a miss into a funded fix, the content pack is the difference between buying an improvement and buying complaints, and the re-test is the only evidence the spend changed anything. Ask for the metrics above too, computed the same way every cycle.
Two things should be explicitly out of scope: a CVSS-scored vulnerability inventory and any pass or fail certification. A purple team exercise produces strong supporting evidence for SOC 2 criterion CC4.1, which covers evaluating whether controls are present and functioning, and for ISO 27001 Annex A 8.16 monitoring activities. The penetration testing that PCI DSS v4.0.1 requires remains separate work with its own scope and report.
How long it takes and what drives the cost
Shape | Techniques | Elapsed | Best for |
|---|---|---|---|
Focused detection sprint | 12 to 20 | 1 to 2 weeks | New EDR or SIEM, single environment, first measurement |
Standard purple team exercise | 25 to 40 | 3 to 5 weeks including tuning between runs | Established SOC, two or three environments, annual assessment |
Threat-led programme | 40 or more in quarterly waves | 12 months | Regulated firms, mature detection teams, continuous reporting |
Cost driver | Lower end | Higher end |
|---|---|---|
Technique count | 12 to 20 | 40 or more |
Environments | One Windows domain | Domain plus Entra ID and M365, plus AWS or Azure, plus Linux |
Rule development | Observe and report only | Vendor writes, tests and hands over content |
SOC participation | One analyst on a bridge | Full rotation including out-of-hours shifts |
Re-run scope | Missed techniques only | All techniques plus evasion variants |
Threat intel tailoring | Generic technique list | Bespoke profiling of named groups, TIBER or DORA style |
Third-party coordination | None | MDR, managed SIEM or outsourced IT in the loop |
Rule development is the biggest lever, because detection engineering is the labour-intensive half of the work. Environment count is next, and variant re-testing third; protect that line item, because it proves the new content is not brittle. Per-technique pricing rewards a vendor for picking trivial techniques, so approve the list yourself.
A purple team engagement is priced against your environments, technique count and defender headcount, so it is quoted rather than listed. Stingrai's published prices on the pricing page cover web application testing only, so for purple teaming request a quote with your technique list attached.
What you must prepare before day one
What you provide | Why it is load bearing |
|---|---|
A detection engineer with rule write access, free during the window and empowered to accept a rule with a known false positive rate | Without a tuner nothing is fixed and you buy a list |
SIEM read access for testers, or an analyst running queries live on the bridge | Removes the multi-day lag between "we missed it" and "here is why" |
Named test accounts at defined privilege levels, plus a cleanup plan | Keeps the exercise attributable and reversible |
Agreed targets with confirmed agent and log-forwarding state | Prevents the classic argument about whether the agent was installed |
A change window and a change ticket | Rule changes are production changes and will otherwise stall mid-exercise |
Written authorisation from your MDR or managed SIEM provider | Third parties may contractually block simulated activity |
A decision on whether the MDR is told which techniques and when | Withholding the schedule measures genuine escalation, but the contract must permit it |
Deconfliction contact and a code word | Ensures a real intrusion during the window is never mistaken for the exercise |
Keeping detections alive after the exercise
Purple team output is perishable: agents upgrade, log schemas change and noisy rules get tuned out. Put every new rule in a regression set replayed on a schedule, give each a named owner and a review date, and hand the technique list to the next red team as a "should be caught" list. That loop is the argument in continuous red teaming versus the annual pentest.
Walk away from a BAS licence rebadged as purple teaming, a heatmap delivered before a single technique has been executed, outcomes reported as detected or not detected with no telemetry source named, a refusal to hand over detection content, a re-test quoted separately, or a public test library run by people who cannot write a rule.
How Stingrai runs purple teaming
Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. Its OSCE³, OSWE, OSEP and CREST CRT certified penetration testers are also security researchers and bug bounty hunters, with 18 published CVEs across the team. Clients choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.
For purple teaming, two named penetration testers from a team holding OSCE³, OSED, OSEP, CRTO, CRTL and CREST CRT certifications sit on a shared bridge with your analysts and run real-world techniques against your Windows, Entra ID and cloud estate, reviewed by a team lead with 16 years in penetration testing and red teaming. The firm also runs covert red teaming, from assumed breach to threat intelligence-led scenarios, as one-time engagements or continuous programmes, so the purple and red cycles can be planned together. It works from Toronto and London and holds 5.0 out of 5 on Clutch across 20 reviews and 4.9 out of 5 on G2. Purple team work is human operators sitting with human defenders; Snipe, Stingrai's autonomous agent, tests web applications and APIs and has no role in it.
Frequently Asked Questions
What is purple teaming?
Purple teaming is a collaborative security exercise in which the red team executes agreed adversary techniques while the blue team watches its own SIEM and EDR consoles in real time. Each technique is scored as blocked, alerted, logged only or no telemetry, detection is tuned during the exercise, and the techniques are re-run to prove the fix works.
What is the difference between a purple team and a red team?
A red team is covert: defenders are not told, and success is measured by whether an operator reaches a defined objective without being stopped. A purple team is transparent: the technique list is shared, the SOC watches live, and success is measured as per-technique detection coverage before and after tuning. Mature programmes run red teams to find blind spots and purple team exercises to close them, then red team again to prove the new detections hold.
Who should run a purple team exercise?
The red side should be experienced offensive testers who can vary a technique and explain the telemetry it produces; the blue side is your SOC or MDR plus at least one detection engineer with rule write access. You do not need a large in-house SOC, but you do need telemetry: if endpoints have no EDR and servers do not forward logs, fix ingestion first. Organisations using an MDR gain most, because the exercise records what the provider escalated, what it silently closed and how long escalation took.
How long does a purple team exercise take?
A focused sprint of 12 to 20 techniques in one environment typically runs one to two weeks end to end. A standard exercise of 25 to 40 techniques across two or three environments usually takes three to five weeks, because tuning has to happen between the first and second execution runs. Threat-led programmes run in quarterly waves across twelve months.
How much does a purple team exercise cost?
Purple team exercises are quoted rather than list-priced, because cost depends on the number of techniques, the environments in scope, how many SOC analysts and shifts take part, and whether the vendor writes and hands over detection content. Rule development and variant re-testing move the number most. Stingrai's published prices cover web application testing only, so purple teaming is quoted against your technique list and environments.
What deliverables should a purple team SOW include?
Demand a per-technique outcome record with UTC timestamps and four outcomes (blocked, alerted, logged only, no telemetry), the telemetry source behind each detection, the detection content in a portable format such as Sigma plus the platform-native version, before-and-after re-test evidence, and a coverage view separating tested and detected, tested and missed, and never tested. Add gap classification with an owning team, response timings and the execution log. If the vendor keeps the rules, you did not buy an improvement.
Is purple teaming required by any regulation?
Yes, for some EU financial entities. Under DORA's threat-led penetration testing standard, the closure of every test includes a replay and a purple teaming exercise on topics the blue team and testers identify together (Delegated Regulation (EU) 2025/1190, Article 12), and TIBER-EU has specified purple teaming as mandatory since February 2025. Elsewhere it is not mandated, but it produces strong supporting evidence for SOC 2 criterion CC4.1 and ISO 27001 Annex A 8.16; it does not replace the penetration testing that PCI DSS v4.0.1 requires.
Related reading
Living off the land detection: a LOLBin detection matrix mapped to MITRE ATT&CK v20
Will your SOC catch a red team? Detection and response benchmarks for 2026
EDR evasion in 2026: how attacks slip past detection, and how defenders catch them
TIBER-EU vs CBEST vs DORA TLPT: which threat-led test your regulator requires
References
Picus Security. Blue Report 2026, August 2026: picussecurity.com/resource/report/blue-report-2026, with year-on-year figures from Help Net Security, 12 August 2026 and the Blue Report 2025 release.
European Commission. Delegated Regulation (EU) 2025/1190 on threat-led penetration testing, Articles 11 and 12, Official Journal 18 June 2025: eur-lex.europa.eu/eli/reg_del/2025/1190/oj.
European Central Bank. TIBER-EU framework update, 11 February 2025: ecb.europa.eu; TIBER-EU Purple Teaming Guidance, January 2025: PDF.
MITRE. ATT&CK release notes v20 (13 October 2026), v19 (28 April 2026) and v18 (28 October 2025): v20, v19, v18; current tactics at attack.mitre.org/tactics/enterprise.
Center for Threat-Informed Defense. Adversary Emulation Library and Summiting the Pyramid.
Stingrai. The State of Penetration Testing 2026, first-party data from 55 tests and 1,206 verified findings.
