Writing a penetration test report
In short: The report is the product of a penetration test; if it is unclear, the test has failed. A good report gives leaders a plain summary of risk, gives technical teams reproducible findings with evidence and fixes, and supports a retest to confirm the issues are closed.
Why the report matters most
Clients pay for a penetration test to reduce risk, and the report is how that happens. Excellent testing with a confusing report leads to nothing being fixed. A report has at least two audiences: leaders, who need to understand business risk and decide on investment, and technical teams, who need enough detail to reproduce and fix each issue.
The executive summary
Keep it to one or two pages, in plain language, with no tool names or jargon. It should answer:
- What was tested, and why?
- What is the overall level of risk, and what could a real attacker achieve?
- What are the most important themes (for example, "patching of internet-facing systems is slow")?
- What should be done first?
Tell the story of impact: "From a standard staff laptop, testers gained control of the domain within one day by chaining three weaknesses" means more to a director than a list of CVE numbers. Include strengths too; it builds trust and shows what to keep doing.
Writing findings
Each finding should be specific and reproducible. Use a consistent risk rating that combines likelihood and impact in the client's context. Many testers include a CVSS score as well, but explain where your rating differs and why.
| Weak finding | Strong finding |
|---|---|
| "SQL injection found." | "SQL injection in the search parameter of /products allows reading the customer table." |
| Screenshot with no explanation | Numbered steps with the request, response and a highlighted screenshot |
| "Patch the server." | "Upgrade the package to the fixed version; as a short-term measure restrict access to the admin path." |
| Generic severity from a scanner | Rating explained with exposure and business impact |
Handle evidence carefully. Redact passwords, personal data and session tokens in screenshots. Reports are highly sensitive documents: encrypt them, share them only with named people, and agree how long working data is kept before secure deletion.
Remediation and retesting
- Give a short-term mitigation and a long-term fix for each high-risk finding.
- Group findings that share a root cause into a strategic recommendation.
- Hold a debrief call to walk through results and answer questions.
- Offer a retest once fixes are in place, and issue an updated report or letter showing which findings are closed.
Report critical issues as soon as they are found during testing, as agreed in the rules of engagement, rather than waiting weeks for the final document.
Tip: before sending, read your report as the client's busiest manager and as their most junior administrator. If either would be lost, rewrite. Good report writing is a major career skill for testers.
Practice
Who is the executive summary for, and what should it avoid?
Name four parts of a well-written finding.
Why should screenshots in a report be redacted?
Key takeaways
- The report is the product of the test; clarity is everything.
- Write for leaders in the executive summary and for engineers in the findings.
- Each finding needs a title, risk rating, description, evidence and fix.
- Protect reports and redact sensitive data in evidence.
- Debrief, then retest to confirm fixes and close findings.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.