| name | pentest-report |
| description | Pentest report authoring with executive summary, CVSS-scored findings, attack narrative, and remediation roadmap (writing methodology) |
| license | MIT |
| metadata | {"category":"compliance","locale":"en","phase":"v1"} |
What this skill does
Guides the structured writing of a professional penetration test report covering executive summary, scoped findings with CVSS v3.1 scoring, attack narrative, strategic recommendations, and quality assurance. No external tools required — this is a methodology skill for report authoring.
When to use
- Documenting the results of a completed penetration test engagement
- Producing deliverables for clients, internal security teams, or compliance reviewers
- Standardizing finding format across engagements (CVSS, CWE, OWASP mapping)
- Creating executive-level summaries from raw technical findings
Prerequisites
Inputs
| Field | Description | Example |
|---|
CLIENT_NAME | Organization being assessed | Acme Corp |
ASSESSMENT_TYPE | Black-box / Grey-box / White-box | Grey-box |
SCOPE | Systems, IP ranges, domains in scope | 10.0.0.0/24, app.example.com |
TEST_DATES | Start and end dates of testing | 2026-03-01 – 2026-03-14 |
FINDINGS | Raw findings data collected during assessment | Finding notes, screenshots, logs |
Report Structure
1. Cover Page
- Report title: "Penetration Test Report — [Client Name]"
- Classification: Confidential
- Version and date
- Tester name(s) and organization
- Client contact
2. Table of Contents
Auto-generate with document processor or list sections manually.
3. Executive Summary
4. Scope and Methodology
5. Risk Rating System
6. Findings Detail
7. Attack Narrative
8. Positive Observations
9. Strategic Recommendations
10. Appendices
Workflow
Step 1: Gather and organize assessment data
Before writing, structure all raw data:
assessment-data/
├── scope.txt — IP ranges, domains, exclusions, RoE
├── findings/
│ ├── FIND-001-sqli.md — one file per finding
│ ├── FIND-002-xxe.md
│ └── ...
├── evidence/
│ ├── screenshots/
│ └── logs/
└── tools-output/
├── nmap-scan.txt
├── nuclei-results.json
└── ...
Finding triage checklist before writing:
Step 2: Write the Executive Summary
The executive summary is read by C-level stakeholders and non-technical decision makers. Write it last, after all findings are documented, but place it first in the report.
Reference: See REFERENCE.md for the full Executive Summary template including Risk Dashboard table and Top Findings Summary format.
Writing rules:
- No CVE IDs, IP addresses, or exploit names
- Focus on business outcomes, not technical mechanisms
- Aim for 1-2 pages maximum
- Every sentence must be understandable by someone without a security background
Step 3: Document scope and methodology
Cover: in-scope and out-of-scope components, testing type (black/grey/white-box), methodology framework (PTES / OWASP Testing Guide / NIST SP 800-115), testing timeline by phase, tools used, limitations, and Rules of Engagement reference.
Reference: See REFERENCE.md for the full Scope and Methodology template with table formats for scope components and testing timeline.
Step 4: Document each finding
Use a consistent template for every finding. Complete all fields — do not leave fields blank. Required fields: Finding ID, Severity, CVSS v3.1 Base Score and Vector, CWE, OWASP Category, Affected System(s), Status, Description, Business Impact, Evidence, Steps to Reproduce, Remediation (with code example where applicable), Compensating Controls, References.
Reference: See REFERENCE.md for the full Finding Detail template, CVSS v3.1 severity threshold table, and a worked SQL injection example.
CVSS severity mapping (summary):
| Severity | Score Range |
|---|
| Critical | 9.0 – 10.0 |
| High | 7.0 – 8.9 |
| Medium | 4.0 – 6.9 |
| Low | 0.1 – 3.9 |
| Info | N/A |
Step 5: Write the attack narrative
The attack narrative shows the logical flow of exploitation in story format. It demonstrates the full impact of chained vulnerabilities that may individually appear low-severity. Structure as sequential phases: Initial Access → Privilege Escalation → Lateral Movement → Objective Achieved → Impact Assessment.
Reference: See REFERENCE.md for the full Attack Narrative template with example phase descriptions.
Step 6: Create strategic recommendations
Organize recommendations by remediation timeframe, not finding severity. This gives the client an actionable roadmap across three horizons: Short-term (0–30 days) for Critical/High findings, Medium-term (30–90 days) for systemic improvements, Long-term (90–365 days) for structural security posture.
Reference: See REFERENCE.md for the full Strategic Recommendations template with example entries for each timeframe tier.
Step 7: Run the quality checklist
Before submitting the report, verify all 10 quality checklist items. Key checks: executive summary readable by non-technical audience, all findings have complete reproduction steps and evidence, CVSS scores accurate, remediation is environment-specific, no sensitive client data leaked, attack narrative is coherent, recommendations prioritized by timeframe, positive observations included.
Reference: See REFERENCE.md for the complete 10-item quality checklist and the full Appendices structure (vulnerability listing, tool output, network diagrams, glossary, compliance mapping).
Done when
- Executive summary written without technical jargon, reviewed by a non-security colleague
- All findings documented with CVSS score, CWE, evidence, reproduction steps, and specific remediation
- Attack narrative written connecting findings into a logical chain
- Recommendations organized into short / medium / long-term roadmap
- All 10 quality checklist items pass
- Report exported to PDF, marked Confidential, and transmitted via encrypted channel
Notes
- Never include actual credentials, private keys, or full PII datasets extracted during testing in the report — reference the finding and describe the data type only.
- Tailor language for the audience: executive summary for C-suite, findings section for security engineers, recommendations for both.
- Positive observations matter — clients need to know what is working, not just what is broken.
- Version-control the report document. Use v0.1 for draft, v1.0 for final delivery, v1.1+ for post-review revisions.
- Agree on the report format and classification handling with the client before the engagement starts.