Organizations detected the intrusion themselves in 52% of the incidents Mandiant investigated in 2025, up from 43% in 2024, while the global median dwell time rose to 14 days from 11 (M-Trends 2026, published 23 March 2026). Detection is improving and attackers still get two weeks. That is the problem a security lead is really buying against when choosing between a penetration test, a red team engagement and a purple team exercise, and the three do very different things about it.
Quick answer: A red team attacks, a blue team defends, and a purple team is the two working together in the open. A penetration test proves what is exploitable in an agreed scope. A red team engagement proves whether a realistic attacker could reach a named objective and whether your defenders would notice. A purple team exercise proves, technique by technique, what your detection sees, and fixes the gaps while the testers are still there. Most mid-market teams should buy them in that order: penetration test, purple team, then an assumed breach red team. Stingrai runs all three with certified penetration testers; its red teaming and purple teaming are scoped per engagement.
This guide gives the definitions first, with their primary sources, then the comparison, the evidence on detection, a decision table by goal and maturity, a one-year sequence and the questions to put to a provider. Standards, regulations and advisories were read at their publishers on 13 November 2026, and every figure links to its source.
Red team vs blue team vs purple team: what each one is
The red team attacks. The US government glossary that NIST publishes defines a red team as "a group of people authorized and organized to emulate a potential adversary's attack or exploitation capabilities against an enterprise's security posture", and gives it a purpose beyond breaking in: to improve security "by demonstrating the impacts of successful attacks and by demonstrating what works for the defenders (i.e., the Blue Team) in an operational environment" (NIST glossary, from CNSSI 4009-2022). In commercial work that means a small group of offensive specialists who pursue an agreed objective covertly, the way a specific adversary would.
The blue team defends. The same glossary defines the blue team as "the group responsible for defending an enterprise's use of information systems by maintaining its security posture against a group of mock attackers (i.e., the Red Team)" (NIST glossary). In practice the blue team is your security operations center (SOC), your incident responders, your detection engineers and, for many mid-market companies, a managed detection and response (MDR) provider. Red team vs blue team is not a contest with a winner. The red team exists to show the blue team what it would and would not have caught.
The purple team is red and blue working together. It is a way of working, not a third group of people. The red side runs agreed attacker techniques one at a time and says so; the blue side watches its own consoles, records what its tools did with each one, and fixes what it missed before the testers leave. NIST's glossary has entries for red, blue and white teams but none for purple (searched on 13 November 2026). The clearest official definition is in EU law: the DORA testing standard defines purple teaming as "a collaborative testing activity that involves both the testers and the blue team" (Delegated Regulation (EU) 2025/1190, Article 1(6)).
One more color completes the set. The white team is the small group on the client side who know that an unannounced test is running, hold the rules of engagement and can stop it. NIST's glossary describes it as "a small group of people who have prior knowledge of unannounced Red Team activities" (NIST glossary). European financial rules call the same group the control team; the TIBER-EU framework changed the name from White Team to Control Team in its February 2025 update.
Team | Who it is | Job during a test | Told about the test? |
|---|---|---|---|
Red team | Offensive testers, internal or from a provider | Emulate an adversary against live systems toward an objective | Yes, they run it |
Blue team | SOC analysts, incident responders, detection engineers, MDR provider | Detect, contain and respond | No in a red team engagement; yes in a purple team exercise |
Purple team | Red and blue on one call, sharing the plan | Run techniques one at a time, record what was seen, tune detection, re-run | Yes, both sides |
White team (control team) | A few named client staff, usually with an executive sponsor | Authorize, deconflict, hold stop authority | Yes, and nobody else is |
What is purple teaming?
Purple teaming is a collaborative security exercise in which testers execute real attacker techniques against your systems, announced and one at a time, while your defenders watch their own tools, so that every technique gets a recorded result (blocked, alerted, logged only or not seen) and detection is tuned and re-tested on the spot.
Three things separate it from the other two engagements in this guide. Stealth is deliberately given up, because the point is to find the detection threshold, not to slip under it. The unit of work is a technique, usually an entry in MITRE ATT&CK, not an asset or an objective. And the output is changed detection content with before-and-after evidence, not a list of vulnerabilities or an attack story.
The European Central Bank's purple teaming guidance for TIBER-EU tests describes the same idea from the regulator's side. It calls purple teaming a collaborative activity involving both the red team testers and the blue team, lists formats from tabletop discussions to re-running attack steps on live systems, and states plainly that it is not intended to replace the confidential red team phase (TIBER-EU Purple Teaming Guidance, January 2025). How an exercise runs phase by phase, the metrics to compute and the deliverables to write into the contract are covered in Stingrai's guide to purple team exercises.
Where the penetration test fits: NIST CA-8 and its red team enhancement
A penetration test is not a team color, which is why it gets confused with red teaming. The cleanest way to see the relationship is the control catalog that US federal security frameworks build on, NIST SP 800-53 Rev. 5.
Control CA-8, Penetration Testing, reads: "Conduct penetration testing [Assignment: organization-defined frequency] on [Assignment: organization-defined systems or system components]." NIST's discussion says penetration testing "goes beyond automated vulnerability scanning", is conducted by "agents and teams with demonstrable skills and experience", and "attempts to duplicate the actions of adversaries". Its glossary definition is a test methodology in which assessors, "typically working under specific constraints, attempt to circumvent or defeat the security features of a system" (NIST glossary).
Enhancement CA-8(2), Red Team Exercises, sits on top of it. It asks organizations to "employ the following red-team exercises to simulate attempts by adversaries to compromise organizational systems in accordance with applicable rules of engagement", followed by a list the organization defines. NIST's discussion draws the line this guide depends on. Red team exercises "extend the objectives of penetration testing by examining the security and privacy posture of organizations and the capability to implement effective cyber defenses", may include "technology-based attacks and social engineering-based attacks", and differ in realism: "While penetration testing may be primarily laboratory-based testing, organizations can use red team exercises to provide more comprehensive assessments that reflect real-world conditions."
Two details matter to a buyer. First, NIST treats red teaming as an extension of penetration testing, not a replacement: in the baselines of SP 800-53B, CA-8 and its independent-tester enhancement CA-8(1) are selected for the high baseline only, and CA-8(2) is not selected for any NIST baseline. FedRAMP is the exception for cloud providers that sell to federal agencies: its 2026 rules say providers with Rev5 Class C and Class D certifications, the classes that broadly correspond to Moderate and High, "MUST include" CA-08 (02), Red Team Exercises, "in a FedRAMP independent assessment at least once per year" (FedRAMP rule IVV-CSF-AIA); see FedRAMP penetration testing requirements. Second, SP 800-53 Rev. 5, including Release 5.2.0, has no control that mentions purple teaming (checked 13 November 2026). Purple teaming entered the rule books through European financial regulation, covered below.
All three engagements share one vocabulary. MITRE describes ATT&CK as "a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations", and its FAQ says the project began as a common language that offense and defense could both use to improve (MITRE ATT&CK; ATT&CK FAQ). The current release, ATT&CK v20 of 13 October 2026, lists 15 tactics, 227 techniques and 479 sub-techniques for Enterprise (MITRE, October 2026 release notes). A penetration test report can map findings to it, a red team report maps every action to it, and a purple team exercise is planned from it. Ask every provider which version they map to.
Penetration test vs red team vs purple team: what each one proves
Penetration test | Red team engagement | Purple team exercise | |
|---|---|---|---|
What it proves | Which weaknesses in an agreed scope can actually be exploited, and how to fix them | Whether a realistic adversary can reach a named objective, and whether your people and tools detect and stop it | Which attacker techniques your stack blocks, alerts on, only logs or never sees, and that the fixes work |
Unit of work | An asset list: applications, APIs, IP ranges, cloud accounts | One or more objectives, such as domain administrator or the payments system | A list of ATT&CK techniques and sub-techniques |
Are defenders told? | Usually yes | No, only the white team (control team) knows | Yes, both sides share the plan |
What it needs from you | A defined scope, test accounts, a contact, and engineers with time to fix findings | A working detection and response function, a white team with stop authority, logs that can rebuild a timeline, a crown jewel worth naming | Telemetry on the target systems (EDR and central logging), an analyst on the call, and someone who can change a detection rule during the window |
Typical duration | Days to two weeks of testing (Stingrai planning guidance) | 2 to 3 weeks for an assumed breach, 4 to 8 weeks from outside (Stingrai planning guidance); at least 12 weeks of active testing under DORA | 1 to 2 weeks for a focused sprint, 3 to 5 weeks with tuning between two runs (Stingrai planning guidance) |
What drives cost | Scope size, number of user roles, depth (black, grey or white box) | Operator days: scenario and starting point, number of objectives, weeks of covert operation, threat intelligence depth, social engineering and physical add-ons | Technique count, number of environments, who writes the detection content, how many analysts and shifts take part, re-run scope |
What you receive | Findings with severity, evidence and remediation guidance, then a retest | An attack narrative, a detection and response timeline per stage, ATT&CK mapping, root causes, a replay with the SOC | A per-technique result record, the telemetry source behind each detection, tuned detection content, before-and-after re-run evidence |
Common mistake | Buying it to answer "would we notice an attacker?" Defenders are told, so it cannot say | Buying it before the basics are fixed or before anyone watches the alerts, then paying for a report that says "patch" and "not logged" | Running it with nobody able to change a rule, or accepting a coverage heatmap in place of executed techniques |
Sources: NIST SP 800-53 Rev. 5, CA-8 and CA-8(2); Delegated Regulation (EU) 2025/1190, Article 11 for the DORA minimum; Stingrai's red teaming and purple teaming service scopes for cost drivers and deliverables.
Read across the first row and the three stop looking like small, medium and large versions of one product. A penetration test measures your attack surface. A red team engagement measures your defenders. A purple team exercise improves your defenders and measures the improvement. The two-way comparison, with compliance mapping, is in red team testing vs penetration testing, and the full definition of red teaming is in what is red teaming.
The evidence: detection fails quietly, and a covert test is a slow way to learn that
Two public red team assessments by the US Cybersecurity and Infrastructure Security Agency (CISA) show what the engagements find in practice, and why the order you buy them in matters.
AA24-193A: unseen until the red team said so, then three months of working together. In advisory AA24-193A, published 11 July 2024, CISA describes a SILENTSHIELD red team assessment of a large federal civilian agency that ran for about eight months in 2023. The team got in twice, through a known vulnerability in an unpatched web server and through phishing, went on to full domain compromise, and "remained undetected by network defenders throughout the first phase". Five months into the assessment, the red team notified the SOC itself; CISA's timeline puts the first foothold on 25 January 2023 and the notification on 12 June. The detail that matters most to a buyer is why nothing fired: endpoint detection tools had detected and quarantined several of the team's tools, including the first phishing payload, but, in CISA's words, "the organization's daily procedures did not always include review of EDR alerts". The lessons learned include that the organization "did not effectively or efficiently collect, retain, and analyze logs" and that "a 'known-bad' detection approach hampered detection of alternate TTPs".
Then the assessment changed shape. For three months the red team met weekly with the organization's SOC, senior technical staff and system administrators, deliberately withholding its indicators so the defenders would build and test their own detections. CISA reports that this "led to measurable improvements in response times for known techniques and behavior-based detections that uncovered previously unknown tradecraft". CISA does not use the phrase, but that second phase is purple teaming as the EU standard defines it: a collaborative testing activity that involves both the testers and the blue team.
AA24-326A: some access cut off, Windows activity missed, alerts unread. In advisory AA24-326A, published 21 November 2024, CISA assessed a critical infrastructure organization, at its request, over about three months. After its own spearphishing attempts failed, the red team got in through "a web shell left from a third party's previous security assessment". About two weeks later the team had compromised a Windows domain controller. The defenders did detect and remove much of the red team's access in the Linux environment once CISA had reported the entry point, and the Windows activity went undetected. CISA's findings read like a purple team backlog: the organization "relied too heavily on host-based endpoint detection and response (EDR) solutions", hosts on a legacy operating system had no EDR at all, and "the red team's activities generated security alerts that network defenders did not review". In the one case where EDR stopped the phishing payload, it "generated an alert that network defenders neither read nor responded to".
Three conclusions follow for a buyer.
Most detection failures are ordinary. Unreviewed alerts, missing log sources and rules that match one known-bad string are not exotic. They are what a purple team exercise is built to find, in days, with the fix applied in the same window. A covert red team finds the same things too, but it reports them weeks or months later as a timeline of what nobody saw.
A red team is the only way to test the whole response. An announced exercise would not have shown either organization that its defenders failed to act promptly on what they saw, that bureaucratic processes and decentralized teams slowed them down, or that leadership had deprioritized a vulnerability its own security team had flagged. Those are findings about behavior under real conditions, and only an unannounced test produces them.
The mature pattern is red, then purple. CISA's own SILENTSHIELD design runs a covert phase and then a collaborative one. European financial regulation now requires the same sequence, as the section on regulators shows.
Speed raises the stakes. M-Trends 2026 reports that the median time between initial access and hand-off to a second threat group fell from more than 8 hours in 2022 to 22 seconds in 2025. On 30 October 2026, Google Threat Intelligence Group and Mandiant reported attackers running open-source agentic frameworks inside real intrusions, with individual ARTEX execution sequences running in bursts of roughly 2 to 25 seconds, and observed that such frameworks "currently trade stealth for velocity" (Google, ARTEX and Friends). The same report makes the point that detecting an attack and disrupting it are different functions. For a purple team exercise, that means recording time to alert and time to acknowledge for every technique, not just whether an alert exists. For a red team engagement, it means the metric to demand is time to containment. Stingrai's analysis of that report is in ARTEX and agentic offensive frameworks.
The decision table: what to buy, by goal and maturity
Start from the question you need answered and the state of your defenses, not from the engagement name on a proposal.
Your situation | Buy first | Then | Why |
|---|---|---|---|
No penetration test in the last 12 months, or High and Critical findings still open | Penetration test of the estate that matters most (often the internal network and the main application) | Retest, then a purple team sprint | A red team would walk in through known flaws and tell you to patch. A penetration test tells you the same with the complete list |
A customer, auditor or framework has asked for a penetration test report | Penetration test | Nothing else is required for that request | A red team follows one path and a purple team scores detection. Neither covers a defined scope |
EDR and central logging are deployed, but nobody has measured what actually alerts | Purple team exercise, as a focused sprint | Assumed breach red team | You already own the data. The cheapest gain is finding out which techniques are logged and never alerted on |
Detection is outsourced to an MDR provider and escalation has never been verified | Purple team exercise with the MDR on the call | Assumed breach red team, unannounced to the MDR | A per-technique record of what the provider escalated, closed silently or raised late is evidence you can act on |
New SIEM or EDR, a cloud migration, or the months after an incident | Purple team exercise | Red team once the new content has settled | Default rule packs have never met your build, your identity provider or your administrators' habits |
A SOC that triages around the clock, fixed penetration test findings, and a board asking whether the defenses hold | Red team engagement (assumed breach if initial access has already been proven in earlier tests) | Replay and a purple team session on what was missed | Only a covert test measures people, process and technology together |
Designated by a financial supervisor for threat-led testing | The supervisor's framework (DORA TLPT, TIBER-EU, CBEST), with accredited providers where the framework demands them | The closure-phase replay and purple teaming it prescribes | The shape, providers and cadence are set for you |
A significant new application, API or release | Penetration test of that application | Add it to the next purple or red scope if it holds crown jewels | New code needs coverage, which only a scoped test gives |
Stingrai's own data explains the first row. In its State of Penetration Testing 2026 dataset, 92% of the findings from internal network penetration tests (408 findings across 8 tests) were rated High or Critical, and 56.9% of them were outdated or unpatched software. An estate in that condition gets more from a penetration test and a patching cycle than from any exercise that measures detection.
When a purple team exercise is the right first step for a mid-market team
For a company with a security team of a handful of people, an MDR contract and an EDR agent on most endpoints, purple teaming is usually the first detection purchase, ahead of a red team. Four conditions make it the right call.
The basics have been tested and fixed. A recent penetration test exists, and its High and Critical findings are closed and retested.
Telemetry exists. Endpoints run EDR, and identity, server and cloud logs reach a central platform. If they do not, fix ingestion first; an exercise against systems that record nothing produces the same finding over and over.
Someone can change a rule. A detection engineer, a senior analyst or the MDR's engineering team can write, approve and deploy detection content during the exercise. Without that person you buy a list.
The question is "what do we see?", not "would they get in?" If leadership needs proof that the crown jewels are reachable, that is a red team question.
When those hold, a purple team exercise gives a mid-market team three things a red team cannot give at the same cost. Coverage is chosen, so the budget goes to the middle of the attack chain (credential access, discovery, lateral movement, persistence, defense impairment) where detection is usually thinnest, instead of being spent on weeks of stealthy initial access. Fixes land during the engagement, with a second run to prove them. And the analysts learn by watching real techniques cross their own consoles, which is the training most small SOCs never get. The technique-level detail for two common starting points is in Stingrai's guides to Kerberoasting and password spraying.
Know its limit before you buy. A purple team exercise is announced and cooperative, so it says nothing about whether the gaps chain into a route to an objective, whether an analyst would have escalated at 2 a.m., or whether your incident process works under pressure. It measures detection. It does not measure response to surprise.
When a red team engagement is the right call
Buy a red team engagement when there is a defensive capability worth measuring and a decision that depends on the answer. The readiness signs are concrete:
Alerts are triaged around the clock, in-house or by a provider, and somebody acts on them.
Endpoint, identity and network logs are retained long enough to reconstruct an intrusion that lasts weeks.
At least one round of detection tuning has happened, through a purple team exercise or your own engineering, so the test is not a tour of known gaps.
A crown jewel has been named, with a business owner who will act on the result. Stingrai's guide to red team objectives and crown jewels covers how to choose one.
A small white team exists, with an executive sponsor, written rules of engagement and stop conditions.
Most first-time buyers should start with an assumed breach engagement, which begins from a compromised laptop or a stolen credential and spends the budget inside the network. Neither CISA assessment above needed anything novel to get inside, one using an unpatched server and phishing, the other a leftover web shell after its own phishing attempts failed, and what decided the outcome was everything that happened afterwards. A full-scope engagement from outside, with social engineering and physical entry where authorized, is worth the extra weeks when initial access is itself the question, or when a board or a customer needs the whole chain demonstrated.
A red team is a poor way to get a vulnerability list, a poor first test of a new SOC, and a poor substitute for the penetration test an auditor asked for. It answers one question well: against a realistic adversary with a goal, do our defenses hold, and how long does each stage take us to notice?
When a penetration test is still the answer
The penetration test stays in the program whatever else you buy. It is the only one of the three that examines a whole defined scope, so it is the only one that supports statements such as "this application was tested across every role" or "the cardholder data environment was tested from inside and outside". It is the test that audits and customer security reviews most often ask for by name, and it is the cheapest way to remove the paths a red team would otherwise spend your money rediscovering.
Buy a penetration test when something new ships, when an environment has not been tested in a year, when an audit or a customer asks for one, and before the first purple or red engagement. Scope and cost for the two network variants are in Stingrai's guides to internal network penetration testing and external network penetration testing.
How to run all three in sequence over a year
The three engagements feed each other when they are booked in the right order. The calendar below is one workable plan for a mid-market company running them for the first time; the months are illustrative, not a fixed schedule.
Months 1 to 2: penetration test. Internal and external network, plus the application that holds the most sensitive data. The output is a fix list.
Months 2 to 4: fix and retest. Close High and Critical findings and have them retested. Every path closed here is one the later engagements do not waste time on.
Months 5 to 6: purple team exercise. Pick the technique list from the threat groups relevant to your sector, weighted toward the middle of the chain, and keep a first sprint small enough to run every technique twice. Run one, tune, run two. Keep the per-technique record; it becomes the baseline for next year.
Months 8 to 9: assumed breach red team. Leave a gap so the new detections settle into normal operations, then test them unannounced against operators who are trying not to trip them. Keep the list of techniques that should now be caught away from the red team until the engagement ends, then use it as the scoring sheet.
Month 10: replay and purple team session on the misses. Walk the SOC through the red team's path, stage by stage, and re-run the steps that were logged but not alerted on, or alerted on but not triaged.
Months 11 to 12: retest and plan. Retest the fixes from the red team, replay the purple team regression set, and set next year's scope from what changed.
Larger enterprises compress or repeat the cycle: continuous penetration testing of applications between annual tests, purple team waves each quarter, and a full-scope or threat-led red team once a year or on the supervisor's cycle. The argument for the continuous version is in continuous red teaming versus the annual pentest.
What regulators say about red and purple teaming
Financial regulators have written the red-then-purple sequence into their frameworks. They are worth reading even if none applies to you, because they are the most carefully argued public designs for these exercises.
Framework | What it says about red teaming | What it says about purple teaming |
|---|---|---|
DORA threat-led penetration testing (EU) | Identified financial entities must run TLPT at least every 3 years, a frequency the competent authority may raise or lower; DORA defines TLPT as a controlled, bespoke, intelligence-led red team test of critical live production systems. The active red team phase lasts at least 12 weeks | Mandatory in closure: the blue team and testers replay the test no later than 10 weeks after active testing ends, and the control team conducts a purple teaming exercise on topics they identify together. A limited purple teaming exercise is also the last-resort way to continue a test that cannot safely go on covertly |
TIBER-EU (ECB) | The framework that the DORA standard mirrors; covert, intelligence-led red teaming of live systems | Specified as mandatory since the February 2025 update. The guidance places the closure exercise no later than ten weeks after active testing and says purple teaming does not replace the confidential red team phase |
CBEST (Bank of England) | Regulator-led, intelligence-led testing of systemically important firms; average project around 9 to 12 months; threat intelligence and penetration testing providers must be CBEST accredited | The 2024 implementation guide does not use the term. Its learning step is a Detection and Response Capability Assessment by the testing provider, including post-testing interviews with the firm's SOC and incident response team |
NIST SP 800-53 Rev. 5 (US) | CA-8(2) red team exercises, an enhancement to penetration testing that no NIST baseline selects; FedRAMP requires it at least once a year for Class C and Class D (broadly Moderate and High) cloud services | No control mentions purple teaming (Rev. 5, including Release 5.2.0, checked 13 November 2026) |
Sources: Regulation (EU) 2022/2554, Articles 3 and 26; Delegated Regulation (EU) 2025/1190, Articles 11 and 12; ECB, 11 February 2025; TIBER-EU Purple Teaming Guidance; Bank of England, CBEST Implementation Guide; NIST SP 800-53 Rev. 5.
Two points carry over to any buyer. The EU standard, which says it draws on the experience of TIBER-EU tests, makes the collaborative follow-up mandatory so that the most is learned from the covert test, so book the replay and the purple team session when you book the red team. And the ECB's TIBER-EU purple teaming guidance insists that purple teaming does not stand in for the covert phase, so a program that only ever runs announced exercises has not tested its response.
A note on providers for regulated tests: CBEST work can only be delivered by firms the Bank of England has accredited for it. Stingrai is CREST accredited for Penetration Testing and AI-Enabled Penetration Testing. It is not a CBEST provider and does not hold CREST's Threat Led Penetration Testing accreditation, so confirm which registers your supervisor requires before you shortlist anyone. The frameworks are compared in TIBER-EU vs CBEST vs DORA TLPT.
Duration and cost: what moves the number
None of the three has a meaningful average price, because each is priced on a different unit.
Penetration tests are priced on scope. The number of applications, user roles, hosts and environments sets the tester-days. For one web application and associated APIs, Stingrai publishes fixed prices: the Autonomous Pentest is US$3,000 and the Hybrid Pentest is US$6,800 (pricing). Network, cloud, mobile and other scopes are quoted.
Red team engagements are priced on operator days. The drivers, in rough order of weight: the scenario and starting point (assumed breach costs less than a full chain from outside), the number of objectives and how far apart they sit, how many weeks the operators must stay covert, the depth of threat intelligence, the environments in scope, and add-ons such as phishing, vishing and physical entry. Stingrai's planning guidance is 2 to 3 weeks for a single-scenario assumed breach and 4 to 8 weeks for a full-scope engagement. Published reference prices and the six cost drivers are in how much a red team engagement costs.
Purple team exercises are priced on techniques, environments and detection engineering. The biggest lever is whether the provider only observes and reports or also writes, tests and hands over detection content. Next come the number of environments (one Windows domain, or a domain plus Entra ID plus a cloud account), how many analysts and shifts take part, and whether the second run covers only the misses or every technique with variants. By Stingrai's planning guidance, a focused sprint runs 1 to 2 weeks and an exercise with tuning between two runs takes 3 to 5.
Stingrai scopes red team and purple team work per engagement, so there is no list price for either. If the budget only stretches to one detection-focused engagement this year, a purple team sprint followed by a short assumed breach usually tells you more than a single long red team.
What to ask a provider
Use the same questions for every bidder and compare the answers side by side. A fuller set, with scoring guidance, is in the pentest and red team RFP question bank, and a ranked view of the market is in best red teaming companies.
For any of the three
Who will do the work? Ask for named testers, their certifications and their experience with your technology.
Can we see a sample report for this exact engagement type?
Is the retest included, and how long after delivery can we use it?
How is every tool, account, implant and file you place on our systems logged and removed, and will you confirm cleanup in writing? CISA's AA24-326A red team got in through a web shell left from a third party's previous security assessment.
Which ATT&CK version do you map to, and at technique or sub-technique level?
For a penetration test
Which roles and which authenticated journeys will be tested, and how much of the work is manual?
How do findings reach us: at the end, or as they are confirmed?
What will the attestation letter state about scope and dates?
For a red team engagement
What objective would you propose for us, and why that one?
Are detection and response timings per stage a contractual deliverable, or a courtesy?
Who do you need in the white team, how does deconfliction work, and what stops the test?
What starting position do you recommend, and which leg-ups would you ask for if a stage stalls?
Is a replay with our SOC included, and can it turn into a purple team session on the misses?
For a purple team exercise
Do you score four outcomes (blocked, alerted, logged only, no telemetry), and do you name the log source behind each?
Who writes the detection content, in which format, and do we own it afterwards?
Is the second run in the price, and does it include variants of each technique?
Have you worked with our MDR provider or our SIEM, and will the provider be on the call?
How do you choose the technique list, and can we approve it?
Walk away from a breach and attack simulation license presented as purple teaming, a coverage heatmap delivered before a single technique has been executed, a red team proposal with no detection timeline, and any proposal that cannot say who will be at the keyboard.
How Stingrai runs penetration tests, red team engagements and purple team exercises
Stingrai is a CREST-accredited penetration testing company offering fully human-led and hybrid (human penetration testers plus AI agents) penetration tests, delivered by experienced penetration testers who are also world-class security researchers and bug bounty hunters. Founded in Toronto, Canada in 2021, it holds CREST accreditation for both Penetration Testing and AI-Enabled Penetration Testing. The team has published 18 CVEs and holds OSCE³, OSEP, OSWE, CRTO, CRTL and CREST CRT certifications across its members.
Red teaming. Engagements are human-led and scoped around objectives, in three modes: assumed breach, black-box full chain, and threat intelligence-led scenarios in the DORA and TIBER-EU style, on-premise and in the cloud (Active Directory, Entra ID, AWS, Azure and Google Cloud), with phishing, vishing and physical entry where scoped. Two named penetration testers from that team run each engagement, led by a team lead with 16 years in penetration testing, red teaming and exploit development. Detection and response timings are a contractual deliverable: every stage records what was prevented, logged, alerted or missed. You receive an executive summary, an attack narrative, the detection and response timeline, ATT&CK mapping with root causes, a replay and debrief with your SOC, an included retest and an attestation letter. Details are on the red teaming page.
Purple teaming. Stingrai's operators execute techniques selected from MITRE ATT&CK while your analysts watch their SIEM and EDR, on-premise and in the cloud, with both teams talking throughout. Blind spots in log collection, correlation logic and alert thresholds are identified as they appear, rules are tuned during the exercise, and SOAR playbooks are tested against the live techniques. You receive a gap analysis report with validated detection rules, tuning recommendations and per-technique results mapped to ATT&CK, as a one-time exercise or a continuous program. Details are on the purple teaming page.
Penetration testing. Internal and external network penetration tests, Active Directory security assessments, cloud and mobile application tests are human-led and scoped per engagement. For web applications, the Hybrid Pentest pairs penetration testers with Snipe, Stingrai's autonomous AI agent for web applications and associated APIs, testing together throughout. Snipe has no role in red team or purple team work, which is human operators working against, or beside, human defenders. Findings are posted to the PTaaS portal as they are confirmed, each with a proof of concept and remediation guidance, and tests run as one-time annual engagements or continuous programs.
Next step: Purple teaming service | Red teaming service | Get a quote | Book a scoping call
Frequently Asked Questions
What is a purple team?
A purple team is a red team and a blue team working together on one exercise. The red side runs agreed attacker techniques in the open, one at a time, while the blue side watches its own tools, records whether each technique was blocked, alerted on, only logged or not seen, and tunes detection before the techniques are run again. It is a way of working, not a third group of people.
What is the difference between a red team and a blue team?
A red team attacks and a blue team defends. NIST's glossary defines a red team as a group authorized to emulate a potential adversary's attack or exploitation capabilities against an enterprise's security posture, and a blue team as the group responsible for defending the enterprise against those mock attackers. In practice the blue team is the SOC, incident responders, detection engineers and any managed detection provider, and the red team's purpose is to show them what they would and would not have caught.
What is purple teaming?
Purple teaming is a collaborative security exercise in which testers execute real attacker techniques against your systems, announced and one at a time, while your defenders watch their own consoles. Every technique gets a recorded result, detection is tuned during the exercise, and the techniques are re-run to prove the fix. The EU's DORA testing standard defines it as "a collaborative testing activity that involves both the testers and the blue team".
Purple team vs red team: which should we buy first?
Most mid-market teams should buy the purple team exercise first. It needs only working telemetry and someone who can change a detection rule, it spends the budget on the techniques where detection is weakest, and the fixes land during the engagement. Buy the red team first when you already have a tuned detection and response function that triages alerts around the clock, or when a regulator requires a threat-led test.
What is the difference between red teaming and penetration testing?
A penetration test examines an agreed scope and reports every exploitable weakness it finds, usually with the security team aware. A red team engagement pursues one objective covertly, with only a small control group informed, to measure whether defenders detect and stop a realistic adversary. NIST SP 800-53 treats red team exercises as an enhancement, CA-8(2), that extends the objectives of penetration testing to the organization's capability to implement effective cyber defenses.
Can a purple team exercise or a red team engagement replace a penetration test?
No. A purple team exercise scores detection of a technique list and a red team follows one path to an objective, so neither examines a whole defined scope. When a standard, an auditor or a customer asks for a penetration test, a penetration test is what satisfies the request. The other two add evidence about detection and response that a penetration test cannot give.
Do we need our own SOC to run a purple team exercise?
No, but you need telemetry and someone who can act on it. Endpoints should run EDR and logs should reach a central platform, and a detection engineer, senior analyst or your managed detection provider must be able to change a rule during the exercise. Companies that outsource detection often gain the most, because the exercise records what the provider escalated, what it closed silently and how long escalation took.
How long do a penetration test, a red team engagement and a purple team exercise take?
By Stingrai's planning guidance, a penetration test usually runs days to two weeks of testing, a red team engagement runs 2 to 3 weeks for a single-scenario assumed breach and 4 to 8 weeks for a full-scope engagement from outside, and a purple team exercise runs 1 to 2 weeks as a focused sprint or 3 to 5 weeks with tuning between two runs. Regulated tests are longer: DORA sets the active red team phase at a minimum of 12 weeks.
Is purple teaming required by any regulation?
Yes, for some EU financial entities. Under the DORA threat-led penetration testing standard, Delegated Regulation (EU) 2025/1190, the closure phase of every test includes a replay and a purple teaming exercise on topics the blue team and testers identify together, and TIBER-EU has specified purple teaming as mandatory since its February 2025 update. NIST SP 800-53 Rev. 5, including Release 5.2.0, has a red team enhancement, CA-8(2), but no control that mentions purple teaming (checked 13 November 2026).
Related reading
Purple Teaming: What a Purple Team Exercise Is, How It Runs and What to Demand
Red Teaming: What It Is, How an Engagement Runs and When You Need One (2026)
Red Team Testing vs Penetration Testing vs Continuous Validation
Assumed Breach Engagements: When to Start the Test From Inside
Red Team Rules of Engagement: What to Demand Before You Sign
Best Adversary Simulation and Red Teaming Companies in 2026: 12 Providers Compared
Will Your SOC Catch a Red Team? Detection and Response Benchmarks for 2026
Network Penetration Testing: What It Is, Types, Process and Cost (2026)
Best Enterprise Penetration Testing Companies and Providers (2026): 11 Compared
References
NIST. SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, controls CA-8, CA-8(1) and CA-8(2). https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final. Baseline allocation in SP 800-53B: https://csrc.nist.gov/pubs/sp/800/53/b/upd1/final.
NIST Computer Security Resource Center. Glossary entries for red team, blue team, white team and penetration testing, the team definitions sourced from CNSSI 4009-2022.
MITRE. ATT&CK knowledge base, FAQ and v20 release notes, 13 October 2026. https://attack.mitre.org/; https://attack.mitre.org/resources/updates/updates-october-2026/.
European Parliament and Council. Regulation (EU) 2022/2554 (DORA), Articles 3(17) and 26. https://eur-lex.europa.eu/eli/reg/2022/2554/oj.
European Commission. Delegated Regulation (EU) 2025/1190 on threat-led penetration testing, Articles 1, 11 and 12, Official Journal 18 June 2025. https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj.
European Central Bank. TIBER-EU Framework updated to align with DORA, 11 February 2025: https://www.ecb.europa.eu/press/intro/news/html/ecb.mipnews250211.en.html; TIBER-EU Purple Teaming Guidance, January 2025: https://www.ecb.europa.eu/pub/pdf/annex/ecb.tiber_eu_purple_best_practices_2025.en.pdf.
Bank of England. CBEST Threat Intelligence-Led Assessments: Implementation Guide, 2024 edition. https://www.bankofengland.co.uk/financial-stability/operational-resilience-of-the-financial-sector/cbest-threat-intelligence-led-assessments-implementation-guide.
CISA. AA24-193A: CISA Red Team's Operations Against a Federal Civilian Executive Branch Organization Highlights the Necessity of Defense-in-Depth, 11 July 2024. https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-193a.
CISA. AA24-326A: Enhancing Cyber Resilience: Insights from CISA Red Team Assessment of a U.S. Critical Infrastructure Sector Organization, 21 November 2024. https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-326a.
Mandiant (Google Cloud). M-Trends 2026, 23 March 2026. https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026.
Google Threat Intelligence Group and Mandiant. ARTEX and Friends: Enter Agentic Offensive Frameworks, 30 October 2026. https://cloud.google.com/blog/topics/threat-intelligence/artex-and-friends-enter-agentic-offensive-frameworks.
Stingrai. The State of Penetration Testing 2026, first-party data from 55 penetration tests and 1,206 verified findings, October 2024 to August 2026.
FedRAMP. Consolidated Rules for 2026, Rev5 Independent Verification and Validation, rule IVV-CSF-AIA. https://www.fedramp.gov/2026/providers/rev5/rules/independent-verification-and-validation/. CA-08 (02), Red Team Exercises, in the annual independent assessment for Class C and Class D certifications.
