Why PCI DSS Internal Penetration Testing Finds the Systems Your Scope Diagram Missed
PCI DSS internal penetration testing is required by Requirement 11.4.2, at least once every 12 months and after any significant change. It is a separate obligation from external testing under 11.4.3, and satisfying one does not satisfy the other. Its scope covers the cardholder data environment plus every connected system that can reach it.
A merchant books an annual penetration test. The tester works from outside the perimeter, probes the public IP ranges, reports on the web application and the VPN concentrator, and delivers a clean-enough report. The QSA reads it and asks a question nobody in the room expected: where is the internal test? The answer, usually, is that everyone assumed the external test covered it. It did not, and the standard has been explicit about that since v4.0.
This is one of the more expensive misreadings in PCI, because it is discovered late. The external test is finished, the budget is spent, the assessment window is closing, and the internal test has not been scoped, let alone scheduled. In our PCI assessment work at Clone Systems, we consistently find that organizations do not skip internal penetration testing on purpose. They skip it because Requirement 11.4 reads like one obligation with a few clarifications attached, and it is actually a set of separate obligations with separate scopes.
The evidence that this matters is not theoretical. The Zero Networks 2026 Lateral Movement Exposure Report, built from 54 trillion activities observed across 312 enterprise environments, found that more than 80% of enterprise servers are reachable from anywhere inside the network, that 87% accept inbound RDP or SSH connections from broad internal sources, and that 78% remain reachable over SMB or WinRM [1]. Forty-three percent of internal authentication traffic still relies on legacy NTLM [1]. Those are the conditions an internal penetration test exists to measure, and they are invisible from outside the perimeter by definition.
Recent incidents keep making the same point. In the second week of August 2026, Levi Strauss disclosed that a social engineering campaign had compromised three employee computers, exposing corporate data, while a separate advisory covered an unauthenticated flaw in Cisco ASA and FTD devices affecting VPN infrastructure [4]. Neither of those is a story about a weak perimeter. They are stories about how an attacker arrives inside, which is the starting position an internal penetration test is designed to simulate.
Does PCI DSS Actually Require an Internal Penetration Test?
Yes, and it is a named, separate sub-requirement rather than an implication of the general testing obligation. This is the single most useful thing to get straight before scoping anything.
What Requirement 11.4.2 Requires
PCI DSS v4.0.1 Requirement 11.4.2 calls for internal penetration testing performed according to the entity's defined methodology, at least once every 12 months and after any significant infrastructure or application upgrade or change. The testing must be performed by a qualified internal resource or a qualified external third party, and organizational independence of the tester must exist, though the tester is not required to be a QSA or an ASV [2].
That last clause is worth reading twice. Organizational independence means the person testing the environment cannot be the person who manages, develops, or maintains it. An internal team can perform the test, but not the internal team that owns the systems [3].
Requirement 11.4.1 sits above both tests and is where most methodology findings originate. It requires a documented penetration testing methodology based on an industry-accepted approach such as NIST SP 800-115, covering the CDE perimeter and critical systems, network-layer and application-layer testing, review of threats and vulnerabilities from the previous 12 months, and retention of results and remediation activities for at least 12 months [2]. A test performed without that documented methodology can be technically excellent and still produce a finding.
Why an External Penetration Test Does Not Satisfy 11.4.2
Because it is scored against a different sub-requirement. Requirement 11.4.3 covers external penetration testing on the same 12-month cadence, and 11.4.2 covers internal [2]. They are assessed separately, and an assessor marking 11.4.2 as in place needs evidence of an internal test, not a thorough external one.
The distinction is not bureaucratic. An external test answers whether an attacker can get in. An internal test answers what happens after one does, which is a question about lateral movement, credential reuse, service exposure between internal segments, and how far a compromised workstation can travel before it touches account data. Those are different findings produced by different methods against different targets. We have written before about how automated scanning and penetration testing answer different questions (penetration testing vs vulnerability scanning); the internal versus external split is the same kind of distinction one level further in.
What Is In Scope for a PCI DSS Internal Penetration Test?
Here is where most scoping goes wrong, and it is the position this article argues: an internal penetration test is scoped to the systems that can reach the cardholder data environment, not only to the systems inside it. Scoping to the CDE alone produces a test that validates the destination while ignoring every route to it.
The CDE Is the Target, Not the Boundary
Requirement 11.4.1 asks for coverage of the CDE perimeter and critical systems [2]. In practice that means the test scope includes in-scope non-CDE networks: the systems that are not storing, processing, or transmitting account data themselves but that can connect to systems that do. Guidance from QSA firms describes the in-scope set as all internal networks including workstations, servers, and databases, within both the CDE and in-scope non-CDE networks [3].
Clients are often surprised by this, and the surprise is nearly always about the same category of system. Not the payment application. The jump host. The backup server. The monitoring platform with an agent on every host in the estate. The virtualization management interface sitting on a flat administrative VLAN that can reach the CDE without crossing the segmentation boundary anyone thought to test.
The Clone Systems Five-Path CDE Reachability Check
Before you approve an internal penetration test scope, walk these five paths. Each one is a route into the CDE that does not pass through the network boundary most scope diagrams draw, and each one has produced findings in our assessment work.
1. Administrative and management planes. Hypervisor management consoles, out-of-band management interfaces, and jump hosts routinely sit on a shared administrative network that can reach both the CDE and the general corporate network. The segmentation diagram shows two zones. The management plane touches both.
2. Monitoring, backup, and endpoint agents. Any platform with an agent installed on CDE systems has a control channel into the CDE. If the management server for that platform lives outside the CDE and accepts connections from corporate networks, it is a reachable path regardless of what the firewall rules between the two user networks say.
3. Identity infrastructure. Domain controllers, directory services, and single sign-on components that authenticate CDE systems are in scope by function even when they sit outside the CDE by address. With 43% of internal authentication traffic still running on NTLM across the environments Zero Networks observed [1], the identity layer is frequently the shortest path between a compromised workstation and a payment system.
4. Build and deployment pipelines. CI/CD systems, artifact repositories, and configuration management tooling that deploy to CDE systems hold credentials for them. A pipeline that can push to a CDE host is a path into the CDE, and it is one that rarely appears on a network diagram at all.
5. Third-party and vendor access. Standing remote access for support vendors, integration partners, or managed service providers is an inbound path that bypasses the corporate perimeter entirely. The August 2026 threat reporting on a hospital vendor breach traced 1.8 million exposed patient records to exactly this shape of access, undetected for roughly three months [5].
A scope that covers all five is an internal penetration test. A scope that covers only the CDE address range is a validation of the destination.
If you are scoping an internal penetration test for a PCI assessment and are not certain which of those five paths are covered, that is worth resolving before the test starts rather than after the report lands. Clone Systems performs internal and external penetration testing scoped to PCI DSS v4.0.1 Requirement 11.4. See our penetration testing services or contact our team to talk through your current scope.
Doesn't Segmentation Testing Already Cover This?
It covers a related question, and it is a separate requirement again. Requirement 11.4.5 applies when segmentation is used to isolate the CDE from other networks, and it requires penetration testing of segmentation controls at least once every 12 months and after any change to segmentation controls or methods. Requirement 11.4.6 tightens that to every six months for service providers [2].
A segmentation test verifies that the controls isolating the CDE are operational and effective. It asks whether traffic can cross a boundary that is supposed to block it. That is a valuable answer, and it is not the same answer as an internal penetration test, which asks what an attacker who is already inside an in-scope network can actually reach and exploit.
The gap between those two questions is the one that keeps producing findings. A segmentation control can be functioning exactly as designed while a management interface, an agent control channel, or a service account provides a path the segmentation control was never positioned to see. We covered a version of this problem from the compliance side previously (the integration access gap that PCI segmentation testing often misses). The internal penetration test is the control that is supposed to catch what segmentation testing structurally cannot.
What Happens to the Findings, and Who Verifies Them?
Requirement 11.4.4 requires that exploitable vulnerabilities and security weaknesses found during penetration testing are corrected in line with the entity's risk assessment, and that testing is repeated to verify the corrections [2]. That retest is scoped to the reported finding, which is a narrower question than most teams assume, and we have written about that distinction at length (why passing a penetration test retest isn't the same as fixing the root cause).
The remediation half of this is where compliance-driven programs underperform. Cobalt's 2026 State of Pentesting Report found an overall resolution rate of 52% across its five-year dataset, a median remediation time of 39 days against typical seven-day SLA targets, and a striking perception gap: 57% of C-suite respondents believe their organization consistently meets remediation SLAs while only 15% of practitioners agree [6]. The same report found that 40% of organizations still rely on compliance-driven testing rather than programmatic testing, and that programmatic programs are 4.5 times more likely to resolve critical findings within three days [6].
An internal penetration test scoped correctly and then left unremediated for 39 days is not a control. It is a document. That distinction is the one we keep returning to in this cluster (why your pen test findings keep showing up in next year's report).
Test Your Own Scope: Three Questions
Pull your most recent penetration test statement of work and answer these three before your next assessment.
- Does the document contain a separate internal testing section, with its own target list, distinct from the external section? If the internal work is one line inside an external scope, an assessor evaluating 11.4.2 has nothing specific to look at.
- Do the internal targets include any system that is not inside the CDE address range? If every listed target is inside the CDE, the test cannot demonstrate anything about the paths into it, and none of the five reachability paths above were exercised.
- Who signed off on the tester's organizational independence, and would that hold if the tester reports to the same manager as the systems team? Independence is a requirement of 11.4.2, not a preference [2], and it is one of the easier findings for an assessor to raise.
An uncertain answer to any of these is worth resolving before the assessment window opens, not during it.
How Clone Systems Can Help
Clone Systems is a PCI Approved Scanning Vendor and Managed Security Services Provider, which means PCI scope conversations are routine work for us rather than an annual event. That vantage point is why our position on this topic is a scoping position rather than a testing-methodology one: the internal penetration tests that produce findings an assessor accepts are the ones scoped to reachability, not to address ranges.
Our penetration testing services cover internal and external testing scoped to Requirement 11.4.2 and 11.4.3, segmentation control testing under 11.4.5 and 11.4.6, and the 11.4.4 retest that closes findings out. Where an environment needs continuous visibility between annual tests, our vulnerability scanning services cover the internal and external scanning obligations under Requirement 11.3 alongside the ASV scan.
If your last penetration test was external only, that is a 11.4.2 finding waiting to happen, and it is a straightforward one to close with enough notice. Start the conversation at clonesystems.com.
Frequently Asked Questions
Does PCI DSS require internal penetration testing? Yes. PCI DSS v4.0.1 Requirement 11.4.2 requires internal penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, performed according to the entity's documented methodology.
What is the difference between internal and external penetration testing for PCI DSS? External testing under Requirement 11.4.3 assesses systems reachable from outside the network perimeter, while internal testing under 11.4.2 assesses what an attacker already inside an in-scope network can reach and exploit. They are separate sub-requirements, and evidence for one does not satisfy the other.
What is in scope for a PCI DSS internal penetration test? The cardholder data environment plus in-scope non-CDE systems, meaning any internal system that can connect to systems that store, process, or transmit account data. That typically includes management planes, identity infrastructure, monitoring and backup platforms, deployment pipelines, and vendor access paths.
Can our own security team perform the PCI internal penetration test? Yes, provided the testers are qualified and organizationally independent from the management of the systems being tested. The tester does not need to be a QSA or an ASV, but the independence condition is assessed and is a common source of findings.
How often is internal penetration testing required under PCI DSS? At least once every 12 months, and additionally after any significant infrastructure or application upgrade or change. Segmentation control testing under Requirement 11.4.5 follows the same 12-month cadence for most entities, tightening to every six months for service providers under 11.4.6.
Does segmentation testing count as internal penetration testing? No. Segmentation testing under Requirement 11.4.5 verifies that isolation controls block traffic they are meant to block, while internal penetration testing under 11.4.2 assesses exploitable weaknesses across in-scope internal systems. An assessor evaluates them separately.
Conclusion
The organizations that get caught by Requirement 11.4.2 are rarely the ones that ignored it. They are the ones that read Requirement 11.4 as a single testing obligation, commissioned a competent external test, and discovered during the assessment that the standard had asked two separate questions. The second question, what an attacker who is already inside can reach, is the one the current data says most environments would answer badly: more than 80% of enterprise servers reachable from anywhere internally, and 87% accepting broad inbound administrative connections [1].
Scope the internal test to reachability rather than to address ranges, resolve the tester independence question before the work starts, and treat the findings as remediation work with a deadline rather than as a report. If you are preparing for a PCI assessment and are not sure whether your internal testing scope would hold up, Clone Systems can help you check it against Requirement 11.4 before an assessor does. Visit clonesystems.com to talk with our penetration testing team.
References
[1] Zero Networks — 2026 Lateral Movement Exposure Report, based on analysis of 54 trillion activities across 312 enterprise environments, June 2026. https://zeronetworks.com/resource-center/reports/2026-lateral-movement-exposure-report
[2] PCI Security Standards Council — PCI DSS v4.0.1, Requirement 11.4 (11.4.1 methodology, 11.4.2 internal penetration testing, 11.4.3 external penetration testing, 11.4.4 correction and retesting, 11.4.5 segmentation control testing, 11.4.6 service provider segmentation cadence), 2024. https://www.pcisecuritystandards.org/document_library/
[3] Schellman — PCI DSS & Penetration Testing FAQ, on internal test scope, in-scope non-CDE networks, and tester organizational independence. https://www.schellman.com/blog/pci-compliance/pci-dss-penetration-testing-faq
[4] eSecurity Planet — AI Security Failures, Active Exploits, and Breaches Define the Week in August 2026, August 14, 2026. https://www.esecurityplanet.com/weekly-roundup/ai-security-failures-active-exploits-and-breaches-define-the-week-in-august-2026/
[5] Zentera — Threat Briefing, August 2026, covering a third-party vendor with standing network access undetected for roughly three months and 1.8 million patient records exposed. https://www.zentera.net/news/threat-briefing-august-2026
[6] Cobalt — The 2026 State of Pentesting Report, 2026. https://www.cobalt.io/state-of-pentesting
[7] Clone Systems — In our PCI assessment and penetration testing work, internal test scopes are most often drawn around the CDE address range rather than around reachability, and the systems that produce findings are consistently the shared management planes, monitoring and backup control channels, identity infrastructure, deployment pipelines, and standing vendor access paths that can reach the CDE without crossing the segmentation boundary the client believed was the only route in.
[8] Clone Systems — Penetration Testing vs Vulnerability Scanning: Why the Difference Matters. clonesystems.com/blog/penetration-testing-vs-vulnerability-scanning
[9] Clone Systems — Why Passing a Penetration Test Retest Isn't the Same as Fixing the Root Cause. clonesystems.com/blog/why-passing-a-penetration-test-retest-isnt-the-same-as-fixing-the-root-cause
[10] Clone Systems — The Integration Access Gap That PCI Segmentation Testing Often Misses. clonesystems.com/blog/pci-segmentation-integration-access-gap
[11] Clone Systems — Penetration Testing Services. clonesystems.com/penetration-testing