PCI DSS is the one standard on this list that does not make you read between the lines. The future-dated v4.x requirements became mandatory on 31 March 2025, and Requirement 11.4 says it plainly: perform internal and external penetration testing, on a defined cadence, using a documented methodology, and test your segmentation controls. There is no debate about whether a pentest is required. The debate, where there is one, is about getting scope, cadence, and the segmentation rules exactly right, because that is where assessors fail organizations.
This post walks 11.4 sub-requirement by sub-requirement, breaks out the methodology and segmentation rules, shows the different cadences for merchants versus service providers, scopes a card-not-present merchant concretely, shows what a segmentation test actually looks like at the command line, and maps findings to the sub-requirements a QSA ticks off. If you are coming from v3.2.1's 11.3, the renumbering is the least of the changes.
Yes, unambiguously. Requirement 11.4 explicitly requires both internal and external penetration testing. This is the clearest pentest mandate of any major compliance standard, and a missing or stale test is a straightforward audit failure, not a judgment call.
11.4 breaks into sub-requirements an assessor checks against directly: 11.4.1 the methodology, 11.4.2 internal testing, 11.4.3 external testing, 11.4.4 remediation and retest, and 11.4.5 and 11.4.6 segmentation control testing. Unlike the outcome-based language in SOC 2 or HIPAA, these are prescriptive. If you process, store, or transmit cardholder data and fall under PCI DSS, penetration testing is not optional. The room you do have is in scope: shrink the cardholder data environment with segmentation and you shrink what must be tested, which is exactly why the segmentation rules exist.
Requirement 11.4 mandates a documented methodology, regular internal and external testing, remediation with retesting, and segmentation validation. Each sub-requirement is specific, and the methodology one is where partial credit gets lost.
The nuance assessors enforce: 11.4.1 expects the methodology to cover the application layer specifically, including the Requirement 6 threats (injection, broken access control, and the rest), 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 how that application-layer testing actually runs, see penetration testing types and process and the OWASP API Top 10 methodology.
If you are still testing against v3.2.1's Requirement 11.3, you are out of date, and a QSA will treat it that way. v4.x moved the testing requirement from 11.3 to a restructured, tightened 11.4. The future-dated requirements that were "best practice" during the transition became mandatory on 31 March 2025.
v4.0.1, released in June 2024 as a limited maintenance update, did not loosen anything: it clarified wording and corrected errata while keeping the 11.4 structure. What changed relative to v3.2.1 matters for testing: 11.4.1 is more explicit about what the methodology document must contain, segmentation testing expectations are clearer, and the standard formally separates service-provider obligations with the 6-month 11.4.6 cadence. v4.x also leans harder on documenting and validating CDE scope at least annually. The practical migration checklist is short: refresh your methodology document so it names an industry-accepted approach and covers both layers, confirm your segmentation testing cadence against your entity type, and make sure your scoping artifacts reflect the v4 emphasis on annual scope validation. Treat the deadline as in the past, because it is.
A QSA asks for the methodology document, the scope it covered, dated internal and external reports, segmentation 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:
QSA evidence request - Requirement 11.4
[11.4.1] Pentest methodology doc -> references NIST 800-115?
covers app + network layers?
[11.4.2] Internal report, dated within 12 months + post-change
[11.4.3] External report, dated within 12 months + post-change
[11.4.4] Retest evidence closing each exploitable finding
[11.4.5] Segmentation test results (all entities, 12 mo)
[11.4.6] Segmentation test results (service providers, 6 mo)
[scope ] Annually validated CDE scope + data-flow diagramThe two most common failures we see: a CDE scope 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, 11.4.5 and 11.4.6 require you to prove the segmentation actually works, and the cadence differs by entity type. 11.4.5 applies to all entities: test segmentation controls at least every 12 months and after any change. 11.4.6 applies to service providers: every 6 months and after any change, because a single segmentation failure exposes many clients at once.
A segmentation test verifies that systems outside the CDE genuinely cannot reach systems inside it. In practice the tester sits on an out-of-scope network and tries to route, scan, and connect into the CDE, confirming firewall and ACL controls block it. The telltale output is everything filtered or refused:
$ nmap -sS -Pn -n --reason -p 22,443,1433,3389 10.20.0.0/24
(from CORP VLAN 10.99.0.0/24, expected fully isolated from CDE)
Host 10.20.0.15
PORT STATE REASON
22/tcp filtered no-response <- good: firewall dropping
443/tcp filtered no-response
1433/tcp filtered no-response
3389/tcp filtered no-response
Host 10.20.0.40
3389/tcp open syn-ack <- FINDING: RDP reachable into CDEThat single syn-ack on 3389 is the whole finding: an out-of-scope corporate host can reach RDP inside the CDE, so the corporate VLAN is not actually out of scope, and the next assessment just got bigger and more expensive. The "after any change" trigger is independent of the calendar: re-architect a firewall rule in month three and you owe a segmentation test then, not at the next scheduled interval. For the network-layer fundamentals, see internal network penetration testing and enterprise network misconfigurations.
Scope is the cardholder data environment plus any system that could impact CDE security, and the methodology must be documented and industry-accepted before testing starts. For a card-not-present e-commerce merchant the boundary is sharper than it looks, because a system is only out of scope if segmentation testing proves it cannot reach the CDE.
Scope the public web app and its checkout flow, the payment API and tokenization service, any servers that touch the primary account number 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 a segmentation test proves isolation. That last clause is the trap: the common mistake is assuming a system is out of scope rather than proving it, which is exactly what 11.4.5 exists to catch.
On a recent assessment of a mid-market online retailer, we found the checkout app shared a Redis instance with the marketing CMS for session storage. The CMS was "out of scope," but it could read session tokens minted by the in-scope checkout, which let us pivot from a low-value CMS host toward authenticated checkout sessions. The fix was a dedicated, network-isolated session store for the CDE, and the CMS came back into a properly tested boundary. Because the CDE drifts and "after significant change" testing is mandatory, many teams pair the annual assessor-grade test with continuous validation; agentic pentesting catches CDE drift between formal tests. Before any engagement, prepare your scope and methodology so the assessor accepts the result.