What Is Red Teaming? How a Red Team Assessment Works

Red teaming is an authorized, objective-based simulation of a real adversary. Instead of listing every vulnerability in a fixed scope, a red team agrees on goals that matter to the business, such as reaching a payment system or a domain administrator account, then pursues them with the tactics a likely attacker would use, usually without warning the defenders. The result shows whether your people, processes and technology can prevent, detect and respond to a determined attack, and which specific gaps let the team through. A good assessment ends with a report, a debrief and a purple-team replay.

What Is Red Teaming in Cybersecurity?

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 organization's security posture, with the aim of improving security by demonstrating the impact of successful attacks and what works for the defenders. That definition, published in the NIST CSRC glossary, contains the three ideas that separate red teaming from other security testing:

• Authorized. Leadership approves the exercise in writing, sets boundaries and keeps a way to stop it at any moment.
• Adversary emulation. The team behaves like a specific, plausible attacker rather than running every test it knows.
• Defender-focused outcome. Success is measured by what the organization learns about its detection and response, not by the number of findings.

In practice, a red team assessment (also called a red team exercise or red team engagement) starts from a scenario. Someone decides who the attacker is, how they are likely to get in and what they want. The red team then has a fixed window to reach those objectives, often called flags or crown jewels, while the security operations center (SOC) and incident responders work as they normally would. Only a small control group, sometimes called the white team or control team, knows the test is running.

Why is it called a red team?

The term comes from US military and defense war-gaming in the early 1960s, when RAND Corporation simulations used red to represent the Soviet Union and blue to represent the United States, according to the Wikipedia entry on red teams. Security adopted the same colors: the red team attacks, the blue team defends and a purple team describes the two working together. Our guide to red team vs blue team in cybersecurity covers the roles of each team in more detail.

Red Teaming vs Penetration Testing

Red teaming and penetration testing use many of the same skills, and the same testers often do both. The difference is the question each one answers. A penetration test asks, "What exploitable weaknesses exist in this scope?" A red team asks, "Can a realistic attacker reach this objective before we notice and stop them?"

Neither test is better in general. A penetration test is the right tool for finding and fixing weaknesses in a specific system before release or for a compliance requirement. A red team is the right tool once the basics are under control and you need to know whether your monitoring and response would catch a real intrusion. For the full picture of how a scoped test works, see what penetration testing is and our penetration testing methodology guide.

Two adjacent practices are often confused with red teaming:

• Purple teaming is a collaborative exercise in which attackers and defenders work side by side, run techniques openly and tune detections in real time. It usually follows a red team engagement rather than replacing it.
• Automated or continuous red teaming platforms run scripted attack techniques on a schedule. They help with regression testing of known techniques, but they do not replace a human team that adapts to your environment and makes judgment calls.

Objectives, Threat Profiles and Rules of Engagement

A red team engagement lives or dies on its planning documents. Three decisions shape everything that follows.

1. The objectives. Objectives should describe business impact, not technical tricks. "Obtain domain administrator rights" is a milestone; "Approve a fraudulent payment in the treasury system" or "Read the board's mergers and acquisitions folder" is an objective a business leader understands. Most engagements set two to four objectives tied to critical systems or data.

2. The threat profile. The scenario names a realistic adversary: a financially motivated ransomware affiliate, a state-aligned group targeting your sector, a compromised supplier or a malicious insider. Threat intelligence about that actor's known behavior decides which entry points and techniques the team will use, which keeps the test grounded in real risk instead of the testers' favorite tools.

3. The rules of engagement (ROE). The ROE is the signed agreement that makes the exercise safe and legal. It should answer at least the following questions.

The deconfliction and stop conditions matter more than they appear. If the SOC escalates a real incident during the test, the control team must be able to confirm within minutes whether the activity is the red team, so a genuine attack is never dismissed as "just the exercise."

How a Red Team Assessment Works: The Seven Phases

Every provider names its phases differently, but a well-run engagement moves through the same seven stages. The descriptions below explain what happens and what each stage tells defenders. They are deliberately non-operational: the specific techniques depend on the agreed threat profile and must stay inside the ROE.

1. Planning and threat intelligence

The control team and the red team agree on objectives, the threat profile, the ROE and the timeline. Threat intelligence on the chosen adversary feeds attack scenarios, and the organization's critical systems are mapped to flags. In regulated programs such as TIBER-EU, a separate threat intelligence provider writes a targeted threat intelligence report before testing begins.

• Defender question answered: Are we testing against the threats that actually matter to us?
• Outputs: Signed ROE, scenario descriptions, flag list, test plan and contact sheet.

2. Reconnaissance

The team gathers information the way a real attacker would: public employee data, exposed services, domain records, leaked credentials, technology stack clues and third-party relationships. Much of this is passive and leaves no trace on your systems.

• Defender question answered: How much does our public footprint give away? This stage often produces quick wins for attack surface management on its own.
• Outputs: Target map, candidate entry points and pretexts for social engineering, all kept within scope.

3. Initial access

The team attempts to gain a first foothold using the entry vectors the scenario allows. Common routes include phishing or other social engineering, exploitation of an internet-facing application or VPN, abuse of weak or reused credentials and, when approved, physical or wireless access. If a full external breach is not the point, the engagement may start from an assumed breach, where the control team provides a foothold that simulates a compromised laptop or account.

When the goal is to test people and processes rather than reach a business objective, a scoped social engineering penetration test is the better fit.

• Defender question answered: Do email security, perimeter controls, identity protections and user reporting stop or flag the first move?
• Outputs: Evidence of each attempt, successful or blocked, with timestamps.

4. Persistence, privilege escalation and lateral movement

From the foothold, the team tries to keep access, gain higher privileges and move toward the systems that hold the objectives. This is where identity weaknesses, flat networks, exposed credentials and over-permissive trust relationships usually show up. The team moves deliberately and quietly, because the point is to measure whether endpoint detection, identity monitoring and the SOC notice it.

• Defender question answered: Would we see an intruder inside the network, and how long would it take?
• Outputs: An attack path showing each hop, the technique used and whether any alert fired.

5. Objective execution

The team attempts to reach each flag and prove it, for example by reading a marker file in a restricted share, creating a harmless record in a financial system or taking a screenshot of an administrative console. Proof should demonstrate impact without causing it: no real payments, no destructive actions and no bulk copying of sensitive data.

• Defender question answered: If an attacker got this far, what could they actually do to the business?
• Outputs: Flag evidence and a timeline of the full kill chain.

6. Reporting

The report should read as a story, not a list. It explains the scenario, the path the team took, every point where defenders had a chance to detect or stop the attack, what they saw and what they missed. Technical appendices give reproducible evidence and fixes. A strong red team report includes:

• an executive summary written for leadership, tied to the objectives;
• an attack narrative with a timeline and each step mapped to MITRE ATT&CK;
• a detection and response timeline: what was logged, what alerted, what was investigated;
• control gaps grouped by people, process and technology;
• prioritized remediation and the evidence needed to show each fix works.

Our penetration testing report guide covers report structure, severity and evidence standards that also apply here.

7. Debrief and purple-team replay

The most valuable hours of a red team often come after it ends. In a replay, the red team walks the blue team through the attack step by step, so defenders can find the logs and telemetry they missed. In the purple-team session that follows, both teams rerun selected techniques in the open, tune detections and confirm that new alerts fire. TIBER-EU now makes this purple-team step mandatory, and many organizations treat it as the point where the investment turns into lasting detection improvements.

Our purple teaming guide shows how to plan and score that session.

Many teams replay the red team's attack path as a tabletop exercise for executives.

• Defender question answered: Can we now detect and stop the techniques that worked?
• Outputs: Tuned detections, a remediation plan with owners and dates, and a retest plan.

Mapping Red Team Activity to MITRE ATT&CK

MITRE ATT&CK is the shared vocabulary that makes red team results comparable and actionable. MITRE describes it as a knowledge base of adversary tactics and techniques based on real-world observations. As of ATT&CK v20, released on October 13, 2026, the Enterprise matrix lists 15 tactics, from Reconnaissance (TA0043) and Initial Access (TA0001) through Lateral Movement (TA0008), Exfiltration (TA0010) and Impact (TA0040). Older guides refer to TA0005 as Defense Evasion; the current matrix names TA0005 Stealth and lists Defense Impairment (TA0112) as a separate tactic, so check which version a report uses before comparing results.

ATT&CK helps a red team engagement in three places:

1. Planning. Threat intelligence about the chosen adversary lists the techniques that actor is known to use. The red team builds its scenario from those techniques, which keeps the test realistic. MITRE's Center for Threat-Informed Defense publishes full adversary emulation plans on GitHub that show how this works for specific groups.
2. Reporting. Each action in the attack narrative is tagged with its technique ID, so defenders can search their own data for the same behavior and compare results across tests.
3. Follow-up. After remediation, teams can rerun individual techniques with open-source frameworks such as MITRE Caldera or Atomic Red Team in a lab or approved test window, to check that new detections work. These tools support regression testing; they do not replace a human red team.

For a side-by-side look at Cobalt Strike, Sliver, Mythic, Havoc, Caldera and Atomic Red Team, see our comparison of red team and C2 tools.

A simple way to turn ATT&CK mapping into a decision tool is to score each technique the team used on a four-level outcome. The table below is an illustrative example, not data from a real engagement.

Read across a table like this and the priorities become obvious: the organization had telemetry for two steps, but only one alert was investigated, and nothing watched credential use or remote logons. Those gaps, not the individual vulnerabilities, are what a red team is designed to expose.

What Real Red Team Assessments Find

Public red team results are rare, but the US Cybersecurity and Infrastructure Security Agency (CISA) has published two detailed advisories that show what these assessments reveal.

In advisory AA23-059A, published February 28, 2023, CISA described a three-month red team assessment of a large critical infrastructure organization. The team gained initial access through spearphishing, compromised the domain and reached systems adjacent to sensitive business systems. CISA reported that the organization did not detect the red team's activity during the assessment, even when the team tried to trigger a response. Contributing issues included plaintext credentials in scripts and backups, standard users with local administrator rights on critical servers and a domain key account password that had not been changed in over a decade.

In advisory AA24-193A, published July 11, 2024, CISA described a no-notice assessment of a federal civilian agency that ran for about eight months in 2023, including three months of collaboration with defenders. The team entered through an unpatched public-facing web server and through phishing, then reached full domain compromise. CISA highlighted weak segmentation, unrestricted outbound traffic, unmanaged service accounts and a detection approach that relied on known indicators of compromise, which let the team's varied tools and behaviors go largely unnoticed.

Both advisories map the activity to MITRE ATT&CK and recommend continuously testing security controls against those techniques. The lesson for any organization is the same: vulnerabilities opened the door, but missing detection, weak identity hygiene and flat networks decided how far the attacker got.

TIBER-EU and DORA Threat-Led Penetration Testing

In the European financial sector, red teaming is regulated. The EU Digital Operational Resilience Act (DORA) requires financial entities designated by their authorities to carry out threat-led penetration testing (TLPT) at least every three years. Under Article 26, each TLPT covers several or all critical or important functions and runs on live production systems. When an entity uses internal testers, it must contract external testers every third test. The detailed rules sit in the TLPT regulatory technical standards, Commission Delegated Regulation (EU) 2025/1190.

The European Central Bank's TIBER-EU framework is the reference method for this kind of intelligence-led red teaming. The Eurosystem published an update on February 11, 2025, aligning TIBER-EU with the DORA TLPT standards, making purple teaming mandatory and renaming the white team the control team. The January 2025 framework document sets out a structure worth copying even outside regulated testing:

Two details from TIBER-EU are useful for any red team program. First, the framework notes that, because of the resources and costs involved, tests are not expected too often, with three-year intervals as the norm. Second, the red team report must record flags reached and not reached, attack paths and TTPs that worked and failed, deviations from the plan and any leg-ups granted. That is a strong template for any red team report. For the full framework walkthrough, read our guide to the TIBER-EU framework, and for who must comply and how, see DORA penetration testing and TLPT requirements.

Common Types of Red Team Engagements

Not every organization needs a full-scope, multi-month campaign. The engagement type should match the question you want answered.

For AI models, agents and LLM applications, see our LLM and AI penetration testing service.

An assumed-breach engagement is often the most efficient first red team for organizations with mature perimeter controls, because the hardest and most uncertain step, initial access, is replaced by a realistic starting point and the testing time goes into the internal detection questions that matter most.

What Drives the Cost of a Red Team Assessment

Red team pricing is almost always quoted per engagement, and the range is wide because the work varies so much. Rather than a price list, these are the factors that move the scope and effort up or down. Use them to compare proposals on a like-for-like basis.

• Length of the active testing window. Stealthy campaigns take longer than noisy ones. A regulated TLPT requires at least 12 weeks of active testing, which is far longer than most commercial engagements.
• Number of objectives and scenarios. Each additional flag or threat scenario adds planning, testing and reporting time.
• Starting point. A full-scope external breach costs more effort than an assumed-breach engagement with a provided foothold.
• Attack surface and vectors. Adding social engineering, physical intrusion, wireless, multiple offices, cloud tenants or operational technology increases the work and the risk controls needed.
• Threat intelligence depth. A bespoke targeted threat intelligence report on your sector and adversaries is a separate piece of work from a generic scenario.
• Stealth and detection evasion expectations. Emulating a sophisticated adversary that must stay undetected for weeks requires more senior operators and more custom preparation than a test that accepts being caught.
• Team seniority and custom tooling. Experienced operators and purpose-built infrastructure cost more than commodity testing, and they are what makes a red team realistic.
• Purple teaming, replay and retesting. Collaborative replay sessions and retests of fixed issues add time but deliver most of the long-term value.
• Regulatory and reporting overhead. TLPT and TIBER-EU tests carry fixed deliverables, control team meetings and authority reviews.
• Travel and on-site work. Physical testing across several locations adds logistics.

When comparing quotes, ask each provider which of these factors its proposal assumes. Two proposals with very different totals often describe very different engagements. For broader context on how security testing is priced, see our guide to penetration testing cost, and for how to compare providers, our list of red team service providers.

When to Choose Red Teaming Over a Penetration Test

Red teaming delivers the most value once an organization can act on what it finds. Running one too early usually produces a long list of basic issues that a penetration test would have found faster and for less effort.

Use this readiness check before commissioning a red team. If you answer "no" to several questions, start with penetration testing and fix the basics first.

1. Have your critical systems had recent penetration tests, with high-severity findings fixed and retested?
2. Do you have a SOC, managed detection and response service or on-call team that monitors alerts every day?
3. Is endpoint detection deployed on most workstations and servers, with logs retained long enough to investigate?
4. Do you have an incident response plan that people have practiced?
5. Can leadership name the two to four systems or data sets whose compromise would hurt the business most?
6. Is there an executive sponsor who will fund remediation of what the red team finds?

Many organizations combine the two: annual penetration tests on critical applications and infrastructure, and a red team every one to three years to check that detection and response keep pace. A clear penetration testing scope helps decide which assets belong in which test.

Frequently Asked Questions

What is the main purpose of red teaming?

The main purpose is to test whether an organization can prevent, detect and respond to a realistic attack on the things that matter most. A red team measures the whole defense, including people and processes, rather than producing a complete list of vulnerabilities.

How long does a red team assessment take?

It depends on objectives, scope and stealth. Commercial engagements commonly run for several weeks to a few months. The two CISA assessments described above ran for about three months and about eight months. Under TIBER-EU, active red team testing alone lasts at least 12 weeks, plus preparation and closure.

Is red teaming legal?

Yes, when it is authorized. A red team works under signed rules of engagement from someone with the authority to approve testing of the systems, people and premises involved, plus any required permission from third-party providers. Without that authorization, the same actions would be illegal.

Does the blue team know about a red team exercise?

Usually not. Only a small control team knows about the test, so the SOC and responders react as they would to a real incident. The control team handles deconfliction and can stop the test if needed.

What is the difference between red teaming and purple teaming?

Red teaming is a covert test of defenses. Purple teaming is an open, collaborative session where the red and blue teams run techniques together and tune detections in real time. Purple teaming usually follows a red team engagement to turn its findings into working detections.

Does red teaming replace penetration testing?

No. Penetration tests find and fix weaknesses across a defined scope; red teams test detection and response against a realistic attacker. Most mature programs run both, with penetration tests more often and red teams less often.

What is AI red teaming?

AI red teaming applies the same adversarial approach to AI models, agents and the applications built on them. It tests for issues such as prompt injection, sensitive data leakage and unsafe autonomous actions, and it complements, rather than replaces, testing of the surrounding infrastructure.

Our AI red teaming guide walks through the full method, from harm taxonomy to regression testing.

Next Step: Plan a Red Team Engagement That Answers a Real Question

Red teaming is worth the effort when it is built around clear objectives, a realistic threat profile and rules of engagement that keep production safe, and when it ends with a replay that turns missed detections into working ones. If your controls are mature and you want to know whether your team would catch a capable attacker, start by writing down the objectives and the adversary you are most worried about.

DeepStrike's red teaming services cover objective-driven campaigns across people, identity, cloud, applications and internal networks, with detection validation and a debrief that prioritizes fixes. To discuss scope, objectives and rules of engagement, contact DeepStrike.

About The Author

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

Sources and References

• NIST CSRC Glossary: red team (CNSSI 4009-2022)
• MITRE ATT&CK
• MITRE ATT&CK: Enterprise tactics
• MITRE ATT&CK: Updates (v20, October 13, 2026)
• MITRE Center for Threat-Informed Defense: Adversary Emulation Library
• MITRE Caldera
• Atomic Red Team
• CISA Advisory AA23-059A: CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks
• CISA Advisory AA24-193A: CISA Red Team's Operations Against a Federal Civilian Executive Branch Organization Highlights the Necessity of Defense-in-Depth
• Regulation (EU) 2022/2554 (DORA)
• Commission Delegated Regulation (EU) 2025/1190 (TLPT RTS)
• European Central Bank: TIBER-EU
• European Central Bank: TIBER-EU Framework (January 2025)
• ECB news: Eurosystem updates TIBER-EU framework (February 11, 2025)
• Wikipedia: Red team