What Makes a Good Red Team?

When people talk about red team capability, the conversation almost always starts with technical execution.

Can the team bypass EDR?

Can it compromise Active Directory?

Can it identify cloud privilege escalation paths?

Can it reach high-value assets without being detected?

Can it emulate real-world threat actors?

These are not unreasonable questions.

A red team's purpose is to evaluate an organization's security posture from an adversarial perspective. A team that lacks offensive capability cannot effectively validate defensive controls, detection logic, or incident response procedures.

Technical capability is a prerequisite.

But it is not the entire story.

Recently, while revisiting the Red Team Capability Maturity Model (Red Team CMM), I found myself returning to a question that many organizations rarely ask:

Is a skilled red team the same thing as a good red team?

The answer, in my view, is no.

The two frequently overlap, but they are not synonymous.

A skilled red team can compromise systems.

A good red team improves organizations.

The distinction matters more than most people realize.

The Trap of Technical Success

The security industry tends to evaluate red teams through technical outcomes.

Did they obtain Domain Admin?

Did they bypass EDR?

Did they evade the SOC?

Did they reach the objective?

Did they successfully emulate a threat actor?

All of these outcomes are valuable.

A red team that cannot execute realistic attacks cannot provide meaningful validation of an organization's defenses.

However, technical success and organizational success are not the same thing.

Consider a hypothetical scenario.

A red team conducts a multi-week operation.

The operators gain initial access, escalate privileges, move laterally across the environment, and eventually obtain Domain Admin privileges. They reach critical assets. The SOC fails to detect meaningful portions of the attack chain.

The engagement is considered a success.

The report is delivered.

The project ends.

Twelve months later, a real threat actor compromises the organization using nearly the same attack path.

The same initial access vector.

The same privilege escalation technique.

The same detection gaps.

Was the red team engagement successful?

From an offensive perspective, absolutely.

The team demonstrated compromise.

The operators achieved their objectives.

The attack chain worked.

From an organizational perspective, however, the answer is less clear.

The engagement identified weaknesses, but the organization did not meaningfully improve.

The same doors remained open.

The same blind spots remained unaddressed.

The red team demonstrated that compromise was possible, but failed to make future compromise more difficult.

This is where the distinction between a skilled red team and a good red team begins to emerge.

Defining Red Teaming

Before discussing maturity, it is worth clarifying terminology.

Security practitioners frequently use several adjacent concepts interchangeably, even though they serve different purposes.

A Vulnerability Assessment identifies weaknesses across a broad scope. Coverage is prioritized over depth.

A Penetration Test demonstrates exploitability and impact within a defined scope. Its primary output is evidence of compromise.

A Red Team Engagement evaluates an organization's ability to prevent, detect, and respond to realistic attacks. Its primary output is not a vulnerability list but a validation of organizational security assumptions.

Adversary Emulation focuses on reproducing the known tactics, techniques, and procedures (TTPs) of a specific threat actor.

Purple Teaming is a collaborative process in which offensive and defensive teams work together to improve detection and response capabilities.

This distinction is important.

The primary output of a penetration test is often a vulnerability.

The primary output of a red team exercise is an assessment of organizational resilience.

The value of a red team engagement is not that it got in.

The value is understanding what worked, what failed, what was detected, and what remained invisible.

Once that distinction is accepted, it becomes difficult to argue that technical capability alone is an adequate measure of red team maturity.

What Red Team CMM Actually Measures

This is precisely where the Red Team Capability Maturity Model becomes interesting.

At first glance, many practitioners expect a red team maturity model to focus primarily on offensive capability.

Exploit development.

Malware engineering.

EDR bypasses.

Operational security.

Cloud attack expertise.

Adversary emulation.

Instead, Red Team CMM organizes maturity across four broader domains:

Program
Process
People
Technology

Within those domains are categories such as:

Planning
Authorization
Documentation
Reporting
Findings Management
Metrics
Knowledge Sharing
CTI Integration
Leadership Relationships

Many of these areas have little to do with offensive tradecraft.

Instead, they focus on sustainability, organizational influence, governance, and measurable improvement.

Initially, this may seem surprising.

In reality, it aligns closely with how mature threat-led testing frameworks operate today.

CBEST in the United Kingdom.

TIBER-EU across Europe.

Threat-Led Penetration Testing (TLPT) under DORA.

All of these frameworks share a common philosophy:

Red teaming is not an event.

It is a program.

The objective is not compromise.

The objective is resilience.

The goal is not proving that a breach is possible.

The goal is improving the organization's ability to withstand future attacks.

Seen through that lens, the structure of Red Team CMM becomes much easier to understand.

Program: Red Teaming as a Continuous Function

The Program domain is arguably the most important component of the model.

Many organizations treat red teaming as a series of isolated projects.

A scope is defined.

An engagement is conducted.

A report is delivered.

The team moves on.

This model creates activity but rarely creates cumulative improvement.

Mature programs operate differently.

Immature red teams ask:

What should we attack next?

Mature red teams ask:

Which assumptions should we validate next?

The difference is subtle but important.

One focuses on offensive opportunities.

The other focuses on organizational risk.

For example, an organization may assume:

MFA adequately protects user accounts
Cloud environments are properly segmented
SaaS applications are securely configured
Detection logic is sufficient
AI systems are isolated from sensitive data

A mature red team designs operations specifically to validate these assumptions.

This shift becomes increasingly important as attack surfaces evolve.

Modern attack paths increasingly traverse:

Identity providers
Cloud control planes
SaaS ecosystems
CI/CD pipelines
Source code repositories
AI-enabled workflows

The most valuable red team programs are not built around the latest offensive techniques.

They are built around the organization's most important risks.

Process: Repeatable and Explainable Operations

Red teaming has historically been highly dependent on individual expertise.

Many teams possess institutional knowledge that exists only inside the heads of a few operators.

This creates risk.

If knowledge cannot be transferred, it cannot scale.

If it cannot scale, it cannot mature.

The Process domain addresses this problem.

Planning.

Authorization.

Documentation.

Reporting.

Findings Management.

These categories may appear administrative at first glance.

In reality, they are foundational.

A good red team is not merely capable of executing attacks.

It is capable of explaining them.

Why did the attack succeed?

Why did it fail?

Which controls were bypassed?

Which controls worked as intended?

Where were the detection opportunities?

Which ATT&CK techniques were observed?

What evidence supports the conclusion?

Immature red teams produce screenshots.

Mature red teams produce narratives.

They describe attack paths, detection opportunities, defensive failures, and actionable recommendations.

Most importantly, mature teams ensure that findings become part of an improvement process rather than remaining trapped inside a PDF report.

People: Good Red Teams Do Not Operate Alone

The People domain may be the most underrated part of Red Team CMM.

The model explicitly evaluates relationships with:

Incident Responders
Threat Hunters
Detection Engineers
Security Engineers
Architects
CTI Teams
Leadership
Legal
GRC

This often surprises practitioners.

Why should relationships with Legal or Leadership matter when assessing red team maturity?

Because organizational change requires organizational influence.

Finding a detection gap is easy.

Getting the gap fixed is harder.

Identifying architectural weaknesses is easy.

Changing architecture is difficult.

Producing a report is easy.

Driving investment decisions is not.

Good red teams accumulate organizational credibility.

Detection engineers trust their findings.

Architects seek their input.

Executives consider their recommendations.

GRC teams incorporate their results into risk management processes.

This influence is often more valuable than technical capability alone.

Technical credibility gets a red team invited into a conversation.

Organizational credibility is what allows it to influence decisions.

Technology: The Most Visible but Least Important Domain

Technology is often what practitioners notice first.

Tooling.

Infrastructure.

C2 frameworks.

Automation.

Custom payloads.

EDR bypasses.

All of these matter.

Effective offensive operations require effective tools.

However, Red Team CMM treats technology as an enabling capability rather than the primary measure of maturity.

This distinction is important.

Many teams become obsessed with tooling.

Building new C2 frameworks.

Developing novel loaders.

Creating increasingly sophisticated bypass techniques.

These activities can be valuable.

But tooling does not improve security outcomes by itself.

Technology should support the program.

It should support the process.

It should support people.

When technology becomes the objective rather than the mechanism, maturity stagnates.

Metrics: Proving Value Beyond Domain Admin

Perhaps the most overlooked maturity indicator is measurement.

Immature red teams prove value through anecdotes.

"We obtained Domain Admin."

"We bypassed the EDR."

"We remained undetected."

These statements describe events.

They do not describe progress.

Domain Admin is not a KPI.

It is a data point.

Mature teams evaluate trends:

Detection coverage over time
ATT&CK technique visibility
Mean Time to Detect (MTTD)
Mean Time to Respond (MTTR)
Finding remediation rates
Finding recurrence rates
Retest success rates
Improvements in cloud, SaaS, and identity visibility

The question shifts from:

Did we compromise the environment?

to:

Is the organization becoming harder to compromise?

That is a fundamentally different measurement problem.

And it is ultimately the one that matters.

So What Makes a Good Red Team?

Red Team CMM leads to a simple conclusion.

A good red team is not defined solely by its ability to compromise systems.

Offensive capability is necessary.

It is not sufficient.

Good red teams validate assumptions.

They identify realistic attack paths.

They expose blind spots.

They improve defensive capabilities.

They influence decision-making.

They create measurable organizational change.

Most importantly, they make future compromise more difficult than it was before.

Red teams are offensive organizations.

But offense is not the objective.

Offense is the mechanism.

The objective is improvement.

Conclusion

Red teaming will always be a technical discipline.

New attack techniques will emerge.

New defensive technologies will appear.

The technical arms race will continue.

But Red Team CMM highlights something many practitioners eventually discover through experience:

The factors that make a red team effective extend far beyond offensive tradecraft.

Program.

Process.

People.

Technology.

Metrics.

Together, these domains point toward a single idea.

Red teams should not be evaluated solely by what they can compromise.

They should be evaluated by what they help organizations become.

A skilled red team compromises systems.

A good red team improves organizations.

References

Red Team Capability Maturity Model — redteammaturity.com
CBEST — Bank of England
TIBER-EU — European Central Bank, 2018
DORA TLPT — EU Digital Operational Resilience Act