From Findings to Fixes: Getting Value from Red Team Results
TL;DR: The value of a red team engagement doesn’t end when the report lands. This post covers how to read findings for root cause, prioritize remediation, and build the improvement habit that makes each engagement more valuable than the last.
The engagement is complete. The objectives were well-formed, the report has landed, and the outbrief is done. Now what?
Red team results are evidence about how an attacker could move through your environment, where your organization should have detected or contained them, and what capability needs to improve next. The report is only useful if something happens after it’s read. That sounds obvious, but translating findings into remediation, detection improvements and process change is harder in practice than it looks on paper. Competing priorities, resource constraints, and the sheer volume of findings can make it difficult to know where to start.
This post picks up where our last post left off: after the report lands. In our first post, we covered what a quality red team report should contain: the attack path narrative, root cause findings, and the technical detail needed to support detection engineering. What follows is about what to do with it. The organizations that improve year over year treat results as an opportunity to act on, not a box to check. Getting there requires understanding what quality findings should contain, how to read them for detection and response improvement, and how to close the loop from report to remediation.
What quality findings should tell you
Not all red team findings are created equal: the difference between a useful finding and a checkbox finding usually comes down to depth.
Consider two ways of documenting the same event:
- Surface-level: “The red team extracted Domain Administrator credentials from LSASS on a compromised workstation and used a privileged synchronized identity to access Entra ID and Azure resources.”
Root cause:
- Description: “Privileged Entra ID directory roles and Azure RBAC roles were assigned to identities whose credentials and lifecycle were controlled by on-premises Active Directory, allowing compromise of the on-premises identity environment to provide privileged access to cloud resources.”
- Impact: “This creates a path by which an attacker who compromises an appropriately privileged on-premises identity can gain administrative access to Entra ID or Azure without first compromising cloud infrastructure. The resulting impact depends on the assigned role and may include control of the Entra ID tenant, Azure subscriptions, or critical cloud resources. During the assessment, SpecterOps demonstrated this attack path by obtaining credentials for an on-premises privileged identity and using the identity’s cloud role assignments to access Azure resources.”
The surface-level finding tells you what happened. The root cause finding tells you why it was possible, what an attacker could do with it, and what SpecterOps demonstrated during the engagement. A complete finding also includes remediation guidance.
The inverse is worth calling out. Red team findings carry the most weight when they are grounded in demonstrated impact: something the team actually achieved, not just a theoretical weakness they identified. A finding that identifies a theoretical weakness without proving it was exploitable is harder to prioritize, regardless of how it’s classified. Remediation bandwidth is finite, and findings that show what an attacker could actually do in your environment should take priority.
Reading attack path narratives
A detailed attack path narrative is a map of detection opportunities and a window into how an attacker thinks. SpecterOps designs narratives to demystify adversary tradecraft, to show not just what happened, but why each technique was chosen and how the attack path was constructed. That level of detail is what allows defenders to extract that logic and apply it beyond the specific findings in the report.
Quality narratives walk through each step of the attack chain: initial access, discovery, lateral movement, privilege escalation, and objective completion, with timestamps and technical detail at each step. That documentation gives defenders the raw material to cross-reference against their own logs after the engagement. Where deconflictions were communicated during the assessment, those are captured separately. Where they weren’t, the narrative gives defenders a starting point to find out.
For example, a narrative could note that at 14:23, an operator identified a synced on-premises account with an Entra ID directory role assignment and used it to access the Entra tenant. The red team continued operating without interruption. When a defender reads that entry and checks the logs, the questions become concrete: was telemetry being collected for that access? Was a detection rule missing or misconfigured? Was an alert generated but not investigated? Each answer points to a specific fix.
As we covered in our first post in this series, a red team report should include chronological timelines, timestamps, and indicators of compromise. The narrative is where that detail lives.
Beyond detection gap analysis, narratives support two other uses. If the organization detected activity at some point, the narrative shows how long it took. A 72-hour gap between attacker action and SOC awareness tells you something specific about where the response process broke down and gives the team a concrete target for improvement. The indicators and techniques documented in the narrative also support historical threat hunting. If the red team used a technique that went undetected, the question worth asking is whether a real attacker used the same method before the engagement began.
Prioritizing remediation
Not every finding needs immediate action. Organizations frequently stall after an engagement when they attempt to treat each issue as urgent. According to the 2026 Trends in Identity Attack Path Management Report, 41% of respondents said that difficulty prioritizing attack paths is their primary challenge when implementing management processes. The problem is not the total number of findings, but deciding where to start.
Effective prioritization is based on three factors:
- Severity of potential impact. Consider what an attacker could achieve by using a specific path. This includes gaining access to sensitive data, causing business disruptions, or creating regulatory exposure. A path that leads to customer data or financial systems and requires no special tooling or insider knowledge warrants a different response timeline than a complex chain that reaches a low-value internal system.
- Detection coverage. Determine if there is visibility into the attack path. A path that is both exploitable and invisible to the SOC is the highest-priority combination; it means an attacker could move through the environment without generating a single alert.
- Remediation complexity. Some fixes are simple, such as changing a configuration or removing a permission. Other fixes require structural changes like new tools, process redesigns, or architectural shifts. A configuration change that closes a high-severity path in a day is worth doing even while a longer structural fix is being scoped. Quick wins maintain momentum without displacing the harder work.
When an engagement surfaces more than the organization expected, the volume of findings can feel overwhelming. Start with what carries the most risk and build from there.
Closing the detection loop
Findings document vulnerabilities and inform remediation. A finding tells you what to fix. It doesn’t tell detection engineers how an attacker moved through the environment to get there.
Attack path narratives inform detection. The narrative is where the tradecraft lives: how credentials were extracted, how lateral movement occurred, what techniques enabled privilege escalation, and what the attacker did at each step. That level of detail is what gives detection engineers something actionable. The goal is to build detection for the underlying technique that would catch any attacker using similar methods rather than writing a signature for the exact tool the red team used.
For each step in the attack path narrative, detection engineers should be asking: what telemetry should have been generated, is that telemetry being collected, and what detection would catch this technique and its variations?
Validating that new detections fire is a separate step, and one most organizations skip. As we covered in our second post, purple team assessment is built for that: testing detection coverage against multiple variations of a technique to confirm it holds.
Communicating findings to leadership
The frame that works for executive audiences is business impact. Consider the root cause finding from earlier in this post: ‘Privileged cloud roles were assigned to identities synced from on-premises Active Directory, removing the trust boundary between environments.’ For a technical audience, that’s a clear and actionable description. For a board or executive team, the relevant version is: ‘An attacker who compromised one of your privileged on-premises accounts could have gained administrative control over your cloud environment without being detected.’ Same finding, different frame.
What to emphasize in executive communication:
- Business impact: What could an attacker have achieved? Access to customer data, financial systems, or intellectual property? And how does this affect the organization’s ability to operate, and what consequences does this access have?
- Detection reality: Did we know this was happening? If not, why not?
- Remediation path: What will it take to fix, and what is the priority?
- Progress over time: How do these results compare to previous engagements?
The framing that tends to work focuses on improvement rather than failure. Red team findings reveal gaps because that is the purpose of the engagement. Leadership should understand that findings indicate the engagement worked. The goal is to build support for remediation investment. And, they are more likely to invest in remediation when the conversation leads with what was learned and what comes next, rather than relitigating how the gaps got there.
Building the improvement habit
The organizations that get the most from red teaming over time share a common trait: they are genuinely open to what the findings reveal. When an engagement surfaces more than expected, that’s a clearer picture of where the program stands, not a problem to manage.
The alternative is more costly than it appears. Organizations that dismiss findings, minimize their significance, or accept risk without fully understanding it tend to see the same issues resurface, either in the next engagement or in an actual incident. The difference is that an incident doesn’t come with a debrief.
Engagements measure capability, but measurement only compounds if something changes between engagements. Findings should enter the remediation workflow with assigned owners and be tracked to completion. Detection gaps should enter the detection engineering backlog. Process issues should trigger process improvement efforts.
When previous findings have been addressed, confirming that identified gaps were closed is worth doing before the next full engagement. Some organizations do this through a focused remediation test. Others wait and let the next engagement validate whether improvements held while surfacing the next layer of gaps. That compounding of improvement, whether confirming fixes, surfacing new gaps, or testing detection posture, is what makes each engagement more valuable than the last, and what this series has been building toward.
The environment doesn’t stay still between engagements either. New systems get deployed, architectures change, and AI applications get added to the stack. Enterprise AI adoption is accelerating, and with it the attack surface. Each new deployment introduces surface area and assumptions that haven’t been tested yet, and the risk can grow faster than a security program’s ability to keep pace. As we explored in our third post, turning those assumptions into answerable objectives is how the improvement habit stays calibrated to what the organization is running today. That includes AI application assessments, where the attack path narrative still maps detection opportunities but the telemetry sources and detection surface are different. Model infrastructure access, retrieval pipeline queries, and lateral movement from AI-supporting systems generate different indicators than traditional attack paths, and most organizations haven’t built detection for them yet. We’ll be exploring this on September 17 in our How AI Changes Red Teaming webinar with my SpecterOps colleagues Andrew Chiles and Adam Chester.
From report to improvement
The report is where the engagement ends. What happens next is where security programs either improve or repeat the same findings a year later. This series has been building toward that distinction. In our first post, we established what red teaming is designed to measure and why engagements start from assumed breach. In our second, we made the case for practicing response before an incident forces the issue. And in our third, we covered how well-formed objectives shape what an engagement can answer. Finally, we discussed what happens after: how findings drive action, how action produces improvement, and how each engagement builds on the last.
Organizations that run this cycle well don’t just get better findings over time. They build security programs that stay calibrated to what they’re running and what adversaries would actually do. That’s what red teaming is for.
