Penetration Test Report: Format and Sample Outline
A penetration test report describes what was tested, what was found, how serious each finding is and how to fix it. NIST SP 800-115 says a report is generally developed to describe identified vulnerabilities, present a risk rating and give mitigation guidance, and PTES recommends an executive summary and a technical report so each audience gets what it needs.
Below is a sample outline with what belongs in each section, a fictional finding written in full, and a checklist to judge a report you have been sent. It is for buyers and testers; it contains no attack instructions. Last reviewed 3 November 2026.
Updated 3 November 2026
Sample outline
| Section | What goes in it |
|---|---|
| 1. Cover and document control | Client, tester, dates of testing, version, classification, distribution list. |
| 2. Executive summary | One or two pages: objective, overall risk in plain words, the few findings that matter most, and the decisions needed. No jargon. (PTES: written for decision-makers.) |
| 3. Scope and rules of engagement | Targets in and out of scope, test types, time window, constraints, authorisation. Created in the scoping tool. |
| 4. Method and limits | Approach used (for example NIST SP 800-115 phases, PTES, OWASP WSTG), tester viewpoint, and what was not tested. State that the result is true on the days of testing. |
| 5. Findings summary | A table of all findings: ID, title, severity, affected asset, status. |
| 6. Detailed findings | One entry per finding using the layout below. |
| 7. Conclusions and next steps | Themes (for example weak access control across several apps), a fix order and a retest plan. |
| 8. Appendices | Scoring method, tools list, evidence, scan output, glossary. |
One finding, written in full (fictional)
F-03: Customer invoices readable by changing the invoice number (insecure direct object reference)
- Severity: High (CVSS vector and score shown here, with the version stated).
- Affected: portal.example.test, endpoint
/api/invoices/{id}. - Description: A signed-in user can read another customer's invoice by requesting a different numeric ID. The server checks that the user is signed in but not that the invoice belongs to them.
- Evidence: request and response for two test accounts, with personal data redacted.
- Impact: exposure of other customers' names, addresses and amounts.
- Recommendation: enforce an ownership check on every invoice request; use non-guessable identifiers as a second layer; add a test for cross-account access.
- Status after retest: Fixed on a stated date.
Score technical severity with the CVSS calculator, then rank the work with the vulnerability prioritiser. Record the fixes in a risk register so they are tracked to closure.
Is this a good report? A buyer's checklist
- The executive summary makes sense to someone who will not read the rest.
- Scope and exclusions match what you agreed; limits and the test dates are stated.
- Every finding has a severity, the method used to rate it, affected assets, evidence and a specific fix.
- Findings are not just scanner output. NIST separates scanning, which checks for the possible existence of a vulnerability, from testing that attempts to exploit one to confirm it.
- False positives are removed or marked.
- There is a retest section or a plan to retest.
- The UK NCSC notes a pen test only shows your systems are not vulnerable to known issues on the day of the test; treat the report as one input to vulnerability management.
New to the subject? Start with penetration testing explained.
Frequently asked questions
What should a penetration test report include?
NIST SP 800-115 says a report is generally developed to describe identified vulnerabilities, present a risk rating and give guidance on how to mitigate them. PTES splits reporting into an executive summary and a technical report. A good report adds scope and rules of engagement, method, a findings table, evidence, and a retest result.
What is the format of a penetration test report?
There is no single mandatory format. A common structure is: cover and document control, executive summary, scope and method, summary of findings, detailed findings, conclusions and next steps, and appendices. The outline below follows the NIST and PTES descriptions of what a report must communicate.
How long should a pen test report be?
Long enough to let engineers reproduce and fix each finding, and short enough that the executive summary fits on one or two pages. Length depends on scope. Judge a report on whether each finding can be acted on, not on page count.
How do I rate the severity of findings?
Many teams use CVSS to score technical severity, then adjust for business impact and exploitability in their environment. Use the CVSS calculator to check a vector, and the vulnerability prioritiser when you need to decide what to fix first. State the scoring method in the report so readers know what the ratings mean.
Is there a free penetration test report template?
Several public projects publish sample reports and outlines. We do not offer a downloadable template on this page; the outline below shows the sections and what to put in each, which you can copy into your own document. A sample from a real engagement should always be sanitised before it is shared.
Who is the report for?
Two audiences. Decision-makers need the headline risk, what it means for the business and what to fund. Engineers need steps to reproduce, affected assets, evidence and a fix. PTES recommends separate executive and technical parts for this reason.
What is a retest?
A retest checks, after fixes, whether each finding is closed. Reports should state the finding’s status afterwards (fixed, partly fixed, not fixed) and the date, so the record shows risk reducing over time.
Should the report contain exploit code?
Include the minimum needed to reproduce a finding, such as the request, the payload class and the observed response, and no more. A report is a sensitive document: it describes how to attack your systems. Control who receives it, store it securely and delete working copies when they are no longer needed.
Sources
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (September 2008), reporting, accessed 3 Nov 2026
- PTES: Reporting, accessed 3 Nov 2026
- OWASP Web Security Testing Guide: Reporting, accessed 3 Nov 2026
- FIRST: Common Vulnerability Scoring System (CVSS)
- UK NCSC: Penetration testing guidance, accessed 3 Nov 2026