What a good penetration test report should contain

The test itself takes days. The penetration test report is what you keep for years. It goes to your board, your auditors, your customers’ security questionnaires and, most importantly, to the engineers who have to fix things. If it cannot do all of those jobs, the test was only half delivered.

These are the sections we think every penetration test report should have, and what separates a useful one from a padded one.

An executive summary a non-specialist can read

The first two pages should answer three questions in plain English:

• What was tested, and what was deliberately left out.
• How exposed you are, in terms of business impact rather than CVE numbers.
• What to do first.

If your managing director has to read past page ten to learn that customer data was reachable, the report has failed at its most basic job.

A precise scope and methodology

The scope section protects both sides. It should list every target (hostnames, IP ranges, application roles, API versions), the testing window, the source IP addresses used, and whether the test was black box, grey box or white box.

The methodology should name the frameworks followed, such as the OWASP Web Security Testing Guide or PTES, and say where the tester went beyond them. A report that says “we used industry-standard tools” and nothing else usually means an automated scan with a cover page.

Findings you can reproduce

Each finding should stand on its own, because it will often be copied into a ticket and read out of context. A good finding includes:

1. A clear title that describes the issue, not the tool output.
2. A severity rating with the reasoning behind it. CVSS is a useful baseline, but the rating should reflect your environment. An SQL injection on an internal test server is not the same as one on your checkout page.
3. Affected assets, listed exactly.
4. Step-by-step reproduction, with requests, responses and screenshots.
5. Impact, written as what an attacker could actually do.
6. Remediation guidance specific to your stack, not a link to a generic cheat sheet.

POST /api/v2/orders/export HTTP/1.1
Host: app.example.co.uk
Authorization: Bearer <token for user A>
Content-Type: application/json

{"accountId": "<account ID belonging to user B>"}

A request like the one above, together with the response showing another customer’s data, lets your developers confirm the issue in minutes instead of arguing about whether it is real.

Attack narratives, not just a list

Real attackers chain small weaknesses together. A verbose error message, a predictable identifier and a missing authorisation check might each be rated low on their own, but together they can mean full account takeover. The best reports include a short narrative showing how findings combine, because that is what drives the right priorities.

Positive observations

Knowing what held up is valuable too. If your rate limiting stopped credential stuffing, or your WAF blocked common payloads, the report should say so. It helps you avoid “fixing” controls that already work, and it gives an honest picture to anyone reading the report later.

Warning signs of a weak report

• Dozens of informational findings padding the page count.
• Severity taken straight from a scanner with no context.
• No reproduction steps, or screenshots of tool output only.
• Remediation advice that could apply to any company.
• No offer of a retest to confirm fixes.

After the report

A report is a starting point. Plan remediation in order of real risk, fix the root causes rather than individual instances, and book a retest so you have evidence that the issues are closed. That evidence is often what your customers and auditors actually ask for.

If you would like to see an example of how we structure our reports, get in touch and we will share a redacted sample.