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)