How to read a penetration test report

A useful report says what was tested, how to reproduce each vulnerability and what to do. A list of identifiers is not enough.

sample report

See a real report before you commission one.

A 69-page report generated by the ExploitFinder engine on a public, deliberately vulnerable test application (testphp.vulnweb.com). It shows the structure, level of detail and traceability of a complete report.

Management summary

Overall risk, methodology and results on a page that non-technical readers can follow.

Evidence and reproduction

An evidence register and technical sheets for each vulnerability, with the steps to repeat it.

Remediation plan

Fix tracking, residual risk and a risk acceptance declaration.

Download the sample report (PDF, 69 pages)

Note. The target is a public test application, not a client. The report is in English and was produced by the automated engine; reports delivered to clients go through the human review described on the How it works page.

what it should contain

Eight elements every report should have.

Scope

What was tested and what was not.

Dates and method

When, with which roles and with which approach.

Issues

A list with a unique title for each vulnerability.

Reproduction steps

Enough detail for a technician to repeat the test.

Severity

Justified, not just a number.

Impact

What an attacker could do with that vulnerability.

Fix

What to change and where.

Limits

What was not verified, and why.

a warning sign

When to be careful.

A report with a hundred vulnerabilities of the same severity, without reproduction steps, is often unverified scanner output.

A report that does not state its scope or limits does not tell you what was really tested.