You are buying a report. The testing matters enormously, but the report is what you receive, what your auditor reads, what your engineers work from and what you hand to a customer. It is also the only part of the work you can evaluate before you commit.
Ask any prospective supplier for a redacted sample. If they will not provide one, that is itself information. Here is what to look for when you get it.
What should be there
An executive summary that a non-specialist can act on
Two or three pages stating what was tested, what was found, what it means commercially and what should happen first. No CVE numbers, no tooling, no jargon. If your board or your auditor cannot read it unaided, it has not been written for them.
Explicit scope and rules of engagement
What was in scope, what was excluded, which roles and environments were tested, and over what dates. This bounds the assurance. A report without it invites the reader to assume it covers more than it does — and when that assumption is discovered later, in an audit or after an incident, the omission is yours to explain.
Methodology
Named, industry-recognised, and specific about what was applied where. PTES and NIST SP 800-115 for engagement structure; OWASP WSTG and ASVS for web; the OWASP API Security Top 10 for APIs; OWASP MASVS and MASTG for mobile. An assessor will ask for this, and PCI DSS 11.4.1 requires it.
Findings with reproduction steps
Each finding should state what it is, exactly how to reproduce it — the actual request, the actual response — what the impact is in your context, and how to fix it. An engineer should be able to reproduce the issue from the report without contacting the tester.
Severity that reflects consequence
CVSS with the vector shown, so the reasoning is visible, and an explanation where business impact diverges from the technical score. An authorisation flaw exposing one record and one exposing a million may share a vector; they do not share a priority.
What was tested and found sound
The parts that held up. This is not padding: it tells you where your investment worked, and it tells an auditor the assessment had breadth rather than stopping at the first problem.
A redaction key, if the report is for onward distribution
If you will share the report with customers or auditors, there should be a version that masks exploit detail and sensitive data, with an explicit statement of what has been masked and what the full copy contains instead. How a firm handles this tells you more about its evidence discipline than its findings do.
Retest results
A final report should show each finding as fixed, partially fixed or open, with the retest date. This is the part auditors most often find missing, and it is the part that turns a list of problems into evidence of a working process.
What should not be there
- Raw scanner output. Unverified tool results padding the finding count. If a finding was not manually verified, it should not be in the report, and you should not be paying to triage it.
- Exfiltrated personal data. Where a vulnerability exposes records, the report should state how many and of what type — not contain them. A report carrying your customers’ data is a new liability, and it is one that persists long after the finding is fixed.
- Live credentials. Recovered secrets should be recorded as recovered and masked, including in your own copy.
- Severity inflation. Verbose headers and missing cookie flags rated High to make the report look substantial. It wastes remediation effort and it erodes trust in the ratings that matter.
- Generic remediation. “Implement input validation” is not guidance. Advice should be specific to your stack and your code.
- An accreditation mark. A penetration test report is a technical assessment issued by the testing firm. It is not an accredited output, and any implication otherwise is misleading.
The test for a sample report
Read one finding end to end and ask: could my engineer fix this from what is written here, without a call? Then read the executive summary and ask: would my board understand what to worry about?
If both answers are yes, the firm can write. That is not everything, but it is the part you can verify before you sign.