Most people looking for a sample penetration test report are doing one of two things: checking whether the report they just received is any good, or working out what to demand before they commission a test. Both are the right instinct. The report is the entire deliverable, and its quality varies more between providers than the testing does.
Several firms publish redacted samples, and reading two or three before you commission work is the cheapest preparation available. This guide covers what a competent report contains, how to spot one that is scanner output in a template, and what to do with it once it lands.
The structure a competent report follows
Reports vary in house style but the useful ones carry the same seven parts.
The part most often missing is the methodology statement. Without it you cannot tell whether "no findings in the payment module" means the module is sound or that it was never tested. A report that does not state its own coverage is not evidence of anything.
Reading the executive summary properly
The executive summary exists so a director can make a decision without reading the technical body. Judge it on whether it answers three questions: what is the overall risk position, what must be fixed before the next release, and has anything changed since the last test.
Be sceptical of a summary that leads with counts. "We found 3 high, 7 medium and 24 low severity issues" is a shape, not a risk position. Twenty four low severity findings in an internal admin tool matter less than one high in a public payment flow, and a good summary says so in words.
Watch for severity inflation too. Providers are commercially motivated to find something serious, and a report where routine configuration observations are rated high is either poorly calibrated or deliberately alarming. Check the justification for each high rating against the actual business impact.
Reading an individual finding
Each finding should carry enough for a developer to reproduce and fix it without contacting the tester.
The reproduction steps are the test of a real finding. A finding described only in general terms, with no specific request, parameter or sequence, was probably lifted from a scanner's description library rather than demonstrated against your application.
Evidence should be specific to your system. A screenshot of your application showing the flaw is evidence. A generic diagram of how the vulnerability class works is documentation, and its presence in place of evidence is a signal.
Telling a real test from a scan with a cover page
This is the distinction that determines whether you got value, and it is visible in the report without any security expertise.
The strongest single check: look for findings that no automated tool could produce. Broken authorisation between two user accounts, a business logic flaw that lets a workflow be skipped, a race condition in a checkout, a privilege escalation across a tenancy boundary. These require a human who understood your application. If every finding is a missing header, an outdated library or a TLS configuration note, you have bought a scan.
Ask the provider directly to point at two such findings in a sample report before you sign. A good provider answers immediately and enjoys the question.
Severity ratings, and how to read them sceptically
Most reports rate findings using CVSS, which produces a number between zero and ten. It is useful and it is regularly misapplied.
CVSS measures technical severity in the abstract: how exploitable is this flaw, what does it compromise, does it need authentication. It does not know which of your systems matters. A high rated finding on an internal tool behind a VPN, reachable by twelve trusted employees, may be far less urgent than a medium in your public checkout.
So read the rating as an input to your decision rather than the decision. The question to ask of each finding is what an attacker actually gains in your environment, and a good report answers that in the business impact field rather than leaving you to infer it from a score.
Two patterns are worth treating as warnings. Severity inflation, where routine configuration observations are rated high, suggests a provider demonstrating value rather than calibrating honestly. The reverse, everything rated low or informational, can indicate a tester who did not reach anything interesting and is padding the document.
If a rating looks wrong in either direction, ask the provider to justify it. The quality of that answer tells you a great deal about the quality of the testing.
What to do with the report once you have it
Triage by business impact rather than by the severity column. The provider knows security; you know which systems hold what and which ones are exposed. A medium rated finding in your payments path may outrank a high in an isolated internal tool.
Create a ticket per finding in your own tracker rather than working from the PDF. A report as a document gets read once and filed. Findings as tickets get assigned, estimated and closed, and you can prove what happened to each one.
Agree remediation deadlines by severity when you commission the test, not when the report lands. Arguing about timelines while holding a list of live vulnerabilities is the worst moment to be having that conversation.
Book the retest. A finding you have fixed but never had verified is a finding you are guessing about, and the most common gap between a report and an actual improvement in security is the absence of verification.
The retest section, and why its absence matters
Most reports you receive describe a moment in time and stop. The retest section is what converts a list of problems into evidence that they were solved.
A complete retest records each original finding, what was changed, whether the fix was verified, and the date. Without it you have your developers' word that something was fixed, which is not the same as somebody having tried to exploit it again and failed.
This matters commercially as well as technically. If a customer or an auditor asks for evidence of your security posture, an original report showing eleven findings is a liability on its own. The same report with a verified retest showing all eleven closed is an asset.
Watch for partial verification too. A retest that confirms the fix in the specific endpoint that was reported, without checking whether the same flaw exists in three similar endpoints, leaves you exposed while looking closed. Ask whether the retest covered the class of issue or only the instance.
Using published samples well
Several security firms publish redacted reports, and they are worth reading before you commission work. Read them for structure and depth rather than for the findings themselves, which are specific to somebody else's system.
Compare two samples from different providers on the same criteria: does each finding carry reproduction steps, is the evidence specific, is the methodology stated, does the remediation advice reference the actual code pattern or just the vulnerability class. The difference between a thorough provider and a thin one is obvious within ten minutes when you read them side by side.
Then ask your shortlisted provider for their own sample. A refusal at that point tells you what you need to know.
Handling the report as a sensitive document
A penetration test report is a precise description of how to compromise your systems. Until every finding is fixed and verified, it is one of the more dangerous documents your organisation holds.
Control distribution deliberately. It needs to reach the engineers who will fix the findings and the people accountable for the risk. It does not need to sit in a general engineering channel or an open drive folder, which is where these documents usually end up within a week of arrival.
Agree retention with the provider in the contract. Some firms keep client reports indefinitely on their own infrastructure, and that is a copy of your vulnerabilities outside your control. Ask where it is stored, who can access it, and when it is deleted.
If you share the report with a customer or an auditor, share the retest version rather than the original. The original shows unresolved problems, the retest version shows problems found and closed, and the difference in how each reads is considerable.
Commissioning with the report in mind
The time to influence report quality is before the engagement, not after it.
Put the reporting requirements in the statement of work. Specify that every finding carries reproduction steps, evidence taken from your own system, and remediation guidance that references your stack. Specify that negative results are recorded, so a component tested and found sound is documented as such rather than omitted.
Ask for a redacted sample during procurement and read it properly. Reports are the part of the deliverable providers vary most on, and the sample is an accurate preview because it is what they chose to show.
Agree the delivery format too. A PDF is standard and largely useless for tracking work. Ask whether they can supply findings in a structured format, or import directly into your tracker, so the remediation work starts from tickets rather than from somebody transcribing a document.
Finally, schedule the retest in the original contract with a date. A retest that has to be commissioned separately after the fixes are done competes with other work for budget, and frequently loses.
Related reading
For the engagement side of this, see our guides on penetration testing of web applications and penetration testing tools.
If you want help reviewing a report you have received, our VAPT testing team can go through it with you.