PCI DSS Penetration Testing Requirements

PCI DSS Requirement 11.4 mandates penetration testing as a discrete, recurring security control for any organization that stores, processes, or transmits cardholder data. This page covers the specific testing requirements under PCI DSS v4.0, how those requirements translate into structured engagement practices, the scenarios in which testing obligations arise, and the criteria that define adequate scope and methodology. Understanding this compliance framework is essential context for organizations in penetration testing for financial services and for practitioners seeking work in that sector.

Definition and scope

PCI DSS — the Payment Card Industry Data Security Standard — is published and maintained by the PCI Security Standards Council (PCI SSC), a body founded by American Express, Discover, JCB International, Mastercard, and Visa. Version 4.0, finalized in March 2022 and mandatory for compliance assessments from March 2025 onward, reorganized and expanded the penetration testing obligations relative to prior versions.

Requirement 11.4 is the primary control anchor for penetration testing under PCI DSS v4.0. It specifies that organizations must:

Define a penetration testing methodology
Perform penetration testing on external and internal network perimeters and critical systems at least once every 12 months, and after any significant infrastructure or application upgrade
Conduct application-layer penetration testing covering vulnerabilities listed in OWASP Testing Guide criteria and other relevant standards
Correct exploitable vulnerabilities and verify remediation through additional testing

The defined cardholder data environment (CDE) forms the primary scope boundary. The CDE includes all system components that store, process, or transmit cardholder data, plus any systems that could impact the security of the CDE if compromised. Connected and segmentation-adjacent systems are included unless network segmentation controls are validated as effective — and validating that segmentation itself requires penetration testing under Requirement 11.4.6.

Organizations classified as Service Providers under PCI DSS face more stringent obligations than merchants: penetration testing must occur at least every 6 months, and additional controls around penetration of segmentation controls apply. The PCI DSS v4.0 document distinguishes merchant levels and service provider classifications in separate applicability matrices.

How it works

PCI DSS v4.0 requires that penetration testing follow a defined, documented methodology. The standard does not mandate a single named framework but specifies that an acceptable methodology must incorporate:

Coverage of the entire CDE perimeter — both external (internet-facing) and internal attack paths
Network and application layers — network-layer tests cover infrastructure; application-layer tests must address OWASP Top 10 class vulnerabilities and logic flaws
Threat-intelligence grounding — testing must reflect current attack techniques relevant to the organization's environment, an explicit update in v4.0
Segmentation validation — organizations using network segmentation to reduce PCI scope must test that segmentation controls cannot be bypassed; this test must be performed by a qualified internal resource or a qualified external penetration tester

A complete PCI-compliant engagement follows the phased structure common to penetration testing methodology frameworks:

Pre-engagement: Scope definition, rules of engagement, and authorization documentation — see rules of engagement in penetration testing
Reconnaissance: Enumeration of CDE-adjacent systems and external attack surface
Exploitation: Attempted exploitation of identified vulnerabilities, including credential attacks, injection flaws, and privilege escalation within CDE boundaries — see privilege escalation techniques
Post-exploitation: Assessment of lateral movement potential within the CDE — see lateral movement techniques
Reporting: Documented findings with severity ratings, evidence of exploitation, remediation recommendations, and a re-test schedule

PCI DSS v4.0 does not require the use of specific tools, but Requirement 11.4.1 mandates that the tester possess sufficient independence — internal testers must be organizationally separate from the teams managing the systems tested, and external testers must be qualified by experience or certification. The penetration testing certifications landscape — including OSCP, GPEN, and CREST credentials — is commonly referenced by Qualified Security Assessors (QSAs) when evaluating tester qualifications.

Common scenarios

Annual compliance cycle: The most common PCI testing scenario is the mandatory 12-month cycle for merchants and the 6-month cycle for service providers. An organization running an e-commerce platform that accepts card payments directly must test its web application stack, the payment gateway integration, and the network perimeter surrounding those systems. Web application penetration testing and network penetration testing are both required components.

Post-change testing: Requirement 11.4.2 specifies testing after any significant infrastructure or application upgrade or change. A payment processor migrating its card vault to a cloud environment triggers a new penetration test obligation regardless of where the migration falls in the annual calendar. Cloud penetration testing practices apply directly in this scenario.

Segmentation validation: An organization that has reduced its PCI scope by segmenting the CDE from the broader corporate network must test whether that segmentation can be breached from the non-CDE side. This is a scoped test focused specifically on the controls at the boundary — firewalls, VLANs, and access control lists — rather than a full-scope engagement.

Third-party service providers: Under PCI DSS v4.0 Requirement 12.9, service providers must provide evidence of their own penetration testing to the merchants they serve, or agree to accept responsibility for the control. This drives a secondary market of provider-level testing distinct from merchant-level obligations.

Decision boundaries

Internal vs. external testers: PCI DSS v4.0 permits internal penetration testing if the internal tester is organizationally independent. However, Requirement 11.4.7 mandates that organizations in the smallest merchant tier and those with complex or high-risk environments use external, qualified penetration testers. QSAs typically scrutinize internal tester qualifications closely; the standard de facto pushes most organizations toward hiring a penetration testing firm.

Scope — segmentation vs. full CDE: If network segmentation is applied to reduce PCI scope, only the CDE and segmentation controls require testing — the broader corporate environment falls outside mandatory scope. If no segmentation exists, the entire network is considered in scope. The cost and complexity difference is substantial: cost of penetration testing scales directly with scoped system count and attack surface breadth.

Penetration testing vs. vulnerability scanning: PCI DSS Requirement 11.3 mandates vulnerability scanning (internal and external, quarterly) as a separate, parallel control. Vulnerability scanning and penetration testing are not interchangeable — scanning is automated enumeration; penetration testing requires demonstrated exploitation. The penetration testing vs. vulnerability assessment distinction is a common point of confusion during QSA assessments and an explicit classification boundary in the v4.0 standard.

Application scope — web vs. API: PCI DSS does not limit application-layer testing to traditional web applications. Any interface through which cardholder data flows — including REST and SOAP APIs processing card transactions — falls within scope. API penetration testing practices apply specifically to these surfaces, and omitting API endpoints from an engagement risks a finding of non-compliance during QSA review.

Frequency triggers: Beyond the calendar-based requirement, three events trigger out-of-cycle testing obligations: deployment of a new CDE component, a significant infrastructure change, and a confirmed compromise or suspected breach. Organizations relying solely on annual scheduling without a change-control linkage to testing cycles risk compliance gaps between annual tests.

References

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator