Why purple teaming is the first test to commission before a full red team
When a framework, regulator, customer security review or insurer asks for evidence that detection works, a list of vulnerabilities does not answer the question. Purple teaming is usually the first test to commission in that situation. Testers and the blue team work together on specific MITRE ATT&CK techniques, and each step is checked against what the logs captured, what the detection rules flagged and what alerts reached an analyst. The output is a set of confirmed gaps and tuned detections, not a narrative of how an attacker got in. Under TIBER-EU, purple teaming is now a mandatory part of test closure, so a financial entity running a TIBER-EU test will need it regardless of what else it commissions.
The risks it addresses are concrete. A technique may generate no log at all because the relevant log source was never enabled or forwarded. A rule may exist but never fire against production behavior because it was written against a lab sample. A SIEM may look well covered on a dashboard while missing entire tactics. Before the exercise, agree the technique list with the blue team, mapped to the tactics your threat model says matter most, and confirm the log sources, retention periods and alert routing for each one. CIS Controls v8.1 Safeguard 18.4 asks for security measures to be validated after penetration testing and rulesets adjusted to detect the techniques used, which is the core output of a purple team exercise. The TIBER-EU framework sets out how this fits into a wider intelligence-led test.
Purple teaming is a lower-cost entry point than a full red team because it has a narrower scope: a defined technique list, no covert operation against the organization's people, and no need for an extended adversary campaign. Delegated Regulation (EU) 2025/1190 requires at least 12 weeks of active red team testing for a DORA threat-led penetration test, which shows the scale a full red team can reach. Cost sits mainly in tester time, blue team time and detection engineering, and recurs whenever rules change. When you request a quote, ask for the technique list, the log sources in scope, how many detection changes are expected and whether a retest of the changed detections is included. Confirm that the provider's testers have the threat intelligence and red team skills your regulator expects before you sign.
What purple teaming scope covers and who decides it
A purple team exercise is only as useful as its scope, so the decisions below are agreed in writing before any technique runs. Blue team leads and management sign off on the list together, because the goal is to confirm what the organization sees and responds to, not to catch anyone out.
Which ATT&CK tactics and techniques to run
Testers and the blue team select techniques from the MITRE ATT&CK Enterprise matrix, which lists 15 tactics from Reconnaissance to Impact. Selection is driven by the threat actors most likely to target the organization, the controls that matter most to the business, and the detections the blue team already believes it has. Each technique is listed with a planned execution time so defenders know what to expect in their telemetry. Ask the provider to map every planned technique to a tactic and a technique ID before the exercise starts.
Which environments and telemetry sources are in
The scope names the systems where techniques run, such as specific cloud accounts, network segments, identity providers or endpoint groups, and lists the log sources that must capture the activity. Typical sources include endpoint detection, identity and directory logs, cloud audit trails, proxy and DNS logs, and the SIEM itself. Confirm which sources are actually forwarded, retained and parsed, because a gap found here is one of the most common purple team results. Production systems are included only where the organization has explicitly accepted that risk.
Which test accounts and endpoints are used
Testers need named accounts and endpoints to execute techniques, and these are provisioned, labeled and tracked so the blue team can distinguish test activity from real intrusions. Decide whether test accounts start as standard users, privileged users or workstations already under the tester's control. Record every account, host and credential lifecycle, including when it is created, what it can reach and when it is removed. Ask how test artifacts are cleaned up after the exercise.
Rules of engagement and stop conditions
The rules of engagement set what testers may and may not do, which systems are off limits, how data is handled, and who can halt the exercise. They also define stop conditions, such as an unplanned outage, data exposure or a real incident that appears during testing. Name a contact on each side with authority to pause work at any hour. Because purple teaming is collaborative, these rules are written down and signed by the blue team lead and management, not left to tester discretion.
Who approves the scope and who owns decisions
The blue team lead and management agree the technique list, environments and timing in advance, and the provider's lead tester runs the exercise against that list. Confirm who can change scope mid-exercise, who receives the findings and who owns the detection tuning that follows. Clear ownership prevents disputes later about whether a missed alert was in scope. Ask the provider to show how it records scope changes and approvals in the final report.
Exercise timing and advance notice
Timing decisions cover the calendar window, whether the blue team knows the exact schedule, and how notice is given to any hosting provider. Cloud providers publish testing rules, and AWS requires a simulated events request at least 2 weeks in advance for red, blue or purple team testing against AWS-hosted assets. Confirm the provider's rules for each platform in scope before setting dates. Agree how the team will pause or resume techniques between sessions.
How a purple team engagement runs, phase by phase
The sequence turns a list of ATT&CK techniques into confirmed evidence of what the defenders see, alert on and can respond to, with tuned detections proven by retest before the report closes.
Agree scope and select techniques
The engagement lead, the security operations owner and the testers agree which systems, data and business services are in scope and which adversary behavior matters most to the organization. The team maps candidate behaviors to MITRE ATT&CK Enterprise tactics and techniques, then selects a bounded set that reflects threat intelligence and the controls the client most needs to test. Written rules of engagement record the techniques allowed, the hosts involved, the stop conditions and who can halt activity. The step is complete when the signed technique list and rules of engagement are held by both teams.
Plan execution with the blue team
Testers and defenders walk through each selected technique together, agreeing the expected telemetry, the log sources that should record it, the alerts that should fire and the analyst action expected. Defenders confirm which SIEM, EDR and cloud logging feeds are live for each in-scope system, and the team names a coordinator who knows the exact start and stop times. Known gaps in logging are recorded before testing begins so they are not mistaken for new findings. The step is complete when each technique has a written expectation the defenders have accepted.
Execute techniques one at a time
Testers run one technique at a time in the agreed order while defenders watch the relevant consoles and log feeds live. Each action is timestamped and logged by the testers so that every event can be matched against what the defenders observe. The team pauses between techniques to confirm whether an alert fired, how the analyst responded and whether the activity was contained. The step is complete when every planned technique has been run, or stopped under the rules of engagement, with a timestamped record for each one.
Analyze detection gaps
The team compares each executed technique against the expected telemetry and alerts, classifying every outcome as logged and alerted, logged but not alerted, partially observed or not observed at all. Gaps are traced to their cause, such as a missing log source, a rule with the wrong threshold, a parsing failure or an alert routed to a queue nobody monitors. Where a gap is caused by a control failure rather than a detection gap, the team records it as a separate finding. The step is complete when each technique has a documented outcome and a root cause for every gap.
Tune rules and alerts
The blue team changes detection content, such as rules, correlation logic, log collection settings and alert routing, to address the gaps the team has identified. Testers review proposed changes for whether they would catch the technique as executed and whether they are likely to produce excessive noise in production. Each change is recorded with its owner, the technique it addresses and the date it was made. The step is complete when every gap has either a tuned detection, an accepted risk with an owner or a remediation item in the plan.
Retest the tuned detections
Testers rerun the same techniques against the tuned detections in a controlled way, so the team can confirm that the changes produce the intended alerts and analyst actions. Results are compared with the first run to show what changed, and any detection that still fails is returned to tuning. This retest is the evidence that separates a verified improvement from a configuration change that was assumed to work. The step is complete when each retested technique shows the expected outcome, or a documented residual gap has been accepted.
Report findings and validated measures
The report maps each technique to its ATT&CK identifier, records the before and after detection outcomes, and lists the tuned rules, the remaining gaps and the owners for each action. It also states how the security measures were validated after testing, in line with CIS Controls Safeguard 18.4, which asks for detection capabilities to be modified where needed to catch the techniques used. The client should confirm the report format with its auditor or customer in advance, since many accept this mapping as evidence. The step is complete when the report has been reviewed by both teams and the agreed remediation items are assigned.
How purple teaming differs across SIEM, EDR, cloud and identity
Before any technique is run, a purple team should confirm that the events it intends to exercise actually reach the SIEM, are parsed correctly and carry the fields analysts need. Many detections that look sound on paper fail because a log source was never forwarded, a parser drops a field, or retention is shorter than the time a team needs to investigate. Testing here is largely about the pipeline itself, so the exercise often begins with a log source inventory rather than an attack.
- Source coverage: Confirm which hosts, cloud accounts and applications forward logs for the techniques in scope, and record any gaps as findings before testing starts.
- Parsing and normalization: Check that fields such as user, process, source address and timestamp survive ingestion with consistent names and time zones.
- Ingestion latency: Measure how long events take to become searchable, since an alert that fires hours late has limited value during an incident.
- Retention: Verify that the window covers the period an investigator would need, including test artifacts kept for the replay.
- Detection content: Map each test step to the rule or query that should fire, then record whether it fired, how fast, and with what severity.
Before the exercise, ask the provider which techniques will be mapped to ATT&CK and how each log source will be verified against them.
Endpoint detection and response tools see process creation, script execution, file and registry changes, and network connections from the host itself. Purple teaming here tests whether the agent records the behavior, whether its built-in rules or the team's custom rules raise an alert, and whether the response action is what the playbook expects. Results depend heavily on agent configuration, policy mode and exclusions, so a technique that is detected on a default build may be missed on the production image.
- Telemetry depth: Confirm the agent captures command lines, parent-child process relationships and script block content on the operating systems in scope.
- Tuning state: Test with production policies, not a lab profile, and record any exclusions that suppress telemetry for legitimate tools.
- Prevention versus detection: Note whether a technique is blocked, alerted only, or silently allowed, since each outcome needs a different follow-up.
- Response actions: Confirm that isolation, containment or evidence collection steps work as documented and do not disrupt business systems.
- Coverage across builds: Sample more than one operating system version and workstation image, because agent behavior and telemetry often differ between them.
Ask the provider how test payloads will be kept inside the agreed rules of engagement and how the team will avoid triggering uncontrolled spread between endpoints.
Cloud control plane activity, such as API calls that create roles, change policies or disable logging, is recorded by the provider's audit services rather than by the operating system. Purple teaming in the cloud must therefore confirm that management-plane logs are enabled in every account and region, delivered to the central store, and that the detections target the actions an adversary would take. Testing also has to stay inside each provider's published rules, which set the boundaries for what can be simulated and when the provider must be notified.
- Audit log enablement: Confirm that the provider's management event logging is on across all accounts, regions and subscriptions in scope, including logs that protect the logs themselves.
- Provider rules: AWS requires a simulated events request at least 2 weeks in advance for red, blue or purple team testing, so schedule that notice into the plan before any technique is run.
- Shared responsibility: Separate what the provider monitors from what the customer must monitor, and test only the customer side.
- Alert routing: Verify that cloud alerts reach the same on-call path and ticketing workflow as on-premises alerts.
- Cleanup: Plan for removing test roles, keys and resources created during the exercise, and record each one.
Before committing, ask the provider to confirm the notice period and approval steps for each cloud service in scope against the published rules for that provider.
Identity systems, including directory services, single sign-on providers and privileged access tools, are where many adversary techniques converge. Authentication events, group membership changes, token issuance and privileged session starts are the signals that matter. Purple teaming in this area tests whether those events are captured, whether the detections distinguish abnormal use from normal administrative work, and whether the identity team can act on an alert quickly, such as disabling a session or resetting a credential.
- Authentication events: Confirm that failed and successful sign-ins, MFA challenges and federation events are logged with enough context to attribute them to a user and source.
- Privilege changes: Test whether additions to privileged groups, role assignments and policy edits generate alerts with the actor and target named.
- Baseline noise: Use real administrative patterns from the environment to tune detections so they fire on abnormal use without flooding analysts.
- Containment steps: Verify that the identity team can revoke sessions, disable accounts and rotate secrets within the time the playbook expects.
- Service accounts: Include non-human identities, since their activity is often logged poorly and alerted on least.
Ask the provider how test accounts will be created, labeled and removed, and who in the identity team must approve any change to production directory settings.
Detection gaps purple teaming finds and why they matter
This table lists the detection gap categories a purple team exercise typically uncovers, with what each looks like in day-to-day operations and the risk it creates. Read each row as a symptom to check in your own environment before and after an exercise. The main takeaway is that a technique that goes unlogged, unalerted or misrouted is effectively undetected, even when the security tooling appears to be in place.
| Gap category | What it looks like in practice | Risk it creates |
|---|---|---|
| Missing log sources | A technique's telemetry, such as endpoint process events or cloud control plane activity, is never collected in the first place | Activity happens with no record, so no detection can ever fire and investigators have nothing to reconstruct |
| Events logged but not forwarded | Logs exist on the host or service but are not shipped to the SIEM or analytics platform, or are dropped by a parser or agent | The security team believes coverage exists, yet searches and alerts never see the events |
| Rules that never fire | A detection rule is deployed and enabled, but its logic, field names or thresholds never match the telemetry it targets | Coverage looks complete on paper while a documented technique passes unnoticed |
| Alerts routed to no one | Alerts generate correctly but go to a mailbox, queue or on-call group that is unmonitored, muted or no longer staffed | Detection succeeds technically but response never starts, so the alert has no operational effect |
| Correlation gaps | Individual low-severity events are recorded, but no rule links them across hosts, identities or time windows | A multi-step intrusion looks like scattered noise, and the sequence that matters is never surfaced |
| Detections firing on the wrong technique | An alert triggers on a related but different behavior, or is mapped to the wrong ATT&CK technique in the detection catalog | Reports overstate coverage for a tactic, and the actual technique remains unmonitored and unrecorded |
Which frameworks expect purple teaming and what each expects
Is purple teaming mandatory under TIBER-EU?
Yes. The TIBER-EU framework dated January 2025 made purple teaming mandatory as part of closure, after it was aligned with the DORA TLPT standards. Closure of a TIBER-EU test includes red and blue team reports, a replay, purple teaming, a test summary report, a remediation plan and an attestation. The framework also renamed the White Team the Control Team, so the body that manages the test under control is now called by that name in your planning documents. Tests under the framework produce no pass or fail result. Ask your authority which edition of the framework governs your test and how it expects the purple teaming output to be recorded before you agree scope. DeployOpen can prepare the detection evidence and remediation tracking that feed into that closure, but the attestation itself is issued by the authorities and the designated providers, not by DeployOpen.
How does DORA threat-led penetration testing relate to purple teaming?
DORA defines threat-led penetration testing (TLPT) as a framework that mimics the tactics, techniques and procedures of real-life threat actors, delivered as a controlled, bespoke, intelligence-led red team test of a financial entity's critical live production systems. Delegated Regulation (EU) 2025/1190 requires at least three TLPT scenarios, of which at most one may be non-threat-led, and active red team testing of at least 12 weeks with at least weekly progress reports. The TLPT itself is a red team exercise, so purple teaming is not defined as a separate DORA test type. Its relevance is practical: the detection gaps a red team exposes are best confirmed and tuned with the blue team, and TIBER-EU's alignment with the DORA standards brings that step into the closure process. Confirm with your competent authority how TLPT and purple teaming will be documented for your entity.
What does CBEST require and when did it start?
CBEST is a targeted, threat intelligence-led assessment that has been part of the Bank of England, PRA and FCA supervisory toolkit since 2014. The current CBEST Implementation Guide is the 2024 edition, and it should be the first document you read when scoping a CBEST-style assessment for a UK firm. Teams commissioning this work should check how the guide expects detection and response to be validated, and whether the regulator expects a feedback loop between the testers and the defenders. Your supervisory contacts confirm which firms are in scope and what evidence they need. DeployOpen can help prepare controls, logging and detection evidence for the assessment, but it does not issue the regulator's conclusions or any attestation.
What do NIST SP 800-115 covert testing and boundary rules mean for purple teaming?
NIST SP 800-115 describes covert testing as work performed without the IT staff's knowledge but with upper management's permission. That form tests technical controls, the staff's response to perceived incidents and policy knowledge, and it usually stops at defined boundaries such as a set level of access. Purple teaming is the opposite choice on visibility: the blue team knows the techniques in advance, so the exercise measures whether logging and alerting fire as expected. Many organizations run covert red team work first and purple teaming afterward, with the boundaries written into the rules of engagement either way. Confirm with management which mode applies to each phase, and who holds the authority to stop activity that crosses a boundary.
Which NIST SP 800-53 control covers penetration testing?
Control CA-8, titled Penetration Testing, in NIST SP 800-53 Rev. 5 covers penetration testing and has three enhancements: use of an independent penetration testing agent or team, red team exercises, and facility penetration testing. SP 800-53B selects CA-8 and CA-8(1) for the high baseline. For a purple teaming exercise, CA-8 gives assessors a control-level reason to require independence, documented scope and reporting that ties findings to the systems tested. If your authorization or customer requirements are written against this control, ask the provider to map each deliverable to the control and enhancement you cite. Use the control catalog as the reference for wording, and have your assessor confirm which enhancements apply to your system categorization.
What does CIS Controls v8.1 Safeguard 18.4 ask for after a penetration test?
Safeguard 18.4, under Control 18 on penetration testing, asks that security measures be validated after each penetration test. Where needed, the organization modifies rulesets and capabilities so it can detect the techniques used during the test. That is the core output of a purple team exercise: each technique run is checked against what was logged, detected and alerted, and detection rules are tuned until the gap closes. Ask any provider to show how each technique maps to an observed result, what was changed in the rules, and how the changes were re-tested. DeployOpen prepares these validation records as evidence, but the assessment of whether your program meets the safeguard is made by your assessor or auditor.
Can DeployOpen issue a compliance attestation for a purple teaming exercise?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors, certification bodies and designated testing providers perform those roles under their own frameworks. For purple teaming, DeployOpen can run the technique exercises, document detection results, record rule changes and package the evidence so your auditor or authority can assess it. Before you commission the work, ask your assessor which evidence format they accept, and confirm in writing which party signs each deliverable. That split should appear in the scope agreement, which is agreed in writing before work starts.
Which framework should I check first for my purple teaming needs?
Start with the framework your regulator, customer or insurer names, because that document sets the purple teaming expectation and the evidence format. If you are a financial entity in the EU, read TIBER-EU and the DORA TLPT rules together. If you are a UK firm in scope of CBEST, use the 2024 Implementation Guide. If your obligation comes from a security standard or customer review, map your requirement to NIST SP 800-53 CA-8 or CIS Controls Safeguard 18.4 and ask the assessor to confirm the mapping. Where the requirement is unclear, put the question to the authority in writing before scoping, since the answer affects team roles, timing and reporting.
What you receive and whether it satisfies an auditor or customer
A purple team engagement ends in a set of documents, and each one answers a different reader. The cards below cover what the report contains, how far it can stand in for formal evidence, and what to settle with your assessor or customer before testing begins.
Technique-by-technique results
The core of the report is a table that maps each ATT&CK technique the team ran to what happened: whether the activity was logged, whether it was detected, and whether it alerted a responder. Each row should name the data source, the log location and the time of execution, so a reviewer can trace the result back to the telemetry. Ask for the matrix format and the ATT&CK version used before testing starts, because the technique IDs must match what your team reports against.
Detection rule changes
Every gap found in the exercise should produce a documented change: a new or modified rule, a tuned threshold, an added log source or a suppressed false positive. The report should record the before and after logic, the owner who approved it and the date it went live. Confirm that changes are versioned in your detection-as-code or SIEM change process, since an undocumented tweak is hard for an auditor to accept.
Retest results
CIS Controls v8.1 Safeguard 18.4 expects security measures to be validated after a penetration test, with rulesets changed where needed to detect the techniques used. The retest replays the same techniques against the updated controls and shows which now alert. Agree in advance whether retest is included in the fixed price, how many retest rounds apply and who runs them, because a retest that is not written into scope is often billed separately.
Remediation plan
Each open finding needs an owner, a priority, a target action and a status that the next review can check. Separate detection gaps from configuration gaps and from process gaps, since each is fixed by a different team. The plan is the document most likely to be requested by a customer security review, so make sure it names real owners rather than teams alone.
Executive summary
The summary states the objectives, the techniques in scope, the detection outcome in plain terms and the most significant residual risks. Boards and procurement teams usually read only this section, so it should avoid implying a pass or fail grade that the test never assigned. Ask the provider to show how the summary links to the detailed tables.
Whether the report satisfies an auditor
A purple team report is evidence for a regulator or customer only when that body accepts it. Under TIBER-EU, closure includes red and blue team reports, a replay, purple teaming, a test summary report, a remediation plan and an attestation, and tests produce no pass or fail result. Under DORA, threat-led testing follows the Delegated Regulation's specific requirements, so a standalone purple exercise may not count toward a TLPT obligation. Confirm acceptance with your assessor or customer in writing before scoping, and agree which report sections they expect.
What your team must prepare before the exercise starts
Purple teaming only produces useful output if the blue team can see what the testers do, so the first preparation task is access. Confirm in writing that the exercise team can query the SIEM for the relevant log sources, including endpoint telemetry from EDR, identity provider and directory logs, and cloud control plane logs such as audit trails for the accounts in scope. Check retention periods and ingestion lag before the exercise, because a technique that is logged but takes hours to appear in the SIEM will look like a missed detection when it is really a pipeline problem. Name one owner for each log source and confirm that the detection rules, alert routing and case management tools that will be tuned during the exercise are available to the people who will change them. Next, agree who is in the room and who makes decisions. Name a blue team lead, the detection engineers who own the relevant rules, and a SOC analyst who will work the alerts, with a deputy for each. Agree on a shared technique plan before any testing starts: the MITRE ATT&CK techniques to be exercised, the order in which they run, the hosts and accounts they touch, and the expected telemetry for each step. Record each technique with its ATT&CK identifier and the log or alert the blue team expects to see. This plan is the working document for the sessions and the baseline against which detection gaps are measured. Finally, settle the operational rules. Confirm change freezes and maintenance windows with IT operations so that a tuned rule or a contained host is not mistaken for an outage, and agree how the exercise will be marked in the SIEM and ticketing system. Define escalation paths in advance, including a written rule that exercise alerts are handled inside the exercise and never escalated as live incidents unless the control team calls a stop. Set test account rules and data handling terms: which accounts testers may use, how credentials are stored and destroyed, and where captured data is kept. Obtain sign-off from the executive sponsor and the system owners before testing begins, and confirm that the scope and rules of engagement are the same ones the blue team has read.
What to check in a purple teaming provider before signing
A purple team exercise is only as useful as the people running it and the paperwork that governs it. The checks below cover who will test, how they will work with your defenders, and what you will own at the end. Ask for evidence of each one before you sign, not after the exercise starts.
Detection engineering alongside testing
Purple teaming succeeds or fails on whether findings turn into tuned detections, not on how many techniques were run. Ask whether the provider's testers write or modify detection logic, work in your SIEM and EDR consoles, and can explain why a rule missed an event. Ask who will own the tuning work after the exercise and how changes will be tested for false positives before they reach production.
Threat intelligence and testing expertise
Under DORA, threat-led penetration testing requires testers with specific expertise in threat intelligence, penetration testing and red team testing. Even where DORA does not apply, ask for named people and their experience in each area. Confirm whether the team that runs the exercise is the team that wrote the proposal, and whether the people you meet are the people who will work your environment.
Team experience levels and staffing
For TLPT under Delegated Regulation (EU) 2025/1190, Article 7 requires a red team manager with at least 5 years' experience and at least two testers with 2 years each. Use these as a benchmark even for non-TLPT work. Ask for experience levels per named tester, how much of the work is done by senior staff, and what happens if a key person leaves during the engagement.
CREST accreditation where relevant
CREST is a not-for-profit company that accredits and certifies across disciplines including security testing, red teaming, threat intelligence and incident management. Where your regulator, customer or insurer expects accredited providers, ask which CREST accreditations the provider holds, for which services, and whether the named testers are individually certified. Verify the status directly with CREST rather than relying on a logo in a proposal.
Written scope and rules of engagement
The scope document should list the ATT&CK techniques to be run, the systems and networks in bounds, the times of testing, the named contacts on both sides, and the stop conditions. It should also state how safety-critical or production systems are handled and what happens if a technique causes an outage. Insist that the rules of engagement are signed before any technique runs, and that any change to them is recorded in writing.
Sample report and deliverable structure
Ask for a redacted sample report and check that it maps each technique to what was logged, what was detected, what alerted, and what was changed. A useful report also records detection gaps with owners and retest dates. Confirm whether the report is written for your SOC and engineers, your auditor, or both, and whether it includes the detection rules, queries and log evidence needed to repeat the test.
How much effort purple teaming takes and whether you can run it yourself
How much does a purple teaming exercise cost?
Cost depends on the number of ATT&CK techniques in scope, the number of systems and log sources the blue team must check, and how many test-and-tune cycles are needed. Most of the spend is tester time, split between preparing the technique list, executing techniques under observation, and writing up detection changes. Ask each provider for a quote that breaks out preparation, execution, tuning support and reporting, and state whether a retest is included. No price list is published; a quote follows from the written scope, and no figure in this section applies to any specific engagement.
How long does a purple teaming exercise take?
Duration is set by how many techniques you want to exercise, how many detection rules need changing, and how quickly your team can review alerts and deploy tuning. A narrow exercise against a single tactic can run as a short workshop series, while a broad one covering several ATT&CK tactics needs longer sessions and at least one retest cycle. Ask the provider to show a week-by-week plan with named blue team checkpoints, and confirm how much of the calendar depends on your change approval process.
What does purple teaming need from our security operations team?
The work needs named analysts who can read SIEM and EDR telemetry during each technique, the authority to change detection rules, and someone who owns the log sources in scope. Expect to provide access to a test environment or agreed production hosts, an escalation contact who can stop a run, and time to review each alert in a shared tracker. Without these, findings stall at the report stage. Confirm the staffing commitment in writing before the scope is signed.
Can an internal team run purple teaming without outside help?
An internal team can run purple teaming alone if it already maps detections to ATT&CK, has engineers who can write and test detection content, and has a repeatable way to execute techniques safely. Many teams start with an external provider for the first cycle, then run later exercises in-house. Be realistic about the gap: an internal team tests its own assumptions, so an external tester often finds blind spots the team did not expect. Ask whether the provider will train your staff and hand over the technique library and tuning records.
How does purple teaming differ from red teaming and assumed breach testing?
Purple teaming is collaborative and focused on detection. Testers and defenders work through techniques together, in the open, to confirm what is logged, alerted and detected, and then tune controls. Red teaming is covert and objective-based, measuring detection and response against a realistic adversary across people, process and technology. Assumed breach testing starts from a provided foothold, such as a standard user account, to measure lateral movement and privilege escalation. Choose purple teaming when the goal is detection engineering, and the others when the goal is to test the response itself.
Does purple teaming satisfy TIBER-EU requirements?
Purple teaming is a required part of TIBER-EU closure, but it does not replace the full test. The January 2025 TIBER-EU framework made purple teaming mandatory and aligned the framework with the DORA TLPT standards. Closure also includes red and blue team reports, a replay, a test summary report, a remediation plan and an attestation, and tests produce no pass or fail result. Confirm with your national authority and the test's control team how the purple teaming phase will be documented before the exercise starts.
How does retesting work after a purple teaming exercise?
Retesting re-runs the techniques that were missed or only partly detected, after the detection changes are deployed, to confirm that the new rules fire. CIS Controls v8.1 Safeguard 18.4 expects security measures to be validated after each penetration test and adjusted where needed to detect the techniques used. Ask the provider whether retesting is included in the quote, how many cycles are covered, which techniques will be rerun, and what evidence, such as alert records and rule versions, you will receive for your auditor.
How retesting confirms that tuned detections hold
The retest loop reruns the same ATT&CK techniques after detection changes and checks that each one fires, reaches the right queue and is documented before and after. The output is evidence that the tuning worked, not an assumption that it did.
Freeze the baseline and technique list
Before any rule changes, the purple team exports the techniques run in the initial session, the expected log sources, the detection logic in place and the alert destinations. The red team and the blue team both sign off on this list so that the retest repeats the same behavior rather than a new one. The step closes when the baseline is stored with the test record and the technique list is version-controlled alongside the exercise plan.
Apply detection and alert changes
The blue team makes the agreed changes to rules, thresholds, log collection and alert routing in the SIEM or detection platform. Each change is tied to a specific gap observed in the first session, such as a missing event source or an alert that fired but was routed to a queue nobody monitors. The step closes when every change has a ticket or change record that names the technique it addresses and the person who approved it.
Rerun the same techniques
The red team repeats the techniques from the frozen list under the same rules of engagement, using the same accounts, hosts and timing conditions where the environment allows. Repeating the exact sequence matters because a changed test cannot show whether a changed detection works. The step closes when the execution record shows each technique was run, with timestamps, and any deviations from the original plan are noted.
Confirm firing and queue routing
For each technique, the team checks three things: the telemetry was logged, the detection fired, and the alert reached the intended analyst queue or case management tool with enough context to act on. A detection that fires into an unmonitored queue counts as a gap. The step closes when each technique has a recorded outcome of detected, logged but not alerted, or not logged, with the evidence reference attached.
Record before and after states
The team places the original outcome beside the retest outcome for every technique, showing what was logged, detected and alerted in each case and which change produced the difference. Where a technique still produces no detection, the entry states that clearly and links to a remediation item. The step closes when the comparison table is complete and reviewed by both teams.
Update the report and remediation plan
The final report is revised to show the retest results, the changes made, residual gaps and the owners and status of open items. Findings are not closed on the strength of a rule being edited; they are closed only when the retest shows the expected detection. The step closes when the report version, its date and the list of accepted residual risks have been issued to the client's security leadership.
Schedule ongoing retesting
Detections drift as software, configurations and staff change, so a one-time retest proves little for long. Organizations that want the loop repeated at intervals can place it under an ongoing retainer, which covers recurring technique selection, reruns and reporting. Confirm with the provider how the retainer defines its technique set, how it handles new ATT&CK releases and what is delivered each cycle before committing. The step closes when the agreed cadence and deliverables are written into the statement of work.
How DeployOpen scopes, tests, reports and retests purple teaming
DeployOpen plans and runs purple teaming as a fixed-scope engagement, with the red and blue sides working from one written scope and one shared record of what was run and what was seen. Ongoing support and repeat testing are available as a retainer.
How we scope
- Agree in writing which ATT&CK techniques, tactics and target systems the purple team will exercise
- Confirm which log sources, SIEM rules, EDR policies and alerting paths are in scope for review
- Name the blue team contacts, the coordinating lead and the communication channel used during live runs
How we build
- Map each planned technique to the telemetry it should produce and the detection expected to fire
- Prepare a test plan that records start and stop times, execution steps and the owner of each action
- Set safety controls and stop conditions so live production systems are not disrupted during technique runs
How we hand over
- Deliver a technique-by-technique record showing what was logged, what was detected and what raised an alert
- Provide tuning recommendations for each detection gap, with the rule, log source or threshold to change
- Document a retest plan so the blue team can confirm each tuned detection fires on a repeat run
How we support
- Offer a retainer for repeat purple teaming cycles as detection content and the environment change
- Re-run agreed techniques after tuning to confirm closed gaps and record the new results
- Confirm with your auditor or assessor which evidence from the engagement they need before work starts
