Seven Things Every Pen Test Report Needs

The report is what you actually buy. Everything else is process, and you will forget it within a month. So it is worth knowing what a good one contains before you commission the work rather than after.

1. An executive summary a non technical reader can act on

Not a paragraph restating the scope. A short answer to three questions: what is the state of this system, what is the worst thing we found, and what should happen next.

Someone approving the remediation budget will read this page and nothing else. If it is written for engineers, the budget conversation goes badly.

2. Reproduction steps for every finding

The single strongest tell of real testing. A finding that says “the application is vulnerable to SQL injection” without showing the request, the payload and the response is an assertion. A finding with a reproduction path is evidence.

It also matters practically: your engineers will need to confirm the fix worked, and they cannot do that from a description.

3. Severity that is argued, not asserted

A CVSS score alone is a number, not a judgment. It does not know that the affected system holds no sensitive data, or that it is reachable only from a segmented management network, or that it fronts your entire customer database.

A good report shows the reasoning: what an attacker gains, what they need already, and how the finding interacts with your environment. Where a compliance regime is in play, severity should account for that too, because a SOC 2 auditor and a DoD prime care about different things.

4. Remediation specific enough to implement

“Implement input validation” is not remediation guidance. It is a category.

Useful guidance names the parameter, the endpoint, and the approach, and where there are trade offs it says so. If the real fix is architectural and expensive, the report should say that plainly rather than suggesting a filter that will be bypassed in a year.

5. Scope, stated honestly, including what was not tested

The most valuable paragraph in the report and the one most often missing.

What was in scope, what was excluded, what could not be reached, what was blocked by a WAF, and what ran out of time. A report that implies full coverage it did not have is worse than no report, because it creates confidence that is not warranted.

6. Evidence

Screenshots, request and response pairs, extracted data with the sensitive parts redacted. Enough that a reader who was not there can see what happened.

This is also what an auditor asks for when they want to know the test was real.

7. A retest path

A finding is not closed because a ticket says so. The report should say how remediation gets verified and when, and a good provider includes that verification rather than quoting it separately.

The tells, in one list

When comparing vendors, ask of each report:

• Does every finding have a reproduction path, or do some only assert a risk?
• Is severity argued, or is it a bare CVSS score?
• Does it say what was not tested?
• Is there anything in it a scanner could not have produced?
• Would an engineer know what to do on Monday morning?

Those questions are worth asking of our reports as much as anyone else’s, which is why we will show you one before you buy.