Purple Teaming: How to Run a Purple Team Exercise

Purple teaming is less a third team than a way of working: red team operators run real attacker techniques in the open while the blue team watches its own tools, checks what was logged, alerted and stopped, and fixes gaps on the spot. A purple team exercise repeats that test-detect-tune cycle for every technique on a planned list, usually mapped to MITRE ATT&CK, then scores detection coverage and retests. Use it to turn red team findings, threat intelligence or a new security tool into detections you have proven work.

What Is a Purple Team?

Purple teaming is a collaborative security exercise in which offensive testers (the red team) and defenders (the blue team) work together, with full knowledge of each other's actions, to test and improve detection and response. The European Central Bank's TIBER-EU Purple Teaming Guidance describes it as a collaborative activity that involves both red team testers and the blue team and their offensive and defensive actions, and notes that it can range from tabletop discussions to specific technical testing. The open-source Purple Team Exercise Framework (PTEF), published by SCYTHE, puts it more simply: a purple team is a collaboration of various information security skill sets.

Three ideas separate purple teaming from other testing:

• Openness. The defenders know the test is running, see what the red team does and when, and can ask questions. Nothing is hidden, because the goal is learning, not a pass or fail grade.
• Technique-level focus. The exercise moves one technique at a time. For each one, the team asks whether the activity was visible, whether a detection fired and whether the response worked.
• Immediate improvement. When a detection misses, detection engineers adjust logging or rule logic during the session and the red team runs the same procedure again to confirm the fix.

Is a purple team a separate team?

Usually not. In most organizations, "purple team" describes the exercise or the function, not a standing group with its own headcount. PTEF describes three engagement models: ad hoc purple team exercises, an operationalized purple team that runs as a continuing virtual team, and a dedicated purple team with its own staff. Most programs start with occasional exercises and move toward a regular cadence once the method proves its value.

Red Team vs Blue Team vs Purple Team

The three colors answer different questions. A red team asks whether a realistic attacker can reach business objectives without being stopped. A blue team defends every day. A purple team brings the two together to make specific detections work.

For a deeper look at each team's role and skills, see our guide to red team vs blue team in cybersecurity. For how a covert engagement runs from planning to debrief, read what red teaming is and how a red team assessment works.

Purple team vs red team

The difference is secrecy and purpose. A red team stays hidden so it can measure how your organization reacts to an attack it does not expect. A purple team gives up that realism on purpose so that defenders can see every step and learn from it. The two work best in sequence: a red team shows which attack paths and techniques went unnoticed, and a purple team replays those techniques in the open until the detections work. TIBER-EU builds exactly this order into its tests, with a purple team exercise in the closure phase after the covert red team phase.

Purple teaming vs penetration testing and breach and attack simulation

A penetration test looks for exploitable weaknesses in a defined scope and mostly measures prevention. "Purple team pen testing" usually means running a penetration test with the SOC watching, so that each exploitation step is also checked for detection. Breach and attack simulation (BAS) platforms run scripted techniques on a schedule. They are useful for regression testing once detections exist, but they do not replace the human discussion, threat intelligence and on-the-spot tuning that make a purple team exercise valuable.

When Purple Teaming Is the Right Choice

Purple teaming pays off when you have detection tools and people to operate them, but you do not know which attacker techniques they actually catch. Typical triggers include:

• After a red team engagement. Replay the techniques that went undetected and fix them while the details are fresh.
• After a threat intelligence alert. A government advisory or sector report describes a group's techniques; test whether you would see them.
• After a tooling change. A new endpoint detection and response (EDR) agent, SIEM migration or logging pipeline change can silently break detections.
• Before a red team engagement. Close obvious gaps first so that an expensive covert test measures something harder.
• To train analysts. Junior analysts see what real attacker activity looks like in your own logs, not in a vendor demo.

Purple teaming is less useful if basic logging is missing across most of the estate, or if no one has time to tune detections after the session. In that case, fix log collection first, using a threat modeling exercise to decide which systems and attack paths matter most.

Roles in a Purple Team Exercise

A purple team exercise needs clear roles even though everyone is in the same room. The roles below adapt the responsibilities described in PTEF and in the TIBER-EU guidance for a commercial setting.

The coordinator role matters most. The TIBER-EU guidance stresses that the red team should explain its tactics clearly, acknowledge areas of strength and keep regular checkpoints so both sides understand each other's actions. Someone has to enforce that tone, keep the session moving and make sure every result is written down.

How to Run a Purple Team Exercise: An Eight-Step Playbook

The steps below cover a single exercise. A focused first exercise usually tests 10 to 20 techniques; PTEF notes that exercises can last a few hours, days or weeks depending on goals. The steps are deliberately non-operational: specific procedures depend on your environment and must stay inside the agreed rules of engagement.

Step 1: Set objectives, scope and rules of engagement

Start with a sentence that a sponsor can approve, such as "Confirm that we detect the credential theft and lateral movement techniques used in the last red team" or "Validate detections after the EDR migration." Then agree in writing:

• Scope. Which hosts, accounts, cloud tenants and network segments are in play. Prefer dedicated test hosts and test accounts that mirror production configuration.
• Safety rules. No destructive actions, no real data leaving the network, no changes to production that cannot be reversed, and a named person who can stop the session.
• Environment. Production or production-like systems give real answers about logging and alerting; a lab is safer for risky techniques. Many teams run most techniques on monitored production test hosts and keep impact-style techniques in a lab.
• Communications. Who is in the room or call, which secure channel the teams use and how real incidents are separated from exercise activity.
• Cleanup. How every artifact the red team creates is recorded and removed afterward.

Step 2: Choose the adversary and pick ATT&CK techniques

MITRE ATT&CK is the common language for purple teaming. As of ATT&CK v20, released October 13, 2026, the Enterprise matrix has 15 tactics, including TA0005 Stealth and TA0112 Defense Impairment, which older material groups together as Defense Evasion. Check which version your detection mappings use before you compare results across exercises.

Pick techniques with threat intelligence, not by browsing the matrix. Good sources include ATT&CK group pages, government advisories, your own incident history and the findings of your last red team engagement. Then score each candidate technique on five criteria:

1. Threat relevance. Is it used by groups that target your sector or by the ransomware crews you worry about most?
2. Position in the attack chain. Techniques that sit at choke points, such as credential access and lateral movement, give you more chances to stop an intrusion.
3. Current confidence. Techniques you have never tested, or that changed with new tooling, deserve priority.
4. Safety. Can the technique be run safely on test hosts, or does it need a lab?
5. Fix ownership. Will someone be able to act on the result within weeks?

The table below is an illustrative plan for a generic ransomware intrusion scenario. It is an example of the format, not a recommendation for any specific organization; build your own list from your threat intelligence.

MITRE ATT&CK reference pages for these techniques: T1566.001, T1059.001, T1053.005, T1087.002, T1558.003, T1003.001, T1021.001, T1047, T1567.002 and T1490.

Background on several of these techniques is in our explainers on LSASS dumping and living off the land attacks, which rely on built-in tools such as PowerShell and WMI.

Step 3: Write a test card for each technique

A test card turns a technique into something the room can run and score. Write one per procedure before the session, and share it with the blue team only when that procedure starts, so analysts still have to find the evidence themselves.

Test more than one procedure for high-priority techniques. In CISA advisory AA24-193A, published July 11, 2024, a federal agency's detection rules keyed to specific strings, such as "kerberoast" in command lines, missed kerberoasting performed in other ways. One passed procedure proves that one variation is covered, not the whole technique.

Step 4: Prepare the environment and baseline

Before the session, confirm that the plumbing works so the exercise tests detections, not broken log forwarding:

• Time is synchronized across hosts, SIEM and EDR, so timestamps can be matched.
• Test hosts send the expected logs to the SIEM or data lake, and retention covers the exercise period plus the reporting window.
• Known exclusions and suppression rules are documented, since they are a common reason detections stay silent.
• The red team's infrastructure and test accounts are listed so the SOC can distinguish exercise activity from a real intrusion.
• Change control is informed, and detection engineers can deploy rule changes during the session.

Step 5: Run the test-detect-tune cycles

This is the core of the exercise. PTEF describes a per-technique flow in which threat intelligence presents the technique, the coordinator leads a short discussion of expected controls, the red team executes while sharing its screen and indicators, the blue team follows its standard process to find evidence, and detection engineering makes short-term adjustments before the red team repeats the technique. A practical version has five beats:

1. Brief. The threat intelligence analyst explains the technique and the expected detection from the test card. The room agrees what "good" looks like.
2. Execute. The red team runs the procedure on the agreed host and calls out the start time, host and account.
3. Observe. Analysts look for the activity using their normal tools and process: alert queues, SIEM searches, EDR consoles. The coordinator starts a timer.
4. Score. The coordinator records the highest outcome level reached, whether the technique was prevented, and the time to detect and triage.
5. Tune and re-run. If the result falls short, detection engineers check whether the gap is in visibility, detection logic, suppression or process. If a fix is quick, they deploy it and the red team runs the same procedure again. If not, the gap becomes an action item with an owner.

Keep a strict time box per technique, typically 20 to 45 minutes, and park deep investigations for later. A session that spends three hours on one missing log source tests nothing else.

Step 6: Score detection coverage

Score each procedure with a consistent scale (see the next section) and calculate coverage for the exercise as a whole. The point is not a single impressive percentage but a clear before-and-after view of which techniques moved and which still need work.

Step 7: Report and assign remediation

Write the report while the session is fresh. PTEF recommends delivering lessons learned in less than two weeks. A useful purple team report includes:

• objectives, scope, adversary profile and the technique list with ATT&CK IDs and version;
• a results table per procedure: outcome level before and after tuning, prevented yes/no, time to detect and time to triage;
• detections created or changed, with rule names and logic summaries;
• gaps grouped by type: visibility, detection logic, alert suppression, process and timeliness (the gap categories PTEF uses);
• action items with owners, due dates and the evidence needed to close each one;
• a coverage heat map, for example an ATT&CK Navigator layer;
• a retest plan.

The same evidence standards that make a penetration testing report useful apply here: reproducible steps, timestamps and clear priorities.

Step 8: Retest and automate regression

Detections decay. Log sources change, rules get tuned for noise and agents are updated. After remediation, rerun the failed and newly fixed procedures, then add the passing ones to a regression set that runs on a schedule with an open-source framework or BAS platform. Plan the next exercise around new threat intelligence rather than repeating the same list.

Scoring Detection Coverage

A scoring scale makes results comparable across techniques, teams and exercises. The six-level ladder below is a DeepStrike editorial scale built from the same idea as PTEF's graded score, which runs from "no visibility" to "full response." Record the highest level each procedure reaches.

Track prevention separately. A control can block a technique at any level, and a blocked technique with no alert is still a detection gap: the attacker will simply try a variation. Recording "prevented: yes/no" next to the score keeps that visible.

From the ladder, calculate a few simple measures for the exercise:

• Visibility coverage = procedures at level 2 or higher ÷ procedures tested.
• Alerting coverage = procedures at level 3 or higher ÷ procedures tested.
• Response coverage = procedures at level 5 ÷ procedures tested.
• Time to detect and time to triage for each alerted procedure, which roll up into your mean time to detect (MTTD) and mean time to respond (MTTR).
• Detections created or tuned, and their false positive rate two weeks later.

The scorecard below is illustrative, not data from a real exercise. It applies the ladder to the ten-technique plan from Step 2.

In this example, visibility coverage moves from 60% (6 of 10) to 90% (9 of 10), and alerting coverage moves from 20% (2 of 10) to 70% (7 of 10). The three procedures still below level 3 become the backlog. Note that these percentages describe the procedures tested, not the whole ATT&CK matrix; a "70% covered" claim without that context is misleading.

To visualize results, export scores as a layer for ATT&CK Navigator, MITRE's web app for annotating ATT&CK matrices. DeTT&CT is an open-source framework that uses ATT&CK to score data source quality, visibility and detection coverage, and it exports Navigator layers too.

What Real Collaboration Achieves: Lessons From CISA

Public purple team results are rare, but CISA has published two red team advisories that show why the collaborative phase matters.

In advisory AA23-059A, published February 28, 2023, CISA described a red team assessment of a large critical infrastructure organization that did not detect the red team's activity during the assessment, even when the team tried to trigger a response. Undetected activity like that is exactly what a follow-up purple team exercise is designed to fix.

In advisory AA24-193A, the assessment of a federal civilian agency ran for about eight months in 2023, with roughly three months spent collaborating directly with the agency's defenders after the red team notified the SOC. The team held weekly sessions with technical staff, withheld its indicators so defenders had to build their own detections, proposed behavior-based, tool-agnostic detections and helped correlate data sources such as EDR alerts and memory analysis. CISA reported measurable improvements in response times for known techniques and new behavior-based detections.

The advisory also listed lessons any purple team should check: short log retention, detections written for one tool rather than the underlying technique, alerts that were not reviewed every day, and IT teams that worked in silos from the SOC. CISA recommends exercising, testing and validating your security program against the ATT&CK techniques in its advisories, which is a ready-made technique list for a first exercise.

Purple Teaming in TIBER-EU and DORA

In the European financial sector, purple teaming is now part of regulated threat-led testing. On February 11, 2025, the Eurosystem updated the TIBER-EU framework to align with the DORA regulatory technical standards on threat-led penetration testing (TLPT), specifying purple teaming as mandatory and renaming the white team the control team. The TIBER-EU Purple Teaming Guidance (January 2025) defines two variants:

The guidance also names useful exercise types that work outside regulated testing:

• Catch-and-release: after the blue team detects the red team, a dedicated channel lets defenders report indicators, the red team confirms which are part of the test, and agreed responses are exercised without ending the test.
• Collaborative proof-of-concept: red and blue teams work together to prove a weakness that is too risky to exploit alone on production systems.
• War game: both teams know the flags; the red team tries to capture them and the blue team tries to stop it.
• Tabletop discussion, re-exploration of planned scenarios on live systems, and exploration of alternative scenarios in the closure phase. The re-exploration format walks through activity that was invisible in logs, visible but not detected, alerted but mistriaged, or answered with an ineffective response.

If the gap is decisions rather than detections, start with a tabletop exercise.

For the full framework, read our guide to the TIBER-EU framework, and for who must run TLPT and how often, see DORA penetration testing and TLPT requirements.

Open-Source Tools for Purple Teaming

You can run a strong purple team exercise with open-source tools. Each one below should be run only on approved test hosts or in a lab; review every test before execution, because some change system configuration.

Commercial BAS platforms automate many of these steps. They are a good fit for regression once you know what you are testing, but the human brief, discussion and tuning loop is what turns a failed test into a working detection.

Common Purple Team Mistakes

• Testing the tool, not the behavior. A rule that matches one tool's name proves nothing about the technique. Vary procedures.
• Scoring prevention as detection. A blocked technique with no alert hides a gap.
• Reading the test card to the blue team before execution. Analysts should find the evidence with their normal process, or the time to detect is meaningless.
• No time box. One stubborn gap can consume the whole session.
• No owner for fixes. Gaps that need new log sources or budget must leave the room with an owner and a date.
• Reporting a coverage percentage without the denominator. Always state how many procedures were tested and which ATT&CK version was used.
• Blame. If analysts feel graded, they stop asking questions. Keep the session about the system, not individuals.
• One-off exercises. Without retests and a regression set, detections drift back to where they started.

An Illustrative Two-Day Purple Team Exercise Agenda

The agenda below is an illustrative example for a first exercise with ten techniques. Adjust it to your scope; PTEF suggests a break at least every 90 minutes for remote sessions.

Frequently Asked Questions

What is a purple team in cybersecurity?

A purple team is a collaborative way of testing defenses in which red team testers run attacker techniques openly while the blue team checks whether its tools and people detect and respond to them, then tunes detections on the spot. It is usually an exercise or function rather than a permanent separate team.

What is a purple team exercise?

A purple team exercise is a planned session in which red and blue teams work through a list of attacker techniques, usually mapped to MITRE ATT&CK. For each technique, the red team executes, the blue team looks for evidence, the result is scored and detections are tuned and retested.

What is a purple team assessment?

A purple team assessment usually means an outside provider or internal team runs a purple team exercise and delivers a scored report of detection coverage, gaps and remediation actions. The method is the same as an exercise; the emphasis is on the measured result.

How long does a purple team exercise take?

It depends on scope. PTEF notes that exercises can last a few hours, days or weeks. A focused first exercise covering 10 to 20 techniques commonly fits into a few days of joint sessions, plus preparation before and reporting after.

Do you need a red team before purple teaming?

No, but it helps. A red team shows which techniques went unnoticed under realistic conditions, which gives the purple team a high-value list. Without one, threat intelligence and government advisories provide a good starting list.

How often should you run purple team exercises?

There is no fixed rule. Many programs run an exercise after each red team engagement, after major detection or logging changes, and on a regular cadence such as quarterly, with automated regression testing of passing techniques in between.

What is the difference between purple teaming and red teaming?

Red teaming is covert and measures how the organization reacts to an unexpected attack. Purple teaming is open and collaborative and focuses on making specific detections work. Red teaming finds the gaps; purple teaming closes them.

Next Step: Turn Missed Detections Into Working Ones

A purple team exercise works when it starts from a short list of techniques that matter, runs each one in the open with a strict time box, scores the result on a consistent scale and leaves every gap with an owner and a retest date. The easiest way to start is to take the techniques from your last red team or a recent CISA advisory, write test cards for ten of them and book two days with your SOC and detection engineers.

If you do not yet know which techniques your defenders miss, an adversary's view comes first. DeepStrike's red teaming services measure your SOC, alerting and response workflows against realistic tradecraft, and the debrief gives your security and engineering teams attacker pathways, evidence, remediation priorities and retest-ready next actions: the raw material for your first purple team exercise. To discuss scope, contact DeepStrike.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

• European Central Bank: TIBER-EU Purple Teaming Guidance (January 2025)
• ECB news: Eurosystem updates TIBER-EU framework (February 11, 2025)
• Purple Team Exercise Framework (PTEF v4), SCYTHE, on GitHub
• MITRE ATT&CK
• MITRE ATT&CK: Updates (v20, October 13, 2026)
• MITRE ATT&CK: Enterprise tactics
• CISA Advisory AA24-193A: CISA Red Team's Operations Against a Federal Civilian Executive Branch Organization Highlights the Necessity of Defense-in-Depth
• CISA Advisory AA23-059A: CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks
• ATT&CK Navigator
• DeTT&CT
• Sigma
• Atomic Red Team
• MITRE Caldera
• MITRE Center for Threat-Informed Defense: Adversary Emulation Library