Redteam Report Template

When to use

Use this skill for client-deliverable reports:

• External red-team engagements with a signed SOW
• Pentest reports going to a CISO / IT-Sec team (not a triager)
• Findings that will be reviewed by both technical and non-technical stakeholders
• Reports that need DOCX/PDF output (not just markdown / platform UI)

Do NOT use for:

• Bug-bounty platform submissions (use report-writing / bugcrowd-reporting instead)
• Quick proof-of-concept memos
• Internal team writeups

---

The 6-section format per finding

This is the canonical structure each finding follows:

## Finding F##: <descriptive title>

**Severity:** Critical / High / Medium / Low / Informational
**Status:** Confirmed / Patched mid-engagement / Suspected (1 signal)
**CVSS 3.1:** <score> (<vector>)
**Affected Asset:** <URL / IP / app name>

### 1. Subject
<One-line statement of the issue. Plain English, no jargon.>

### 2. Observations
<Bulleted list of what was observed during testing. Concrete facts only, no interpretation yet.>
- <Observation 1>
- <Observation 2>
- ...

### 3. Description
<Technical explanation of the vulnerability. 2-4 paragraphs. Reader should understand WHY the observations indicate a vulnerability, what the underlying flaw is.>

### 4. Impact
<What an attacker could achieve. Concrete attacker outcomes, NOT generic CIA triad statements. Tie to the client's business, money, data, reputation, regulatory exposure.>

### 5. Recommendation
<Specific, actionable remediation. Vendor patch, configuration change, code-level fix. Avoid "implement security best practices", say what specifically.>

### 6. Proof of Concept (PoC)
<Steps to reproduce, numbered. Include the exact HTTP requests, payloads, tools used.>

**Step 1:** <action>
```http
<full HTTP request or curl one-liner>

Step 2: <action>

<response excerpt>

Screenshot:

---

## Severity & status disciplines