Penetration test report template: sections, an example finding and a checklist

Who reads a penetration test report

A penetration test report is read twice. Leadership reads the first two pages to decide how worried to be and what to fund. Engineers read the findings to reproduce and fix each issue. Most weak reports fail one of those readers: either a wall of technical output with no summary, or a glossy summary with no evidence behind it.

The template below works for internal, external, web application and cloud tests. Use the sections in this order, and keep the executive summary free of jargon.

The template, section by section

1. Cover and document control. Client, test type, test dates, report version, author, reviewer, distribution list and a confidentiality marking.
2. Executive summary. One page: what was tested, the overall result in plain language, the three to five findings that matter most, and what to do first. No CVSS vectors here.
3. Scope and rules of engagement. In-scope hosts, ranges, URLs and accounts; what was out of scope; testing windows; any restrictions (no denial of service, no social engineering) and who approved them.
4. Methodology. The approach and standards followed, for example PTES, the OWASP Web Security Testing Guide or NIST SP 800-115, plus the main tools used.
5. Findings summary. A table of every finding with ID, title, severity and affected asset count, sorted by severity, and a chart or count by severity if you like.
6. Detailed findings. One block per finding, using the fields in the next section.
7. Attack narrative. For tests that chained issues together, the path from first foothold to final access, step by step, so the client sees why low-severity findings mattered in combination.
8. Remediation roadmap. What to fix now, next and later, grouped by owner where possible. This is the page the client will work from.
9. Appendices. Tool output, full host lists, credentials used (redacted), and a glossary of severity ratings.

The fields every finding needs

An example finding, written out

PT-03: Outdated VPN appliance firmware allows unauthenticated command execution (Critical, CVSS 10.0). The external VPN gateway at vpn.example.com runs a firmware version affected by CVE-2024-3400. The issue is on CISA's Known Exploited Vulnerabilities list and has an EPSS score above 90%, so attackers are actively using it.

Evidence: the device banner and version endpoint report the vulnerable version (screenshot 3.1). No exploit was run, per the rules of engagement. Impact: an unauthenticated attacker on the internet could run commands on the gateway and use it as a foothold into the internal network. Remediation: apply the vendor's fixed firmware now; until then, apply the vendor's published mitigations and review the device for signs of compromise. References: CVE-2024-3400, vendor security advisory, CISA KEV entry.

Rating severity so clients believe it

Clients learn to ignore reports where everything is Critical. Use CVSS for the technical score, then say plainly when you raised or lowered it for this environment and why. A finding that is known to be exploited, reachable from the internet and on a key system should rank above a theoretically higher-scored issue on an isolated test box.

For the reasoning behind exploitation-first ordering, see CVSS vs EPSS vs CISA KEV.

Checklist before you send it

• The executive summary makes sense to someone who skips everything else.
• Every finding has evidence and a specific fix, not just a link.
• Scope matches what was signed off, and anything you could not test is stated.
• Credentials, session tokens and personal data are redacted from screenshots.
• Severity is consistent across findings and explained where adjusted.
• The remediation roadmap has an order and, ideally, owners and dates.
• A second person has reviewed it.

Where vulnerability scans fit

Many engagements include a vulnerability scan alongside manual testing, and the scan output often ends up pasted into an appendix nobody reads. Varaxon Scan Hub turns a Nessus, Qualys, Rapid7, Greenbone / OpenVAS or Nuclei export into a prioritized, plain-language report with exploited issues first, which can stand as the scan section of a wider report. It does not perform penetration tests. See vulnerability scan vs penetration test for how the two differ.

Common questions