What a Penetration Test Report Should Contain

A penetration test report should contain a one-page executive summary, a scope statement that says what was excluded, a short methodology, findings an engineer can act on without asking a question, a remediation summary and appendices. It is read by an executive deciding whether to worry, an engineer deciding what to change and an auditor deciding whether to accept it, and most reports serve one of them well and the other two badly.

The sections, and who each is for

A penetration test report template lays these out in order; what matters is knowing who each section serves.

1. Executive summary. One page, no jargon, answering four questions in this order: what was tested, what is the worst thing found, what does it mean for the business, what happens next. Not a severity tally. A count of highs tells a director nothing they can act on, which is the argument of writing an executive summary that gets read.
2. Scope statement. What was in, what was out, and the dates. The out-of-scope list is the more valuable half and it is usually missing.
3. Methodology. Short. Enough to show the work was structured, not a transcription of a public standard.
4. Findings. The body of the document, one entry each, ordered by severity.
5. Remediation summary. A table an engineering lead can turn into tickets without reading the whole thing.
6. Appendices. Tool output, host lists, anything long enough to interrupt the narrative.

What belongs in a finding

This is where reports differ most. A finding that an engineer can act on without asking a question contains all of the following, and one that is missing any of them will generate an email.

• A title that names the weakness, not the tool. "Authenticated user can read another organisation’s purchase orders" beats "Insecure Direct Object Reference".
• Where. The exact endpoint, parameter, host or file. Not "the application".
• Reproduction. Numbered steps that a competent developer can follow to see it themselves. If they cannot reproduce it, they will conclude it does not exist.
• Evidence. The request and response, or the screenshot, with anything sensitive redacted at the point of capture.
• Impact in your terms. Not the generic consequence of the vulnerability class. What an attacker gets in this system.
• Remediation that names the change. "Validate authorisation server-side on this endpoint against the authenticated session" is actionable. "Implement proper access controls" is not.
• A severity, with the reasoning. If you used CVSS, publish the vector, not just the number: many vectors give the same score and the vector is what somebody can argue with.

The six things reports leave out

• What was not tested and why. Without it, a reader assumes coverage you did not have, and that assumption outlives the engagement.
• The version or commit tested. A report about a system that has shipped forty times since is a historical document, and nothing in it says so.
• Positive results. The controls that were tested and held. It is evidence, it is short, and it stops the report reading as a list of everything that is wrong with the team.
• Effort. Days spent, so a reader can weigh the absence of findings appropriately. Two days finding nothing means something different from ten.
• Retest terms. When a retest is available, what it covers, and how long the result is valid for.
• A contact. A named person to ask, with a phone number, for the finding that turns out to be worse than it looked.

Length, and the trap of thoroughness

Long reports are not more thorough, they are less read. Padding usually comes from three places: a methodology section reproducing a public standard, boilerplate repeated in full for every instance of the same weakness, and raw tool output inline instead of in an appendix.

Fix all three by merging: one finding for one weakness with every affected host listed against it, and the evidence for each host in a table beneath. Eleven findings become one finding on eleven hosts, and the report gets shorter while saying more.

Severity, and the argument you are inviting

Every severity is a claim, and the report should make it possible to disagree with the claim without disagreeing with the finding. That means showing the reasoning: the vector if you scored with CVSS, and a sentence about the context you applied, because the same weakness on an internal tool and on an internet-facing platform is not the same risk. The usual CVSS scoring mistakes are where most of these arguments start.

Where you adjusted a rating up or down from the tool’s default, say so and why. A finding that arrives at medium with no explanation invites a client to argue it down to low, and you will be arguing from memory. A finding that arrives at medium with the reasoning attached is usually accepted, and where it is not, the disagreement is about something specific.

Write the remediation for the person who has to do it

The most common weakness in an otherwise good report is remediation written for the reader of the report rather than the person who will change the code. "Implement input validation" is addressed to a manager. "Bind this query parameter rather than concatenating it, in this handler" is addressed to a developer, and only one of those gets done this sprint. Writing remediation a developer will action goes into this in depth.

Where a fix has trade-offs, name them. Where there is a quick mitigation and a proper fix, give both and say which is which, because the team will do the quick one first whatever you write and it is better that they know it is temporary.

The format matters less than people argue about

PDF for the record, because it is fixed and quotable. Something structured for the engineers, because a table of findings that can be filtered is more use to them than a document. What matters is that both come from the same source, so the version an auditor reads and the version a developer works from cannot disagree.