A penetration test retest confirms that the specific vulnerability documented in the original report can no longer be exploited using the same attack path. It does not confirm that the underlying misconfiguration or root cause has been corrected anywhere else it may exist in the environment. PCI DSS v4.0.1 Requirement 11.4.4 requires this kind of retest for corrected findings, but the requirement is scoped to the reported instance, not a broader search for the same weakness elsewhere [1].
Picture a compliance team closing out a penetration test finding: the retest confirms the exploit no longer works, the report is filed, and the item moves to "resolved." That sequence is correct as far as it goes. The trouble is what happens next, when the same weakness that produced the original finding is still present somewhere else in the environment, on a system nobody thought to check, because nothing in the retest was ever scoped to look there. A retest is a real, useful control. It is also a narrower one than most organizations assume.
The scale of the underlying remediation gap is well documented. The Cobalt 2026 State of Pentesting Report puts the industry-wide resolution rate at 52% across a five-year dataset, and finds that top-performing organizations close high-risk findings in about 10 days while the bottom tier takes roughly 249 days, an eight-month difference in exposure on a known issue [2]. The same report found a sharp perception gap behind those numbers: 57% of C-suite respondents believe their organization consistently meets remediation SLAs, but only 15% of security practitioners agree [2]. A passed retest is often exactly what widens that gap, a clean, dated artifact that reads as proof of safety to leadership while practitioners understand it answered a narrower question.
A disclosure published August 16, 2026 illustrates the stakes of that narrower question going unasked. Security researchers at Reco reported a data-harvesting campaign, dubbed City-Forum, that persisted against Salesforce and ServiceNow customer portals for roughly seventeen months before being identified, rooted in access misconfigurations that ongoing reviews apparently did not catch [5]. Not every long-lived exposure traces back to a retest scoped too narrowly. But the pattern, a gap that survives despite an organization believing its controls were already checked, is exactly what this article addresses.
What Does a Penetration Test Retest Actually Check?
A retest is a narrow, scoped engagement in which a tester attempts to reproduce each specific vulnerability listed in the original report, using the exploitation steps that worked the first time. If the exploit no longer succeeds, that finding is marked corrected. PCI DSS v4.0.1 Requirement 11.4.4 requires exactly this: correction and retesting of the exploitable vulnerabilities and security weaknesses a penetration test identifies [1]. The requirement does not ask whether the same weakness exists anywhere else in the environment.
What's typically in scope versus out of scope for a standard retest:
| In scope | Usually out of scope | |---|---|---| | The specific finding, on the specific system where it was reported | The same misconfiguration on other systems | | Confirming the documented exploit no longer succeeds | The root cause that produced the finding | | A pass/fail determination per finding | Infrastructure provisioned after the original test |
Even descriptions of the retest process from testing vendors confirm this narrow scope: one methodology page describes retesting as reproducing "each documented vulnerability" using the original attack steps [4], not searching for the same misconfiguration pattern elsewhere. That is not a flaw in the process. It is simply not what a retest is built to answer.
Why Doesn't Fixing One Instance Fix the Underlying Risk?
Because the fix that closes a specific finding is often narrower than the problem that created it. An instance fix closes the one exposed system a tester found. A root-cause fix addresses the reason it was exposed in the first place, such as a base image, a misapplied access policy, or an infrastructure template used to provision multiple systems. A retest scoped correctly to Requirement 11.4.4 verifies the instance fix. It is not designed to verify the root-cause fix, and treating the two as equivalent is where residual risk survives undetected.
A common pattern in cloud environments illustrates this. An administrative interface gets exposed on one server because of a shared base image or provisioning template. That specific server is flagged, corrected, and retested. The image or template that produced the exposure, still active on every other system built from it, was never part of the retest's scope, because it was never part of the original finding.
This gap is more consequential given how quickly attackers now move once a weakness becomes known. One industry analysis, citing Mandiant's M-Trends 2026 data, noted that mean time to exploit for some vulnerability classes has gone negative, meaning attackers are often positioned before public disclosure, while typical remediation timelines for comparable issues still run closer to a month [6]. When the attacker side of that equation keeps compressing and the defender side is still verifying one instance at a time, the gap between "retested" and "actually resolved" becomes the more expensive half of the problem.
What Should a Retest Report Actually Tell You?
A useful retest report should state which specific findings were retested, the method used to confirm each fix, and the date, which is what PCI DSS 11.4.4 expects as corrective-action evidence [1]. It should also separately state whether the underlying cause was identified, and whether that cause was checked for anywhere else in the environment. Most retest reports only do the first part.
The Clone Systems Retest Scope Checklist, before filing a passed retest as proof a risk category is closed, check:
- Does the report name the root cause, not just the finding?
- Was the same misconfiguration pattern checked for elsewhere in the environment?
- Is there a ticket tracking the root cause itself, separate from the ticket that closed the original finding?
- Would the same weakness reappear if the same process were used to provision a new system today?
If the answer to any of the first three is no, treat the underlying risk as open until you can answer the fourth with confidence. Pull your own most recent retest report and check it against question one right now: does it name the cause, or only restate the symptom? That single answer tells you whether you're holding an instance fix or a root-cause fix.
Clone Systems Penetration Testing services
How Clone Systems Can Help
Clone Systems performs penetration testing and retest engagements scoped to PCI DSS v4.0.1 Requirement 11.4.4 [1]. For organizations that also want confirmation of whether a finding's root cause exists elsewhere in their environment, not just the reported instance, that can be scoped as an explicit addition to a standard compliance-driven retest. Clone Systems Penetration Testing services
Frequently Asked Questions
Does passing a retest replace the need for next year's full penetration test? No. A retest only re-examines the specific findings from the prior engagement; it does not replace the broader annual penetration test required to find new exploitable weaknesses across the full scope [1].
How long does a penetration test retest take? Retest duration depends on how many findings need to be re-verified, but because it's scoped only to previously identified issues rather than a full assessment, it's typically much shorter than the original penetration test.
Who can perform a penetration test retest? Either the original testing team or an independent qualified tester can perform a retest, as long as they have the original findings and reproduction steps. An independent tester can sometimes catch cases where a fix addressed the symptom but missed the underlying cause.
What happens if a retest fails? The finding remains open and uncorrected; it must be remediated again and retested before it can be marked resolved, which can affect compliance attestation timelines tied to Requirement 11.4.4 [1].
Conclusion
A passed penetration test retest is real evidence of real work, and it is not, on its own, evidence that the risk category behind that finding is closed. The fix isn't more retesting, it's asking retesting to answer a second, separate question it was never scoped to answer. If you're preparing for a Requirement 11.4.4 retest, or you're not sure whether your last one checked for root cause or just the reported instance, Clone Systems can help you scope it correctly. Visit clonesystems.com to talk to our penetration testing team.
References
[1] PCI DSS v4.0.1, Requirement 11.4.4 (Correction of Exploitable Vulnerabilities and Security Weaknesses via Penetration Testing), PCI Security Standards Council, 2024. https://www.pcisecuritystandards.org/document_library/ [2] The 2026 State of Pentesting Report, Cobalt, 2026. https://www.cobalt.io/state-of-pentesting [3] Clone Systems, Why Your Pen Test Findings Keep Showing Up in Next Year's Report. https://clone-systems.com/blog/why-pen-test-findings-keep-showing-up [4] Remediation Verification: Confirm It Is Fixed, Halock Security Labs. https://www.halock.com/penetration-testing/remediation-verification/ [5] "City-Forum" data-harvesting campaign against Salesforce and ServiceNow portals, reported by Reco, industry security reporting, August 16, 2026. [6] Most Remediation Programs Never Confirm the Fix Actually Worked, Nimrod Zantkern Lavi (Pentera), The Hacker News, May 13, 2026. https://thehackernews.com/2026/05/most-remediation-programs-never-confirm.html