Skip to content
Back to skills

Reporting Pentest Report

ASecurity

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.

  • 20 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 22, 2026
securitygotesting

Works with

  • cli

Security analysis

A100/100

Scanned September 22, 2026

npx -y skills add NoorQureshi/SploitAgent --skill reporting-pentest-report --agent claude-code

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.

Security grade badge for Reporting Pentest Report
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/noorqureshi-reporting-pentest-report/badge)](https://www.skillsdirectory.com/skills/noorqureshi-reporting-pentest-report)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…