Red Teaming Guide

Most organisations know which vulnerabilities they have, but not whether their people, processes and tools would notice and stop a determined attacker working towards a real business objective. Red teaming answers that question with a controlled, goal-driven simulation of a realistic adversary against production systems, usually without the defenders being told. This guide covers how red teaming differs from penetration testing and purple teaming, the threat-led frameworks regulators use (TIBER-EU, CBEST, DORA threat-led penetration testing, iCAST and AASE), and how to scope, govern, run, report and remediate an engagement safely. It is written for security leaders commissioning red team work, control team members who manage it, and blue teams who need to turn the results into lasting improvements.

Key takeaways

• A red team tests detection and response, not just exposure. The output is evidence of how far a realistic adversary got, what the defenders saw and how they reacted. TIBER-EU states plainly that "the outcome is not a pass or fail."
• Threat intelligence drives the scenarios. TIBER-EU, CBEST and DORA all require a threat intelligence phase before testing, so the red team emulates adversaries that actually target your sector and critical functions.
• A small control team carries the risk. Only a handful of people know the test is live; they set flags, approve leg-ups, deconflict real incidents and can halt the test at any time.
• The value is realised in closure. Replay, purple teaming and a tracked remediation plan turn a report into new detections and fixed weaknesses. Under the DORA technical standards, remediation plans are due within 8 weeks.
• Identity is the usual path. Valid accounts, service accounts and weak delegation settings recur in red team findings; scenarios and fixes should cover non-human identities as well as people.

Red team, penetration test, purple team and BAS compared

Buying the wrong exercise is a common and expensive mistake. NIST SP 800-53 separates them: CA-8 covers penetration testing, CA-8(1) requires an independent testing agent or team, and CA-8(2) covers red team exercises "to simulate attempts by adversaries to compromise organizational systems". The NCSC notes that a penetration test "can only validate that your organisation's IT systems are not vulnerable to known issues on the day of the test", and that "assessing whether defined security controls are functioning is not a valuable use of penetration testing resources."

Decision guidance: commission a penetration test for assurance on a specific system or release, a red team to test the whole defensive chain against a credible adversary, and purple teaming when you want known gaps fixed quickly. BAS stops the gains from decaying. See the Breach and Attack Simulation (BAS) Guide.

Threat-led and intelligence-led frameworks

Financial regulators have formalised red teaming as threat-led penetration testing (TLPT). The frameworks share a structure: initiation and scoping, threat intelligence, active red teaming, and closure with remediation. They differ mainly in oversight and frequency.

Unregulated organisations can use the TIBER-EU 2025 guidance set (scope specification, threat intelligence report, test plan, blue team report, remediation plan) as free templates. For the wider DORA testing regime, see the DORA Guide.

Tester requirements

• Experience: DORA requires the external red team to include "at least a manager, with at least 5 years of experience in penetration testing and red team testing" (Art. 7(1)(f)(i)). Internal testers are allowed only under Art. 15 conditions, and TIBER-EU states that significant credit institutions under DORA cannot use them.
• Accreditation and vetting: CBEST providers must be Bank of England accredited CREST members with certifications such as CREST Certified Red Team Manager (CCRTM); AASE adds insurance, indemnity and background checks.

Scoping: objectives, flags and scenarios

A red team without a sharp objective drifts into an expensive penetration test. Start from the business, not the network.

• Critical functions: list the services whose disruption would cause real harm; TIBER-EU suggests no more than 10 per test.
• Flags: TIBER-EU expects the control team to set at least one flag per system in scope. Good flags are specific and provable: read a named record in the payments database, approve a transaction in a test account, or change a setting in the production cloud tenant.
• Scenarios: derive two or three from the threat intelligence report, each naming a credible actor, entry point and goal, for example a financially motivated group, a nation-state actor and an insider. See the Threat Actor Groups Guide.
• Attack surfaces: decide explicitly on social engineering, physical intrusion, third parties and cloud tenants. Physical red teaming needs written authority from the site owner and a letter testers can show if challenged.
• No-fly zones: name systems never to be touched (safety systems, fragile legacy hosts, platforms you cannot authorise) and prohibited actions such as destructive payloads.
• Leg-ups: pre-agree fallbacks such as a provided internal foothold. TIBER-EU requires them to be approved and logged, and never to give direct access to flags or disable controls.

Governance: control team, deconfliction and legal authority

The control team (also called the white team, white cell, control group or Exercise Working Group) is the safety system of the engagement. DORA asks for it to be "as small as possible" and makes the control team lead responsible for day-to-day management (Art. 4(1)).

Roles

• Control team lead: owns the test, the risk assessment and the decision to pause or stop. TIBER-EU: "The CT may at any time order a temporary or complete halt of the test if concerns are raised over damage."
• Trusted agents: one or two senior people in security operations or IT who can deconflict without tipping off the defenders. In CISA's red team assessment of a critical infrastructure organisation (advisory AA24-326A), trusted agents supplied scope, deconflicted access to a sensitive system and later moved defenders to a monitoring-only mode.
• Red team provider: keeps a timestamped activity log and reports critical issues immediately.

Rules of engagement

• Written authorisation: a signed letter of engagement (AASE) or authorisation letter naming the systems, people, sites, dates and the person who can grant consent for each. Testing without authority from the system owner can be an offence under computer misuse laws, and you cannot authorise testing of a supplier's platform on its behalf.
• Deconfliction process: how the blue team's real incident escalations are checked against the red team log, who answers out of hours, and a code word for stopping.
• Stop conditions: AASE requires high-risk vulnerabilities to be reported immediately, and evidence of a prior real compromise halts the attack until incident response is complete.
• Data handling: limits on what testers may view or copy, and destruction of collected data after the test.
• Safe execution: AASE allows high-risk actions to run in a replica environment. Prohibit techniques that could degrade availability unless the control team accepts the risk in writing.

Adversary emulation and red team infrastructure

Emulation means reproducing the behaviours of a specific, named adversary rather than whatever the testers happen to know. MITRE's Center for Threat-Informed Defense maintains an adversary emulation library with 11 full plans (including APT29, FIN7, Sandworm, Turla and Wizard Spider) and 12 micro plans for compound behaviours such as web shells and log clearing. Each full plan contains an intelligence summary, an operational flow and step-by-step procedures, and the library states its content "is only to be used with appropriate prior, explicit authorization." Atomic Red Team and MITRE Caldera are covered in the Breach and Attack Simulation (BAS) Guide.

• Map scenarios to ATT&CK: every planned and executed step should carry a technique ID so findings can be compared with detection coverage. CISA's AA24-326A maps each red team technique to ATT&CK and recommends testing your controls against them.
• Command and control infrastructure: red teams operate their own command and control (C2) frameworks, redirectors and domains. Require it to be dedicated to your engagement, hosted in agreed jurisdictions, protected with MFA, logged and torn down at closure. Captured credentials live on it, so it is part of your attack surface.
• Implants and persistence: require an inventory of every implant, account, scheduled task and configuration change. AASE makes a clean-up report "strongly recommended"; CISA's assessment ended with the red team still holding implants on four hosts that defenders had not found.

Running an engagement step by step

1. Initiate: agree the sponsor, control team, budget and any regulator involvement; procure accredited providers.
2. Scope: document critical functions, flags, exclusions, leg-ups and stop conditions in a scope specification; complete a risk assessment of testing in production (DORA Art. 5(1)).
3. Threat intelligence and test plan: indicatively 4 to 6 weeks and 2 to 3 weeks under TIBER-EU, ending in scenarios and a plan the control team approves.
4. Active testing: at least 12 weeks for TLPT. Hold a weekly control team call; review the red team log; deconflict incidents; approve leg-ups. Pause rather than push on if a production system shows stress.
5. Clean-up and roll back: remove implants, accounts and changes from the inventory, rotate every credential the team captured, and have the blue team verify removal independently.
6. Reporting and replay: red and blue team reports, then a joint replay of both timelines side by side.
7. Purple teaming: TIBER-EU requires the closure purple teaming exercise "no later than ten weeks after the end of the active red team testing phase".
8. Remediation plan and attestation: within 8 weeks under DORA; owners, dates and retest criteria for every finding. Regulated tests end with a test summary report and attestation.

Reporting, purple teaming and remediation tracking

A good red team report ties findings to critical functions and includes a timeline of each action with its ATT&CK ID, time of action and time of detection, if any. The blue team report explains what was seen, what was escalated and why other signals were missed.

Purple teaming formats

In the testing phase, limited purple teaming is "a last resort" when the test cannot continue securely; its outcomes must be "clearly documented and form an integral part of the Remediation Plan." Each missed technique should leave purple teaming as a ticket for a new or tuned detection rule, with a test case to prove it. See the Detection Engineering Guide.

• Track findings like vulnerabilities: load them into the same tracker as other remediation work, with an owner, due date, compensating control and retest status. The NCSC reminds clients that "risk assessment and decisions on the application of fixes are your responsibility" and that rating discussions "should not be used to downplay issues."
• Link findings to business risk: CBEST expects the remediation plan to connect technical findings to important business services, and supervises it for 6 to 12 months or longer.
• Retest: close a finding only after the specific technique has been replayed and prevented or detected. Add it to the BAS library so it stays closed.

Where identity fits

Many red team attack paths run through identities. T1078 Valid Accounts appears under Initial Access, Persistence, Privilege Escalation and Stealth in ATT&CK v20, and its sub-techniques include default, domain, local and cloud accounts. CISA's AA24-326A found unconstrained delegation enabled on 42 non-domain-controller hosts, cleartext passwords stored in Active Directory, unprotected private keys, and no detection for DCSync, golden tickets or anomalous LDAP activity.

• Include non-human identities in scenarios: service accounts, CI/CD tokens, cloud access keys and SaaS integration credentials are frequent flag paths. See the Service Account Security Guide.
• Rotate what the red team touched: every password hash cracked, token stolen or key read during the test is a live credential in someone else's possession until rotated. The Cloudflare Thanksgiving breach shows what happens when a handful of credentials are left unrotated after an incident.
• Test identity detections specifically: privilege escalation through directory misconfigurations, token theft and help desk resets should each have a scenario and an expected alert. See the ITDR Guide.

Frequency, cost drivers and organisation size

Regulated TLPT runs at least every three years under DORA Art. 26. Voluntary programmes rarely exceed one engagement a year, with purple teaming and BAS in between.

• Cost drivers: length of active testing, number of critical functions and scenarios, physical and social engineering scope, jurisdictions, and internal control and blue team time, which is easy to underestimate.
• Small organisations: a short assumed breach exercise plus a purple team day usually gives more value than a covert engagement; fix penetration test findings first.
• Mid-sized organisations: an annual objective-based red team with one or two scenarios, using a threat-led framework as a template, plus quarterly purple teaming.
• Large and regulated organisations: regulator-led TLPT every three years, an internal red team for continuous campaigns between them, and a dedicated purple team function feeding detection engineering.

Measuring the programme

Record per scenario and per ATT&CK technique whether the step was prevented, detected and escalated, logged only, or missed. Useful metrics:

• Time to detect and respond: from the first red team action to the first alert and first containment action.
• Detection rate by technique: percentage of executed techniques that produced an alert a human reviewed, tracked across engagements.
• Flags captured and depth reached: how many flags were obtained and how many leg-ups were needed.
• Remediation closure rate: percentage of findings closed and retested by the agreed date, and median age of open findings.
• Detection uplift from purple teaming: number of new or tuned detections produced per engagement and verified by retest.
• Recurrence: findings that reappear in a later engagement.

Framework mapping

Common failure patterns

• Buying a penetration test labelled as a red team: no threat intelligence, no flags, a vulnerability list as output.
• Too many people know: once the help desk or SOC is warned, the test measures nothing. Keep the control team small and use trusted agents for deconfliction.
• Accepting findings instead of fixing them: CISA found that "leadership deprioritized the treatment of a vulnerability their own cybersecurity team identified" and that a web application firewall had been left in monitoring mode.
• Over-reliance on one control: the same assessment found the organisation "relied too heavily on host-based endpoint detection and response (EDR) solutions", with no network-layer detection and a legacy environment without EDR.
• Incomplete clean-up: implants, test accounts and captured credentials left behind become a real attacker's foothold. Demand an inventory and verify removal independently.
• No retest: findings marked closed on a change ticket rather than a replayed technique, so the same path works in the next engagement.

Practitioner checklist

• Decide whether you need a penetration test, a red team, an assumed breach exercise or purple teaming before procurement.
• Scope from critical functions, with at least one specific flag per system in scope.
• Base scenarios on a targeted threat intelligence report, not on the testers' preferences.
• Appoint a small control team with a named lead who can halt the test, plus trusted agents for deconfliction.
• Sign written authorisation covering every system owner, site and third party in scope; define no-fly zones and stop conditions.
• Require dedicated red team infrastructure, an implant inventory, a clean-up report and rotation of every captured credential.
• Hold a replay and purple teaming within ten weeks of active testing, and turn each miss into a tested detection.
• Track findings with owners and dates, link them to business risk, and close them only after retest.
• Measure time to detect, detection rate, remediation closure and recurrence across engagements.

Standards and references

• European Central Bank: TIBER-EU framework and guidance
• EUR-Lex: Commission Delegated Regulation (EU) 2025/1190 on threat-led penetration testing
• Bank of England: CBEST Threat Intelligence-Led Assessments Implementation Guide
• Association of Banks in Singapore: Red Team Adversarial Attack Simulation Exercise Guidelines
• European Central Bank: TIBER-EU Purple Teaming Best Practices
• CISA: Enhancing Cyber Resilience, Insights from CISA Red Team Assessment of a US Critical Infrastructure Sector Organization
• MITRE Center for Threat-Informed Defense: Adversary Emulation Library
• NCSC: Penetration Testing

Related NHI Mgmt Group resources: Breach and Attack Simulation (BAS) Guide · Detection Engineering Guide · Threat Actor Groups Guide · Vulnerability Management Guide · DORA Guide