How to structure a penetration test report a client will actually read

A penetration test produces exactly one lasting artefact: the report. Everything else — the scans, the shells, the late nights — is scaffolding. Yet reports are usually written last, under time pressure, by the person most tired of the engagement. The result is a document that a technical reviewer cannot reproduce, an executive cannot act on, and an auditor cannot audit. Fixing that is mostly structure, and structure can be decided before the test starts.

Who is actually reading

Three audiences open the same file and want different things from it.

• The executive or budget holder wants to know: how exposed are we, in business terms, and what do we spend to fix it. They will read the first page and the severity summary.
• The engineer who has to fix it wants the exact request, the exact response, the affected parameter, and a fix that does not require guessing.
• The auditor or client's security lead wants scope, rules of engagement, methodology, evidence integrity and proof that nothing outside scope was touched.

Write each section for exactly one of them, in that order, and the report stops arguing with itself.

The sections, in the order a reviewer expects

1. Cover and document control. Client, engagement name, report version, date range of testing, classification (usually Confidential), and who authored and approved it. Version control matters: "final_v3_actually_final.pdf" is a red flag.
2. Scope and rules of engagement. Every host, URL, application and credential in scope; explicitly out-of-scope items; testing windows; permitted techniques; emergency contact. If you tested something that was not listed, it goes in a scope-deviation note, not quietly into findings.
3. Executive summary. One page. What was tested, the overall risk posture, the two or three findings that matter, and a recommended fix order. No jargon, no tool names, no CVSS decimals.
4. Methodology. Name the standard you followed — PTES, OWASP Web Security Testing Guide, NIST SP 800-115 — and say which phases were performed. A reviewer uses this to judge coverage: if you did not test authentication, say so.
5. Findings. The body. One finding per weakness, consistently structured (below).
6. Attack narrative. Optional but valuable: the chain from initial access to impact in plain prose. This is where the reader understands that five medium findings combined into a compromise.
7. Appendices. Raw tool output, evidence index with file hashes, accounts and artefacts created during testing, and anything the client must clean up or revoke.

The finding template

Every finding should contain the same fields in the same order. Ours:

Severity: CVSS is an input, not an answer

CVSS gives you a reproducible base score, and reproducibility is why it is worth including. It is also famously bad at expressing business context: a 9.8 in a marketing microsite with no data can matter less than a 6.5 in the system that moves money. State both — the score, and your contextual severity — and say in one sentence why they differ if they do.

Two habits undermine reports more than any other. Inflating everything to critical, which trains the reader to ignore the rating. And copying the vector string from a scanner without checking it: if the finding needs authentication, the vector metric should say so, and reviewers notice when it does not.

Evidence handling is part of the deliverable

Anything you present as proof should be traceable. In practice that means: keep the original capture files, hash them (SHA-256 is enough), record when each was captured and against which asset, and index them in the appendix so the client can verify the file they hold matches the one in the report. If you are working with disk images or seized material, the same idea scales into a full chain of custody with per-action audit entries.

Retain evidence for the period your contract specifies, and destroy it on schedule. A report that says "screenshots available on request" is a report nobody can audit in six months.

Writing style that survives review

• Statement, impact, evidence, fix — in that order, every time.
• Active voice, no adjectives: "the endpoint returned all 4,912 records" beats "a serious data leak was discovered".
• Never claim exploitation you did not perform. "Confirmed by executing the payload" and "indicated by the response body" are different findings.
• Redact credentials, tokens and personal data consistently, and say that you did.
• Quantify where you can: number of records, number of hosts, time to exploit.

Common reasons a report comes back rejected

1. No reproduction steps, so the fix team cannot confirm the issue exists.
2. Findings aggregated into one entry, so remediation cannot be tracked item by item.
3. Missing CVSS vector, or a vector that contradicts the description.
4. No retest criteria, so nobody agrees on when the item closes.
5. Scope deviations undisclosed.
6. Evidence without timestamps, or screenshots that cannot be tied to an asset.

Where automation helps, and where it does not

Tool output, hashing, evidence indexing, severity tables and the PDF layout are mechanical — a platform should do them, and ours does. What cannot be automated is the judgement: which findings matter, how they chain, what the business impact is, and what the fix should be for this specific codebase. That is the part reviewers pay for, and it is the part to protect when the deadline gets tight.