Quick answer: A penetration test report is not a technical list but a decision document. When reading it, look at three things: each finding's severity (critical, high, medium, low), its CVSS score (a standard risk rating from 0 to 10), and most importantly the proof of exploitability (a PoC showing the finding can actually be exploited). A good report explains each finding with the trio "what was found, why it matters, how to fix it." The critical mistake is reading a report by scores alone and ignoring business context: a low CVSS finding may be critical in your environment, and a high CVSS finding may sit on an unreachable system. The report is the starting point of prioritization, not the end.

You commissioned a penetration test and received a 60 page report, full of red and orange boxes, woven with technical terms. Now what? This is where most organizations struggle most: commissioning the test is easy, reading the report correctly and doing the right work in the right order is hard. This article explains how to read a penetration test report and interpret CVSS scores.

The sections of the report

A well structured penetration test report consists of these sections:

  • Executive summary. For non technical executives. Overall risk posture, the most critical findings and business impact. This is the section decision makers read.
  • Scope and methodology. What was tested, what was not, which standard (PTES, OWASP) was followed. This section defines the report's boundaries.
  • Finding details. For each flaw: description, severity, CVSS score, proof of exploitation and remediation advice.
  • Appendices. Raw output, screenshots, the list of scanned assets.

The most common mistake is jumping straight to the finding list and skipping the executive summary. Yet without understanding business impact you cannot correctly prioritize the technical list.

To understand why the methodology section matters, see our article on the PTES methodology.

What CVSS is and what the scores mean

CVSS (Common Vulnerability Scoring System) is an international standard scoring a vulnerability's severity between 0 and 10. Its purpose is to make different flaws comparable on a common scale.

CVSS range Severity Roughly means
9.0 to 10.0 Critical Urgent, usually remote and easily exploitable
7.0 to 8.9 High Serious, requires priority remediation
4.0 to 6.9 Medium Planned remediation, low impact alone
0.1 to 3.9 Low Limited impact, when there is time
0.0 Informational Not a risk, an awareness note

The CVSS score is computed from base metrics: attack vector (remote or local), attack complexity, privileges required, whether user interaction is needed, and impact on confidentiality, integrity and availability. These metrics combine through a formula into a single number.

The limit of CVSS: the score does not know business context

This is the most critical point. CVSS measures a flaw's technical severity but does not know the real risk in your environment. Two examples:

  • Low CVSS, high real risk. A CVSS 4.0 information disclosure looks unimportant alone. But if that disclosure opens the path to your customer database, it is critical for you.
  • High CVSS, low real risk. A CVSS 9.0 flaw on an internal test server never exposed to the internet, accessed only by authorized admins, has far lower urgency.

This is why mature organizations use two layers on top of the CVSS base score: environmental metrics (the flaw's position in your environment) and threat intelligence (whether this flaw is actually being exploited right now). CVSS version 4.0 emphasizes this contextual assessment even more.

In short: CVSS is the start of prioritization. The real decision emerges when you combine the score with business context.

The real proof: exploitability

The most valuable thing in a report is not the score but the proof that the finding can actually be exploited. Automated scanners report many "potential" flaws, and a significant share are false positives. A good penetration test validates the finding: it actually exploits it and provides a proof of concept (PoC).

When reading the report, ask this for every critical finding: was this actually exploited, or is it just a possibility a scanner flagged? A validated finding and an unvalidated alert carry entirely different priority. This distinction between detection and validation is what separates a penetration test from an automated scan. For the difference between vulnerability scanning and penetration testing, see our article on vulnerability scanning and management.

How to prioritize findings

After receiving the report, build the remediation order with these three questions:

  1. Is it exploitable and validated? Validated critical findings are at the top.
  2. What is the business impact? Does the flaw touch your most valuable asset or a trivial system?
  3. How easy is it to exploit? A flaw exposed to the internet and exploited in one step is more urgent than a complex chain.

A practical approach: internet facing, validated findings affecting a critical asset in the first 48 hours; high ones within a week; medium and low ones in the planned maintenance cycle.

After the report: retesting

The work does not end when you fix the findings. To confirm the fix actually worked, a retest should be done. A good penetration test service includes post remediation validation in scope. Saying "we fixed it" without a retest is an unproven claim.

For the full penetration test process, price and when it is needed, see our article on the penetration test process and scope.

Common mistakes

  • Looking only at critical and high findings. Chained low findings can be critical together.
  • Treating the CVSS score as the sole truth. The score does not know business context, you make the decision.
  • Mistaking an unvalidated scanner finding for critical. A finding without proof of exploitation is not the same priority as a validated one.
  • Not retesting. Only a retest proves the fix works.
  • Skipping the executive summary. Technical prioritization is impossible without understanding business impact.
  • Treating the report as a one time document. When the system changes, so does the risk; penetration testing should be repeated.

Frequently asked questions

Should I fix a CVSS 10 flaw immediately? Usually yes, but first confirm whether it is exploitable in your environment. If it is on an internet closed system, the urgency may change.

Do I have to fix every finding in the report? The ideal is addressing all of them, but the realistic approach is risk based prioritization. Start with critical and high.

What does false positive mean? A finding a tool flags as a flaw but that cannot actually be exploited. A good penetration test eliminates these.

Are CVSS and real risk the same thing? No. CVSS measures technical severity, real risk emerges with business context.

Is a retest paid? It varies by provider, but a good service usually includes post remediation validation in scope.

How often should I update the report? When the system undergoes major change and regularly, typically at least once a year with a new test.

Sources

To read your penetration test report correctly and prioritize findings by business context, or to commission a validated test, contact DSET. From our Ankara Hacettepe Teknokent laboratory we provide penetration testing, prioritization consultancy and retesting.