Red Team Report Template 2026: Structure, Findings & Executive Summary

A red team report is the only thing that survives the engagement. The access you got, the shells you dropped, the domain admin you owned — none of it matters if the report doesn’t communicate it clearly to the people who need to act on it.

Most red team reports fail in one of two ways: they’re written for other red teamers (and executives ignore them), or they’re dumbed down for executives (and the technical team can’t remediate). A good report speaks to both audiences at once.

This guide gives you the full template — structure, section-by-section breakdown, finding format, executive summary formula, and the language that actually moves organizations to fix things.

Why Most Red Team Reports Miss

A few patterns I see constantly:

Too technical, top to bottom. The executive summary is three pages of CVE IDs and exploit chains. The CISO reads the first paragraph, skims the rest, and asks their team to “handle it.” Nothing gets prioritized.

Too vague at the finding level. “The system was vulnerable to privilege escalation.” Cool. How? Via what? Reproducible how? The sysadmin tries to verify, can’t, and tickets it as “can’t reproduce.”

No narrative. A list of findings is not a red team report. A red team report tells the story of what an attacker would actually do — the path from initial access to objective. Most reports skip this entirely.

Remediation as afterthought. “Patch the system.” Helpful. What patch? What version? What configuration change? When this section is vague, remediation stalls.

The template below fixes all of this.

Report Structure Overview

A complete red team report has seven sections:

1. Cover Page & Metadata
2. Executive Summary
3. Scope & Rules of Engagement
4. Attack Narrative
5. Technical Findings
6. Risk Summary Matrix
7. Remediation Roadmap

Each section has a different audience. Executives read 1-2. Security managers read 1-4. Technical teams read everything.

Section 1: Cover Page & Metadata

Keep it clean. Required fields:

Report Title:      Red Team Assessment Report
Client:            [Organization Name]
Assessment Period: [Start Date] – [End Date]
Report Date:       [Delivery Date]
Report Version:    1.0 (Final)
Classification:    CONFIDENTIAL — RESTRICTED DISTRIBUTION
Prepared By:       [Red Team Lead Name / Team]
Contact:           [Email / Phone]

Add a distribution list if you know who’s supposed to receive it. Red team reports are sensitive documents — scope creep in distribution is a real risk.

Section 2: Executive Summary

This is the most important section and the most consistently written poorly. Write it for someone who has 90 seconds and no technical background.

The formula:

What we did → What we found → What it means → What to do about it

Length: One page maximum. Two short paragraphs plus a bullet list.

Template:

During [timeframe], [Team/Company] conducted a [X-day] red team assessment of [Organization]’s [environment description — e.g., “external perimeter, internal network, and Active Directory environment”]. The assessment simulated a realistic threat actor with the goal of [objectives — e.g., “gaining unauthorized access to financial systems and exfiltrating sensitive data”].

The team successfully [high-level outcome — e.g., “achieved complete domain compromise within 48 hours of initial access, accessed [X] sensitive systems, and exfiltrated [Y] records without triggering any security alerts”]. The primary attack path exploited [one-line root cause — e.g., “a phishing-susceptible user account, an unpatched internal web application, and misconfigured Active Directory permissions”]. These findings indicate that a motivated threat actor could achieve [business impact — e.g., “full access to customer data and financial systems with current detective controls in place”].

Critical Findings:

• [Critical Finding 1 — one sentence, business impact language]
• [Critical Finding 2]
• [Critical Finding 3]

Key Recommendation: [One sentence — the single most important action to take]

What to avoid in the executive summary:

• CVE numbers (nobody in the C-suite knows CVE-2025-XXXXX)
• Technical jargon without translation
• Passive voice (“vulnerabilities were identified” → “we found”)
• More than five bullet points
• Saying “critical” about everything (it dilutes the word)

Section 3: Scope & Rules of Engagement

This section protects both parties and sets context for everything that follows.

Include:

• In-scope targets: IP ranges, domains, applications, physical locations
• Out-of-scope targets: What was explicitly excluded
• Attack vectors tested: External network, phishing, physical, cloud, wireless, etc.
• Assessment type: Black box / gray box / white box / assumed breach
• Rules of engagement: DoS prohibited? Production systems off-limits? Business hours only?
• Deconfliction contacts: Who to call if something breaks
• Start/end dates: With timestamps if relevant

Sample scope table:

Section 4: Attack Narrative

This is what separates a red team report from a vulnerability scan output. The attack narrative tells the story of the engagement chronologically — how you got in, how you moved, what you got to.

Write it like a threat intelligence report about your own operation. Third-person, past tense, factual. Walk the reader through the kill chain.

Structure:

4.1 Initial Access

How did you get in? What vector worked?

On Day 1, the red team identified a phishing opportunity using publicly available LinkedIn data. A spear-phishing email was sent to three employees in the finance department. One user clicked the link and entered credentials into a cloned login portal. Captured credentials were valid for the internal VPN.

Include:

• Method used
• Target selected and why
• What succeeded (and what failed, briefly)
• Timestamp if relevant

4.2 Foothold Establishment

What did you do once inside?

With valid VPN credentials, the team connected to the internal network at 14:23 on Day 1. Initial host enumeration identified a Windows 10 workstation assigned to the compromised user. A C2 beacon was deployed via a malicious macro-enabled document sent as a follow-up email attachment. Execution was confirmed at 14:51. The beacon established outbound communication over HTTPS to the team’s C2 infrastructure using a domain-fronted channel.

4.3 Privilege Escalation

How did you go from user to something more?

The compromised user account had local administrator rights on 14 additional workstations, identified via BloodHound analysis. Lateral movement to a secondary workstation revealed a Kerberoastable service account (svc_backup) with a weak password. The hash was cracked offline within 6 minutes. The svc_backup account held Domain Admin rights via nested group membership.

4.4 Lateral Movement

How did you spread?

With Domain Admin privileges via svc_backup, the team dumped NTDS.dit from the domain controller using a DCSync attack. All 2,847 domain credentials were extracted. The team then accessed the financial application server using the CFO’s cached credentials, establishing access to [X] records.

4.5 Objective Achievement

Did you reach the stated objective?

The team accessed the target financial database at 09:14 on Day 3, successfully exfiltrating a sample dataset of 500 records to demonstrate the attack path. Full exfiltration of the database (estimated 1.2M records) would be feasible in under 4 hours given available bandwidth. The entire attack path — from initial phishing to data exfiltration — was completed without triggering a single alert in the SIEM.

4.6 Missed Detections

This is optional but high-value. Document what controls failed to detect you.

Section 5: Technical Findings

This is the detailed evidence section. Each finding gets its own entry. Every finding follows the same format.

Finding Format Template

Finding ID:     RTF-001
Title:          [Short, descriptive title — not a CVE name]
Severity:       Critical / High / Medium / Low / Informational
CVSS Score:     [Optional, if applicable]
Status:         Exploited / Identified (not exploited) / Verified

Affected Systems:
  - [hostname / IP / URL]

Description:
  [2-3 sentences explaining what the vulnerability is and why it exists.
  Write for a senior sysadmin who will verify and remediate it.]

Evidence:
  [Screenshots, command output, proof-of-concept steps. 
  Enough for another practitioner to reproduce it.]

Business Impact:
  [What does this mean in business terms? Data exposure? 
  Operational disruption? Regulatory risk? Reputational damage?]

Exploitation Steps (if exploited):
  1. [Step 1]
  2. [Step 2]
  3. [Result]

Remediation:
  [Specific, actionable steps. Not "patch the system" — 
  "Apply KB5XXXXXX, enforce Group Policy setting X, 
  rotate the svc_backup service account password and remove 
  it from Domain Admins."]

References:
  - [CVE link, vendor advisory, relevant documentation]

Severity Ratings — Use These Consistently

Don’t invent your own definitions. Use a standard:

Important: Severity should reflect exploitability AND impact in context. A Critical CVE on an isolated test machine is not the same as a Medium on a public-facing payment system. Adjust accordingly and document your reasoning.

Sample Finding Entry

Finding ID:     RTF-003
Title:          Active Directory Kerberoasting — Weak Service Account Password
Severity:       Critical
Status:         Exploited — Domain Admin obtained

Affected Systems:
  - svc_backup (DOMAIN\svc_backup)
  - DC01.company.local (Domain Controller)

Description:
  The service account DOMAIN\svc_backup has a Kerberos Service Principal 
  Name (SPN) configured, making it eligible for Kerberoasting. The account 
  uses a weak password that was cracked offline in approximately 6 minutes 
  using a standard wordlist. The account is a member of the Domain Admins 
  group, providing complete control over the Active Directory environment.

Evidence:
  [Screenshot: GetUserSPNs output showing svc_backup]
  [Screenshot: Hashcat session cracking the TGS hash]
  [Screenshot: BloodHound path showing svc_backup → Domain Admins]

Business Impact:
  Complete compromise of the Active Directory environment. An attacker with 
  Domain Admin access can create backdoor accounts, disable security controls, 
  access all systems and data, and maintain persistent access indefinitely. 
  This finding alone represents a full organizational compromise.

Exploitation Steps:
  1. Identified Kerberoastable accounts: GetUserSPNs.py DOMAIN/user:pass -dc-ip 10.0.0.1 -request
  2. Saved TGS hash to file and ran: hashcat -m 13100 hash.txt rockyou.txt
  3. Password cracked: "Summer2024!" (6 minutes, standard wordlist)
  4. Authenticated as svc_backup and confirmed Domain Admin membership

Remediation:
  1. Immediately rotate the svc_backup service account password to a 
     randomly generated 25+ character password.
  2. Remove svc_backup from the Domain Admins group — service accounts 
     should operate with least-privilege.
  3. Audit all SPNs for accounts with elevated privileges: 
     Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties MemberOf
  4. Consider using Group Managed Service Accounts (gMSA) which use 
     automatically rotated, complex passwords managed by AD.
  5. Enable ATA/Defender for Identity alerting on Kerberoasting patterns.

References:
  - https://attack.mitre.org/techniques/T1558/003/
  - https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/

Section 6: Risk Summary Matrix

A one-page visual that gives stakeholders a fast read on the overall risk picture.

Finding Summary Table:

Severity Distribution Chart:

Critical: ■■■ (2)
High:     ■■■■■ (3)
Medium:   ■■ (2)
Low:      ■ (1)
Info:     (0)

Attack Chain Summary:

Phishing Email → Credential Capture → VPN Access (no MFA)
     → Kerberoasting → Domain Admin → DCSync → Full Compromise

Map this to MITRE ATT&CK if your client uses it — it helps their blue team prioritize detection rules.

Section 7: Remediation Roadmap

Don’t just list what’s broken — give them a plan.

Priority tiers:

Sample roadmap:

P1 — Immediate (within 72 hours):

• Rotate all domain service account passwords, especially svc_backup
• Enable MFA on VPN immediately
• Reset credentials for all users targeted in phishing
• Review Domain Admins group membership and remove unnecessary accounts

P2 — Short-term (2–4 weeks):

• Implement Defender for Identity or equivalent — configure Kerberoasting detection
• Audit and remove excessive local admin rights across workstations
• Review and harden SIEM alerting — ensure C2 beacon patterns are detected
• Patch all Critical/High CVE systems

P3 — Medium-term (1–3 months):

• Migrate service accounts to gMSA
• Implement PAM solution for privileged access
• Conduct phishing awareness training for all staff, mandatory annual re-test
• Review Active Directory tier model and implement if not in place

P4 — Long-term (3–6 months):

• Implement Zero Trust network segmentation
• USB port management policy enforcement
• Annual red team assessment cadence
• Purple team exercise to validate improved detection coverage

Language & Tone Guide

A few quick rules that make reports significantly better:

Use active voice.

• ❌ “Credentials were captured by the team”
• ✅ “The team captured credentials”

Use business impact language in findings.

• ❌ “The system is vulnerable to CVE-2024-XXXX”
• ✅ “This vulnerability allows an attacker to read all customer records without authentication”

Be specific with remediation.

• ❌ “Enable MFA”
• ✅ “Enable MFA on the Cisco AnyConnect VPN using Microsoft Authenticator — configuration steps in Cisco documentation KB12345”

Don’t hype your own work.

• ❌ “The team’s elite tradecraft allowed us to…”
• ✅ “Using standard publicly available tools, the team…”

Don’t soften impact.

• ❌ “This could potentially allow an attacker to…”
• ✅ “This allows an attacker to…” (if it’s true)

Appendices

Include these as-needed:

• Appendix A: Full tool output / raw evidence
• Appendix B: Methodology (PTES, OSSTMM, MITRE ATT&CK alignment)
• Appendix C: Glossary (for non-technical readers)
• Appendix D: Scope documentation / authorization letters
• Appendix E: Retest criteria (what “fixed” looks like for each finding)

Operational Security Note

Red team reports are the most sensitive deliverables in your engagement. They document exactly how your client’s environment was compromised.

Delivery rules:

• Encrypt the report (password-protected PDF or encrypted container)
• Deliver over a secure channel — not plain email
• Confirm receipt with the point of contact
• Delete working copies from your own systems after delivery confirmation
• Clarify with the client how they’ll store and distribute the report internally

Final Checklist

Before submitting:

• Executive summary fits on one page
• Every finding has a severity, evidence, business impact, and specific remediation
• Attack narrative tells a coherent story from initial access to objective
• No finding says only “patch the system” — remediation is specific
• Risk matrix is complete and accurate
• Remediation roadmap has prioritized tiers
• Report is encrypted before delivery
• All screenshots are labeled and legible
• Client name and dates are correct throughout

Wrapping Up

The goal of a red team report isn’t to show off what you found. It’s to give the organization exactly what they need to understand their risk and fix it.

Write it for two audiences — the executive who needs to understand the business risk and approve the remediation budget, and the technical team who needs to reproduce, verify, and fix each finding. If both of them can read your report and get what they need without calling you, you’ve written a good report.

Need help turning your red team findings into polished, boardroom-ready reports? CipherWrite handles technical writing for cybersecurity teams — from raw notes to final deliverable.