How to read a penetration test report

A penetration test report is asked to do at least three jobs at once, for readers with almost nothing in common. An engineer needs to reproduce and fix each issue. A manager needs to know how much work is coming and in what order. An auditor or a customer needs to know what was examined, by whom, and what happened to what was found. A single document that serves all three well is unusual, which is why the same engagement is better presented in different profiles for different audiences than compressed into one file.

Read the scope statement first, before any of the findings. It tells you what the rest of the document can honestly claim. A report with no critical findings against a scope that excluded the administrative interface is telling you something quite narrow, and the finding list is not where that shows up.

Then read the dates. Testing dates and report date are usually separate and often weeks apart. The testing date is the one that matters for anything time-bound, including the observation window on a SOC 2 examination.

The test of a finding is whether an engineer who was not on the call can reproduce it, understand why it matters and fix it, without asking anybody a question. Judge every finding you receive against that.

If several findings share a root cause, a good report says so, because fixing the cause is one piece of work and fixing eight symptoms is eight. Findings we publish carry the CVSS vector, the affected endpoints and the request and response pairs that prove them, which is what lets an engineer start work without a handover meeting.

CVSS is a scoring system maintained by FIRST. The base score, which is the number you almost always see, is calculated from the intrinsic characteristics of the vulnerability: how it is reached, how hard it is to exploit, what privileges and user interaction are needed, and what it costs in confidentiality, integrity and availability. It runs from 0.0 to 10.0 and is usually presented as a severity rating.

The important point is one FIRST makes in its own guidance: CVSS measures severity, not risk. The base score is deliberately environment-independent, because it has to mean the same thing for a hospital and a games company. It knows nothing about whether the affected system holds your customer records or a copy of your marketing site, whether it is reachable from the internet, or whether a compensating control sits in front of it. Those are the questions that decide risk, and the base score is silent on all of them.

CVSS provides further metric groups for exactly this reason. Environmental metrics let you adjust a score for your own context, and threat metrics account for whether exploitation is actually being seen. Most reports quote the base score alone, so unless somebody has explicitly said otherwise, assume the number in front of you has had no knowledge of your environment applied to it. Version 4.0 of the standard restructures these groups and is being adopted gradually; version 3.1 remains what most tooling and most reports still use.

Two findings can share a score of 8.1 and deserve completely different responses. The one on the internet-facing service holding customer payment data is an emergency. The one on an internal tool reachable only from an administrator workstation, used by four people, is a scheduled piece of work. Nothing in the score distinguishes them, and a remediation plan built purely on severity ordering will spend its first week in the wrong place.

The factors the score cannot know

• Reachability. Who can actually get to the affected component, and what they need in order to be there.
• Data sensitivity. What is behind it, and what the consequence of losing it would be.
• Compensating controls. Something in front of the flaw may already reduce what an attacker can do with it, though it rarely reduces it to nothing.
• Exploitability in practice. A theoretically exploitable condition with no known technique is not the same as one with public tooling behind it.
• Chaining. A medium that grants the foothold for a critical is not a medium in your environment. Good reports say when a finding is a step in a chain.
• Business context. Regulatory exposure, contractual commitments and reputational consequence do not appear anywhere in a base score.

This is also why a report from a supplier who has never spoken to you tends to be less useful than one from a tester who understood what the system is for. The impact statement is where that understanding shows, and it is worth reading the impact of every finding even when you are triaging quickly.

Manual testing produces far fewer false positives than automated tooling, because a tester confirms an issue by exploiting it before writing it up. Fewer is not none. There are three things people usually mean when they say a finding is wrong, and they need different responses.

1. 1Genuinely incorrect. The behaviour described does not occur, or it occurs for a reason unrelated to what was concluded. Reproduce it, capture what you see, and send that back.
2. 2Correct but not exploitable here. The condition is real, but a control the tester did not know about prevents it being used. Say what the control is and how it applies, because the tester may still be able to get past it.
3. 3Correct and accepted. The finding stands and you have decided not to fix it. That is not a false positive, it is a risk acceptance, and it belongs in the next section.

Challenge with evidence rather than with assertion. A message saying we do not think this is exploitable moves nothing; a request and response showing the behaviour, or a configuration extract showing the control, gives the tester something to act on. A good supplier will either withdraw the finding, downgrade it with a note explaining what changed, or explain why it stands. All three are acceptable outcomes. What is not acceptable is silence, or a finding quietly disappearing between drafts with no record of why.

Have that conversation attached to the finding rather than in email, so the reasoning survives. On our engagements each finding carries its own discussion thread and an append-only history of every change, which means the question your engineer asked in March is still readable next to the finding in November.

Not everything gets fixed. A finding may sit in a component being decommissioned next quarter, or the fix may cost more than the exposure justifies, or the remediation may itself introduce a larger problem. Deciding not to act is a legitimate response and every standard that touches this expects it to be available. What separates an acceptance from negligence is entirely the record.

• A named owner. Not a team, a person, and somebody senior enough to carry the decision.
• The rationale, written for a reader who was not in the room and may be an auditor.
• The compensating controls relied on, if any, and how they were verified.
• A review date. An acceptance with no expiry becomes permanent by accident.
• The date the decision was made and by whom, so the timeline is reconstructable.

Auditors do not object to accepted risk. They object to undocumented accepted risk, because from outside it looks exactly like a finding nobody looked at. The same applies to a customer reviewing your report during a security review: an acceptance with a clear rationale reads as a functioning process, while an open finding with no annotation reads as neglect.

Work through this order rather than straight down the severity column. It usually reorders the top ten substantially.

1. 1Anything currently exploitable from the internet without credentials. Whatever its score, this is where an opportunistic attacker starts and it should be closed within days.
2. 2Anything giving access to data belonging to somebody who is not the requesting user. Cross-tenant and cross-account access is the category that causes the most damage per finding, and it is usually cheap to fix once located.
3. 3Anything that grants a foothold others depend on. Fixing the first step of a chain can close several findings at once, so read the report for chains before planning.
4. 4Root causes shared by several findings. One change closing eight rows is better value than eight separate changes, and it is more likely to hold.
5. 5High severity issues on internal or authenticated surfaces, ordered by who can actually reach them.
6. 6Everything else, batched into normal engineering work rather than treated as an incident.
7. 7Informational observations, which are for your backlog and for the next architectural decision rather than for this sprint.

Assign each item to the person who owns the code, not to a central security queue. Findings routed through a queue lose their context and sit. Where an outside contractor is doing the fix, they should be given the work without being given the estate: a membership can be narrowed to a single application, or an individual finding assigned so they see that and nothing else.

Then verify. A fix that was never checked by anybody outside the team that wrote it is an assertion, and several standards, PCI DSS 11.4.4 among them, expect verification rather than assertion. The PCI DSS guide covers that obligation in detail. Retests are included in our engagements, so a fix is ruled on by a tester rather than closed on trust.

Sending the full technical report to everybody is the default and it is a poor one. It hands a customer a working exploit description for a system they do not operate, and it buries the two facts an auditor needs under sixty pages they will not read.

Generating each of those from the same engagement, rather than editing a PDF by hand, keeps them consistent and keeps them current after a retest changes the status of something. Ours produces comprehensive, executive and framework-mapped profiles in Word, PDF and Excel, described on the compliance reporting page. If the report you have was produced by a supplier who gave you one PDF and nothing else, the comparison between platform-delivered and traditional engagements explains what the difference is in practice.