What Is a Purple Team Engagement?

The short definition

Security exercises give their roles colours. The National Institute of Standards and Technology (NIST) glossary 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 a 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)."

Purple is what happens when the two work together instead of against each other. In a purple team engagement, offensive operators run agreed attacker behaviours one at a time while your defenders watch their tools. After each one, both sides compare notes: did it show up, did it alert, would an analyst have understood it? If not, the detection is fixed and the behaviour is run again until it is caught.

Purple team or red team?

A red team engagement is a test. Most of your staff do not know it is happening, the operators try not to be caught, and the result tells you how your organization would perform against a real intrusion.

A purple team engagement is a working session. Everyone involved knows exactly what is being run and when, nothing is hidden, and the goal is not to measure your defenders but to improve what they can see.

Neither replaces the other. The red team tells you where you stand under realistic conditions; the purple team is the fastest way to move.

The detection loop

The core of a purple team engagement is a short, repeated loop. The Cybersecurity and Infrastructure Security Agency (CISA) recommends a version of it in an advisory following one of its red team assessments, advising organizations to test security controls against the adversary behaviours it describes:

1. "Select an ATT&CK technique described in this advisory".
2. "Align your security technologies against the technique."
3. "Test your technologies against the technique."
4. "Analyze your detection and prevention technologies' performance."
5. "Repeat the process for all security technologies to obtain a set of comprehensive performance data."
6. "Tune your security program, including people, processes, and technologies, based on the data generated by this process."

The techniques come from MITRE ATT&CK, a knowledge base of adversary tactics and techniques based on real-world observations. A purple team engagement runs that loop with an offensive operator executing each technique and your defenders analysing and tuning in the same session, so the time between finding a gap and proving the fix is measured in minutes rather than months.

Why detections fail

A purple team session usually finds that a missed behaviour falls into one of a few buckets:

• No telemetry. The activity never reached your logging platform, because the source was not collected or the right event type was not enabled.
• Telemetry, no detection. The evidence is in the logs, but no rule looks for it.
• A detection nobody sees. An alert fires, but lands in a queue that is not watched, or is buried under routine alerts.
• A detection nobody understands. The alert reaches an analyst, but does not carry enough context for them to recognise what is happening or know what to do.

CISA's lessons from two simultaneous red team assessments name the same problems: "Untuned detection tools lead to missed threats," and "Detection tools are only as effective as the people, processes, and procedures supporting them." The first three buckets are engineering fixes that can often be made inside the session. The fourth is a process fix, and a purple team session is a good place to find it because the analysts are in the room.

How an engagement runs

A purple team engagement follows the same authorization discipline as any offensive work: a statement of work (SOW), rules of engagement and signed authorization for the systems where behaviours will run. Our approach page describes each document. The work itself usually looks like this:

1. Choose the behaviours. Agree the set of techniques to exercise, prioritized by threat, and the systems they will run on.
2. Confirm the viewing points. Make sure the people who watch your security operations center (SOC) tools, your endpoint detection and response (EDR) console and your log searches are available and able to make changes.
3. Run, observe, compare. Execute each behaviour, then check together what was logged, what alerted and what an analyst would have seen.
4. Tune and re-test. Fix what can be fixed in the session and run the behaviour again to prove the change works.
5. Record and hand over. Capture the result for each behaviour and package the test cases so your team can re-run them later.

What you should keep

• A coverage record for each behaviour exercised: detected, logged but not detected, or not seen at all, with notes on why.
• Validated detection improvements: the changes made during the session, each proven against the behaviour it was meant to catch.
• Reusable test cases your team can run again after a tooling change or on a regular schedule, so a detection that works today is not quietly broken next quarter.
• A list of what is still open: gaps that need a larger change, such as a new log source, with the behaviour that exposed each one.

Questions to ask a purple team provider

Use these in the request for proposal (RFP) or the first scoping call. The purple team exercises service lists what is in scope, and the behaviour set, the length of the session and the systems involved are agreed during scoping.

Sources

1. 01NIST, Glossary: red teamAccessed 2026-09-26
2. 02NIST, Glossary: blue teamAccessed 2026-09-26
3. 03CISA, AA23-059A, CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of NetworksAccessed 2026-09-26
4. 04CISA, AA26-237A, A Tale of Two SOCs: Insights From Two Red Team AssessmentsAccessed 2026-09-26
5. 05MITRE, ATT&CKAccessed 2026-09-26