PCI DSS v4.0: Penetration Testing Requirements

Status, plain

PCI DSS v4.0 became the mandatory version on March 31, 2024. Requirements that were marked "best practice until March 31, 2025" are now in force. If you are scoping a PCI engagement today, treat all of v4.0 as applicable.

Requirement 11.4 sets the penetration-testing expectations. The numbering and the definitions tightened in v4.0 compared to v3.2.1, and segmentation testing got an explicit subrequirement (11.4.5) for environments that use segmentation as a scope-reduction control.

What 11.4 actually requires

The substantive requirements break into five subrequirements. The phrasing below is paraphrased; refer to the PCI DSS v4.0 standard for normative text.

Sub-req	What it requires
11.4.1	A documented penetration-testing methodology that covers external and internal testing, application-layer testing, network-layer testing, and segmentation effectiveness.
11.4.2	External penetration testing performed at least annually and after any significant infrastructure or application change.
11.4.3	Internal penetration testing performed at least annually and after any significant change.
11.4.4	Identified vulnerabilities are corrected and re-tested.
11.4.5	For environments using segmentation: segmentation-effectiveness testing performed at least annually (or every six months for service providers) by qualified personnel, with documented results.

Segmentation testing — the part most teams underestimate

If you reduce PCI scope by segmenting the cardholder data environment (CDE) from out-of-scope networks, you must verify that the segmentation actually contains. This is what 11.4.5 codifies.

What that means in practice for a tester:

• Confirm boundary controls. Document every segmentation control between out-of-scope and CDE — firewalls, NACLs, security groups, NSGs, VPC peering, transit gateway routes.
• Test from outside-in. Validate that an attacker on the out-of-scope side cannot reach in-scope systems. Start with allowed paths (proving they only allow what they should), then test denied paths (proving they actually deny).
• Test from inside-out for sensitive data flows. Validate that sensitive data does not leak across the boundary in ways that put out-of-scope systems into scope unintentionally.
• Document scope and findings. Even a passing segmentation test produces a deliverable your QSA will read.

Methodology — what an industry-accepted approach looks like

Requirement 11.4.1 expects a documented, repeatable methodology aligned to an industry-accepted standard. The standards QSAs commonly accept:

• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment.
• OWASP Testing Guide — for web application surfaces.
• OWASP API Security Testing Guide — for API surfaces.
• OSSTMM — Open Source Security Testing Methodology Manual.
• PTES — Penetration Testing Execution Standard.

Reports should explicitly cite which standard the engagement followed. "We tested broadly" is not enough.

The customized approach — when it makes sense

PCI DSS v4.0 introduced a "customized approach" as an alternative to the "defined approach" for many requirements. For penetration testing, the customized approach means: if you can demonstrate that an alternative method meets the intent of 11.4 with equivalent or better assurance, the QSA can accept it.

The honest read is that customized-approach pentest is rarely worth the effort. Defined-approach pentest is well-understood, predictable, and what your QSA wants to see. Customized approach is appropriate for specific operational constraints (for example, an environment where conventional testing methods cannot run safely), not as a general substitute.

How to scope a PCI v4.0 engagement

Three inputs determine the scope:

• The CDE. Every system that stores, processes, or transmits cardholder data, plus all systems connected to those.
• Connected and supporting systems. Identity systems that grant access to the CDE, monitoring infrastructure, backup paths.
• Segmentation boundaries. The exact controls that separate CDE from out-of-scope. These are tested under 11.4.5.

For a typical mid-market merchant or service provider, the engagement combines: external network testing, internal network testing, web application testing of CDE-facing surfaces, segmentation testing, and authenticated testing of CDE-touching applications. Add cloud configuration review if the CDE runs on AWS, Azure, or GCP.

Cadence — annual is the floor

Annual is the floor for both external and internal testing. Service providers do segmentation testing every six months. Add tests after significant changes — new payment integration, new card-on-file feature, new third-party processor relationship, infrastructure migration.