A report is not a list of findings
A penetration testing report must turn technical observations into decisions that teams can act on. A scanner-style output containing only a vulnerability title and generic description is not enough to reproduce, prioritize, and remediate a risk.
Each finding should identify the affected asset, prerequisites, evidence, observed result, business impact, and a concrete remediation path.
Required fields for every finding
A CVSS score is not the entire priority decision. It must be interpreted alongside asset criticality, exposure, and compensating controls. The same weakness can create very different business impact in an internet-facing production system and an isolated test environment.
- Unique finding identifier and title
- Affected asset and user role
- CVSS vector and score
- Request/response or visual evidence
- Reproduction steps
- Business impact and priority
- Remediation and verification method
Two reading layers
An executive summary should explain risk distribution, important attack paths, and recommended action order without unnecessary technical detail. The technical section should enable engineers to reproduce and fix every finding.
Why retesting needs its own record
Marking a ticket complete does not prove a vulnerability is fixed. Retesting should repeat the original attack path, check side effects, and record the result with date and version information. Partial fixes or risks that remain in another form must be reported clearly.