Your Penetration Test Report Is Evidence, Not a Findings List
A penetration test report is the evidence artifact of an authorized security test. It records the scope, method, and tools used, the findings with exploit context and severity, and the remediation plus retest results that confirm fixes. Under PCI DSS Requirement 11.4, it is also compliance evidence, so it must show an independent tester and coverage of the in-scope environment.
Your acquirer just asked for the penetration test that shows Requirement 11.4 is met, and you open the report you paid for. Forty pages. A confident executive summary. A table of vulnerabilities ranked by CVSS. Then the assessor starts asking what was in scope, who ran the test, how the critical finding was verified as fixed, and where the retest evidence is. The report has answers to none of them, because it was never written to be read by an assessor.
In our engagements, this is the pattern that repeats. The testing is often fine. The report is a findings list, and a findings list is not the same thing as evidence. Clients are often surprised to learn that a passing test can still fail in review because the document cannot prove the test happened.
The timing is not accidental. On September 21, 2026, Check Point Research reported that Cisco was aware of active exploitation of CVE-2026-76460, a CVSS 10.0 flaw in Cisco Identity Services Engine that gives an unauthenticated remote attacker access to the management interface [3]. A week like that is exactly when a report either accelerates the fix or buries it under a High label with no context.
Clone Systems' position, from the assessor side of this: a penetration test is not complete when the test ends. It is complete when the report survives review, and every section below exists to help your report do that.
What Is a Penetration Test Report For?
A penetration test report serves two readers who want different things, and most reports serve only one. The first is your technical team, who needs to know what was found, how severe it really is, what the exploit looked like, and exactly what to change. The second is the reviewer: an assessor, an acquirer, or an insurer, who needs to know the test happened, that it was scoped correctly, that the tester was independent, and that the findings were fixed and retested.
PCI DSS Requirement 11.4 is the formal version of the second reader's question. It requires internal and external penetration testing at least once every 12 months and after significant changes, and it expects the testers to be organizationally independent from the systems they test [4]. The report is the only artifact that answers those questions, and it is also where the numbers get real: Cobalt's 2026 State of Pentesting, built on more than 16,500 penetration tests across nearly 3,000 organizations, puts the half-life of a high-risk finding at 10 days for leading teams and 249 days for laggards, a 25x gap driven mostly by how findings are handed off, not by how they are found [2].
The decision document
The executive summary and findings section exist so your team can triage: which finding touches the cardholder data environment, which one is exploitable today, which fix takes a sprint and which takes a quarter. Without exploit context, that triage is a guess, and a guess is how the 249-day half-life starts.
The evidence file
The scope statement, the methodology, the independence statement, and the retest results exist so a stranger with no access to your environment can verify that the test covered what it claimed to cover. A report that is only a decision document is useful but incomplete. A report that is only an evidence file is unreadable by the people who fix things. You need both, in one document.
What Should Be Included in a Penetration Test Report?
At minimum, a penetration test report contains six things: the scope and rules of engagement, the methodology and tools, the findings with exploit context and severity, the remediation steps, the retest results, and the tester's independence statement.
- Scope and rules of engagement. The exact systems tested, the time window, and what was explicitly out of scope. Without this, a reviewer cannot verify that the test covered your environment, and a missing scope statement is one of the first things an assessor notices.
- Methodology and tools. The testing approach, drawn from industry-accepted frameworks such as NIST SP 800-115, OWASP, or PTES, and the tooling behind it, so the test can be reproduced or challenged by someone who was not in the room [4].
- Findings with exploit context. For each finding: what it is, how it was validated or exploited, what an attacker reaches, and which findings chain together into an attack path. A CVSS number without the attack path is a score, not a story.
- Severity that reflects your environment. CVSS is a starting filter, not a verdict. The report should adjust for what is actually reachable in your network and what data is actually exposed, so your team patches in order of real risk.
- Remediation with validation. The fix, and evidence that the fix was verified. A status column that says remediated is a claim, not evidence, and it is the item most often missing from a report that gets pushed back in review.
- The independence statement. Who ran the test, and why they are organizationally independent from the systems tested. PCI DSS expects that independence, and a report that never says who tested or why hands the reviewer a reason to discount the whole document [4].
A report that skips items three to six is a findings list. It may help your team patch. It is not evidence.
Why Do Penetration Test Reports Fail in Assessor Review?
Reports fail in review for four recurring reasons, and none of them is a weak test. BEMO's compliance guidance puts it plainly: "QSA-ready evidence means more than a PDF from the pen tester" [4].
The scope-free report. The document never says what was in scope, so the reviewer reconstructs coverage from the findings. If the scope was drawn too narrow, the classic case being a scope diagram that misses the systems that actually reach the cardholder data environment, the report cannot show it [7].
The severity-without-context finding. A table of CVSS scores with no exploit context. The reviewer cannot tell which High is patch-today and which is patch-next-quarter, so the backlog gets patched in the order the table was sorted. That is the difference between a 10-day and a 249-day half-life, and the gap is in the handoff, not the test [2].
The unvalidated fix. The report says remediated, but there is no retest evidence, or the retest only confirms the specific reported instance and not the root cause [6]. A retest proves the reported instance is closed. It does not prove the fix holds, and a reviewer who knows that will ask for the retest evidence.
The anonymous tester. No independence statement anywhere in the document. PCI DSS expects the tester to be organizationally independent from the systems tested, and a report that never says who ran the test or why they are independent cannot prove it [4].
The PCI SSC flagged this problem in its own guidance. In 2015, when it published guidance on penetration testing, the Council noted that testing security systems was the only area of PCI DSS where compliance had declined over the prior year [1]. Eleven years later, the failure mode is unchanged: the test passes, the document does not. And while the backlog sits, the threat side keeps moving. Oracle's September 2026 Critical Patch Update addressed more than 800 vulnerabilities, over 100 rated critical and more than 240 exploitable remotely without authentication [3].
The Clone Systems 6-Point Penetration Test Report Evidence Check
We score every report we deliver against six checks before we call it done, and we will score yours if you bring it to us:
- The scope statement matches the environment you actually run.
- The methodology and tools are named.
- Every High and Critical finding carries exploit context and an attack path.
- Severity reflects reachability in your environment, not just the CVSS vector.
- Remediation comes with retest evidence, not a status column.
- The report carries a signed independence statement.
Score your own report. Open the last penetration test report you received and work the six checks above. It takes ten minutes and no tools. If the scope statement is missing or generic, if the fixes have no retest evidence, or if you cannot find the independence statement anywhere, you already know what a reviewer will find first.
If your last report fails the check and your next test is coming up, Clone Systems managed penetration testing delivers reports written to survive review, with scope, methodology, retest evidence, and the independence statement built in from day one. Talk to our team before your next engagement if you want a second pair of eyes on the deliverable.
Penetration Test Report vs Vulnerability Scan Report: Which Do You Hand to Your Assessor?
You hand over both, because they answer different questions. A vulnerability scan report shows what is exposed at a point in time. A penetration test report shows what an attacker could actually do with that exposure, and under PCI DSS each satisfies a different obligation [8].
| Vulnerability scan report | Penetration test report | |
|---|---|---|
| What it proves | Known weaknesses exist on the asset | An exploitable path was demonstrated and validated |
| PCI DSS obligation | Quarterly at minimum for internal scans under Requirement 11, plus the external ASV obligation | Annual internal and external testing, plus re-testing after significant changes (11.4) [4] |
| Primary reader | The patching team | The assessor, the acquirer, the board, the insurer |
| When it goes stale | The moment the asset changes | When the environment changes and the test is not repeated |
The two documents feed each other. The scan tells you what to test. The test tells you which of the scan's findings actually matter. We broke the boundary between the two down in penetration testing vs vulnerability scanning, and the internal scanning side of the equation in internal vs external vulnerability scanning. On the scanning cadence, the quarterly obligation and the attestation file are covered in what happens when you miss a quarterly PCI ASV scan.
How Clone Systems Can Help
We run the penetration test side of Requirement 11.4 end to end. Our managed penetration testing covers external, internal, and application testing against a documented methodology, and every report we deliver is scored against the 6-Point Report Evidence Check above before it leaves our hands: scope that matches your actual environment, exploit context on every High and Critical finding, remediation with retest evidence, and the independence statement on page one.
For teams that need more than the annual event, continuous penetration testing keeps the evidence current between the annual tests, so the report file is always the version your assessor will check, not the one from last year. And if you are weighing the automated option, we wrote out the boundary between automated and manual testing in can automated penetration testing replace your manual penetration test.
If you want a second pair of eyes on a report you have already received, start with a conversation. We will tell you whether it holds up, and exactly which of the six checks it is missing.
Frequently Asked Questions
What is included in a penetration test report? A scope statement, the methodology and tools used, the findings with exploit context and severity, the remediation steps, the retest results, and the tester's independence statement. The last three are what separate an evidence document from a findings list.
What makes a good penetration test report? One your technical team can act on without calling the vendor, and one a reviewer can verify without access to your environment. Concretely: exploit context on every significant finding, severity that reflects your network, and retest evidence behind every claimed fix.
How long does it take to get a penetration test report? Most reports are delivered within a few weeks of the test, and any report that includes retest evidence takes longer because the fixes have to be verified first. Your vendor should quote a delivery window before the test starts, and any timeline that promises same-day delivery for a full-scope test deserves a second look.
Does a penetration test report prove PCI DSS compliance? No, it satisfies one requirement (11.4), and only if it shows independent testing of the full scope plus re-testing after significant changes [4]. The other eleven requirements in PCI DSS still need their own evidence.
Penetration test report vs vulnerability scan report: what's the difference? A scan report lists known weaknesses at a point in time. A penetration test report demonstrates which of them an attacker could actually chain into access, with the validation to prove it.
Conclusion
A penetration test report is the document your assessor reads, your board reads, and your patching team lives with. Write it for all three and it holds up. Write it as a findings list and the test's value dies in the inbox, and the clock Cobalt measured runs its full 249 days [2]. Run the 6-Point Report Evidence Check against your last report today, close the gaps in your process, and if you want it done end to end, start at www.clone-systems.com.
References
[1] PCI Security Standards Council: PCI Council Publishes Guidance on Penetration Testing, March 26, 2015 (citing a 2015 Verizon report that testing security systems was the only area of PCI DSS where compliance declined over the prior year). https://www.pcisecuritystandards.org/about_us/press_releases/pci-council-publishes-guidance-on-penetration-testing/
[2] Cobalt: State of Pentesting Report 2026 (data from more than 16,500 penetration tests across nearly 3,000 organizations over five years, analyzed by the Cyentia Institute, plus a survey of 450 security professionals; high-risk finding half-life of 10 days at leading organizations versus 249 days at laggards; programmatic teams resolve 4.5x more critical findings in under three days, 45% versus 10%). https://resource.cobalt.io/state-of-pentesting-2026
[3] Check Point Research: 21st September Threat Intelligence Report, September 2026 (Cisco aware of active exploitation of CVE-2026-76460, CVSS 10.0 in Cisco ISE, unauthenticated access to the management interface; CVE-2026-76461 rated 9.8; Check Point fixed CVE-2026-91843, CVSS 9.8, unauthenticated root code execution on R80 through R82; Oracle September 2026 Critical Patch Update addresses more than 800 vulnerabilities, over 100 critical, over 240 exploitable remotely without authentication). https://research.checkpoint.com/2026/21st-september-threat-intelligence-report/
[4] BEMO: PCI DSS Penetration Testing Requirements, June 9, 2026 (11.4.1 to 11.4.6 breakdown; annual internal and external testing plus retesting after significant changes; organizational independence for testers; methodology based on NIST SP 800-115, OWASP, or PTES; quarterly internal scanning under Requirement 11; "QSA-ready evidence means more than a PDF"). https://www.bemopro.com/cybersecurity-blog/pci-dss-penetration-testing
[5] Clone Systems: In our engagements, penetration tests rarely fail in review because the tester missed something. They fail because the report is a findings list: no scope statement, no exploit context, no validated remediation, and no independence statement for the assessor to check.
[6] Clone Systems: Why Passing a Penetration Test Retest Isn't the Same as Fixing the Root Cause. www.clone-systems.com/blog/why-passing-a-penetration-test-retest-isnt-the-same-as-fixing-the-root-cause
[7] Clone Systems: Why PCI DSS Internal Penetration Testing Finds the Systems Your Scope Diagram Missed. www.clone-systems.com/blog/pci-dss-internal-penetration-testing-scope-gap
[8] Clone Systems: Penetration Testing vs Vulnerability Scanning: Why the Difference Matters. www.clone-systems.com/blog/penetration-testing-vs-vulnerability-scanning
[9] Clone Systems: Internal vs External Vulnerability Scanning: Why PCI DSS Requires Both. www.clone-systems.com/blog/internal-vs-external-vulnerability-scanning-why-pci-dss-requires-both
[10] Clone Systems: What Happens When You Miss a Quarterly PCI ASV Scan. www.clone-systems.com/blog/what-happens-when-you-miss-a-quarterly-pci-asv-scan
[11] Clone Systems: Can Automated Penetration Testing Replace Your Manual Penetration Test? www.clone-systems.com/blog/can-automated-penetration-testing-replace-your-manual-penetration-test
[12] Clone Systems: Managed Penetration Testing service page. www.clone-systems.com/managed-penetration-testing-services/
[13] Clone Systems: Continuous Penetration Testing service page. www.clone-systems.com/continuous-penetration-testing/
[14] Clone Systems: Contact and consultation. www.clone-systems.com/contact