What a penetration test report should contain, and how to spot a scanner export
A report arrives. An engineer opens it, cannot reproduce the third finding, and quietly stops trusting the rest. An executive opens it, reads a summary written for a different executive at a different company, and learns nothing. A customer’s reviewer opens it, finds no scope statement, and asks for another one. The report had two audiences and served neither.
The short version
A useful report answers four questions in order: what was tested, how, what was found, and what to do about it. Everything else is packaging. The two audiences are an engineer who has to fix something and a reader who has to decide something, and a report that does not separate those two jobs will be read badly by both.
Length is not the measure. A report with eleven real findings, each reproducible, is more valuable than three hundred pages of exported scanner output, and the section that matters most is usually under two pages.
The scope statement
First section, no exceptions. It names the assets tested, by hostname or application name; the environment; the roles tested from; the dates of the window; and — the part most often missing — what was explicitly excluded.
The exclusions matter more than the inclusions when somebody reads the report a year later. A reader who does not know that the administrative interface was out of scope will assume it was tested and found clean, which is the most dangerous kind of misreading a report can produce. Getting this right starts before the engagement, in the scope document.
Methodology, and why naming it matters
A named methodology lets a reader check coverage against something public. For web applications that is normally the OWASP Web Security Testing Guide, with the category framing of the OWASP Top 10:2025 used to group what was found. Name the edition; the 2025 list renumbered the categories and a bare category reference is now ambiguous.
A methodology section that describes a general philosophy of testing, with no public reference and no list of what was attempted, is decoration. It is also the section a customer’s security reviewer reads to decide whether to take the rest seriously.
An executive summary an executive can use
Three things, in under two pages. What was tested and what was not, in a sentence. What the overall picture is, stated as a judgement rather than a count — “access control between tenants held; the weakness is in how the system behaves when a dependency fails” is a judgement, “14 medium findings” is not. And what the reader should do in the next month.
It should be readable by somebody who was not involved in the engagement and will not read the rest. If the summary is a table of severity counts, the supplier has handed the interpretation back to you.
Findings: the anatomy of one that works
Each finding needs six parts, and a report that drops any of them is asking its reader to do the work.
| Part | What good looks like |
|---|---|
| Location | The exact endpoint, parameter, screen or component — not “the application” |
| Reproduction | Numbered steps a developer can follow, with the request and the role used |
| Evidence | The response, the screenshot or the record that proves it, redacted where needed |
| Severity with a basis | A rating plus the reasoning — which scale, and what pushed it up or down in this environment |
| Business impact | What an attacker gains, in the language of your business rather than the tool’s |
| Remediation | A specific change, not “validate input” — and where the fix belongs in the code or the configuration |
Severity deserves particular attention. A rating imported unchanged from a public scoring system is a rating that knows nothing about your environment. The same weakness is not equally severe on an internal tool behind a corporate login and on a public endpoint holding customer data, and a report that rates them identically has not been thought about. Our worked example of a single finding shows the whole shape on one page, which is faster than any description of it.
Attack-path narratives
Where findings chain, the chain is the finding. A narrative section walks through it in order: this disclosure produced an identifier, this endpoint accepted it without an ownership check, this returned a token with the wrong scope, and this is what that token reached.
Without the narrative, each step is rated individually — low, low, medium, low — and a remediation team fixing by severity will fix the medium and leave the path open. Chained findings are the main thing a human-led engagement produces that other approaches do not, which is the distinction drawn in pentest vs vulnerability scan.
The retest section and the testing letter
A report that will be retested should say so and leave room for it: each finding gets a status when the retest completes, with the date and what was verified. Statuses should be honest — fixed, partially fixed, not fixed, risk accepted by the client — and the partial category is the one that gets quietly dropped when a supplier wants a clean page.
A testing letter is a short document confirming that an engagement took place against a named scope in a named window, and what its outcome was. It records that testing was performed. It carries no opinion, and it is not an examination artifact of the kind a CPA firm issues. What a letter like that is good for is telling a procurement reader, without handing over the report, that an engagement happened against a defined scope on defined dates and that the findings above a given severity were resolved. What it is not good for is standing in for the report with a reviewer who wants to see the scope and the method.
Appendices worth having
- Tooling and versions. What was run, so results can be reproduced later.
- Accounts used. Which test accounts, so you can confirm they were disabled and reconcile the activity in your logs.
- Timeline of activity. Useful when somebody asks what caused the alerts on the Tuesday.
- Informational observations. Things that are not findings but are worth knowing, kept separate so they do not inflate the counts.
Signs you were handed a scanner export
The tells are consistent: no scope statement, findings with no reproduction steps, severities with no stated basis, identical wording repeated across findings, and no narrative anywhere showing that two findings were joined together.
Four tells
Unfiltered findings, including ones plainly not applicable to your stack. Reproduction sections that say “see the tool output”. A severity column with no rationale anywhere in the document. And no scope statement — because a tool does not have a scope, it has a target list.
A fifth, softer tell: the remediation text is generic advice that would appear identically in any other report. Real remediation names your framework, your configuration file or your middleware.
What your customer will look at
In our experience of reading these on both sides of a deal, a reviewer goes to four places. The date, to see whether it is current. The scope, to see whether it covers the product they are buying. The unresolved findings, to see what is still open. And the methodology, to decide whether the supplier is credible.
If the report is heading into a procurement file, it usually travels with other material — architecture description, policies, roadmap. That bundle is the evidence pack, and a report that sits properly inside one answers more questions than a report sent on its own.
Asking for a better report next time
Put the deliverable in the scope document, not in the hope column. Ask for: reproduction steps for every finding; severity with a stated basis; an executive summary of no more than two pages written for a non-technical reader; an attack-path section where findings chain; and a retest section with per-finding status. Ask for a redacted sample before you sign.
A report can be shared with a customer when the engagement letter permits it, and the usual arrangement is a redacted version under a non-disclosure agreement — scope, methodology, summary and remediation status, without the reproduction steps that would hand a reader a working exploit. Agree that clause at the same time, because retrofitting permission to share is harder than granting it up front. Our own testing work, and what it delivers, is described under penetration testing.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Can we share the report with customers?
A report can be shared with a customer when the engagement letter permits it, and the usual arrangement is a redacted version under a non-disclosure agreement — scope, methodology, summary and remediation status, without the reproduction steps that would hand a reader a working exploit.
What is a testing letter, and what can it say?
A testing letter is a short document confirming that an engagement took place against a named scope in a named window, and what its outcome was. It records that testing was performed. It carries no opinion, and it is not an examination artifact of the kind a CPA firm issues.
How long should a penetration test report be?
Length is not the measure. A report with eleven real findings, each reproducible, is more valuable than three hundred pages of exported scanner output, and the section that matters most is usually under two pages.
How do we tell a real report from a scanner export?
The tells are consistent: no scope statement, findings with no reproduction steps, severities with no stated basis, identical wording repeated across findings, and no narrative anywhere showing that two findings were joined together.
Reading a report you already have
Send the scope page and the first finding. The reply says what the report is and what it is missing. More of our writing is indexed at writing.