pentest-report

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.