Penetration-test report

When it governs

End of a pentest engagement, when findings become a client deliverable. Different from a bug-bounty report (reporting-bug-bounty-writeup): this is the whole engagement — executive narrative plus detailed findings — read by both executives and engineers.

Structure

1. Executive summary — non-technical: what was tested, overall risk posture, the 3–5 things that matter, and business impact. One page. No jargon.
2. Scope & methodology — assets/IPs/apps in scope, dates, testing type (black/grey/white), standards followed (PTES/OWASP WSTG/NIST), and limitations.
3. Findings — one per issue, ordered by risk. Each: title, severity (CVSS vector + rating), affected assets, description, reproduction steps (exact requests/commands), evidence (screenshots/output), impact (business terms), remediation (specific fix), references.
4. Risk ratings — a consistent method (CVSS + likelihood/impact matrix); explain it.
5. Remediation roadmap — prioritized, with quick wins vs strategic fixes; owners/timelines if known.
6. Appendices — full tool output, methodology detail, out-of-scope notes, retest results.

Quality bar

• Reproducible: an engineer can follow each finding from a clean state.
• Two audiences: executives read the summary; engineers read the findings — serve both.
• Actionable remediation: name the specific fix (parameterize the query, enforce object-level authz), not "sanitize input" (see defense-hardening-baseline).
• Evidence hygiene: redact secrets/PII; store raw evidence securely; keep the client's data confidential.

Gotchas

• Severity must reflect demonstrated impact in context, not the theoretical max.
• Don't bury the critical findings under low-severity noise — lead with what matters.
• Deliver the report over a secure channel; it's a map of how to break the client.

References

PTES; OWASP WSTG; NIST SP 800-115; FIRST CVSS 3.1.