October 18, 2026

What's in a penetration test report?

A penetration test report says what was tested, when, by whom, what was found, how serious each finding is, how to reproduce it and how to fix it. A good one is written in two layers: a summary in plain English for the person who asked for the test, and technical detail for the developers who’ll fix things. We publish a full sample report so you can see one before you book.

The sections

Our reports follow the same shape every time, so a customer who has seen one knows where to look in the next.

1. Introduction. The dates, what kind of test it was, who led it and the methodology it followed.
2. Scope. Exactly what was tested: the addresses, apps, APIs or IP ranges you supplied, and what access we had, whether that was no accounts or a login for each role. Anything not listed wasn’t tested, and the report says so.
3. Open source intelligence. What we could find about you from the outside before touching anything: subdomains, forgotten hosts, email addresses.
4. How to use this report. Which section is for whom.
5. Executive summary. Two or three pages in plain English. What the serious findings mean for the business, what was good, and a short list of actions in priority order. This is the part your customer or auditor reads.
6. Technical summary. For each finding, how we found it, the steps to reproduce it, screenshots, and what we could do from there. If one finding led to another, the chain is laid out in order.
7. Vulnerability summary. One table with every finding, its severity and its status, for the people who want the list without the prose.
8. Vulnerability details. The reference entry for each finding: affected hosts or endpoints, evidence, and the fix, with links to vendor guidance where it exists.
9. Tools used. What was run during the test, so your own team can run the same checks later.

What your customer or auditor looks for

Most security questionnaires and audits ask for the same things, and they check the report for each. They want to see that the thing they care about was in scope and that the test is recent, usually within the last twelve months. They want it done by an independent third party, named, using a methodology they recognise. And they expect findings. A report with none makes an auditor suspicious.

The one companies miss is proof of fixing. The first report shows what was wrong. The retest report shows it has been put right, and that is the one the questionnaire is asking for. We issue it at no charge once you’ve fixed things.

Send the sample report to your customer before booking if you want to be sure it covers what they need.

What your developers need

Developers don’t read the executive summary. For each finding they need to know where it is, how to reproduce it and what to change, and they need all three to be exact. Where means the host, endpoint, screen or parameter, down to the request that was sent. “The login page” is not enough to go on. Reproducing it means steps a developer can follow in ten minutes to see the problem themselves, before and after the fix. What to change means a specific change, and where a framework setting or a vendor patch solves it, the report names it.

Then a call. We walk through the findings with the people who’ll fix them, so their questions get answered while we’re all on the line rather than by email afterwards.

What a report shouldn’t be

A scanner export. Hundreds of rows of “informational” findings, each with a generic paragraph copied from a vulnerability database, sorted by a score nobody can act on. Those reports exist because they’re cheap to produce. Your customer’s security team has seen plenty of them and won’t accept one in place of a test. If you’ve been handed one, the difference between a penetration test and a vulnerability scan is worth five minutes.

Download the sample report, or tell us what you need tested and we’ll quote it after a short call.