How to write a penetration testing report your engineering team will actually read
Most pen-test reports are 200 pages of CVSS scores nobody acts on. Here's the format we use instead.
Most penetration testing reports are written for compliance, not for action. They're long, jargon-heavy, and structured around CVSS scores rather than engineering priority. Here's the format we've developed over sixty-plus engagements.
- The problem with traditional pen-test reports
- Structure: what our reports contain
- The reproduction steps section is the most important part
- Retest every finding before closing
The problem with traditional pen-test reports
A typical pen-test report from a legacy security firm runs 180 to 250 pages. The executive summary is three pages of risk ratings. The finding descriptions are copy-pasted from NIST references. The remediation recommendations are generic — 'implement input validation', 'use parameterised queries' — without any reference to the actual codebase.
Engineers read the first ten pages, look at the finding count, and close the PDF. The security team logs the engagement as complete. The vulnerabilities remain.
Structure: what our reports contain
Executive brief (one page): the three most critical findings, their business impact, and whether there are any that need to be remediated before the next deploy.
Finding log: every finding with reproduction steps specific to the target application, a screenshot or HTTP request/response pair where applicable, CVSS score, business impact in plain English, and a remediation recommendation written as a developer task.
Risk register: a prioritised table sorted by exploitability × impact, not CVSS score alone. A CVSS 9.8 that requires physical access to exploit is lower priority than a CVSS 7.2 that can be reached from the public internet.
The reproduction steps section is the most important part
If an engineer can't reproduce a finding from the report, the report is worthless. We write reproduction steps as if we're writing a GitHub issue — with a clear precondition, a numbered sequence of actions, and an expected vs. actual result.
For web application findings we include the full HTTP request, the response that demonstrates the vulnerability, and a modified version of the request that would prevent the vulnerability. Engineers can often fix the issue before they finish reading the finding.
Retest every finding before closing
We include a 60-day retest in every engagement. Not a re-run of the full scope — a targeted retest of every finding that was remediated. This closes the loop on the engagement and gives the client written evidence that the specific vulnerabilities we found have been addressed.
For continuous engagement clients, we track remediation rates over time. The teams that see the most improvement are the ones where we've established a cadence — monthly engagements, fortnightly retests, quarterly executive review.