Reading a penetration test report without panicking

The report lands, it is ninety pages, and the executive summary opens with a chart in which most of the bars are red. Somebody forwards it to the board within the hour. By the afternoon the conversation is about whether the organisation has been hacked, which is not what the report says and not the question worth asking.

A penetration test tells you what a motivated attacker could reach in a fixed window with a defined scope. Reading it well means separating that finding from its severity label.

Read the scope before the findings

The scope section determines what the report can and cannot tell you. Check four things: which systems were in scope, whether testing was authenticated or unauthenticated, whether it was black box or informed, and how many days were spent.

A clean report from a three-day unauthenticated external test says considerably less than a clean report from a two-week authenticated review of the same estate. Neither is wrong; they answer different questions. The most common misreading in a board pack is treating a narrow scope as a broad assurance.

Severity is not priority

Most reports score findings with CVSS, which measures technical severity in the abstract. It does not know that the affected server holds no production data, or that the vulnerable interface is reachable only from an office network with fourteen people on it.

Re-rank the findings yourself against three questions, in this order.

1. Is it reachable from the internet, or does it require a foothold the attacker does not yet have?
2. What does it reach — customer data, funds movement, administrative control, or a test environment?
3. Is it chainable? A medium finding that turns a foothold into domain administrator outranks an isolated high.

This reordering routinely moves two or three findings to the top and moves several criticals down a page. It also gives you an answer for the board that is about consequence rather than colour.

What to fix this week

Some categories deserve action before the remediation plan is even written, because they are cheap and they close the paths attackers use first.

• Credentials that were found, guessed, or reused. Rotate them, and check where else they worked.
• Anything internet-facing that grants administrative access — management interfaces, remote access without multi-factor authentication, forgotten staging environments.
• Publicly known exploited vulnerabilities on internet-facing services. These are being scanned for continuously by people who are not your tester.
• Data exposed without authentication, including backup files and directory listings.

Everything else belongs in a remediation plan with owners and dates. Trying to fix ninety findings simultaneously reliably produces none of them fixed.

The findings that are really one finding

Long reports inflate. Twelve findings of “missing security header” across twelve hosts is one configuration standard that was never applied. Fifteen instances of outdated software is one patching process that does not cover that class of asset.

Group the findings by the control that failed rather than by the host that exhibited it. The list shortens dramatically, and what remains is a set of process fixes rather than a backlog of tickets. This is also the version of the analysis that stops the same report arriving again next year.

Questions to put to your tester

• Which finding would you exploit first, and what would you reach with it?
• What did you not get to, and what would you look at with another week?
• Which of these would a commodity attacker find, as opposed to one targeting us specifically?
• What evidence do you need to confirm a fix, and is a retest included?

A good tester answers these directly. The first question in particular usually produces a sharper prioritisation than the severity column does.

Close the loop in writing

A finding is closed when it has been retested and confirmed, not when a ticket was marked done. Keep the retest evidence with the original report. The next auditor, regulator or enterprise customer who asks about your security posture will want to see the pair, and producing them together is the difference between a short conversation and a long one.

The report is not a verdict on your organisation. It is a map of the paths that were open on the days somebody looked.

Treated that way, a first penetration test is one of the better value assurance exercises available. The panic is optional; the prioritisation is not.