ROOT64 / VERIFIED
Most organisations buy their first penetration test without knowing what a good one looks like. The proposals all use the same words, the price range is wide, and the only artefact you receive is a PDF. Here is what should be in it.
An executive summary that survives being read alone
The first two pages will be the only part most decision-makers read. They should state, in plain language, what was tested, what the overall risk position is, the two or three things that matter most, and what happens next. No CVSS vectors, no tool names, no jargon that requires a translator.
If the executive summary is a paragraph of boilerplate followed by a severity pie chart, the report was assembled rather than written.
Scope stated precisely enough to be falsifiable
A report should name the exact targets, hostnames, IP ranges, application versions and user roles that were tested, along with the dates and the test windows. It should be equally explicit about what was excluded and why.
This matters six months later, when someone asks whether a newly breached system was covered. A vague scope makes that question unanswerable.
Findings with evidence and reproduction steps
Every finding needs five things: what it is, where it is, proof it exists, what an attacker gains from it, and how to fix it. The proof is the part that separates a real finding from a scanner guess.
- A severity rating with the CVSS vector shown, not just the number
- The affected asset named specifically, not as "the web server"
- Evidence — a request and response, a screenshot, a log excerpt
- Steps precise enough for your engineer to reproduce it without calling the tester
- A fix that names the change to make, not a link to a generic advisory
Business context on the severity
CVSS is a technical score, not a business one. A medium-severity finding on your payment path can matter more than a high-severity finding on an internal tool nobody uses. A good report says which, because the tester asked what the system does before scoring it.
A remediation plan ordered by something other than severity
Sorting findings by severity produces a list, not a plan. A plan accounts for effort, dependencies and the fixes that close several findings at once. If three separate findings all resolve with one authorisation change, the report should say so.
Retest terms in writing
A finding is closed when it has been verified as fixed, not when someone says it is fixed. The report should state whether a retest is included, what it covers, and how closure is recorded. If retesting is a separate line item, ask why.
What should not be in it
- Unvalidated scanner output presented as findings
- Any statement that the system is now secure, hardened or compliant as a result of the test
- Severity inflation — a missing header is not a high
- Real customer data pasted into evidence where a redacted excerpt would prove the same point
- Boilerplate that could belong to any client
One question to ask before you sign
Ask for a redacted sample report. Every provider has one, and it tells you more about what you are buying than the proposal does. If a provider will not share one, that is the answer.