The penetration test report is the only thing you keep after the testers leave. It's what your engineers work from, what your auditors review and what your customers ask to see. Yet many buyers only look at the number of "criticals" and file it away. This guide explains what a good report contains, how to read the risk ratings, and how to turn findings into a remediation plan.
Anatomy of a penetration test report
| Section | What it should contain | Who reads it |
|---|---|---|
| Executive summary | Overall risk posture, the most important issues in business terms, key recommendations | Leadership, customers, auditors |
| Scope and limitations | Exactly what was tested, when, from where, with which accounts — and what was not | Auditors, security team |
| Methodology | Standards followed (OWASP WSTG, PTES, NIST SP 800-115) and testing approach | Auditors |
| Findings summary | Table of all findings with severity and status | Everyone |
| Detailed findings | Description, affected assets, evidence, reproduction steps, impact, remediation, references | Engineers |
| Attack narrative | How individual findings were chained into a realistic attack path | Security team, leadership |
| Appendices | Tools used, tested endpoints/hosts, raw evidence | Engineers, auditors |
Understanding severity ratings
Most reports rate findings as Critical, High, Medium, Low and Informational, often using CVSS (Common Vulnerability Scoring System) as a starting point. CVSS measures technical severity — how easy a flaw is to exploit and how bad the technical impact is. A good tester then adjusts for your context: an SQL injection in an internal tool used by three admins may be less urgent than an IDOR exposing every customer's invoices.
Ask your provider to explain their rating model. If two vendors rate the same issue differently, the explanation matters more than the label.
What a good finding looks like
Every finding should let a developer who wasn't on the project reproduce and fix it without a meeting. Check that each one includes:
- A clear title and plain-English description
- The affected URL, endpoint, host or component
- Step-by-step reproduction with requests, responses or screenshots
- Realistic impact — what an attacker could actually do
- Specific remediation guidance that addresses the root cause
- References (OWASP, CWE, vendor advisories)
Red flags in a pentest report
- Dozens of "informational" findings padding the page count
- Scanner plugin output pasted verbatim, with generic descriptions
- No evidence of manual testing — no authorization or business-logic findings on a complex app
- Missing scope statement, so you can't tell what was tested
- Remediation advice like "follow best practices" or "validate all input"
Turning findings into a remediation plan
- Triage within a weekConfirm each finding, assign an owner and agree severity in your context.
- Set target fix timesA common policy: Critical within 7–15 days, High within 30, Medium within 90, Low at the next planned release or risk-accepted.
- Fix root causes, not instancesIf one IDOR exists, check every similar endpoint. Add tests to prevent regression.
- RetestAsk the provider to verify fixes and issue an updated report or retest letter.
- Record risk acceptanceFor anything you won't fix, document why, who approved it and when it will be reviewed.
Sharing your report with customers
Full pentest reports contain a roadmap to attacking you — don't send them around freely. Common options are:
- Attestation letter — a one- or two-page letter from the testing firm confirming the dates, scope, methodology and that critical/high issues were remediated.
- Executive summary only, shared under NDA.
- Full report under NDA, only for strategic customers who insist, ideally via a trust portal with access logging.
Frequently asked questions
How long should a pentest report be?
Length isn't a quality signal. A focused report with clear evidence and remediation for each real finding is better than a long one padded with informational items.
Should we share our pentest report with customers?
Share an attestation letter or executive summary under NDA instead of the full report, which contains detailed attack information.
What if we disagree with a severity rating?
Discuss it with the testers. Severity should reflect your context; a good provider will adjust ratings when you show compensating controls or lower exposure.
Want to see what a strong report looks like? Request a sample report along with your quote.