A penetration test report has five core parts: an executive summary (for leadership), the scope and methodology (what was tested and how), the findings (each vulnerability with a severity rating, CVSS score, business impact, proof of concept and remediation), and a retest section confirming fixes. Read the executive summary for the overall risk picture, then work the findings in order of severity and business risk — the same CVSS score means different things on an internet-facing versus an internal system. After reading, triage, assign, remediate the criticals first, and retest. The tell of a good report is manual proof of concept and specific remediation; the tell of a bad one is unvalidated scanner output.
// 01 What's in a penetration test report?
Most professional reports follow the same structure, whatever the tester. Knowing the map before you dive in saves hours, because different sections are written for different readers — the executive summary for your board, the findings for your engineers.
| Section | Written for | What it tells you |
|---|---|---|
| Executive summary | Leadership | Overall risk posture in plain language; headline findings |
| Scope & rules of engagement | Everyone | What was tested, what was excluded, and the constraints |
| Methodology | Technical / audit | The standards followed (OWASP, PTES, NIST) — proves rigour |
| Findings | Engineers | Each vulnerability with severity, impact, proof and fix |
| Remediation & retest | Engineers / audit | Fix guidance and confirmation that fixes worked |
// 02 Reading the executive summary
The executive summary is the one section leadership will read, so it should answer three questions without jargon: how exposed are we, what are the most serious issues, and what is the overall trend. Look for a clear risk rating, a count of findings by severity, and a narrative that connects the technical findings to business consequences — "an attacker could access customer records," not "SQL injection in parameter X." If the executive summary is just a table of CVE numbers, the report is talking to the wrong audience, and you will have to translate it yourself.
// 03 How to read an individual finding
Each finding is the working unit of the report, and a well-written one contains the same elements every time. Learn to read one and you can read them all.
Title & severity: what the issue is and how serious — Critical, High, Medium, Low or Informational.
CVSS score: a 0–10 standardised severity score. Useful, but not the whole story — see business risk below.
Description: what the vulnerability is, in technical terms.
Business impact: what an attacker could actually achieve — the part that should drive your priority.
Proof of concept: evidence the issue is real and exploitable — a request, a screenshot, reproduction steps. If this is missing, the finding is unproven.
Remediation: specific steps to fix it. Generic advice ("apply patches") is a warning sign; good remediation is specific to your system.
// 04 Understanding severity and risk ratings
Severity tells you how urgently to act, but only if you read it correctly. Most reports use a five-level scale backed by CVSS, and the crucial nuance is that technical severity is not the same as business risk. A Critical CVSS score on an isolated internal test system may be less urgent than a Medium on your public login page. A good report separates the two; if yours does not, apply the lens yourself.
| Rating | CVSS (typical) | What it means for you |
|---|---|---|
| Critical | 9.0–10.0 | Fix now — serious, easily exploitable, high impact |
| High | 7.0–8.9 | Fix urgently — significant risk |
| Medium | 4.0–6.9 | Plan a fix — real but lower risk or harder to exploit |
| Low | 0.1–3.9 | Fix as hygiene — limited impact |
| Informational | 0.0 | No direct risk — awareness / best practice |
// 05 What to do with the report
A report is only valuable if it drives action. The worst outcome is to file it unread, because you now hold documented evidence of known, unfixed risk — a serious liability if you are later breached through one of those findings. Work it in a simple loop:
Triage
Sort findings by severity and business risk. Agree which are genuinely urgent for your context.
Assign
Give each finding an owner and a deadline proportional to its risk.
Remediate
Fix the criticals and highs first, following the report's specific guidance.
Retest
Have the tester verify the fixes actually closed the issues — not just that code changed.
Evidence
Keep the report and retest results for auditors, customers and your own record of closure.
// 06 Red flags of a weak report
If you are evaluating a report — your own or a vendor's — these signs mean it was a scan dressed up as a penetration test:
Findings with no proof of concept
Unvalidated scanner output. Without reproduction evidence, you cannot tell real issues from false positives.
Generic descriptions and fixes
Copy-paste CVE text and "apply the latest patch" with nothing specific to your environment.
CVSS scores with no business risk
A wall of numbers and no explanation of what an attacker could actually do to your organisation.
Hundreds of low-severity findings
Padding the report with noise instead of the handful of exploitable issues that matter.
A report built the right way looks different by design — see how we structure findings in our testing methodology.
// 07 Frequently asked questions
What sections are in a pentest report?
Executive summary, scope and rules of engagement, methodology, findings (each with severity, impact, proof of concept and remediation), and a remediation/retest section.
What do the severity ratings mean?
Critical, High, Medium, Low or Informational, usually backed by a CVSS score 0–10. A good report also states business risk, because the same score means different things on different systems.
What should I do after receiving it?
Triage, assign owners and deadlines, remediate criticals first, retest to verify, and keep the evidence. Never just file it — an unactioned report documents known, unfixed risk.
How do I spot a bad report?
No proof of concept, generic descriptions, CVSS scores with no business context, and hundreds of low-severity findings — the signature of scanner output rather than manual testing.