A smarter way to measure red team impact

This blog was updated on February 23, 2026.

Red teams play a fundamental role in helping security organizations understand how real-world adversaries think and operate. By simulating attacker behavior, red teams expose hidden weaknesses that may not appear in routine testing and pressure-test the security organization’s ability to detect, respond to, and contain threats. But as red team operations mature, a question inevitably arises: how does the red team measure operations in a way that leads to impactful defensive improvements?

For many security leaders, measuring the value of red teaming remains elusive. What should we test? Is the program meaningfully improving defensive capabilities? Does it accurately represent how your adversaries see the enterprise? Are operations identifying systemic weaknesses or simply generating activity? And perhaps most importantly: What should we measure during Red Team operations that will lead to a measurably improved response to real-world threats?

The reality is that you don’t need perfect data or a sophisticated analytics program to start answering these questions. Effective measurement begins with simple, outcome driven metrics that highlight trends, surface gaps, and guide strategic investments. Over the past several years, the Adobe security red team has built a metrics framework that not only evaluates red team effectiveness but also improves the organization’s ability to disrupt advanced threats.

Here’s how we approached it, and the metrics we found most valuable in enabling our red team to effectively demonstrate its impact to the business.

Start with practical, available data

When we began refining our metrics strategy, we relied on publicly available security incident data to identify baseline trends, such as annual industry breach and incident reports aggregated in open source GitHub repositories. Narrowing the dataset to our own industry offered immediate insights that helped shape our early priorities. Even without highly granular information, these directional trends helped us to determine where adversaries were succeeding and what types of behaviors our team should simulate during initial operations.

The takeaway: You don’t need perfect data to begin measuring outcomes. Start small, iterate, and refine over time.

Focus on metrics that improve blue team performance

After building up the fundamentals of developing metrics, I started looking at the broader red team community’s approach to measurement across the industry. One theme quickly stood out: many commonly used metrics don’t show whether an organization’s defenses are improving. Metrics that simply count the number of red team operations or track how many vulnerabilities were uncovered offer very little actionable insight. In many organizations, vulnerability discovery already belongs to dedicated functions within product security or vulnerability management, so using red team results as a proxy for “number of bugs found” creates noise, not clarity. These types of metrics may look quantitative, but they don’t answer the core question: Are we getting better at stopping real adversaries?

What ultimately proved far more valuable were metrics that measured how effectively the blue team could detect, contain, and eradicate red team activity. These metrics directly map to real attacker behaviors and show whether defensive improvements are translating into meaningful security outcomes.

The most effective measurements I found were those aligned directly to adversary disruption and blue‑team readiness: Time-to-Detection, Time-to-Containment, and Time-to-Eviction.

Three metrics worth measuring during red team operations

During red team operations, we deliberately move through an attack path to demonstrate meaningful risk to the business. Along the way, we independently measure how long it takes the organization to detect, contain, and fully evict the red team in these exercises. While these are traditionally considered blue team metrics, measuring them from the red team’s perspective can also help surface valuable insights, quality recommendations, and measurable defensive improvements. Below, I’ll break down how we take these measurements – and how they help demonstrate red team impact.

Time-to-Detection

Time-to-Detection measures the time gap between when a red team action (known as a red team event) should trigger an alert and when the alert is actually surfaced to incident responders. The goal is simple: minimize the window in which malicious activity goes unnoticed or in some cases undetected altogether. In these cases, we work with the detection engineering team to add or update detection rules and identify gaps in security telemetry or tooling.

This metric is foundational because it validates whether “water is flowing through the pipes” and that alerting mechanisms are working as intended. Time-to-Detection helps uncover:

• Missed alerts
• Telemetry blind spots
• Triage delays

For example, if a red team gains an initial foothold and downloads a second stage payload, the clock starts when the command is executed and stops when an actionable alert is raised. If expected signals are not generated, the metric highlights potential gaps in telemetry or detection coverage and helps prioritize improvements with detection engineering teams.

Time-to-Containment

Time-to-Containment measures how long it takes to stop an adversary from taking any further action after an alert has been triggered. The time begins after an alert arises and ends when a command and control (C2) mechanism is blocked and can no longer take further action, eliminating the attacker’s ability to continue. Unlike Time-to-Detection, which only reflects when a threat is noticed, Time-to-Containment reveals when the attacker is actually prevented from progressing.

In more advanced intrusions, real attackers often install resilient C2 frameworks that allow them to continue interacting with a compromised system even after initial patching or system isolation is done by incident responders. Detecting this activity is only the first step; containment means disabling the attacker’s ability to continue toward their objective.

Measuring Time-to-Containment is particularly valuable because it directly measures how effective an organization is in halting an adversary’s progress and neutralizing their ability to take additional actions. The goal is to reduce the time required to achieve containment and to highlight gaps in:

• Host isolation
• C2 disruption
• Workflow efficiency

Time-to-Eviction

Time-to-Eviction measures how long it takes to fully remove an adversary (after initial alert) from the environment once persistence has been established. The clock begins when the attacker installs the first persistence mechanism, such as a C2 channel, and ends only when all persistence mechanisms, backup C2 paths, and footholds have been identified and eradicated.

During advanced intrusions, an attacker may plant multiple agents across the environment to maintain persistence even if one instance is contained. Once responders isolate or disable one C2 agent, they can analyze it to understand how it operates, identifying the command server’s IP address, collecting file hashes, or extracting other unique indicators. These insights allow responders to hunt for and eradicate additional agents that may be hidden elsewhere in the network. While containment stops an attacker from taking further action, eviction focuses on helping to make sure the attacker cannot reenter or regain access, even when the attacker has deployed multiple persistence mechanisms.

By tracking and working toward reducing Time-to-Eviction, it strengthens the blue team’s ability to thoroughly cleanse the environment, restore full operations, and achieve more long-term resilience.

Why measuring attack complexity matters

After refining these operational metrics, it became clear that results were difficult to compare without accounting for attack sophistication. Measuring basic intrusion and an advanced attack in the same way can skew results, prompting a natural next question:  How can we consistently measure the difficulty of an attack chain itself?

To answer this, we developed Red Team Levels, a composite scoring system that assigns a 1–5 difficulty rating to each stage of an attack chain based on weighted factors such as:

• Type of exploit required (e.g., public exploit vs. zero‑day)
• Tooling sophistication
• Attacker technique mapped to skill level involved
• Time required to achieve the objective

For example, establishing a foothold on the public attack surface may score a  1  if it relies on a trivial public exploit, or a  5  if it requires a complex zero-day. Standardizing difficulty in this way allows teams to:

• Deliver consistent, quantitative recommendations
• Identify systemic weaknesses
• Track improvement across years
• Align red team insights with security investment priorities

This scoring model adds much needed repeatability, helping transform red teaming into a more measurable and scientifically grounded discipline. Over time, Red Team Levels also make it possible to track year-over-year improvement in both adversary resistance and defensive capability.

By having Red Teams independently measure metrics such as Time-to-Detection, Time-to-Containment, and Time-to-Eviction, organizations can gain a stronger foundation for evaluating their defensive effectiveness, communicating meaningful results to the business, and guiding strategic security investments. When combined with a consistent scoring model, these metrics offer a clear, outcome driven view of defensive maturity and help security leaders assess whether their red teaming programs are measurably improving the organization’s ability to disrupt real-world threats.