Red team vs blue team: exercise roles compared

Red team vs blue team: which side do you need first?

Decide first whether you are buying an attack or a defense check, because the answer changes who you hire, what they are measured on and what you get back. A red team is, in the words of CNSSI 4009-2022 as quoted in the NIST glossary, a group authorized and organized to emulate a potential adversary's attack or exploitation capabilities against an enterprise's security posture, with the objective of demonstrating the impacts of successful attacks and what works for the defenders. A blue team is the group responsible for defending the enterprise's use of information systems by maintaining its security posture, and it also conducts operational network vulnerability evaluations and provides mitigation techniques. Read the NIST glossary entry for red team and the blue team entry before you write the statement of work.

Start with the defensive side when you have not yet confirmed that your logging, alerting and response work for the techniques an adversary would use. A blue team review, or a validated assessment of detections, is the sensible first step if your SIEM coverage, escalation paths and response runbooks are untested. Start with an attacking exercise when those basics are already measured and the open question is whether an adversary can reach a defined objective, such as access to a payment system or to a patient record store, without being noticed. In regulated settings, the TIBER-EU framework of January 2025 makes purple teaming mandatory, so the joint phase is not optional for those entities. Confirm with your supervisor or auditor which exercise format they expect.

The useful output is the joint review, not a red team win. A red team that reaches its objective shows a gap, but it does not show which control failed, which log entry was missing or which alert should have fired. The TIBER-EU blue team test report records, for each attack step, the detected attack actions and the corresponding log entries, and it identifies topics for purple teaming. Ask your provider for the same structure: each step, what was detected, what was logged, what was missed and which fix will be validated. Agree in writing who attends the review, who owns each fix and how the retest will prove that detections now cover the techniques the testers used, as CIS Controls Safeguard 18.4 asks.

How the red and blue teams differ on goals, scope, method and measures

This table compares the attacking and defending sides of an exercise factor by factor, so you can see what each team is for before you buy either. Read it as a checklist: if a provider cannot answer a row for both sides, the exercise is not yet scoped.

Factor	Red team (emulates the adversary)	Blue team (maintains posture and mitigates)
Objective	Per CNSSI 4009-2022, emulate a potential adversary's attack or exploitation capabilities to demonstrate the impacts of successful attacks and what works for defenders.	Per CNSSI 4009-2022, defend the enterprise's use of information systems by maintaining its security posture, and conduct operational vulnerability evaluations that provide mitigation techniques.
Scope and boundaries	Covert testing usually stops at defined boundaries such as a certain level of access, as NIST SP 800-115 notes. Confirm the rules of engagement and stop conditions in writing before work starts.	Covers the production monitoring, response and control environment the exercise is meant to test. Blue staff are often not told the start date, so scope limits are set and held by the control team.
Method at buyer level	Chains techniques toward an agreed objective, which can include social engineering or physical access where authorized. The path is chosen by testers, not by a checklist.	Works through detection, alerting, triage, containment and reporting for the activity it observes. Output includes detected attack actions and the matching log entries, as TIBER-EU requires.
What the side is measured on	Whether the objective was reached, which paths worked, and which controls or people stopped or slowed the attack. Under TIBER-EU, results carry no pass or fail score.	Whether activity was detected, how quickly it was triaged and contained, and whether detections cover the techniques the testers used, per CIS Safeguard 18.4.
Data and access needed	Agreed initial access or a defined starting position, target lists, and a named contact who can halt activity. Confirm whether credentials, source code or network maps are supplied.	Access to SIEM and log sources, detection rules, runbooks and ticketing records. Confirm retention periods and who may query production logs during the exercise.
Who runs it	An authorized internal or external team, or an accredited provider. For regulator-led schemes, confirm the accreditation body's requirements, such as CREST for CBEST.	The security operations and incident response staff who run the controls day to day. Blue staff usually do not know the exercise is running, so a separate control team manages the exercise.
Main output	An attack narrative with the steps taken, the evidence collected and the controls that were bypassed or failed.	Detection and response records mapped to each attack step, plus mitigations and rule changes. The joint review turns both sets of records into fixes.

What the red team finds and misses, and what the blue team sees

A red team is authorized to emulate a potential adversary and to show what the attack achieves against the enterprise and what works for the defenders, as CNSSI 4009-2022 frames it. Its strongest output is the attack path: a sequence of weaknesses that only becomes serious when chained, such as an exposed service, a reused credential and an over-privileged account. Those chains are rarely visible in a scanner report, which lists weaknesses one at a time.

Attack paths: The team shows how a foothold becomes access to a target, including which steps were slow, blocked or unnoticed.
Chained weaknesses: Individually low-severity issues can combine into a meaningful objective, which is the finding leadership usually needs to understand.
Defender awareness: The team can record whether staff or tooling noticed each step, which a vulnerability scan cannot establish.
Social and physical paths: Where the rules of engagement allow it, testers can show whether people respond to pretexts or unescorted access.

Confirm with your provider which techniques are in scope and how the rules of engagement, following the template in NIST SP 800-115, define stop conditions.

What you receive from each side and from the joint review

A red team exercise produces evidence of what an attacker could reach, and a blue team produces a record of what it saw and did. The value comes when both are laid side by side in a joint review that sorts detections, gaps and fixes by technique.

Red team attack narrative

The red team's core deliverable is a chronological account of how the adversary emulation progressed, from initial access through the objective. Each step should name the technique used, the target and the point where the team was challenged or stopped. Check whether the narrative separates what the testers did from what they only assumed, and whether it states the boundaries agreed in the rules of engagement, since NIST SP 800-115 describes covert testing as stopping at defined boundaries such as a certain level of access.

Objectives reached and evidence

The red team should state which objectives it reached, which it did not, and the evidence behind each claim. CNSSI 4009-2022 frames the red team's purpose as demonstrating the impact of a successful attack and what works for the defenders, so the evidence matters more than a pass or fail label. Ask how the team recorded artifacts without exposing production data, and how it handled material it could not verify.

Blue team detection and response record

The blue team's record shows which attack actions were detected, which were missed, and how the response unfolded. CNSSI 4009-2022 describes the blue team as the group defending the enterprise's security posture, and this record is the only view of what defenders actually did during the exercise. Confirm that timestamps and alert identifiers are kept so the record can be matched against the red team narrative later.

Log correlation and gaps

Correlating the red team's actions with raw log entries shows whether telemetry existed for each step, even when no alert fired. TIBER-EU's blue team test report lists, for each attack step, the detected attack actions and the corresponding log entries, which is the model to ask suppliers to follow. Gaps appear where the logs are absent, where alerts were not triaged, or where logs existed but no rule matched.

Technique-by-technique detection matrix

The joint review turns both records into a matrix that maps each technique to whether it was executed, whether it was detected, and whether the response was effective. CIS Controls Safeguard 18.4 asks for security measures to be validated after each test so that detections cover the techniques the testers used, which is why this matrix is the central artifact. Ask for the mapping to use a consistent technique catalog, such as MITRE ATT&CK, so the matrix can be reused.

Purple teaming topics and retest plan

TIBER-EU identifies topics for purple teaming from the blue team report, so gaps found in one exercise become the agenda for a joint working session. The review should also rank fixes and set a retest that checks whether each fix covers the techniques that were missed. Confirm with your provider how the fix list is prioritized and who owns each remediation, because the retest is what proves the change worked.

When compliance frameworks call for red or blue team work

Start by identifying which requirement actually applies to you, because the frameworks ask for different things. NIST SP 800-53 control CA-8 (Penetration Testing) has enhancements for an independent penetration testing team and for red team exercises, but SP 800-53B Release 5.2.0 selects CA-8 and CA-8(1) only in the high baseline. If your system is categorized at a lower baseline, the red team enhancement is not a control you are obliged to meet under that catalog. Confirm your system categorization and baseline with your assessor before scoping a red team exercise for NIST purposes.

Financial entities face different obligations. DORA Article 26 requires threat-led penetration testing at least every 3 years, but only for entities that their competent authority identifies. If you are not on that list, the requirement does not apply to you, although DORA Article 25 still lists the testing methods your supervisor may expect. TIBER-EU, where it is adopted, runs at least 12 weeks of active testing with mandatory purple teaming, and the ECB states these tests produce no pass or fail result. Ask your competent authority whether you are in scope, which provider accreditation they expect, and how blue team detections will be documented for supervisors.

The CIS Controls ask for a different cadence. Safeguards 18.2 and 18.5 call for external and internal penetration tests at least annually, and Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques the testers used. That last point is where blue team work becomes a compliance matter: a test that is not followed by a review of what was and was not detected does not satisfy the intent. Confirm with your assessor whether they accept an annual penetration test alone or expect evidence of detection validation alongside it.

What drives cost and effort on each side

Red and blue team effort is set by a handful of inputs agreed before testing starts. The cards below cover who is paid for what, which costs are one-time and which recur, and what to ask for in a written quote so both sides can compare like with like.

Scope of target and system count

Every system in scope adds reconnaissance, access attempts, and triage work for the red team, and more logs for the blue team to review. Ask the provider to list the environments, network segments, cloud accounts, and business applications covered, and whether each is production or a replica. NIST SP 800-115 treats penetration testing against production systems as high risk, so the scope list also drives the rules of engagement work. Ask for the scope in writing before any price is discussed.

Depth of threat intelligence

Threat intelligence determines which adversary behaviors the red team emulates. A generic scenario needs less research than a threat-led scenario built on sector-specific intelligence, which usually means a separate provider and more analyst time. Ask whether intelligence gathering is included in the quote, who supplies it, and whether it is refreshed for a second exercise or used once. Written scope should name the threat actors and techniques in play.

Detection maturity and logging coverage

Blue team effort rises sharply when logs are incomplete, because analysts must reconstruct each attack step by hand. Mature logging and tuned alerts shorten the exercise, but they also mean fewer gaps to report. Ask the team which log sources and retention periods are in scope, and whether the blue team will be asked to produce log entries for each detected attack action, as TIBER-EU blue team reports do.

Blue team participants and hours

Blue team cost is mostly internal staff time, not vendor fees, so it is easy to undercount. Count the analysts, incident responders, and managers who will monitor, triage, and document during the exercise, and the hours each one will spend beyond normal duties. Ask the provider how many blue team roles it expects to engage and whether a control team will coordinate access and deconfliction.

Purple review sessions

Joint review sessions convert findings into detection and response changes, and they carry a cost that is often left out of quotes. TIBER-EU makes purple teaming mandatory, so the framework treats these sessions as part of the test, not an optional extra. Ask how many sessions are included, who attends for each side, and who writes the follow-up detection backlog. Those deliverables are where the lasting value sits.

Rules of engagement work

Rules of engagement set the boundaries for the red team, including permitted techniques, stop conditions, and escalation contacts. Drafting them takes legal, management, and technical review on both sides, and the document is usually written once per exercise. NIST SP 800-115 provides a rules of engagement template in Appendix B that teams can adapt. Ask the provider whether drafting, legal review, and deconfliction calls are fixed fees or billed hourly.

How to sequence a red and blue exercise with a joint review

This sequence turns a red team attack into a measured change in detection by agreeing the rules first, capturing what defenders saw at each step, and fixing and retesting the gaps the joint review exposes.

Agree rules of engagement first
The exercise sponsor, the red team lead and legal counsel agree the rules of engagement before any testing starts. NIST SP 800-115 provides a rules of engagement template in Appendix B, and it covers scope, permitted techniques, testing windows, out-of-scope systems, stop conditions and points of contact. Ask the red team to state which objective it will pursue and which boundaries it will stop at, such as a defined level of access. The step is done when the signed document names who can halt the test and how defenders are informed if real incident response is triggered.
Decide what the defenders know in advance
The sponsor decides how much of the exercise the blue team learns beforehand. A covert test, where defenders are not told when or how the attack will occur, tests technical controls, the staff's response to perceived incidents and policy knowledge. A tested-in-advance exercise lets defenders confirm logging before the attack, which suits a first run or a team building its detection baseline. The decision and its reasoning are recorded in the rules of engagement so that the joint review can interpret results correctly.
Run the scoped engagement and record each step
The red team executes the agreed scenario inside the boundaries, and a neutral observer or exercise coordinator logs the time, technique and target of each attack step. Blue team analysts work their normal monitoring and response procedures during this time. The red team should keep its own record of commands and artifacts so that every action can be matched to an event later. The step is done when the attack ends or a stop condition is triggered, and the coordinator holds a complete timeline of attacker actions.
Collect blue team detections and logs per attack step
The blue team exports the alerts, tickets and log entries that correspond to each attack step on the timeline. For each step, the team records whether it was detected, alerted, investigated or missed, and links the detection to the log entries that show it. TIBER-EU's blue team test report follows this structure, listing the detected attack actions and their log entries for each attack step. The step is done when every red team action has a recorded outcome, including the steps with no detection at all.
Hold the joint review to map detections to techniques
Red and blue leads meet with the coordinator and walk the timeline together, mapping each action to a technique in a common framework such as MITRE ATT&CK. The review asks why each missed step went unseen, whether logging was absent, rules did not fire, alerts were triaged away or responders did not escalate. TIBER-EU identifies topics for purple teaming from this kind of review. The output is a ranked list of gaps with an owner and a proposed fix for each, and the review is complete when every gap has a named owner.
Fix the gaps in logging, detection and response
Owners implement changes such as enabling missing log sources, tuning or writing detection rules, adjusting alert routing and updating response runbooks. Each change is tied to the gap it addresses in the joint review record. CIS Controls Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques the testers used, which makes this fix list the input to the next test. The step is done when each change is deployed and the record shows which gap it closes.
Retest the same techniques to confirm the change
The red team or a purple team repeats the techniques that were missed or partly detected, under the same rules of engagement, to confirm that the new logging and rules produce the expected alerts. The retest checks the fixes rather than running a new attack from scratch, so results are comparable to the first run. The step is done when each previously missed technique is either detected and handled or carried forward as an accepted risk with a named approver. The joint review, not the red team's success or failure, is what changes detection, so the closing record should show the before and after detection status for each step.

Questions buyers ask before commissioning red or blue team work

What drives the cost of a red team exercise?

The cost depends on the scope the buyer agrees to, and no published price applies across engagements. The main components are the testers' time for planning, intelligence gathering, the attack phase and reporting, plus any specialist work such as social engineering or physical access. Costs rise with the number of target systems, the number of attack paths to test, the amount of threat intelligence work, and whether the exercise includes a blue team review afterward. Costs fall when the objective, rules of engagement and systems in scope are fixed before work starts. Most engagements are fixed-scope, so ask for a written quote that lists deliverables, assumptions, client-side effort and any retainer for follow-up testing. Ask which items are one-time and which recur if the exercise becomes part of a yearly program.

How long does a red team exercise take?

Duration depends on scope, the objective and how much preparation the client needs. The 12-week minimum of active testing in TIBER-EU applies only to TIBER-EU tests, which also require preparation and closure phases and mandatory purple teaming. A voluntary red team exercise has no such fixed minimum in the supplied sources, so agree its duration in writing during scoping. In a TIBER-EU test, plan for the full framework timeline, including the control team and the purple teaming that follows. Outside that regime, ask the provider to split the schedule into scoping, testing, reporting and the joint review, and confirm which of those the quoted timeline covers.

What does a red team exercise need from our staff?

The exercise needs a small group of named client people who can make decisions during the test. Typically this includes an executive sponsor, a control or exercise lead who knows the environment, system owners who can confirm scope and critical services, and legal or HR contacts who approve the rules of engagement. The blue team needs time to respond, log review and keep records of detections, and the TIBER-EU blue team test report depends on those logs. Agree in advance how the client will handle an alert, when the testers may be stopped and who is told. Ask the provider to list every client input and time commitment in the quote, because these are often the largest hidden costs.

Can our internal team run a red team exercise alone?

An internal team can run red team activity if it has testers with adversary emulation skills, a clear mandate and independence from the defenders it tests. Many buyers still bring in an external provider because the exercise needs an objective that is credible to the board and to regulators, and because internal staff may be known to the blue team. Where a regulator expects external accreditation, check the requirement first. The CBEST framework, for example, names CREST as the accreditation and certification body for its providers. Ask any provider what they will deliver, how they will protect the test from becoming a surprise to the wrong people, and what evidence they will hand over at the end.

If the red team wins, did our security program fail?

Not necessarily. A red team win shows that the attackers reached the objective, which is useful information about the gap between your controls and the attack paths the team chose. The useful output is the joint review, where the blue team shows which actions it detected, which logs existed, and which responses were too slow or missing. TIBER-EU states that its tests produce no pass or fail result, so judge the exercise by what was learned, which fixes were agreed and whether detections improved in a later test. A program has a problem if the same paths succeed after the fixes are validated, or if the blue team never saw the activity at all.

How do we scope a red team exercise safely with legal authorization?

Start with a written authorization letter signed by someone who can approve testing of the named systems, plus the rules of engagement. NIST SP 800-115 provides a rules of engagement template in its Appendix B, which covers scope, timing, permitted techniques, boundaries and emergency contacts, and is a good starting point. Define the stop conditions, the level of access that marks the boundary, how production data is handled, and what happens if a third party such as a cloud or hosting provider is affected. Confirm that the exercise does not touch systems you do not own or control, and check the legal review for any social engineering or physical access. Keep the authorization and the test log together so the blue team review can refer to them.

Should you buy a red team, a blue team review, or both?

Start with a joint exercise if you do not yet know whether your logging and detection work. A joint format lets attackers and defenders go technique by technique, so you can confirm that the events your SIEM and endpoint tools should record actually reach the analysts who would act on them. Before you commission anything, ask the provider which techniques they plan to use, which log sources they will check and how they will record what the blue team saw at each step. If your monitoring has never been validated, a covert attack will mostly show you gaps you already suspect, and the fixes will be harder to scope.

Run a voluntary red team when the question is whether your defenders notice an attack at all. A covert operation with a defined objective and agreed boundaries, such as a level of access that the testers must not exceed, tests technical controls, the staff's response to perceived incidents and their knowledge of policy, as NIST SP 800-115 describes. The rules of engagement template in its Appendix B is a useful starting point for agreeing those limits in writing. Expect the blue team to be measured on detections and response, and expect the joint review afterward to matter more than the attacker's path. Do not treat a red team that reached its objective as a verdict on your defenders. Confirm how the provider will record detections and gaps so that you can act on both.

Use a regulator-led scheme only when it applies to you. TIBER-EU is run under the European Central Bank's framework, and the Bank of England's CBEST has its own implementation guide. The DORA threat-led penetration testing requirement applies to entities their competent authority identifies. Where a scheme applies, the scope, providers and reporting are set by the regulator, not by your internal preference. If you are not in scope, a voluntary red team or joint exercise can still meet your goals, and the sibling comparisons on purple teaming and red teaming and on threat-led testing under DORA explain how the formats differ. Confirm your status with your supervisor before you commit budget.

How DeployOpen scopes, runs and supports red and blue exercises

DeployOpen plans, runs and documents red and blue exercises inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

The written scope names the objective, the systems in play and which defensive teams are measured.
Rules of engagement set permitted techniques, stop conditions, time windows and named contacts for emergencies.
Scope states whether the blue team is informed, partly informed or unaware, so results can be read correctly.

How we build

We prepare the test environment and logging needed so blue team detections can be traced to each red team step.
Red team activity is planned against agreed techniques, with the attack path recorded as it runs.
Blue team tooling, alerts and response runbooks are reviewed before the exercise so gaps are not blamed on setup.

How we hand over

Deliverables include a timeline mapping each attack step to the blue team actions and log entries that did or did not appear.
A joint review session walks both teams through missed detections, slow responses and the fixes they agree on.
Written findings are prioritized with owners and retest points so the next exercise can confirm each fix.

How we support

Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
Retainers can repeat exercises at an agreed cadence to confirm that detections still cover the techniques used.
Confirm with DeployOpen during quoting which deliverables, retest rounds and response windows the written scope includes.

Red team vs blue team