PCI DSS and Penetration Testing: What Requirement 11.4 Actually Requires

PCI DSS is one of the few compliance frameworks that names penetration testing explicitly and specifically, rather than leaving it implied under a general "risk assessment" requirement the way NIS2 and SOC 2 both do. Under PCI DSS v4.0, testing lives under Requirement 11, "Test Security of Systems and Networks Regularly", with the penetration testing obligations specifically broken out into their own numbered sub-requirements, not folded into a single general clause.

What Requirement 11.4 breaks down into

Requirement 11.4 is a defined, multi-part obligation, not a single test. 11.4.1 requires a documented, defined penetration testing methodology to actually exist before testing happens, not just an ad-hoc engagement. 11.4.2 requires internal penetration testing at least every 12 months, and after any significant infrastructure or application change. 11.4.3 requires the same cadence for external penetration testing. 11.4.5 separately requires testing of segmentation controls specifically, confirming the cardholder data environment (CDE) is actually isolated from the rest of the network the way the architecture claims, not just testing the CDE itself in isolation.

Why segmentation testing trips people up

11.4.5's segmentation testing requirement is the part most frequently under-scoped in a rushed engagement. It's not enough to test the systems inside the CDE, the requirement is specifically about confirming that systems outside the CDE genuinely cannot reach it, which means testing from the broader corporate network inward, not just testing the payment environment as an isolated island. A CDE that's individually well-secured but reachable from an under-segmented internal network still fails this requirement, regardless of how strong the CDE's own controls are.

What "significant change" triggers a retest

11.4.2 and 11.4.3's "after any significant change" trigger is broader than many teams assume, a new payment integration, a network architecture change, a new system added to the CDE, or a segmentation control modification can all trigger the retest requirement outside the normal annual cycle. Treating this as purely a once-a-year calendar item, rather than something tied to actual change events, is a common gap we see at QSA assessment time.

What we deliver against this requirement

• A documented methodology aligned with 11.4.1, so the engagement itself satisfies the requirement's own documentation expectation, not just the testing activity
• Both internal and external testing scoped and timed to satisfy 11.4.2 and 11.4.3's annual and change-triggered cadence
• Dedicated segmentation testing under 11.4.5, tested from outside the CDE inward, not just within it
• Reporting structured to hand directly to your QSA as evidence, not a generic report that needs translation into PCI's own language

This runs on the same manual, adversary-emulated methodology behind our core Penetration Testing service, scoped specifically against PCI DSS's own numbered sub-requirements. For how this fits alongside our other financial services compliance work, see our Financial Services Security page.