PCI DSS is the rare standard that does not make you guess. Where SOC 2 and HIPAA only imply testing, PCI DSS v4.0.1 Requirement 11.4 says it outright: you must perform internal and external penetration testing, on a defined cadence, using a documented methodology. There is no ambiguity about whether a pentest is required. The ambiguity, if any, is in getting the scope, frequency, and segmentation rules exactly right, because that is where assessors fail organizations.
This post walks through Requirement 11.4 sub-requirement by sub-requirement, covers the v4.0.1 methodology and segmentation rules, explains the different cadences for merchants versus service providers, and defines what belongs in the cardholder data environment. If you are coming from v3.2.1, the changes are meaningful.
Yes, unambiguously. PCI DSS Requirement 11.4 explicitly requires both internal and external penetration testing. This is the clearest pentest mandate of any major compliance standard.
Requirement 11.4 breaks into several sub-requirements: 11.4.1 covers the methodology, 11.4.2 internal testing, 11.4.3 external testing, 11.4.4 remediation and retesting of findings, and 11.4.5 and 11.4.6 cover segmentation control testing. Unlike the outcome-based language in SOC 2 or HIPAA, these are prescriptive controls an assessor checks against directly. If you process, store, or transmit cardholder data and fall under PCI DSS, penetration testing is not optional and a missing or stale test is a straightforward audit failure.
Requirement 11.4 mandates a documented methodology, regular internal and external testing, and remediation with retesting. Each sub-requirement is specific.
One nuance assessors enforce: 11.4.1 expects the methodology to cover the application layer specifically, including the threats in Requirement 6 such as injection, broken access control, and the rest of the OWASP-style list, not just a network port scan with a few exploit attempts. A test that only hit the network layer leaves 11.4.1 partially unmet. For a deeper look at how that application-layer testing actually runs, see what penetration testing is, types, and process.
The headline change carried from v4.0 into v4.0.1 is the move from v3.2.1's Requirement 11.3 to the restructured 11.4, with stronger expectations around methodology documentation, multi-factor authentication coverage, and more frequent segmentation testing for service providers.
Under v3.2.1 the testing requirement lived in 11.3; v4.x renumbers and tightens it into 11.4. The methodology requirement (11.4.1) is more explicit about what the document must contain. Segmentation testing expectations are clearer, and the standard formally distinguishes service-provider obligations. v4.0.1, released in June 2024 as a limited maintenance update, did not loosen these; it clarified wording and corrected errata while keeping the 11.4 structure. The broader v4.x deadline matters too: the future-dated requirements became mandatory on 31 March 2025, so if your last assessment was under v3.2.1 you should already be testing against 11.4. If you are migrating, the practical takeaway is to refresh your methodology document, confirm your segmentation testing cadence, and check that your scoping artifacts reflect the v4 emphasis on documenting and validating CDE scope at least annually. For how often the various PCI tests need to recur alongside your other obligations, see our guide to penetration testing frequency.
A QSA asks for the penetration testing methodology document, the scope it covered, dated internal and external test reports, the segmentation test results at the right cadence, and evidence that exploitable findings were remediated and retested. Each maps to a specific 11.4 sub-requirement they tick off.
During an assessment the document request usually reads: your 11.4.1 methodology (they will check it references an industry-accepted approach like NIST SP 800-115 and covers application and network layers); the 11.4.2 internal and 11.4.3 external reports dated within the last 12 months, plus any after-significant-change tests; the 11.4.5 or 11.4.6 segmentation results at 12 or 6 months; and the 11.4.4 retest evidence closing out exploitable findings. In our experience the two most common failures are a CDE scope that the QSA does not agree with, and a segmentation test that only checked a sample of paths rather than confirming the full isolation boundary. If the assessor cannot tie a finding to a remediation and a clean retest, 11.4.4 is unmet, full stop. Keep the engagement letter, the methodology, and the retest sign-off together so the mapping is obvious.
If you use network segmentation to reduce PCI scope, Requirements 11.4.5 and 11.4.6 require you to test that the segmentation controls actually work. The cadence differs by entity type, and this catches many teams off guard.
A point teams miss: the "after any change" trigger is independent of the calendar cadence. If you re-architect a firewall rule in month three, you owe a segmentation test then, not at the next scheduled interval. Treating the 6 or 12 months as a ceiling rather than the only trigger is the safe reading.
Segmentation testing verifies that systems outside the CDE genuinely cannot reach systems inside it, usually by attempting to route, scan, and connect from out-of-scope networks into the CDE and confirming firewall and ACL controls block it. If the controls fail, your out-of-scope systems are suddenly in scope, which can blow up the size and cost of your next assessment. This is why service providers carry the 6-month cadence: a single segmentation gap can expose dozens of client environments at once. For the network-layer fundamentals behind this, see what network penetration testing is.
Scope is the cardholder data environment plus any system that could impact the security of the CDE, and the methodology must be documented and industry-accepted before testing starts. PCI is strict on both.
The CDE includes systems that store, process, or transmit cardholder data, plus connected and security-impacting systems such as jump hosts, name resolution, and authentication servers that could affect CDE security. Testing must cover the full perimeter of the CDE and span both network-layer and application-layer attacks, including the OWASP-style application threats referenced in Requirement 6. The methodology document required by 11.4.1 should name your approach (NIST SP 800-115 and PTES are common references), define coverage, and specify retesting. Use OWASP WSTG and the OWASP API Security Top 10 for the application layer.
A concrete scoping example: an e-commerce merchant taking card-not-present payments should scope the public web app and its checkout flow, the payment API and tokenization service, any servers that touch primary account numbers before handoff to the processor, the admin and back-office systems with CDE access, and the segmentation controls separating that environment from the corporate network. The marketing CMS and the warehouse system are out of scope only if segmentation testing proves they cannot reach the CDE. That last clause is the trap: the common mistake is assuming a system is out of scope rather than proving it. Because the CDE changes and "after significant change" testing is mandatory, many teams pair the annual assessor-grade test with continuous validation; agentic pentesting is a modern way to catch CDE drift between formal tests. Before any engagement, prepare your scope and methodology so the assessor accepts the result.
