A penetration testing report with eighty findings is not worse than one with twelve. It may be better, or far worse: it all depends on which findings they are, which are genuinely exploitable and how much damage they would do to your business. The most expensive mistake a committee makes on receiving a report is reading the total number rather than the real exploitability.
This article explains how to read a penetration testing report like a decision-maker: what it must contain, how to interpret severity, why CVSS is not the whole story and how to prioritise remediation of what actually matters. It closes the series alongside our articles on tools and penetration testing methodologies.
Anatomy of a good report
A useful report is not a list of vulnerabilities. It has an executive summary in business language, the exact scope of what was tested (and what was left out), the methodology followed and, for each finding, a description, the evidence that reproduces it, a justified severity and a concrete remediation recommendation. If the reproduction or the remediation is missing, it is not a report: it is a list.
The first sign of quality is honest and simple: does the provider distinguish what it tested from what it could not test? A good report states its limits. A bad report fakes full coverage.
Severity: CVSS is not the whole story
Most reports score severity with CVSS, now at version 4.0. The problem is reading only the base score. CVSS v4.0 explicitly separates the base (CVSS-B) from the threat and environmental metrics (CVSS-BT, CVSS-BE, CVSS-BTE), and it is precisely the latter —exposure and impact in YOUR environment— that turn a theoretical 9.8 into a high or an irrelevant risk for you. A high base CVSS on an isolated system with no data may matter less than a medium CVSS on your payment gateway.
Prioritise by real exploitability: EPSS, KEV and context
Technical severity is only one signal. To decide what to remediate first, cross it with the probability of exploitation and with exploitation observed in the real world. It is the approach we already argue for in KEV, EPSS and SSVC and one a good report should hand you.
| Signal | What it indicates | Source |
|---|---|---|
| CVSS v4.0 (base) | Intrinsic technical severity of the flaw | FIRST |
| EPSS | Probability of exploitation in the next 30 days | FIRST |
| CISA KEV | Confirmed exploitation in the real world | CISA |
| Environmental context | Real exposure and impact on your business | Your own judgement |
No signal decides alone. Priority comes from crossing severity, probability, real exploitation and context.
The EPSS estimates the probability that a flaw will be exploited within the next thirty days; the CISA KEV catalogue confirms what is being exploited already. A finding with a medium CVSS but present in KEV may deserve more urgency than a critical CVSS with no known exploitation and no exposure in your environment. Prioritising means crossing signals, not sorting by one column.
False positives and false negatives
A scanner-only report arrives full of false positives: findings that are not exploitable in your context and that drain the team's time. Worse are the false negatives: what the scanner did not see. Business logic abuses —a meaningful share of real critical findings— do not appear in automated testing, so a report with no logic findings is probably not a clean report but a shallow one.
That is why every relevant finding must come with reproducible evidence. If you cannot reproduce the step, you cannot verify the remediation or defend the decision to an auditor.
From finding to remediation: the cycle does not end at the PDF
The value of a test lies not in the report but in what you change afterwards. That means turning each finding into an action with an owner and a deadline, folding it into your vulnerability management and closing the loop with a retest that confirms the fix works. A finding "remediated" without a retest is an assumption, not a control.
Prioritising remediation by real risk —not by the colour of the finding— is what separates an executable plan from an impossible list. We develop this in vulnerability management: prioritising real risk.
What regulation demands about testing and its evidence
The report is not just a technical deliverable: in regulated environments it is evidence. PCI DSS 4.0.1 requires retaining penetration testing reports and re-testing after significant changes; DORA requires a formal TLPT attestation —under the TIBER-EU framework— for significant entities; NIS2 mandates demonstrating that the effectiveness of measures is assessed; and Spain's ENS requires documented penetration testing for medium and high categories. In every case, a report with no reproducible evidence and no retest is worth little to an auditor.
The essentials
Reading a penetration testing report well means moving from counting findings to assessing risk. Check whether each finding reproduces, cross severity with probability and real exploitation, distrust a report with no logic flaws, and always demand a retest. The test does not end when the PDF arrives: it ends when you have changed what that PDF flagged.