NIST published SP 800-115, "Technical Guide to Information Security Testing and Assessment," on September 30, 2008, and it is still the baseline U.S. federal reference for how to plan and run a security test — yet nearly two decades later, most organizations that run red team exercises still treat them as adversarial theater rather than a feedback loop. MITRE built ATT&CK internally in 2013 out of its FMX research project and released it publicly in May 2015 specifically to solve this: give red teams and blue teams a shared vocabulary for adversary tactics and techniques, so a red team's "we got in" report could be scored against the blue team's "we detected it" evidence, technique by technique. In Europe, the ECB's TIBER-EU framework has gone further, publishing dedicated purple-teaming guidance in 2022 and updating it again in 2025 specifically because financial-sector regulators found that red-versus-blue engagements run without structured collaboration produced long reports and little improved detection. This post breaks down what each team actually does, why the divide between them persists, and how to structure an exercise so the output is fixed detections, not just a scored report.
What does a red team actually do?
A red team emulates realistic adversary behavior to test whether your existing detections and controls catch it — not to prove a system can be broken in the abstract, but to answer a specific question: if a real intrusion attempted these ATT&CK techniques, would anyone notice? That framing matters because it's fundamentally different from a penetration test, which NIST SP 800-115 treats as one testing technique among several (alongside vulnerability scanning and log review) focused on finding exploitable flaws. A red team engagement instead follows a defined rules-of-engagement document, targets in-scope assets, and maps its steps to specific ATT&CK technique IDs so results are comparable across engagements and over time. In regulated sectors, this is formalized further: TIBER-EU and its national variants (the UK's earlier CBEST from the Bank of England in 2014, and later STAR-FS and GBEST) require threat-intelligence-led scoping, meaning the techniques exercised are chosen because they match what real threat actors targeting that sector actually do, not a generic playbook.
What does a blue team actually do?
A blue team is the defensive side of the same exercise: the analysts, detection engineers, and incident responders operating your SIEM, EDR, and alerting pipeline who are supposed to catch and respond to the red team's activity in something close to real time. Their job during an exercise isn't just "did we get an alert" — it's tracing each simulated technique back to a specific detection rule, log source, or correlation logic, and identifying exactly where a gap exists when nothing fires. This is where ATT&CK earns its keep on the blue side: because the framework gives every technique a stable ID (for example T1055 for process injection), a blue team can maintain a detection-coverage matrix mapped directly to it, showing leadership which techniques have a working detection, which have a rule that's never been validated against real behavior, and which have nothing at all. NIST SP 800-115 explicitly recommends that testing results feed back into this kind of ongoing security-posture tracking rather than sitting in a one-time report.
What is purple teaming, and how is it different from just running both?
Purple teaming is a structured, time-boxed collaboration model where the red and blue teams work side by side on the same techniques in real time, rather than the red team attacking in isolation and handing over a report weeks later. The ECB's 2025 TIBER-EU Purple Teaming Best Practices guidance defines it explicitly as a joint activity that can run within, or alongside, a full TIBER-EU red team test — the red team executes a technique, the blue team says in the moment whether they saw it and what alerted (or didn't), and both sides adjust before moving to the next technique. The difference from "running both teams" is sequencing and feedback latency: in a traditional red-vs-blue test, the blue team learns what it missed only when the final report lands, by which point the engagement window has closed and there's no way to re-test the fix. Purple teaming closes that loop inside the same engagement, which is why regulators overseeing critical infrastructure and financial services have increasingly written it into their testing frameworks rather than treating it as optional.
Why do organizations still run red and blue in total isolation?
Organizations keep the two teams siloed largely for cultural and structural reasons that predate any framework: red teams historically reported success by "getting in undetected," which incentivized stealth over collaboration, while blue teams were measured on uptime and alert volume rather than on detection coverage against specific technique sets. NIST SP 800-115 itself was written primarily as a testing methodology guide, not an organizational-design guide, so it says little about reporting lines or incentive structures — leaving many organizations to bolt a red team onto security without ever defining how its findings should route into the detection-engineering backlog. The result, which is exactly the gap TIBER-EU's purple-teaming guidance was written to close, is a familiar pattern: a red team scores a technique as "successful," the blue team's SIEM produces zero related alerts, a report gets filed, and six months later the same technique still works because no one owns turning the finding into a shipped detection rule.
How should an organization structure the cadence between the three?
The structure that scales is a layered cadence: continuous, lower-intensity purple-team sessions validating specific ATT&CK techniques on an ongoing basis, punctuated by periodic full-scope red team engagements that follow a NIST SP 800-115-style methodology and, where regulation requires it, a threat-intelligence-led framework like TIBER-EU. The continuous layer keeps the detection-coverage matrix current as infrastructure and threat behavior change, while the periodic full engagement — with a signed rules-of-engagement, defined blast-radius limits, and executive sign-off — tests whether the accumulated detections hold up against a realistic, chained attack path rather than isolated techniques. Critically, every red or purple finding needs a defined destination: a specific detection-engineering ticket, owner, and re-test date, not a line item in a PDF. Without that routing, ATT&CK coverage matrices and TIBER-EU-style reports become documentation exercises instead of the feedback mechanism they were designed to be.
How Safeguard helps
Safeguard's Red Team engine is built as a purple-teaming tool by design, not an offensive add-on: it emits benign detection canaries mapped to specific MITRE ATT&CK techniques instead of running weaponized payloads, and pairs each simulated technique with the detection it should trigger — surfacing exactly the "technique fired, nothing alerted" gaps that purple teaming exists to catch. Every active step is gated by a signed rules-of-engagement document, scope verification, rate and blast-radius caps, human approval above a low-impact threshold, and a global kill-switch, with a full audit trail of actor, tenant, timestamp, and outcome. Findings feed directly into Safeguard's secops detection substrate — ATT&CK-tagged alerts, Sigma rules, and IOC matching — and correlate with SAST, DAST, and runtime findings in the unified findings model, so a chained attack path confirmed by emulation lands as a prioritized, ownable finding rather than a static report line.