CyphrQ
Menu

Red Team vs Blue Team vs Purple Team: Who Needs Which, and When

Red, blue and purple teaming explained, regulator-led tests such as CBEST, TIBER-EU and DORA TLPT, how to scope one, and what a good report contains.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

11 min read

A red team plays the attacker and tries to reach a real business goal without being caught. The blue team is the defenders who detect and respond. A purple team is the two working together, replaying the attack step by step so the defenders can fix what they missed. In my view, most organisations need a blue team first, purple exercises next, and a full red team only once the basics are in place, unless a regulator says otherwise.

This post explains each term, who needs which and when, the regulator-led schemes in the UK, the EU and Saudi Arabia, how to scope an engagement safely, and what you should expect in the final report.

What is a red team, a blue team and a purple team?

The US Committee on National Security Systems defines a red team as a group "authorized and organized to emulate a potential adversary's attack or exploitation capabilities" against an organisation's security posture, according to the NIST glossary entry, which cites CNSSI 4009-2022. The aim is to show the effect of a successful attack and which defences work in a live environment.

Red team Blue team Purple team
Role Simulated attacker Defenders: monitoring, detection, response Red and blue working side by side
Goal Reach agreed objectives, such as access to payment systems, undetected Spot and stop real and simulated attacks Turn each attack step into a working detection or control
Who knows it is happening A small control group only Usually not told during a red team test Everyone involved
Typical length Weeks to months Permanent function Days to weeks per exercise
Output Narrative of the attack path and findings Alerts, incident records, improvements Tuned detections, tested playbooks

The blue team is often a security operations centre (SOC), an internal team, a managed service, or a mix. The SOC requirements guide explains what US rules expect of that function.

The purple team is a way of working, not a separate department. The attacker shows a technique, the defenders check whether they saw it, and both adjust until the detection works.

How is a red team exercise different from a penetration test?

Saudi Arabia's central bank puts the difference clearly in its Financial Entities Ethical Red Teaming Framework (dated 13 May 2019, listed as in force). It states that "Red Teaming is not a penetration test" and that it "should not be regarded as an Audit." A penetration test assesses one or more specific information assets. A red team simulates a targeted, realistic attack against the whole organisation, and tests how well its detection and response actually work.

In plain terms:

  • A penetration test asks: what weaknesses does this system have? The defenders often know it is happening. The goal is coverage of one scope.
  • A red team asks: could a capable attacker reach our crown jewels, and would we notice? The defenders usually do not know. The goal is a realistic path to an objective.
  • A vulnerability scan is automated and broad. It finds known flaws but does not chain them together.

Who needs red, blue or purple teaming, and when?

Order matters. A red team against an organisation with no monitoring will succeed and teach you little you did not already suspect.

  1. Every organisation needs a blue team function, even if it is one person and a managed service. Someone must watch the alerts and act on them.
  2. Next, vulnerability scanning and penetration tests on internet-facing systems and key applications, I suggest at least yearly and after major changes.
  3. Then purple team exercises. Pick five to ten techniques that attackers use against organisations like yours and test whether you detect each one. In my view this gives the most improvement per day spent.
  4. Then a full red team, when you have monitoring, a working incident process and fixes from earlier tests in place. The question it answers is whether all of that holds together under realistic pressure.

Boards and executives should ask a simple question before approving a red team: what did our last penetration test and purple exercise find, and have we fixed it? If the answer is no, spend the money there first.

Which regulators require threat-led red team testing?

Financial regulators in several regions run or require threat-led red team tests. Threat-led means the scenarios are built from intelligence about real attackers who target that firm or sector.

UK: CBEST. The Bank of England, the Prudential Regulation Authority and the Financial Conduct Authority have used CBEST since 2014, per the CBEST implementation guide (2024 edition). It is a threat intelligence-led assessment that mimics the actions of cyber attackers to test a firm's important business services and the people, processes and technology behind them. It is a supervisory tool aimed at systemically important firms and financial market infrastructures.

EU: TIBER-EU and DORA TLPT. TIBER-EU is the Eurosystem's framework for threat intelligence-based ethical red teaming. On 11 February 2025 the ECB announced an update aligning it with the DORA technical standards on threat-led penetration testing (TLPT). Two changes stand out: purple teaming is now mandatory, as the DORA standards require, and the "White Team" that oversees the test was renamed the "Control Team".

Under DORA, firms the authorities identify must run TLPT at least every three years, under Article 26 of DORA (Regulation (EU) 2022/2554), as the DORA explainer covers. The detail sits in Commission Delegated Regulation (EU) 2025/1190, adopted on 13 February 2025 and drafted in line with TIBER-EU. It sets:

  • an active red team testing phase of at least 12 weeks, scaled to the scope;
  • at least three attack scenarios, chosen by the control team lead from the threat intelligence provider's proposals;
  • for internal testing teams, a test lead plus at least two members, all employed by the firm or an intra-group provider for the preceding 12 months.

Saudi Arabia: F.E.E.R. SAMA's framework, cited above, guides financial institutions in planning and running threat intelligence-based red team tests with certified providers. Its rulebook organises the process into four parts: Preparation, Scenario, Execution and Lessons Learned.

These schemes are written for finance, but the structure works for any sector. If you run critical services anywhere, borrowing the TIBER-EU process is a reasonable starting point.

What should a red team engagement's rules of engagement cover?

A red team is authorised attacking. The paperwork is what keeps it legal and safe. Rules of engagement should cover at least:

  • Objectives. Named business outcomes, such as "initiate a payment from the treasury system" or "read the board pack", not "find vulnerabilities".
  • Scope and exclusions. Which systems, sites, people and third parties are in. Anything out of bounds, such as safety systems, production databases at month-end, or employees on leave.
  • Permitted techniques. Phishing, physical entry, social engineering by phone, use of real employee names. Each needs an explicit yes or no.
  • Legal authority. Written sign-off from someone who can authorise access to every system in scope. Supplier-hosted systems need the supplier's agreement too.
  • The control team. The few people who know, including a senior sponsor. They can pause the test, confirm "this is the red team" if the blue team escalates, and protect secrecy.
  • Stop conditions and a "get out of jail" letter for testers caught on site.
  • Data handling. What testers may copy, how evidence is stored, and when it is destroyed.
  • Timing and communication. Test windows, a 24-hour contact path, and how a real incident discovered during the test is handled.

What does a good red team report contain?

A useful report reads like an incident investigation of an attack that did not hurt you. Expect:

  1. An executive summary in business terms: which objectives were reached, how long it took, and whether anyone noticed.
  2. The attack narrative, step by step, with timestamps.
  3. Detection and response findings: at each step, was there an alert, did anyone act, and how long did it take?
  4. Root causes, not just symptoms. "Plaintext passwords in scripts" is a symptom; "no secrets management standard" is a cause.
  5. Prioritised recommendations with owners.
  6. A replay or purple session so defenders can rebuild the missed detections with the testers.

In practice: what a red team report looks like. In February 2023 CISA published the findings of a three-month red team assessment of a large US critical infrastructure organisation, in advisory AA23-059A. The team gained initial access through spearphishing: of seven targeted employees, two followed the lure and ran a file. The organisation "did not detect the red team's activity throughout the assessment", even when the team tried to trigger a response. Findings included a krbtgt account password unchanged in over a decade, standard users with local admin rights on critical servers, and plaintext credentials in scripts. The report also recorded strengths: strong service account passwords, and multifactor authentication that blocked access to one sensitive system. That balance is what good looks like.

In practice: red teaming an AI system. For an example of an AI agent used as the red team against an enterprise chatbot, see the McKinsey Lilli security test.

Going deeper: for security and IT teams

Threat intelligence first. In threat-led schemes, scenarios start from a targeted threat intelligence report on actors relevant to your sector and region. The ECB publishes separate TIBER-EU guidance documents for the targeted threat intelligence report, the red team test plan, the test summary report, the control team and service provider procurement. Under the updated framework, the red teaming phase has two steps: drafting the red team test plan, then active testing. Use the same structure internally even when no regulator is involved: no intelligence, no scenario.

Map everything to ATT&CK. Ask testers to tag each action with a MITRE ATT&CK technique ID. That turns the report into a detection backlog. Techniques that succeeded without an alert become purple team items. AA23-059A did exactly this and recommended that organisations continuously test their defences against the listed techniques.

What red teams commonly reach, from the CISA case. AA23-059A's findings make a useful pre-test checklist: - krbtgt rotation. CISA recommends changing the krbtgt password every 6 to 12 months and after suspected compromise, twice, waiting longer than the maximum ticket lifetime between changes. Forged Kerberos tickets survive one change. - Endpoint management as a tier-0 asset. The team used the device management system to get root access to many machines. Treat MDM, software deployment and remote management consoles as high-value assets with separate admin accounts and monitoring. - Delegation and legacy auth. Remove Unconstrained Delegation where it is not needed, limit NTLM and WDigest, and enable SMB signing. - Secrets in scripts. Search file shares, script repositories and shell history for credentials before the red team does. - Baseline normal activity. CISA's first recommendation was to establish a baseline of normal network activity and tune tools to flag anomalies, focusing on identity and access behaviour.

Purple team method. For each technique: the red side executes it in an agreed window; the blue side records whether telemetry existed, whether an alert fired, and whether a human acted. Score each step as logged, alerted, responded, or none. Fix, then re-run. Keep the evidence. Under the updated TIBER-EU, purple teaming is part of the test itself, not an optional extra.

DORA specifics to plan for. Regulation 2025/1190 requires at least 12 weeks of active testing and at least three scenarios. If you plan to use internal testers, check the staffing rule above early. Where critical functions run on an ICT provider's systems, the provider's cooperation is a dependency for scoping.

Safety controls during the test. Keep a live log of tester actions with timestamps so any real incident can be told apart from the test. Agree a deconfliction phrase. Require testers to avoid destructive actions and denial of service unless explicitly approved. Agree how harvested credentials are protected and destroyed.

Questions for a red team provider. - Who are the named testers, and what is their experience with organisations of our size and sector? - How do you source threat intelligence for scenarios? - How do you protect data and credentials you collect, and when do you destroy them? - Will the report map every step to ATT&CK and say what we detected? - Do you include a replay or purple session, and is it priced in? - What insurance and legal terms cover accidental disruption?

Tie it to incident response. A red team that goes undetected is an incident-response failure as much as a monitoring one. Feed findings into your incident process; the ISO/IEC 27035 guide shows where lessons learned fit.

A red, blue and purple teaming plan for the next year

  1. Confirm who your blue team is and how fast it responds to a high-severity alert.
  2. Run penetration tests on internet-facing systems and fix the findings.
  3. Hold two purple team days on the techniques most used against your sector.
  4. Check whether a regulator expects threat-led testing of you: CBEST, TIBER-EU or DORA TLPT, or SAMA's F.E.E.R.
  5. If you commission a red team, write rules of engagement with named objectives and a small control team.
  6. Ask for a report mapped to ATT&CK with detection outcomes, and book the replay.
  7. Track every finding to closure, then re-test.

Key takeaways

  • A red team simulates a real attacker against business objectives; a blue team defends; a purple team is both working together to fix detections.
  • A red team test is not a penetration test or an audit: it tests the whole organisation's detection and response, not one system's flaws.
  • UK firms may face CBEST; EU financial entities identified under DORA must run threat-led penetration tests at least every three years, with at least 12 weeks of active testing and at least three scenarios; Saudi financial institutions follow SAMA's F.E.E.R.
  • TIBER-EU's February 2025 update made purple teaming mandatory.
  • In CISA's published red team assessment, the organisation did not detect three months of activity. Fix basics such as krbtgt rotation, admin rights and secrets in scripts before paying for a red team.

Sources