Reading a penetration test report

A penetration test report can run to hundreds of pages, but only a few sections decide what you do next. Knowing how to read it saves time, stops panic and helps you defend the budget you need to fix the right things.

Start with the executive summary

The executive summary should tell you, in plain language, what was tested, what matters most and whether any findings were exploited. If it does not, ask the tester to rewrite it. A report that opens with page after page of methodology before stating a conclusion is a warning sign.

Understand the risk ratings

Most reports use Critical, High, Medium and Low. These are not absolute scores; they combine technical severity with business context. The same missing patch can be Low on an isolated lab and Critical on a public-facing production server.

Critical: exploited or trivially exploitable, with high business impact

High: serious exposure or a clear path to compromise

Medium: useful to attackers but usually chained with other issues

Low: informational or limited real-world impact

Map every finding to an asset and an owner

A finding without an owner is a finding that does not get fixed. For each item, identify the system, the person responsible and the change process. A report is only useful when it becomes a ticket.

Look at CVEs and exploitability

Common Vulnerabilities and Exposures (CVEs) are useful shorthand, but a CVE number alone does not tell you the risk to your organisation. Ask three questions:

Is the vulnerability present on a system we actually run?

Is there public exploit code or is it being actively exploited?

Can it be reached from the internet or an untrusted network?

A Critical CVE on a decommissioned internal server is very different from the same CVE on your public web portal.

Separate exploited from theoretical

The most important distinction in any report is whether the tester actually demonstrated impact. An exploited finding proves the path works. A theoretical finding still matters, but it should be scheduled differently.

Read the remediation advice critically

Good reports include specific, actionable fixes. Generic advice like 'apply patches' is not enough. Look for: the exact patch version, configuration changes, compensating controls if patching is not possible, and verification steps.

Prioritise by business impact, not just score

CVSS scores are a starting point, not a prioritisation system. A lower-scored finding on a payment gateway can be more urgent than a higher-scored finding on a non-production server. Rank by: exploitability, asset value, exposure and effort to fix.

Track retest status

A pen test is not finished when the report is delivered. It is finished when the findings are fixed and retested. Make sure the report includes a retest section or that you schedule one. Closed findings should be closed with evidence, not just marked done.

What to take to the board

Boards need three numbers: how many findings were exploited, how many are Critical or High, and how long the remediation plan will take. Everything else is supporting detail.