A purple team exercise is what you buy when you have stopped asking whether an attacker could get in and started asking whether anyone on your side would notice. Offensive operators execute a chosen set of adversary techniques against agreed systems in agreed windows, while your SOC analysts watch their own consoles in real time. Every technique is announced, timestamped and scored against what your tooling actually did. 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.
That distinction matters commercially, because most statements of work in circulation were drafted for red teams and produce the wrong deliverables when reused for purple. What follows is enough detail to draft your own scope document.
What a purple team exercise is, and what it is not
The defining property is transparency. In a red team the defenders are not told, and the point is to see what an unaware SOC does against an operator trying to stay quiet. In a purple team the technique list is shared in advance, the SOC is on the bridge, and the operator will run the same action three times while an engineer edits a rule between attempts. You are measuring whether the observable exists, whether it reaches your platform, whether content matches it, and whether a human is told.
Four things it is not, each of which turns up in mis-sold proposals:
Not a penetration test. No comprehensive vulnerability discovery, no CVSS-scored finding inventory, no breadth across an estate. Scope a penetration test separately.
Not a breach and attack simulation subscription. A BAS platform replays a fixed catalogue on a schedule. It will not watch your analyst miss something, change one property of the technique and re-run it to find your detection threshold.
Not a tabletop. Real techniques hit real hosts and identities and produce real telemetry. A tabletop tests decision making; purple tests instrumentation.
Not a stealth-scored red team. Operators deliberately run noisy and quiet variants of the same technique, and getting caught is a successful outcome.
The honest framing: a purple team exercise is a detection engineering assessment with an offensive engine attached, which is why its deliverables look nothing like a pentest report.
Purple team vs red team: which engagement you should actually buy
Purple team vs red team is the most common scoping question. The answer follows from what you need to learn.
Dimension | Red team | Purple team exercise |
|---|---|---|
Question answered | Could an adversary reach the crown jewels unstopped? | Does detection fire on this technique, and what carried it? |
Defender awareness | Covert, limited trusted agent list | Transparent, SOC on the bridge |
Unit of measurement | Objective achieved, kill chain stage, time to detect | Per-technique outcome, telemetry source, rule state |
Operator adapts to | Evade detection | Expose the detection threshold |
Repeatability | Low, path dependent | High, techniques replayed on demand |
Primary output | Attack narrative, detection timeline, remediation plan | Outcome matrix, detection content, re-test evidence |
Typical trigger | Board or regulator wants proof | New SOC or SIEM, MDR onboarding, gaps from a prior test |
Blind spot | Rarely tells you which log source you lacked | Says nothing about whether gaps chain into an objective |
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; a second red team tests whether the new content survives an operator trying not to trip it. The fuller comparison is in red team vs penetration test vs continuous validation, and both sit under the same adversary simulation practice. Purple is a mode of working, not a third team you hire.
When to buy purple teaming services instead of another red team
Buy a purple team exercise when:
You already know you have gaps. A prior red team or pentest produced a detection timeline with whole stages nobody saw. Paying for a second covert test to rediscover the same blindness is expensive nostalgia.
Your SOC is new or newly tooled. New SIEM, migrated EDR, fresh MDR contract, changed log platform. Default rule packs are written for a generic estate and have never met your build or your identity provider.
You outsource detection and have never verified escalation. You get a per-technique record of what your MDR called, what it silently closed, and how long escalation took out of hours. That record 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 you have had no offensive testing at all, 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.
Market data supports the shape of the problem. Across more than 160 million attack simulations run from January to June 2025, controls prevented 62% of simulated attacks, down from 69% the prior year, logging coverage held flat at 54%, and only 14% of attacks generated an alert (Picus Blue Report 2025). The interesting number is not 14%. It is the distance between 54% and 14%: much adversary activity is already recorded somewhere and never reaches a human. That gap is cheap to close once you know which techniques sit in it, and expensive to guess at.
How a purple team exercise is structured, 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; 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 |
The outcome taxonomy has four states, 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.
Every miss gets a failure mode, and five are not interchangeable: no observable produced or sensor absent; observable produced but never forwarded or ingested, thanks to an agent policy, a log filter, a schema drop or an ingestion licence cap silently truncating events; ingested but no content exists; content exists but did not match, usually a field mapping error or a rule written against a command string rather than a behaviour; and content matched but the alert was suppressed, deduplicated, queued at low priority or never triaged. That last one is a process failure, not a detection failure, and most reports quietly mislabel it.
Technique selection and the ATT&CK coverage heatmap trap
Nobody exercises the whole matrix. Enterprise ATT&CK v19, released 28 April 2026, contains 15 tactics, 222 techniques and 475 sub-techniques (MITRE ATT&CK v19 release notes). The tactic count moved from the long-standing 14 because v19 renamed defence evasion to stealth (TA0005) and split a new defence impairment tactic (TA0112) out of it, so a technique list still organised around a single defence evasion column was built against an older matrix. A three to five day window covers roughly 15 to 40 techniques properly, meaning with variants and re-runs, so 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 is usually a different control owner; detection goes quiet in credential access, discovery, lateral movement, persistence, stealth, defence impairment and exfiltration. For a Windows and Entra ID estate:
Tactic | Representative techniques worth exercising |
|---|---|
Credential access | LSASS credential dumping (T1003.001), Kerberoasting (T1558.003), MFA request generation (T1621), cloud instance metadata API credentials (T1552.005) |
Discovery | Domain account discovery (T1087.002), domain trust discovery (T1482), cloud service discovery (T1526) |
Lateral movement | Pass the hash (T1550.002), pass the ticket (T1550.003), WinRM (T1021.006), SMB admin shares (T1021.002) |
Persistence | Scheduled task (T1053.005), Windows service creation (T1543.003), additional cloud credentials (T1098.001) |
Stealth, TA0005 (defence evasion in v18 and earlier) | Process injection (T1055), system binary proxy execution (T1218) |
Defence impairment, TA0112 (new in v19) | Disable or modify tools (T1685, formerly T1562.001) |
Command and control | Web protocol channels (T1071.001), DNS channels (T1071.004) |
Exfiltration | 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 states minimum: tested and detected, tested and missed, not tested. Nothing unexecuted may be green, and every green cell must trace to a timestamped entry in the execution log. The scoring games are broken down in grading ATT&CK coverage claims.
Two currency tests. ATT&CK v18 (October 2025) replaced single-sentence detection notes with structured Detection Strategies and Analytics objects and deprecated Data Sources (MITRE ATT&CK v18 release notes), and v19 Enterprise ships 697 Detection Strategies and 1,758 Analytics (MITRE ATT&CK v19 release notes), so a proposal built on the old model is stale. 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 | 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 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 the 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 |
Comparable executive metric | Coverage delta expressed the same way it will be expressed next cycle | A letter grade with no method |
Three do the heavy lifting. Telemetry attribution converts a miss into a funded fix and protects a log source from being cut next budget round. The content pack is the difference between buying an improvement and buying complaints. The re-test is the only evidence the spend changed anything.
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 a SOC 2 examination under CC4.1, which covers evaluating whether controls are functioning, and for ISO 27001 Annex A 8.16 monitoring activities. It supports those programmes, and the penetration testing that PCI DSS v4.0.1 mandates remains separate work with its own scope and report.
Duration and what drives the cost of a purple team engagement
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 and an observe-only engagement skips it. Environment count is next: each platform needs its own telemetry expertise and baseline check. Variant re-testing is third, and it is the line item worth protecting, because it proves the new content is not brittle.
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 |
Per-technique pricing quietly rewards a vendor for picking trivial techniques, so if you accept it, insist you approve the list. A purple team engagement is priced against your environments, technique count and defender headcount, so it is quoted rather than listed. Stingrai's published figures on the pricing page cover web application testing only, so for purple teaming services 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 |
The failures that derail exercises are mundane: agents missing from a third of the agreed hosts, log forwarding truncating events, an ingestion licence cap silently dropping the source you needed, and the only person who can write rules being on leave in week two.
From one exercise to continuous validation, and how to spot a commodity substitute
Purple team output is perishable. Detections rot: agents upgrade, log schemas change, SIEM migrations break field mappings, and noisy rules get tuned out by whoever was on shift. So everything the exercise produced should leave with an owner and a lifecycle. Every rule goes into a regression set replayed on a schedule, so a technique that fired in March is proven to still fire in September, and every rule gets a named owner and a review date. The coverage matrix becomes a living artefact your team edits, not a PDF in a shared drive. And the technique list feeds the next red team as a "should be caught" list, turning the covert test into a direct examination of whether the new content survives evasion. That loop is the argument in continuous red teaming versus the annual pentest.
To tell a genuine detection engineering assessment from a commodity substitute, walk away from a BAS licence rebadged as purple teaming services, 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 junior staff running a public test library with nobody able to write a rule.
Stingrai delivers purple teaming with senior human testers holding OSCE3, OSCP, OSWE, OSED, OSEP, CREST CRT, CISSP and CRTO, working alongside your analysts on a shared bridge. The firm was founded in 2021, is CREST-accredited as a penetration testing service provider at firm level, runs from Toronto with a London office, has 18 published CVEs and holds 5.0 out of 5.0 across 19 Clutch reviews. One point of honesty on scope: Snipe, our autonomous agent, is built for web application penetration testing and has no role here. Purple team work is human operators sitting with human defenders.
Frequently Asked Questions
What is a purple team exercise?
A purple team exercise is a transparent, collaborative engagement in which offensive operators execute agreed adversary techniques while the defending team watches its own SIEM and EDR consoles in real time. Each technique is announced and timestamped, then scored as blocked, alerted, logged only, or producing no telemetry at all. Detection content is written or tuned during the engagement and the same techniques are re-executed to prove the fix works.
What is the difference between a purple team and a red team?
A red team is covert and adversarial: defenders are not told, and success is measured by whether an operator reaches a defined objective without being stopped. A purple team is transparent and collaborative: 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.
How much does a purple team exercise cost?
Purple team exercises are quoted rather than list-priced, because cost is driven by the number of techniques executed, how many environments are in scope, how many SOC analysts and shifts take part, and whether the vendor writes and hands over detection content or only observes. Rule development and variant re-testing move the number most. Stingrai's published one-time and monthly prices cover web application testing only, so a purple team engagement is quoted against your technique list and environment inventory.
How long does a purple team engagement 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. That tuning gap is why elapsed time exceeds execution days, and a proposal without one is not re-testing anything.
What deliverables should a purple team SOW include?
Demand a per-technique outcome record with UTC timestamps and four possible outcomes (blocked, alerted, logged only, no telemetry), the named telemetry source that carried each detection, the detection content itself in a portable format such as Sigma plus the platform-native version, before-and-after re-test evidence for every technique that was tuned, and a coverage view separating tested and detected from tested and missed from never tested. Add gap classification with a named owning team, response timings from alert to analyst acknowledgement, and the raw execution log so your team can retro-hunt. If the vendor keeps the rules, you did not buy an improvement.
Do we need a SOC before buying purple teaming services?
You need telemetry and at least one person who can change a detection rule, but not a large in-house SOC. Organisations using an MDR get particular value, because the exercise produces a per-technique record of what the provider escalated, what it silently closed, and how long out-of-hours escalation took. If endpoints have no EDR and servers do not forward logs, fix ingestion first or scope a deliberately small telemetry baseline exercise instead.
Does a purple team exercise satisfy PCI DSS or SOC 2 requirements?
A purple team exercise produces strong supporting evidence for a SOC 2 examination under CC4.1, which covers evaluating whether controls are functioning, and for ISO 27001 Annex A 8.16 monitoring activities. It is not a penetration test, so the penetration testing that PCI DSS v4.0.1 mandates remains separate work with its own scope and report. Treat purple team output as detection and monitoring evidence, and keep your penetration testing cadence unchanged.
How many MITRE ATT&CK techniques should a purple team exercise cover?
A well-run execution window of three to five days covers roughly 15 to 40 techniques properly, meaning with variants and a re-run after tuning. That is a small fraction of the 222 techniques and 475 sub-techniques in Enterprise ATT&CK v19 (MITRE ATT&CK v19 release notes), which is why selection should follow the threat groups credible for your sector rather than matrix breadth. Any proposal claiming full matrix coverage in a single week is describing an automated script, not an exercise.
References
Picus Security. The Blue Report 2025. August 11, 2025. https://www.picussecurity.com/resource/press-release/picus-launches-blue-report-2025. Analysis of more than 160 million real-world attack simulations run between January and June 2025. Source of the 62% prevention effectiveness figure and its fall from 69% the prior year, the 54% logging coverage figure, and the 14% alert generation figure.
MITRE. ATT&CK v19 release notes. April 28, 2026. https://attack.mitre.org/resources/updates/updates-april-2026/. Source of the Enterprise counts of 15 tactics, 222 techniques and 475 sub-techniques, the 697 Detection Strategies and 1,758 Analytics figures, and the split of the defence evasion tactic into stealth (TA0005) and defence impairment (TA0112).
MITRE. ATT&CK v18 release notes. October 28, 2025. https://attack.mitre.org/resources/updates/updates-october-2025/. Source of the move from single-sentence technique detections to structured Detection Strategies and Analytics objects, and of the deprecation of Data Sources.
Center for Threat-Informed Defense. Adversary Emulation Library. Continuously updated. https://github.com/center-for-threat-informed-defense/adversary_emulation_library. Open library of adversary emulation plans covering named groups including APT29, FIN6, FIN7, OilRig, Sandworm and Turla. Cited as a technique-selection input for building a threat-relevant list instead of chasing matrix breadth.
Center for Threat-Informed Defense. Summiting the Pyramid, version 4.0.0. Continuously updated. https://center-for-threat-informed-defense.github.io/summiting-the-pyramid/. Methodology for scoring analytics on how hard they are for an adversary to evade. Cited as the durability test for detection content, and the basis for the point that a rule written against the exact command an operator typed is brittle.
