Penetration Testing Report Example: What a Good Report Includes
The standard structure of a pentest report, an example findings table, and what separates an actionable report from a PDF nobody reads.
What Goes Into a Pentest Report?
A penetration testing report is the deliverable that turns a security test into an actionable record for both technical teams and executives: what was tested, what was found, how it was proven, and how to fix it.
OWASP’s Web Security Testing Guide dedicates a full section to reporting for a reason: the technical quality of a test is irrelevant if the client cannot understand and act on the findings. A good report speaks to two audiences at once, executives who need business impact and engineers who need exact reproduction steps.
Standard Report Structure
- Introduction. Scope, timeline, limitations, and the team involved.
- Executive summary. The business objective, key findings in plain language, and strategic recommendations, with technical detail left out.
- Findings summary. A table of every finding with a reference ID and risk level, for at-a-glance review.
- Findings detail. For each finding: likelihood, impact, risk rating, a detailed description, reproduction steps, and remediation guidance.
- Appendices. Methodology, severity rating definitions, and raw tool output.
Example Findings Table
Illustrative example only, not data from a real engagement.
| Ref ID | Finding | Risk | Status |
|---|---|---|---|
| F-01 | Broken access control on order API (IDOR) | Critical | PoC-validated |
| F-02 | Stored XSS in support ticket form | High | PoC-validated |
| F-03 | Missing rate limiting on login endpoint | Medium | PoC-validated |
| F-04 | Verbose error messages leaking stack traces | Low | Confirmed |
Each row in a real report links to a full finding detail: exact request/response pairs, a reproducible proof of concept, and step-by-step remediation, not just a severity label.
Why It Matters
A report full of unverified, scanner-generated findings creates work rather than removing risk. Every finding needs to be manually checked before an engineering team can trust it, which is exactly the burden a 40 to 70% false positive rate creates. A report where every finding carries proof of exploit skips that step entirely: engineers can go straight to remediation because the finding is already confirmed real.
Frequently Asked Questions
What should be included in a penetration testing report?
An introduction with scope and limitations, an executive summary, a findings summary table, detailed findings with reproduction steps and remediation guidance, and appendices covering methodology and raw output.
What is the difference between a findings summary and findings detail?
The findings summary is a quick-reference table of every issue and its risk level. Findings detail provides the full technical breakdown needed to reproduce and fix each one.
Should a pentest report include proof of concept?
Yes. A proof of concept, such as a request and response pair or a reproducible script, confirms a finding is genuinely exploitable rather than a theoretical or scanner-flagged issue.
Who is the audience for a pentest report?
Both executives and engineers. The executive summary should be understandable without technical background, while the findings detail needs enough depth for an engineer to reproduce and fix the issue.
Why do some pentest reports have a high false positive rate?
Reports built primarily from automated scanner output inherit the scanner’s false positive rate, commonly 40 to 70%, unless every finding is manually or automatically re-verified before it is included.
Related Reading
Get a Report Built From Proof, Not Pattern Matches
Every finding comes with exploit validation, so your team can start fixing instead of re-verifying.