Structure a professional penetration-test report (engagement deliverable, not a single bug). Load at the end of a pentest, on "write the pentest report", "executive summary", "deliverable", or compiling findings for a client. Signals: engagement wrap-up, multiple findings, client report.
Installs into .claude/skills of the current project.
Are you the author of Reporting Pentest Report?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/noorqureshi-reporting-pentest-report)
---
name: reporting-pentest-report
description: >
Structure a professional penetration-test report (engagement deliverable, not a single bug).
Load at the end of a pentest, on "write the pentest report", "executive summary", "deliverable",
or compiling findings for a client. Signals: engagement wrap-up, multiple findings, client report.
domain: reporting
type: reference
stability: locked
modes: [pentest]
severity: info
schema_version: 1
---
# 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.