How to read a penetration test report
Sorting the findings by severity and working down the list is the obvious approach and it will misdirect your engineers. A CVSS base score describes the worst plausible impact for any organisation running the affected component, in a default configuration, with no account taken of where the thing sits in your network or what data it touches. It is a comparison scale, not a work queue. The report is a set of facts, and turning it into a priority order is your job rather than the tester's.
Why is a CVSS score not a priority order?
Because the base metrics deliberately exclude your context. They describe the intrinsic characteristics of a vulnerability: how it is reached, how difficult exploitation is, whether privileges or user interaction are needed, and the effect on confidentiality, integrity and availability. Two systems with the same base score can carry completely different real risk, because one is internet-facing and holds cardholder data while the other is an internal reporting tool reachable by twelve people.
The standard itself anticipates this. CVSS provides further metric groups beyond the base, covering the current state of exploitation and threat intelligence, and an environmental group intended to let you adjust for the value of the asset and the mitigations already in place. Almost nobody uses them, so the number that reaches the report is the one explicitly designed not to know anything about you.
The consequence is predictable and visible in most remediation backlogs: a queue sorted by score, where a high-scoring issue on an isolated system is fixed before a medium-scoring authorisation flaw that lets any registered user read other customers' records. The second is the one that ends up in a regulatory notification.
Which severity signals should you actually combine?
Several exist, each measuring something different, and the useful practice is to read them together rather than choosing one. None of them is a risk rating on its own, because risk needs asset value and that lives only with you.
| Signal | What it measures | What it ignores | How to use it |
|---|---|---|---|
| CVSS base score | Intrinsic difficulty and impact in a default configuration | Your asset value, exposure and compensating controls | A comparison scale, never a queue |
| CVSS threat metrics | Whether working exploit code is known to exist | Whether anyone is targeting your sector | Escalate anything with public exploit code |
| CVSS environmental metrics | Your own adjustment for asset value and mitigation | Nothing, this is where your context belongs | The group worth actually populating |
| EPSS probability | Likelihood of exploitation being observed in the wild soon | Consequences if it happens to you | Ordering large volumes of scanner findings |
| Known exploited vulnerability catalogues | Confirmed real-world exploitation | Reachability in your specific deployment | Treat a listing as a hard escalation |
| The tester's own rating | Judged impact given what they saw in your system | Business impact they were not told about | Usually the most useful column in the report |
What should each finding contain?
Enough for an engineer who was not in the room to reproduce it, and enough for a manager to decide whether it matters. That means the exact request or command used, the response that demonstrates the issue, the affected component identified precisely rather than by product name, the specific impact in your system rather than a generic description, and a remediation recommendation that names the change rather than the principle.
Reproduction detail is the part most often missing and the part that determines whether the finding gets fixed. Validate user input is not a fix instruction. Reject requests where the account identifier in the path does not match the authenticated session, at this named handler, is. Where a finding was found in code, the file and function should appear.
Watch for findings without evidence. A report entry stating that a system is potentially vulnerable, or that a component version is affected by a published issue, is a scan result carried forward without verification. That is not dishonest, but it should be labelled, because the remediation effort and urgency for a confirmed exploited path and an unverified version match are not comparable.
How should you re-rank findings for your own estate?
Three multipliers do most of the work. First, exposure: is the affected surface reachable from the internet, from your corporate network, or only from a position an attacker would already have had to earn. Second, data and privilege: what does this component hold or grant, including onward credentials, because a low-value host that stores a deployment key is a high-value target. Third, whether exploitation is already known to occur in the wild.
Apply them as adjustments rather than a formula. An internet-facing authorisation flaw on the customer portal outranks a locally exploitable privilege escalation on a build server, regardless of which one scored higher, because one requires an attacker to already be inside. That reasoning should be written down next to the decision, so that when an auditor or a successor asks why a high finding was scheduled behind a medium one, there is an answer.
A test you can run this week: take your last report, add two columns for internet reachable and holds credentials for something else, and re-sort. If the resulting order differs substantially from the severity order you have been working through, your remediation queue has been ordered by the wrong thing.
What belongs in the executive summary?
What the tester achieved, what it would mean for the business, and what stopped them, in plain language and without a severity chart. The useful summary reads like a narrative: starting unauthenticated from the internet, we obtained an account, escalated to administrative rights, and could read all customer records. A summary that reports counts by severity band tells a board nothing actionable and invites the wrong question, which is how to reduce the count.
It should also state coverage honestly. Which parts of the scope were not reached and why, whether access delays cost testing time, and which areas the tester considers under-tested. That paragraph is the most valuable one in the document for planning the next engagement, and its absence is a warning sign.
If the summary contains a maturity score or a percentage secure figure, treat it as marketing rather than measurement. There is no accepted method for converting a time-boxed test into a security score, and presenting one to your executives creates a number they will ask you to improve.
What are the signs of a weak report?
Findings that could have been written without seeing your system. Generic entries about missing security headers, TLS configuration, cookie flags and verbose error pages padded out to fill a document, with no finding that required more than one step. Copy and paste remediation text lifted from a scanner's own advice, which is easy to recognise because it describes the product generally rather than your instance of it.
Volume itself is a warning. A long report is often a scan export with formatting, and the effort a tester spends filtering noise is effort spent on your behalf. Ask how many findings were discarded before writing, because a firm doing real work has an answer and a number.
The clearest test is to hand two or three findings to an engineer who was not involved and ask them to reproduce the issue from the report alone. If they cannot, the report will not survive the retest either, and you will end up paying twice: once for the finding, and once for the conversation about what the finding meant.
Common questions
- Why is CVSS not enough to prioritise fixes?
- The CVSS base score describes intrinsic characteristics in a default configuration and deliberately excludes your context, so two findings with identical scores can carry completely different real risk. The standard provides further metric groups for real-world exploitation and for your own environmental adjustment, which most reports leave unpopulated. Ordering a remediation queue by base score alone commonly puts an isolated high-scoring issue ahead of an internet-facing authorisation flaw.
- What should a penetration test finding include?
- The exact request or command used, the response demonstrating the issue, the affected component identified precisely rather than by product name, the specific impact in your system, and a remediation recommendation naming the change rather than the principle. Where the finding came from source review, the file and function should appear. If an engineer who was not present cannot reproduce it from the report alone, the finding is not finished.
- How do you re-rank findings for your own environment?
- Apply three multipliers: whether the affected surface is reachable from the internet or only from a position an attacker must already hold, what data or onward credentials the component grants, and whether exploitation of that weakness is already observed in the wild. Record the reasoning next to the decision, so a later auditor or successor can see why a high-severity finding was scheduled behind a medium one.
- What does EPSS add to a CVSS score?
- EPSS estimates the probability that a vulnerability will be exploited in the wild in the near term, which CVSS base metrics do not attempt. It is most useful for ordering large volumes of automated scanner findings, where severity bands leave hundreds of items looking equally urgent. It says nothing about consequences for you, so it complements rather than replaces asset context, and a listing in a known exploited vulnerability catalogue outranks both.
- Should a penetration test report give a security score?
- Treat any single maturity percentage or secure score with caution. There is no accepted method for converting a time-boxed test with a defined scope into an overall security rating, and the number invites executives to ask for improvement in the metric rather than in the findings. What an executive summary should carry instead is a narrative of what the tester achieved, what it would mean commercially, and what parts of the scope went untested.
- What does a weak penetration test report look like?
- It contains findings that could have been written without seeing your system: missing headers, TLS settings, cookie flags and verbose errors, with no finding requiring more than one step. Remediation text is lifted from scanner advice and describes the product generally rather than your instance. Length is not quality, since long reports are often formatted scan exports. Ask how many findings the firm discarded before writing, because real filtering produces a number.
