Testing
What a good penetration test report looks like — and seven red flags
You are not buying testing. You are buying a document that a developer can act on, an auditor can accept, and a board can understand. Judge providers on the artefact, and ask for a redacted sample before you sign anything.
Testing quality is hard to assess from the outside. Report quality is not. Ask any prospective provider for a redacted sample report before you buy — a good provider will have one ready, and the document will tell you more about how they work than any capability statement.
The three readers a report must serve
| Reader | Needs | Fails when |
|---|---|---|
| Engineer fixing it | Exact reproduction steps, the request, the observed response, and a specific fix | Advice is generic — 'implement proper input validation' |
| Security or risk owner | Severity with reasoning, exploitability in context, remediation priority | Severity is a bare CVSS number with no environmental reasoning |
| Executive or auditor | What was tested, what was not, what it means, what happens next | Executive summary is a chart of severity counts and nothing else |
Most weak reports serve exactly one of those readers well. Strong reports are explicitly structured for all three, usually as an executive summary, a technical findings section, and appendices with raw evidence.
What every finding must contain
- A title that states the issue, not the category. 'Any authenticated user can read other tenants' invoices via the export endpoint', not 'Broken access control'.
- Affected component, precisely — the URL, endpoint, parameter, host or service.
- Reproduction steps a competent engineer can follow without contacting the tester, including the actual request and response.
- Evidence: a screenshot, a request/response pair, or a log excerpt. Redacted where it contains real personal data, but present.
- Impact stated in business terms, not just technical ones. What can an attacker do with this in your environment?
- Severity with reasoning. A CVSS vector is fine, but the report must explain the environmental factors that raised or lowered it.
- Specific remediation for your stack. Not a link to a generic guidance page.
- A stable identifier so the finding can be tracked through remediation and retest.
Seven red flags
1. Scanner output with a cover page
Findings that read like tool descriptions, plugin identifiers left in titles, dozens of informational SSL and header findings padding the count, and no business logic findings at all. This is a scan being sold as a test.
2. No statement of what was not tested
A credible report has a coverage section that names the exclusions and any areas where time ran short. Silence about limitations reads as complete coverage and is the single most misleading omission a report can contain.
3. Severity without environmental reasoning
A base CVSS score describes a vulnerability in the abstract. Whether it is critical for you depends on exposure, data sensitivity, and compensating controls. Reports that never adjust for context are not doing the analytical work you are paying for.
4. Generic remediation
'Implement proper input validation' or 'follow secure coding practices' is not remediation guidance. It is a category name. Good guidance names the function, the framework control, or the configuration setting.
5. No critical-finding protocol
If a tester finds active compromise or a trivially exploitable critical issue on day two, you need to know on day two. Ask how this is handled contractually. A provider who holds critical findings until the report date is optimising for their process, not your risk.
6. Findings with no evidence
A claim without a request/response pair or screenshot cannot be verified, cannot be prioritised confidently, and cannot be retested meaningfully. It also cannot be defended if a developer disputes it.
7. No retest offer
A provider confident in their findings will verify the fixes. Absence of a retest offer usually signals that the engagement model ends at delivery, which leaves you with the least valuable half of the process.
The parts buyers underuse
- The attack narrative. A short chronological account of how the tester chained findings is more useful for prioritisation than the severity table, because it shows which combination actually produced impact.
- The positive findings. Controls that held are worth documenting. They are evidence for auditors and they stop you from removing a control that was silently doing its job.
- The raw evidence appendix. Feed it into your ticketing system directly. It shortens remediation cycles more than any other single practice.
How to run the readout
Ask for a live walkthrough rather than a PDF drop. One hour with the tester who did the work, screen-sharing the exploitation of the top three findings, is worth more than a fifty-page document read in isolation. It also lets your engineers ask the question that PDFs never answer: what would you have done next if you had had more time?
Frequently asked questions
What should a penetration test report include?
An executive summary in business language, a clear statement of scope and what was not tested, technical findings with reproduction steps and evidence, severity with environmental reasoning, specific remediation guidance, an attack narrative showing how findings chained, and appendices with raw evidence. Retest results should be appended once remediation is verified.
Can I ask a penetration testing provider for a sample report?
Yes, and you should. Reputable providers keep a redacted sample for exactly this purpose. Judge it on whether a finding could be reproduced from the text alone, whether limitations are stated, and whether remediation guidance is specific to a stack rather than generic.
Should critical findings be reported before the final report?
Yes. Any competent engagement includes a protocol for immediate notification of critical findings or signs of existing compromise, with named contacts on both sides. Agree this in the rules of engagement before testing begins.
Talk to the team
Need this tested rather than described?
QuietHours is a European cybersecurity practice operated by the securIT team. Send us the system, service, or control you are concerned about and we will help turn it into a workable scope.
Discuss your scope