How to read a penetration test report without a security background

A penetration test report lands as a PDF somewhere between forty and two hundred pages long. It has an executive summary that reads like it was written last, a findings table colour-coded red through blue, and an appendix full of command output. Somebody has to decide what the organisation does about it, and that person usually does not have a security background.

The good news is that reading one properly is a skill, not a qualification. Four sections carry almost all the decision-relevant content, and two of them are the ones most often skipped.

Read the scope before you read the findings

The scope section is usually short, dry, and near the front, which is exactly the combination that gets it skimmed. It is the most important page in the document, because it defines what the rest of the report is allowed to tell you.

A report that says "no critical findings" means no critical findings in what was tested. If the scope was one public web application and the test ran for three days, that sentence says nothing whatsoever about your Microsoft 365 tenant, your VPN, your backups or the laptop in the reception desk drawer. This is not a criticism of the tester. It is the difference between the question you asked and the question you meant.

Five things to find on that page:

• What was in scope, by name — IP ranges, URLs, applications, cloud tenants. And what was explicitly excluded, which is often the more interesting list.
• How long the test ran. A time-boxed engagement is a sample, not a proof. A real attacker is not time-boxed.
• Whether the tester had credentials. An unauthenticated external test and an authenticated test as a standard user answer completely different questions. Most real compromises begin with a valid credential, so a test that never had one has not looked at the part of the attack most likely to happen to you.
• Whether anything was off-limits. No denial-of-service testing and no social engineering are both normal exclusions. They also happen to describe two of the more common ways organisations get hurt.
• The date. A report describes an environment on a particular week. If you have deployed anything since, the report is already partially historical.

What the severity ratings actually mean

Most reports rate findings Critical, High, Medium, Low and Informational, and most derive those ratings from CVSS — a published scoring system that turns the characteristics of a vulnerability into a number out of ten. It is a genuinely useful standard, and it is routinely read as something it is not.

A CVSS base score describes the vulnerability in the abstract: how hard it is to exploit, whether it needs credentials, what it gives up if it works. What it does not describe is your environment. The base score does not know that the affected server is a test box with no data on it, or that it is the machine your practice management system runs on. It does not know you already have a compensating control in front of it. CVSS has environmental metrics designed for exactly this adjustment, and in practice almost nobody applies them.

So the rating is a starting position, not a verdict. A Medium on the system holding client records outranks a High on an isolated development box, every time. Read the severity column, then re-sort it in your head by what the affected asset actually does for the business.

One rating deserves special attention regardless of what the number says: anything the report describes as having a public exploit, a proof-of-concept in the wild, or known active exploitation. That is a different category of urgency to a theoretical weakness of the same score, because the work of weaponising it has already been done by somebody else.

Three lows that are secretly a critical

The single most valuable page in a good report is the attack narrative — the section where the tester describes, in order, how they went from outside to inside. It is worth more than the findings table, because it shows how individually unremarkable findings combine.

A username enumeration flaw is a Low. A password policy that permits a predictable seasonal password is a Low. An account without MFA is a finding people argue about. Chained together, they are the path to a valid credential, and from there the report usually stops being boring. None of the three would have justified a project on its own.

If your report has no narrative — just a table of findings with no account of how they relate — that is worth raising with the tester. It is a fair thing to ask for and it is frequently the difference between a report that gets actioned and one that gets filed.

Informational, false positive, accepted risk

Not every finding needs fixing, and pretending otherwise is how remediation programmes stall. Three categories deserve a decision rather than a ticket.

Informational findings are observations — a version banner disclosed, a missing hardening header with no demonstrated impact. Some are worth a five-minute fix. Others are noise, and treating them as work makes the real list look longer than it is.

False positives happen, particularly where automated tooling contributed. If you think a finding is wrong, say so and ask the tester to confirm. A good one will either produce the evidence or withdraw it. What you should not do is quietly drop it, because in six months nobody will remember whether it was disproved or just ignored.

Accepted risk is a legitimate outcome. Sometimes the fix costs more than the exposure, or breaks something that matters more. The critical part is recording it: what the finding was, why it was accepted, who accepted it, and when it gets revisited. An undocumented decision to do nothing and an oversight look identical to an auditor, an insurer, and to you next year.

The order to actually fix things in

Working straight down the severity column is the obvious approach and rarely the best one. A more useful sequence:

• Anything internet-facing with a known exploit. Exposure plus a working exploit is the combination that gets found by automated scanning, which never sleeps and does not care how large you are.
• Anything on the path to a credential or to administrative privilege. These are the findings that turn a contained problem into an organisation-wide one.
• Findings that fix a class rather than an instance. If the report lists eleven servers missing the same patch, the finding is not eleven servers — it is patch management. Fixing the process closes the eleven and the next eleven.
• Everything else, on a schedule with a name against it. A remediation plan without an owner and a date is a list.

Expect a proportion of the report to be things you already knew. That is normal, and it is not wasted money — it is the difference between a concern and a documented finding you can take to a board.

The retest nobody books

Remediation is not finished when the ticket closes. It is finished when someone verifies the fix from the outside, and that verification is the artefact you will actually be asked for — by an insurer at renewal, by an enterprise customer running a supplier assessment, by a tender.

Many engagements include a retest window at no extra cost, and many organisations let it expire. Check your contract for one before you start remediating, because the window is usually measured from the report date rather than from whenever you get around to the work.

How to tell a pen test from a scan with a cover page

A vulnerability scan runs automated tooling against your environment and reports what it recognises. A penetration test has a human being attempting to combine what the tooling found into something that actually works. Both are useful. They are priced very differently, and they are not always sold under different names.

The tells are straightforward once you know to look:

• Is there an attack narrative, or only a findings table?
• Were findings manually verified, with evidence — a screenshot, a request and response, a reproduction step — or just listed with a scanner's default description?
• Does the remediation advice reference your environment, or is it generic vendor text that would appear identically in any other report?
• Are the testers named, and do they hold recognised offensive security certifications?

One more thing worth saying plainly: a penetration test is a poor first purchase for an organisation that has not yet done the basics. If MFA is not enforced everywhere, patching is ad hoc and nobody has tested a restore, the test will produce a long and expensive report confirming it. Do the foundations first and let the test find what the foundations missed.

Questions