Pentest Report

---
name: pentest-report
description: "Write a clear penetration-test report from findings of an authorized engagement. Use when documenting a pentest, security assessment, or authorized red-team engagement — turning findings into a report clients act on. Produces an executive summary, scope & methodology, findings with severity/evidence/reproduction/remediation, and a risk-ranked remediation plan. For authorized testing only."
---

# Penetration Test Report Skill

A pentest is only as valuable as the report — findings that aren't clearly explained, evidenced, and
prioritized don't get fixed. This skill turns the findings of an **authorized** engagement into a report that
both executives and engineers can act on: risk up top, reproducible technical detail below, remediation
throughout.

> For **authorized** security testing only (signed scope / rules of engagement). This documents results; it is
> not a guide to attacking systems you don't have written permission to test.

## Required Inputs

Ask for these only if they aren't already provided:

- **Engagement scope** — what was in scope (targets, environments), the authorization/rules of engagement, and the testing window.
- **Methodology** — approach (black/grey/white-box), standards followed (e.g. OWASP, PTES), tools.
- **Findings** — each issue found: what it is, affected asset, how it was exploited, evidence, and impact.
- **Audience** — client's technical team, leadership, or both.

## Output Format

### Penetration Test Report: [client / engagement]

**1. Executive summary** — for leadership: the overall risk posture, the count of findings by severity, the 2–3 most important takeaways, and the headline recommendation. No jargon.

**2. Scope & authorization** — what was tested, what wasn't, the authorization basis and testing window. (Establishes this was authorized and bounds the results.)

**3. Methodology** — approach, standards, phases, and tools — enough for the client to understand coverage and limits.

**4. Findings** — one entry per issue, ordered by severity:

> **[FINDING TITLE]** — Severity: 🔴 Critical / 🟠 High / 🟡 Medium / 🔵 Low (CVSS if used)
> - **Affected:** asset/endpoint/component
> - **Description:** what the weakness is
> - **Reproduction:** the steps to reproduce (responsibly detailed — enough to verify and fix)
> - **Evidence:** request/response, screenshot ref, or output (sensitive data redacted)
> - **Impact:** what an attacker gains; business consequence
> - **Remediation:** the specific fix, and any interim mitigation

**5. Risk-ranked remediation plan** — a table of all findings with severity, effort, and priority order, so the client knows what to fix first.

| # | Finding | Severity | Fix effort | Priority |
|---|---|---|---|---|

**6. Positive observations & retest** — controls that held up, and the offer/plan to retest fixes.

## Quality Checks

- [ ] The executive summary conveys overall risk and top actions without jargon
- [ ] Scope, authorization, and methodology are stated (results are bounded and clearly authorized)
- [ ] Each finding has severity, affected asset, reproduction, evidence, impact, and remediation
- [ ] Findings are ordered by severity and rolled into a risk-ranked remediation plan
- [ ] Sensitive data in evidence is redacted; positive findings and a retest path are included

## Anti-Patterns

- [ ] Do not omit the authorization/scope — an unbounded, unauthorized-looking report is unusable and unsafe
- [ ] Do not give a severity without impact and remediation — clients fix what they understand and can prioritize
- [ ] Do not write findings only engineers can read (or only execs) — serve both audiences in their sections
- [ ] Do not leave evidence unredacted — protect the very data you're helping secure
- [ ] Do not produce this for testing that wasn't authorized in writing

## Based On

Penetration-testing reporting standards (PTES, OWASP Testing Guide): exec + technical layers, evidenced reproducible findings, risk-ranked remediation.