A useful penetration test report has six sections: executive summary (10-minute read for non-technical leadership), scope and methodology (what was tested, how, and what was not), findings (one entry per weakness with title, severity, evidence, impact, and remediation), remediation roadmap (what to fix and in what order), retest results (what was verified after the customer fixed things), and appendices (raw evidence, payloads, references). A report that ranks findings only by CVSS without context, or hands the customer a scanner CSV, is not useful.
Executive summary: the 10-minute read
The first section anyone in leadership will read, and often the only one. A useful executive summary:
- Names what was tested and the engagement window.
- Translates findings into business risk in plain language. Not 'three high-severity SQL injection findings' but 'an attacker who reaches the login page can extract every customer record without authentication'.
- Highlights the top three to five issues by realistic impact, not by CVSS.
- Gives a clear next-action recommendation for leadership: what to prioritise, what to delegate, what to track to closure.
What does not belong here: long lists of every finding, methodology details, jargon. Those live in later sections.
Scope and methodology: what was actually done
Auditors, customers, and procurement teams read this section first. They want evidence that the engagement was real and rigorous.
A useful section names:
- Scope. Exactly what was in scope. URLs, IPs, accounts, environments, services. Exactly what was out of scope and why.
- Approach. Black box, gray box, or white box. What information the tester started with.
- Methodology. The standard followed (OWASP WSTG, NIST 800-115, PTES, OSSTMM) and any customer-specific framework requirements.
- Activities performed. What categories of testing were done (authentication, authorisation, input validation, business logic, configuration review, and so on).
- What was not tested. Important. Time-bounded engagements have limits; naming them protects both customer and tester.
Findings: the technical core
Each weakness gets its own entry. A useful finding contains:
- Title. Plain language. 'Authentication bypass on admin login' not 'CVE-2023-XXXXX'.
- Severity. Critical / High / Medium / Low / Informational. CVSS score as a reference, not the only signal.
- Affected component. The URL, endpoint, host, file, contract, or feature.
- Description. What the weakness is, in 100 to 300 words.
- Evidence. The exact request, response, payload, screenshot, or video showing the issue. Anyone with access to the report should be able to reproduce it.
- Realistic impact. What an attacker could actually do with it. Not 'attacker could read data' but 'attacker could read all customer records by enumerating IDs from 1 to N'.
- Remediation. The specific change required. Not 'use parameterized queries' but the line of code or configuration that needs to change.
- References. OWASP, CWE, CVE, vendor advisories, internal links.
Findings sorted by realistic impact, not by CVSS, are more actionable. A CVSS 7.5 that affects every customer matters more than a CVSS 9.8 that affects one admin account behind MFA.
Remediation roadmap: what to fix first
Not every finding gets fixed in the same sprint. A useful roadmap helps the customer prioritise:
- Immediate. The findings that need fixing now, regardless of cost. Usually one to five issues.
- Within the next release. The findings that need fixing in the standard development cycle.
- Within the quarter. Lower-severity issues that should be tracked but do not block other work.
- Backlog. Informational findings worth being aware of.
Good roadmaps also flag findings that need architectural changes (not just a single code change) and findings that share a common root cause. Five SQL injections in different endpoints with the same root cause should be fixed at the data-access layer, not patched one by one.
Retest results: what was verified
Mature engagements include a free retest of fixes within an agreed window (often 60 to 90 days). The retest section documents:
- Which findings were verified as fixed.
- Which findings remain (with updated evidence).
- Any new findings that surfaced because of the fixes themselves (this happens more often than people expect).
A report without a retest path is incomplete. Auditors increasingly ask for it, and engineering teams need the closure.
Appendices: the raw material
Everything technical that does not belong in the main flow:
- Raw scanner output (curated).
- Payloads and request templates.
- Screenshots and video evidence.
- Tool versions used and configuration.
- Reference reading.
Appendices are useful when an engineer reproducing a finding needs the underlying material, or when an auditor verifying the engagement wants raw evidence.
What a bad pentest report looks like
Three patterns to recognise:
- Scanner CSV in a PDF. Hundreds of low-confidence findings, no curation, no business-impact context. Often signals the engagement was a vulnerability scan dressed as a pentest.
- All findings sorted by CVSS, no business context. A CVSS-only sort buries the issues that matter.
- No retest, no remediation guidance. A report that names problems without committing to verify the fix forces the customer to start over.
If the report looks like one of these, ask hard questions about what the engagement actually covered.
References
- [1]NIST SP 800-115(NIST)
- [2]OWASP Web Security Testing Guide(OWASP)
- [3]CVSS v3.1 Specification(FIRST)
- [4]CWE Common Weakness Enumeration(MITRE CWE)