How to read a penetration test report
What each section of a penetration test report is for, how severity ratings work, and how to turn the findings into a plan your team can actually run.
A penetration test report lands in an inbox, and the first reaction is usually to scroll to the findings, count the reds, and feel either relieved or alarmed. Both reactions miss what the document is for. A good report is a plan, written for two readers at once, and it rewards being read in a particular order.
Start with the executive summary, but do not stop there
The executive summary exists so that a board, an audit committee or an insurer can understand the position without reading the technical detail. It should state what was tested, from where, and with what access; whether the tester reached anything that matters; and what the organisation should do first. If a summary reads as a list of vulnerability counts with no sentence about consequence, it has been written for the tester’s convenience rather than the reader’s.
Read it, then keep going. The summary tells you what happened. The findings tell you why, and the why is what your engineers need.
Understand the severity scale before you read a single finding
Every firm rates findings, and the words are similar everywhere: high, moderate, low, informational. The definitions are not. Before you weigh a “high”, find the page that says what “high” means in this report. At Aurian, a rating is threat likelihood multiplied by organisational impact, placed on one of six bands from informational to catastrophic, so two readers can see why a finding sits where it does rather than take the word on trust.
Two things follow. First, counts mislead. One critical finding on the remote-access appliance matters more than a dozen lows on internal test systems. Second, severity is about your environment, not the vulnerability in the abstract. The same weakness is rated differently on a public portal and on an isolated management network, and a report that ignores that context is applying a scanner’s judgement rather than a consultant’s.
Read each finding as a small argument
A well-written finding has the same parts every time: what was found, on which asset, the evidence, what it means, and what to change. The evidence is the part most readers skip and the part that most deserves attention. A request and its response, a screenshot, a command and its output: this is how you confirm the finding is real, reproduce it after a fix, and know when it is closed.
The remediation should be specific enough for an engineer to act on without a second conversation. “Harden the server” is not remediation. “Remove the ENROLLEE_SUPPLIES_SUBJECT flag from the CorpComputer certificate template, or restrict enrolment to a named group” is.
Look for the path, not only the list
The most useful section of any internal network report is the one that shows how findings joined together. A weak service account password and a misconfigured certificate template are two medium-looking findings on their own. Chained, they are a route from a phished user to domain administrator in an afternoon. A report that draws that path, step by step, also tells you the single change that would have broken it, and that is usually the highest-value fix in the document.
If the report you are reading lists findings without ever joining them, ask the tester where the path was. If there was none, that is worth knowing too.
Turn it into a plan
Order the work by risk reduction and effort, not by severity alone. Two questions sort most findings quickly: what does closing this stop an attacker doing, and who has to do it? A critical finding that one person can fix this afternoon goes first. A medium finding that requires a vendor upgrade across forty sites goes into the programme with a date. Systemic findings, the same weakness across many systems, point to a standard or a process to change rather than a ticket per host.
Then schedule the retest. A finding is closed when it has been tested again and the report has been updated, not when a ticket has been marked done. Fixes land in the wrong environment, get applied partially, or are reverted by the next deployment more often than anyone would like, and a retest is how you find out before an attacker does.
Keep it
The report from this year is the baseline for next year. Keeping it, with the retest results, lets the next engagement start from a known state and lets the board see a trend rather than a snapshot. Aurian’s own report structure and severity scale are described on the how we work page, and the remediation support and retesting service exists for teams that have the report and want help getting from findings to closure.
To find out how Aurian can help your organisation assess its exposure, get in touch.