A penetration testing report exists to move two people to action: the engineer who has to fix the finding, and the leader who has to decide whether the fix actually worked. Everything else (the cover page, the risk-scoring methodology, the colour-coded heat map) is packaging around those two jobs.
The report is the artifact that turns a test into evidence auditors, boards, and engineering teams can act on. Most organisations only see two or three of these a year. That scarcity is exactly why so many reports go unread. If a report cannot survive contact with a sceptical engineer or a bored board member, the money spent on the test was largely wasted.
What a Well-Structured Report Includes
1. An Executive Summary for the Leader
The executive summary is a high-level overview of testing objectives, timelines, critical findings, and quick wins in non-technical language for C-suite executives and board members. If a board member reads only one section, this is it. A good executive summary names the three or four most significant findings in plain terms, states the overall risk posture, and connects the findings to business risk rather than CVSS numbers.
2. Scope and Methodology for Context
The report should state precisely what was tested, what was excluded, the testing methodology (OWASP, NIST SP 800-115, PTES, or equivalent), and the testing window. Scope documentation matters for compliance evidence: APRA CPS 234 supervisors and SOC 2 auditors checking a penetration test report want to confirm that the systems they care about were in scope, not assumed to be covered.
3. Contextual Risk Ratings, Not Just CVSS Base Scores
A technically Critical CVSS score on a development server with no production access might reasonably be rated High in context. A Medium CVSS score on a flaw that bypasses authentication to your customer database belongs at Critical. If every finding in a report carries a CVSS score but no contextual adjustment, the firm has not done the harder work of translating technical findings into business risk.
4. Proof-of-Concept Evidence for the Engineer
Proof of concept and reproduction steps help engineers independently verify the vulnerability, understand the attack path, and confirm that remediation addressed the underlying issue. A finding without a proof of concept is an assertion. An assertion is not actionable. If the engineer cannot follow the reproduction steps and rebuild the exploit in a test environment, the finding description was not specific enough to fix correctly.
5. An Attack Chain Narrative Where Findings Combine
A medium-severity authentication flaw combined with weak authorisation controls may produce full account takeover when chained. A report listing both findings in isolation at their individual severities misrepresents the actual risk. The attack chain section shows how an attacker moved through the environment using multiple findings together.
6. A Retest Section with Confirmed Closure Status
A retest entry states plainly whether the finding is open, remediated, or closed, the date it was retested, and what the tester actually did to confirm the fix, not just a status word changed in a spreadsheet.
For why the retest evidence matters as much as the initial findings for compliance purposes, the guide to what happens after a penetration test covers the confirmed remediation cycle that APRA supervisors and SOC 2 auditors specifically look for.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
Four Signs the Report You Received Was Built from a Scanner
Some reports provide little more than a list of vulnerabilities copied from automated scanners. Others deliver detailed narratives, proof-of-concept exploits, business risk analysis, and practical remediation guidance that significantly improve an organisation's security posture.
The gap between those two has measurable commercial consequence. Cobalt's 2026 State of Pentesting Report found that 57% of executives believe their organisation consistently meets remediation SLAs, versus just 15% of practitioners. The Verizon 2026 DBIR found that only 26% of critical known-exploited vulnerabilities were fully remediated last year. The gap between executive belief and practitioner reality is partly a report quality problem: when a report is not specific enough to produce clear engineering action, remediation stalls without anyone formally acknowledging it.
Theoretical Language: "May Be Vulnerable"
Findings phrased as "the target may be vulnerable to CVE-XXXX" rather than "the target was vulnerable to CVE-XXXX and we demonstrated the following access." May be indicates a scanner detection. Was confirms a real, tested exploit.
Generic Remediation Advice
"Apply the vendor patch" with no specification of which patch, which component, and what configuration change closes the specific exposure in the tested environment. Good remediation guidance is specific to the codebase or configuration reviewed during testing.
CVSS Scores Without Contextual Adjustment
Every finding at its theoretical base score, with no explanation of why the score was adjusted up or down for the specific environment. A good report explains why a CVSS 6.5 in the tested environment is treated as Critical and what would need to change for that to be different.
No Retest Section
A report that ends after the finding list, with no mechanism for confirming that remediated findings were actually closed, is a report that cannot produce the compliance evidence that auditors check. CREST-accredited providers include confirmed retest closure as a standard report component.
For how to connect a high-quality penetration test report to the compliance evidence frameworks ANZ organisations most commonly use, the guide to continuous penetration testing for SOC 2 and ISO 27001 compliance covers how each engagement contributes to the evidence trail that regulators and auditors expect.
Book a scoping consultation with Capture The Bug to review a sample report before engaging, and confirm that the reporting format satisfies your specific ANZ compliance framework requirements.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
Frequently Asked Questions
What should a penetration testing report include?
A well-structured penetration testing report includes: an executive summary in non-technical language for leadership, scope and methodology documentation, contextual risk ratings that reflect real-world exploitability rather than CVSS base scores alone, proof-of-concept evidence and reproduction steps for each finding, an attack chain narrative where multiple findings were combined by the tester, remediation guidance specific to the tested environment, and a retest section confirming which findings were verified as closed after remediation. Reports that include only a finding list with CVSS scores and no proof of concept or retest section are typically built from automated scanner output rather than active manual testing.
What is the difference between a good and a bad penetration testing report?
A good report enables two actions: an engineer can follow the reproduction steps and fix the specific finding, and a leader can understand the business risk and confirm whether remediation worked. A bad report is one where findings are described as "the target may be vulnerable" without confirmed exploitation, remediation advice is generic ("apply vendor patches"), CVSS scores have no contextual adjustment for the tested environment, and there is no retest section. The Cobalt 2026 State of Pentesting Report found that 57% of executives believe their organisation meets remediation SLAs, versus 15% of practitioners, reflecting how often unclear reports produce stalled remediation.
What is a proof of concept in a penetration testing report?
A proof of concept is the tester's evidence that a vulnerability was actively exploited rather than theoretically detected. It typically includes screenshots showing the vulnerability in action, annotated HTTP request and response logs, command outputs from exploitation, or a documented sequence of steps that confirms the finding is real and reproducible. Without a proof of concept, a finding is an assertion. Engineering teams need proof-of-concept evidence to independently verify the vulnerability, understand the attack path, and confirm that their remediation actually closed the specific exposure rather than adjacent behaviour.
What does a retest section in a penetration testing report look like?
A retest section states for each finding: the current status (open, remediated, or closed), the date it was retested, and what the tester did to confirm the fix rather than a status word changed in a spreadsheet. It should specify whether the fix was verified by re-running the original exploitation steps and confirming they no longer succeed. For APRA CPS 234 and SOC 2 compliance evidence, the retest section is the part auditors specifically look for under corrective action clauses. A report without a retest section cannot satisfy this compliance requirement regardless of how thorough the initial testing was.
How do I know if a penetration testing report was built from automated scanning rather than manual testing?
Four signs indicate automated scanner output: findings phrased as "the target may be vulnerable to CVE-XXXX" rather than confirmed exploitation, generic remediation advice ("apply vendor patches") with no environment-specific guidance, CVSS base scores with no contextual adjustment, and no attack chain narrative showing how findings were combined. A manual penetration test report will confirm exploitation with proof-of-concept evidence, provide specific remediation guidance, contextually adjust severity ratings, and show how multiple findings chain into higher-impact attack paths. CREST-accredited providers are required to produce proof-of-concept evidence for every confirmed finding as part of their accreditation standards.
