How to Read a Pentest Report: Severity, Proof, What to Fix First

A penetration test report is read by three audiences with three questions: management asks “how bad is it?”, engineers ask “what exactly do I fix and how?”, and customers or auditors ask “was it tested properly and is it fixed now?”. A good report answers all three in separate parts, and knowing where to look saves you from reading 80 pages to answer one question.

Here is how to read one, and how to tell a good one from a bad one.

What a good report contains

Expect these parts, in roughly this order. NIST SP 800-115 and the BSI’s practical guide for penetration tests describe the same structure.

Part	What it answers	Who reads it
Management summary	Overall risk, the three worst things, what to do first, in one to two pages without jargon	Management, customers, auditors
Scope and method	What was tested, from where, with which accounts, in which period, what was excluded, which standard was followed	Auditors, your security team
Findings overview	A table of all findings with severity, status and affected component	Everyone
Detailed findings	Per finding: description, affected component, reproduction steps with evidence, severity with reasoning, fix recommendation	Engineers
Attack chains	How findings combine; often the most important page	Security team, architects
Positive observations	What held up; useful for your auditor and your engineers	Security team
Appendix	Tools, test accounts, raw data, CVSS vectors	Whoever needs it

If the report has no scope section, no reproduction steps and the same generic text for every finding, it is a scanner export with a cover page. See penetration test vs vulnerability scan.

How to read the severity

Most reports rate findings as critical, high, medium, low and informational, with a CVSS score behind it. Three things to know:

The CVSS base score describes the vulnerability, not your risk. The score answers “how exploitable and how impactful is this in general?”. A good report also gives a contextual rating that takes your environment into account: is the system reachable from the internet, what data is behind it, which compensating controls exist. CVSS v4.0 has explicit environmental and threat metrics for this. If the report shows only base scores, do the context yourself before you plan.

Chains matter more than single scores. Three medium findings, information disclosure, a predictable identifier and a missing rate limit, can be one critical account takeover. The chain section of the report, or the management summary, is where the tester tells you this. Read it before the finding list.

Informational is not noise. Findings marked informational are things the tester could not exploit but that an attacker with more time or a future code change might: verbose errors, outdated libraries without a known exploit, missing headers. They are cheap to fix and belong in the backlog, not the bin.

In which order to fix

The practical order, in our experience:

1. Critical and high findings on internet-facing systems, especially anything that gives access to other users’ data or to code execution. Days, not weeks.
2. The chains. Break a chain at its cheapest link: one fix can turn a critical path into three harmless mediums.
3. Authentication and authorisation findings of any severity. These are the ones that scale: one IDOR is usually a pattern, not a single bug.
4. Everything else by severity, bundled by component so an engineer fixes a file once.
5. Root causes. If the report lists six injection findings in six places, the fix is a central input layer, not six patches. Ask the testers which findings share a root cause; good ones say it in the summary.

Set a deadline per severity level and write it into your vulnerability management process, for example 7 days for critical, 30 for high, 90 for medium. Auditors ask for exactly this.

Who gets which part

• Management gets the summary and the finding count by severity, plus the fix plan with dates. Not the 80 pages.
• Engineers get the detailed findings, ideally as tickets with the reproduction steps copied in. One ticket per finding, linked to the report ID, so the retest can reference it.
• Customers and auditors get the management summary and, after the retest, a letter stating what was tested, when, by whom and that the findings above a given severity are fixed. Ask for a redacted version if the full report would leave the company; reproduction steps for an unfixed finding should not travel.
• Your security team gets everything, including the raw data, and keeps it where the next tester can read it.

Signs of a weak report

• Findings with text that would fit any company (“outdated software may lead to compromise”) and no reproduction steps.
• A severity that equals the CVSS base score copied from a database, with no comment on your context.
• No scope statement, no list of what was not tested, no mention of access level or accounts.
• Hundreds of findings, most of them low and informational, and no chains: that is a scan.
• No positive section. A tester who looked at your login properly and found it solid should say so; your auditor wants to read it.
• A fix recommendation that says “fix the vulnerability”.

The retest and the final version

After you fix, the testers verify each finding and update its status: fixed, partially fixed, not fixed, accepted risk. The final report with the retest column is the document you keep and hand on. Ask for the retest in the offer; see our scoping checklist. Zyberum’s reports follow the structure above, CVSS scored and with a contextual rating, and the retest is included in every fixed-price offer. We do not issue certificates; the attestation letter states what we tested and found, nothing more.