How to Write a Penetration Test Report People Actually Act On

A finding you discovered but could not get fixed is a finding that did not matter. The report is the mechanism by which technical work becomes organisational change, and it is where most otherwise good engagements lose their value.

Three readers, not one

Every report is read by at least three people who want different things, and writing for only one of them is the most common structural mistake.

The person who paid. They read the first page and nothing else. They want to know whether they are in trouble, how bad, and what it will cost to fix. No tool names, no CVE numbers.

The engineer who will fix it. They skip to their findings. They want exact reproduction steps, the affected endpoint or parameter, and a remediation that names the actual change rather than the principle.

The auditor or client's client. They want scope, dates, methodology and evidence that the work was real and competent.

Serve all three deliberately, in that order.

The structure that works

1. Executive summary — one page, no jargon.
2. Scope and dates — exactly what was tested, what was excluded, when, and from where. This is what makes the report usable as evidence.
3. Methodology — brief; the standard you followed and what the testing consisted of.
4. Findings summary — a table, ordered by the priority you recommend rather than alphabetically by severity label.
5. Detailed findings — one section each.
6. What was tested and found secure — the section everyone omits, and the one that proves depth. Without it a clean report looks like a shallow test.
7. Appendices — tooling, raw output, full endpoint lists.

Writing the executive summary

Write it last, and write it for someone who will read nothing else.

Weak: "The assessment identified 3 critical, 7 high, 12 medium and 9 low severity findings."

Strong: "We were able to read other customers' invoices by changing a single number in a web address, with an ordinary user account and no special tools. The same weakness affects four other parts of the application. The underlying cause is that the application checks who you are but not what you are allowed to see — a change to one shared component would close all five."

The second version tells a director what happened, how hard it was, how widespread it is, and that there is a single fix. The first version tells them to ask somebody else what it means.

Writing a finding

Each one needs six things:

• A title that states the issue, not the category. "Any user can read any other user's invoices" beats "Broken Access Control (IDOR)".
• Impact in business terms. What can an attacker do, and what does that mean for the organisation. Not "allows unauthorised access" but "allows any registered user to read every customer's billing records, including names and addresses".
• Reproduction steps precise enough to follow. The exact request, the exact parameter, the account used. If an engineer cannot reproduce it in five minutes, the finding will be disputed rather than fixed.
• Evidence. A screenshot or request/response pair showing the result. Redact real personal data — do not paste a genuine customer's record into a document that will be emailed around.
• Remediation that names the change. Not "implement proper access control" but "check that the requested order belongs to the authenticated user before returning it, ideally in the data access layer so every endpoint inherits it".
• Risk rating with your reasoning. A score alone invites argument; a sentence explaining why you rated it that way usually ends the argument.

Severity is not priority — say which you mean

A scoring system measures how bad an issue would be in a worst-case deployment. It does not know that one of your criticals needs administrator access nobody has been granted, while a medium sits on the public login page.

Give both: the standard score for comparability, and a recommended fix order reflecting what is actually reachable in this environment. Clients follow the order; the scores keep the auditors happy.

Report classes, not instances

Nineteen endpoints missing an ownership check are not nineteen findings. Written that way they produce nineteen patches and a twentieth vulnerable endpoint next month.

Write it once as the pattern — the application has no enforced authorisation layer, here are nineteen current examples, here is the single change that closes the class — and you have converted a bug list into a design fix.

Mistakes that get a report ignored

• Pasting scanner output. Clients recognise it immediately, and it devalues everything else in the document.
• Padding with informational findings. Thirty low-severity entries bury the three that matter.
• Generic remediation text. If the advice would apply to any application, you have not done the last step.
• No prioritisation. A list of forty findings with no recommended order gets filed rather than actioned.
• Sloppy writing. Typos and inconsistent formatting make a client wonder how careful the testing was. The inference is unfair and entirely predictable.
• Leaking live data. Real credentials, tokens or customer records in a report that will be forwarded internally is your finding becoming their incident.

Finish with the retest

State clearly what was retested, what is confirmed fixed, what is partially fixed and what remains. The retest letter is what clients hand to their customers and auditors, and it is frequently worth more to them than the original report.

A practical check before sending anything: could an engineer who was not in any of the calls fix the top finding using only this document? If not, the report is not finished, however good the testing was.

Frequently asked questions