A penetration test is only as valuable as the report that documents it. Exceptional technical findings can be undermined by poor documentation. Conversely, a well-written report translates complex vulnerabilities into actionable business intelligence that drives real security improvements. This guide covers the structure, content, and best practices for writing professional penetration testing reports.
Report Structure
A professional pentest report has two primary audiences: executives (who need business context) and technical teams (who need actionable detail). Structure your report to serve both:
- Cover Page — Engagement details, dates, classification
- Executive Summary — High-level findings for non-technical readers
- Scope and Methodology — What was tested and how
- Attack Narrative — Story of the engagement
- Findings — Detailed vulnerability documentation
- Appendices — Raw tool output, credentials, additional evidence
Executive Summary
The executive summary should be readable by a non-technical CISO or board member. Cover:
- Overall risk posture: “The external attack surface is at HIGH risk due to…”
- Most critical findings (briefly, no technical jargon): “An attacker could gain unauthorized access to the payroll database without authentication”
- Risk ratings distribution: e.g., 2 Critical, 4 High, 7 Medium, 3 Low
- Key recommendations: “Patch CVE-2024-XXXX immediately; implement network segmentation”
Keep it to 1-2 pages. Executives decide budget based on this section.
Scope and Methodology
Document exactly what was tested:
Scope:
- IP Range: 10.0.0.0/24 (internal), external.target.com
- Testing Type: Grey-box (credentials provided for authenticated testing)
- Testing Window: April 14-18, 2026, business hours only
- Excluded: Production database servers (10.0.0.50-60)
Methodology:
PTES (Penetration Testing Execution Standard):
Phase 1: Reconnaissance
Phase 2: Scanning and Enumeration
Phase 3: Exploitation
Phase 4: Post-Exploitation
Phase 5: Reporting
Attack Narrative
This section tells the story of how an attacker could compromise the environment, connecting individual findings into a realistic attack chain:
“The assessment began with external reconnaissance, identifying the login portal at portal.target.com running Citrix Workspace 2023.1.2. Exploitation of CVE-2024-0001 (Critical) yielded unauthenticated remote code execution on the Citrix gateway. From this foothold on the DMZ server (10.0.0.5), the assessor enumerated the internal network and discovered an SMB service on 10.0.0.20 accepting default credentials. This host had database access to the HR system, exposing 15,000 employee records.”
The narrative helps stakeholders understand risk in context, not as isolated bullet points.
Finding Documentation
Each vulnerability should be fully documented. Use a consistent template:
Finding Title: Unauthenticated RCE via CVE-2024-0001 in Citrix Workspace
Severity: Critical | CVSS Score: 9.8
Affected System: portal.target.com (10.0.0.5)
Description:
The Citrix Workspace version 2023.1.2 deployed at portal.target.com is vulnerable to CVE-2024-0001, a pre-authentication remote code execution vulnerability in the XML API endpoint. An unauthenticated attacker can send a specially crafted HTTP POST request to /Citrix/StoreWeb/Resources/List to execute arbitrary commands as the IIS application pool identity (SYSTEM privileges).
Evidence:
POST /Citrix/StoreWeb/Resources/List HTTP/1.1
Host: portal.target.com
[PAYLOAD REDACTED FOR REPORT]
Response:
HTTP/1.1 200 OK
...
uid=0(root) gid=0(root)
Screenshot: citrix_rce_proof.png
Impact:
An unauthenticated attacker can execute arbitrary code with SYSTEM privileges on the Citrix gateway, enabling lateral movement into the internal network, credential theft, and access to all services accessible from the DMZ.
Remediation:
- Apply the vendor-supplied patch: Citrix Security Bulletin CTX-XXXX
- As interim mitigation, restrict access to the Citrix portal by source IP via firewall rules
- Enable WAF rules to detect XML injection patterns
- Review IIS application pool identity — run with least privilege
References:
- CVE-2024-0001
- CVSS Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Severity Rating System
Be consistent with severity ratings. Use CVSS v3.1 as your primary scoring system, supplemented by business context:
| Severity | CVSS Range | Description |
|---|
| Critical | 9.0-10.0 | Immediate exploitation risk, significant business impact |
| High | 7.0-8.9 | Exploitation likely, high data exposure risk |
| Medium | 4.0-6.9 | Exploitation possible with conditions, moderate impact |
| Low | 0.1-3.9 | Limited exploitability, low impact |
| Informational | N/A | Best practice deviation, no direct risk |
Adjust CVSS scores based on your client’s environment — a medium CVSS finding in a credit card processing environment may warrant High severity in context.
Screenshots and Evidence
Screenshots make findings irrefutable. Best practices:
- Capture the full command, its output, and timestamp
- Blur out actual sensitive data (real passwords, PII) — demonstrate proof without exposing data
- Label screenshots clearly:
fig-01-nmap-discovery.png
- Use a screen capture tool that captures terminal cleanly (Flameshot on Linux)
For command-line evidence, include the exact command and output:
$ sqlmap -u "https://target.com/search?q=test" --dbs --batch
[CRITICAL] The back-end DBMS is MySQL
available databases:
[*] hrdb
[*] payroll
[*] customers
Remediation recommendations should be:
- Specific: Not “update software” but “upgrade Apache to 2.4.62 or later per vendor advisory”
- Prioritized: Group by severity
- Actionable: Include patch links, configuration examples
- Realistic: Short-term (patch now) vs. long-term (architecture change)
Common Report Writing Mistakes
- Too much tool output: Appendices exist for raw data — synthesize findings, don’t dump nmap logs inline
- No business impact: “SQL injection found” tells executives nothing; “attacker could exfiltrate customer payment data” creates urgency
- Inconsistent severity: Rate consistently; stakeholders notice when Critical findings seem like typos
- Missing reproduction steps: Technical teams need step-by-step to reproduce and verify fixes
- Passive voice overuse: “A vulnerability was found” → “We discovered a vulnerability” — own your findings
- Pwndoc — Open-source pentest report generator with templates
- PlexTrac — Commercial platform for pentest report management
- Dradis — Collaboration platform with report generation
- OSCP Exam: Their report template (available publicly) is an excellent starting reference
The best pentest report is one that results in vulnerabilities being fixed. Write for your audience, document evidence rigorously, and provide actionable remediation that the blue team can act on immediately.