Direct answer
A useful pentest report connects each finding to an affected asset, reproducible evidence, business impact, a fix and a retest result. Download the blank findings register, then accompany it with an executive summary, scope and coverage statement. A filled spreadsheet alone is not a complete assessment report.
Download findings and retest template (CSV)Write an executive summary that supports a decision
State what was assessed, when testing happened and which release was examined. Explain demonstrated impact in terms the owner can act on, such as access to another test tenant's records. Separate observed impact from possible consequences that were not tested.
End with concrete decisions: who owns remediation, what should happen first and what must be retested. Avoid claiming zero findings means zero vulnerabilities. Readers should understand the assessment's value and limits without interpreting raw scanner output.
Reference: OWASP WSTG: Reporting.
Document scope and unavailable coverage
List authorized assets, environments, assessment dates, test roles and exclusions. Document restrictions on active testing, data access and third-party integrations. Note missing accounts or unreachable workflows because these change what conclusions the report supports.
Keep a coverage list for checks that passed, produced findings or could not be completed. Do not count unavailable tests as passes. A finding register records issues; it cannot describe every check that was attempted.
- Assessment dates, build and environment
- Authorized assets, accounts and permitted actions
- Exclusions, unavailable features and evidence limitations
Complete one row per actionable finding
The CSV includes an identifier, title, asset, preconditions, expected and observed behavior, evidence reference, impact, severity rationale, remediation, owner and status. Where several routes share one underlying repair, link those locations to the same finding.
For an invoice ownership failure, record which test role reached which other test record and why that action was forbidden. Keep the redacted request and response in your approved evidence location. Do not embed passwords, session tokens or customer records in a shared report.
Reference: OWASP WSTG: Reporting.
Explain severity and verify the repair
If you use CVSS, include its version, vector and rationale alongside the score. Product context still matters: affected data, exposure and required privileges inform priority. Do not copy a generic critical label onto an unverified candidate.
Describe a testable repair, such as enforcing caller ownership at every route that reads an invoice. Keep the original evidence and record the fixed build, retest date and result separately. Repeat the failing case and a valid control, then check adjacent routes. If retesting is unavailable, record that limit instead of declaring the issue fixed.
Reference: FIRST CVSS v4.0 specification.
Assessment limits
This template is not a certification, compliance attestation or independent penetration test. It does not establish that a scanner covers all required tests. Agree report and evidence requirements with the recipient before work begins.
Frequently asked questions
Is the pentest report template free?
Yes. Download the blank CSV findings and retest register without an account. This guide explains the accompanying report sections.
Can this replace an independent pentest?
No. A template organizes evidence but does not perform an assessment or establish tester independence. The recipient determines required scope and evidence.
Where is the example assessment report?
The MyPentest example report shows the product's report layout and a labelled example assessment. It illustrates the format, not results from your application.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.