What a good penetration test report looks like
Most pen test reports are scanner output with a cover page. Here is what to expect from a real one, and how to tell the difference before you sign.
We review a lot of penetration test reports written by other firms. Clients bring them to us when they are changing vendors, when an auditor rejected one, or when their engineering team read one and could not figure out what to do with it. The pattern is consistent enough to describe.
The bad ones are scanner output with a cover page. A list of CVEs, severity copied from the CVSS base score, no evidence anything was actually exploited, no context about what the affected system does, and a “remediation” column that says “apply the vendor patch.” The report is long, the findings are many, and nobody can tell what matters.
The good ones look different in ways you can check.
It states what was tested, and what was not
A real report begins with scope: the targets, the access levels used, the testing windows, and the exclusions. It also states limitations honestly. If a system was out of scope, if testing was halted to avoid disruption, if credentials for a role were never provided, the report says so, because those gaps change what the conclusions mean.
If a report has no limitations section, assume the tester did not think about what they missed.
Severity reflects your environment
CVSS base scores describe a vulnerability in the abstract. A “critical” base score on a system that is isolated, unauthenticated-access-only, and holds nothing sensitive is not a critical finding for you. A “medium” on the server that fronts your customer database might be the most important thing in the report.
Good reports rate severity with environmental context and explain the reasoning. The executive summary should reflect that reasoning: three things that actually matter, not a count of findings by color.
Every finding has evidence
Screenshots, request and response captures, command output, or a described reproduction path. Evidence serves two purposes. It lets your engineers reproduce the issue and confirm the fix, and it proves the finding is real rather than a scanner’s guess. Findings without evidence are claims.
The flip side: evidence should prove access without extracting data. A tester who demonstrates database access by dumping a table of patient records has created a second incident. The report should describe the approach taken to minimize exposure.
Remediation is specific and ordered
“Apply the vendor patch” is not remediation guidance. A good finding explains the root cause, offers specific fixes (configuration changes, code changes, architectural changes, compensating controls), notes dependencies, and estimates effort. The report as a whole orders remediation by a combination of severity and effort, so a team with limited time knows what to do first.
It is written for two readers
Leadership needs to understand exposure and priorities without reading exploit details. Engineers need enough detail to fix things. A good report serves both from one document: an executive summary that a board member can read, followed by technical findings an engineer can act on.
The debrief is part of the deliverable
The clients who get the most from a penetration test are the ones who get on a call with the tester afterward. The debrief is where the context lives: why a finding was rated the way it was, what the tester saw that did not become a finding, which fixes are quick wins and which need planning. A vendor that emails a PDF and disappears is leaving most of the value on the table.
One of our clients put it well after an engagement: what set the work apart was not the report but the walkthrough, where the engineers explained the real-world impact of each finding to the team that had to fix it.
The retest is included
Findings are not closed until they are retested. A report that does not come with a retest leaves you guessing whether the fixes worked. Retest should be part of the engagement, not an upsell.
A short checklist
Before you sign with a penetration testing vendor, ask to see a sanitized sample report and check for:
- Explicit scope and limitations
- Environmental severity, not just CVSS base scores
- Evidence for every finding, with an approach that minimizes data exposure
- Specific, ordered remediation guidance
- An executive summary a non-engineer can read
- A live debrief with the person who did the testing
- A retest of remediated findings
Sidechain performs every penetration test in-house and delivers all seven. A sanitized sample report is available on request, and our methodology describes how each engagement runs.
