PCI DSS 4.0 Penetration Testing Requirements: What Changed and How to Prepare for 2026

TL;DR: PCI DSS 4.0 significantly expanded penetration testing requirements compared to version 3.2.1. The future-dated requirements became mandatory on March 31, 2025, meaning every organization processing, storing, or transmitting cardholder data must now comply with the stricter rules. Key changes include mandatory documented methodology, explicit internal and external testing requirements, expanded segmentation verification, application-layer testing aligned to OWASP Top 10, and the new customized approach validation option that requires even more rigorous testing. Service providers face additional obligations including semi-annual segmentation testing and multi-tenant isolation verification. This guide maps every requirement, explains what changed, and provides a practical preparation checklist for 2026 assessments.

---

PCI DSS 4.0 represents the most significant overhaul of the Payment Card Industry Data Security Standard since its inception. Released in March 2022 with a transition period ending March 31, 2025, the updated standard introduced substantial changes to penetration testing requirements that many organizations are still working to understand and implement. With 2026 assessments approaching, the window for preparation is narrowing.

If you process, store, or transmit cardholder data -- or if you provide services to organizations that do -- understanding the penetration testing requirements in PCI DSS 4.0 is not optional. Unlike some compliance frameworks where penetration testing is implied or recommended, PCI DSS explicitly mandates it with specific scope, methodology, and frequency requirements that your Qualified Security Assessor (QSA) will evaluate in detail.

What Changed from PCI DSS 3.2.1 to 4.0

PCI DSS 3.2.1 addressed penetration testing primarily in Requirement 11.3, with relatively broad language that gave organizations significant latitude in how they conducted and documented their testing. Version 4.0 renumbered, expanded, and tightened these requirements considerably. Here are the most significant changes.

Renumbered Requirements

PCI DSS 4.0 reorganized the requirement structure. Penetration testing moved from Requirement 11.3 to Requirement 11.4, with sub-requirements 11.4.1 through 11.4.7. This is not just cosmetic -- the renumbering reflects expanded content and additional sub-requirements that did not exist in 3.2.1.

Mandatory Documented Methodology

Requirement 11.4.1 now explicitly requires that a penetration testing methodology be defined, documented, and implemented. The methodology must:

• Be based on an industry-accepted approach (PTES, OSSTMM, OWASP Testing Guide, or NIST SP 800-115)
• Cover the entire cardholder data environment (CDE) perimeter and critical systems
• Include both internal and external testing
• Include testing from both inside and outside the network
• Include application-layer testing that addresses, at minimum, the vulnerabilities listed in Requirement 6.2.4 (which maps closely to the OWASP Top 10)
• Include network-layer penetration tests that cover all network functions and operating systems

Under 3.2.1, organizations could get by with a methodology that referenced industry standards in general terms. Under 4.0, the QSA will evaluate whether your documented methodology specifically addresses each of these elements and whether your actual testing followed the documented methodology. A vague reference to "industry best practices" will not pass muster.

Expanded Scope and Criticality

Requirement 11.4.2 specifies that internal penetration testing must be performed on all in-scope systems. The definition of "in-scope" under PCI DSS 4.0 includes any system that stores, processes, or transmits cardholder data, any system that is in the same network segment as CDE systems, and any system that could affect the security of the CDE. This is broader than many organizations realize, and underscoping the penetration test is one of the most common findings QSAs report.

Requirement 11.4.3 covers external penetration testing, requiring testing of the externally accessible perimeter of the CDE and any critical systems accessible from outside the organization's network.

Segmentation Testing: Now More Rigorous

Requirement 11.4.5 addresses network segmentation verification -- testing that confirms network segmentation controls effectively isolate the CDE from out-of-scope systems. Under 3.2.1, segmentation testing was required but the methodology was loosely defined. Under 4.0:

• Segmentation testing must confirm that segmentation methods are operational and effective
• Testing must verify that out-of-scope systems cannot communicate with systems in the CDE
• For service providers, segmentation testing must be performed every six months (not just annually)
• Testing must occur after any changes to segmentation controls or methods

The semi-annual requirement for service providers is particularly significant. Organizations that were performing annual segmentation verification under 3.2.1 now need to double their testing frequency, which has meaningful cost and operational implications.

Future-Dated Requirements (Now Mandatory)

Several penetration testing requirements were designated as "future-dated" when PCI DSS 4.0 was released, meaning they were best practices until March 31, 2025, after which they became mandatory. These are now fully enforceable:

• 11.4.1: The documented methodology requirement described above.
• 11.4.6: For service providers, penetration testing must specifically confirm that the customized approach results in expected security controls. This is new territory -- the customized approach is a PCI DSS 4.0 concept that allows organizations to meet security objectives through alternative controls, but those alternative controls must be validated through testing.
• 11.4.7: Multi-tenant service providers must support penetration testing by their customers. This means that if you provide shared infrastructure to merchants, you must have processes and policies that allow your tenants to conduct (or have conducted on their behalf) penetration testing of their environments within your infrastructure.

The Scan vs Pentest Distinction: Critical for Compliance

PCI DSS 4.0 is exceptionally clear about the difference between vulnerability scanning and penetration testing, and conflating the two is one of the fastest ways to fail an assessment.

Vulnerability scans (Requirements 11.3.1 and 11.3.2) are automated assessments that identify known vulnerabilities, misconfigurations, and missing patches across systems. PCI DSS requires:

• Internal vulnerability scans at least quarterly
• External vulnerability scans at least quarterly by an Approved Scanning Vendor (ASV)
• Scans after any significant change

Penetration tests (Requirement 11.4) go beyond scanning to include active exploitation. The standard explicitly states that penetration testing involves "attempting to exploit vulnerabilities" to "determine whether unauthorized access or other malicious activity is possible." A penetration test that only identifies vulnerabilities without attempting exploitation does not satisfy Requirement 11.4.

This distinction matters because some vendors market vulnerability scanning as penetration testing. An automated scan report, regardless of how comprehensive it is, does not satisfy the penetration testing requirement. Your QSA will examine the report methodology and evidence to determine whether actual exploitation was attempted. If the evidence shows only scanner output without exploitation attempts, the requirement will be marked as not in place.

The implication for AI-automated testing platforms is important: the platform must demonstrate exploitation validation, not just vulnerability detection, to satisfy PCI DSS penetration testing requirements. ThreatExploit's automated testing includes active exploitation attempts with evidence capture, which is specifically designed to meet this requirement.

Requirement-by-Requirement Breakdown

Here is a detailed mapping of each penetration testing requirement under PCI DSS 4.0, what the QSA evaluates, and how to satisfy it.

Requirement 11.4.1: Methodology and Scope

What it says: A penetration testing methodology is defined, documented, and implemented, and includes industry-accepted penetration testing approaches, coverage for the entire CDE perimeter and critical systems, testing from both inside and outside the network, and testing to validate segmentation and scope-reduction controls.

What the QSA evaluates:

• Does a written methodology document exist?
• Does it reference a recognized standard (PTES, OSSTMM, OWASP, NIST)?
• Does the scope cover all in-scope systems?
• Is there evidence that testing followed the documented methodology?

How to satisfy it: Maintain a penetration testing policy document that specifies the methodology, scope definition process, testing frequency, and reporting requirements. Ensure your testing provider (whether internal, external, or automated) follows and documents adherence to this methodology.

Requirement 11.4.2: Internal Penetration Testing

What it says: Internal penetration testing is performed per the defined methodology at least once every 12 months and after any significant infrastructure or application change.

What the QSA evaluates:

• Was internal testing performed within the last 12 months?
• Does the test report cover all in-scope internal systems?
• Were tests repeated after significant changes?
• Were identified vulnerabilities corrected and retested?

How to satisfy it: Conduct internal penetration testing annually at minimum. Document what constitutes a "significant change" in your methodology. Maintain evidence that retesting occurred after major infrastructure changes, application deployments, or network modifications.

Requirement 11.4.3: External Penetration Testing

What it says: External penetration testing is performed per the defined methodology at least once every 12 months and after any significant infrastructure or application change.

What the QSA evaluates:

• Same criteria as 11.4.2, applied to external testing
• Was the entire external perimeter tested?
• Were all externally accessible systems included?

How to satisfy it: Conduct external penetration testing annually at minimum. Ensure scope includes all internet-facing systems in the CDE: web applications, APIs, VPN endpoints, email gateways, and any other externally accessible services.

Requirement 11.4.4: Remediation and Retesting

What it says: Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected, and testing is repeated to verify corrections.

What the QSA evaluates:

• Is there a remediation plan for each finding?
• Were critical and high findings remediated?
• Is there evidence of retesting after remediation?
• Is the retest evidence documented in the report?

How to satisfy it: Establish a remediation workflow with defined SLAs by severity (e.g., critical: 15 days, high: 30 days, medium: 90 days). After remediation, perform retesting and document results. AI-automated testing makes retesting efficient and immediate -- you can validate a fix within hours of deployment rather than scheduling a follow-up engagement.

Requirement 11.4.5: Segmentation Verification

What it says: If segmentation is used to isolate the CDE, penetration tests are performed to verify segmentation controls are operational and effective -- at least every 12 months, and every six months for service providers.

What the QSA evaluates:

• Is there segmentation between CDE and out-of-scope networks?
• Were segmentation controls tested by attempting to penetrate from out-of-scope to in-scope segments?
• For service providers: were two segmentation tests performed in the last 12 months?
• Were tests repeated after changes to segmentation methods?

How to satisfy it: Schedule segmentation-specific tests at the required frequency. Testing should include attempts to cross segment boundaries using routing analysis, firewall rule testing, VLAN hopping attempts, and exploitation of any services that span segments. Automated testing can perform segmentation verification on a continuous basis, catching configuration drift between formal assessment cycles.

Requirement 11.4.6: Customized Approach Validation (Service Providers)

What it says: If using the customized approach for any PCI DSS requirement, the entity's customized approach is confirmed through penetration testing.

What the QSA evaluates:

• Has the organization adopted the customized approach for any requirement?
• If so, does the penetration testing specifically validate the alternative controls?
• Is there documented evidence that the alternative controls achieve the intended security objective?

How to satisfy it: If you use the customized approach, work with your QSA to define specific penetration testing scenarios that validate your alternative controls. Document the testing approach, expected results, and actual results. This requires close coordination between your testing program and your compliance team.

Requirement 11.4.7: Multi-Tenant Service Provider Testing Support

What it says: Multi-tenant service providers support their customers' requests for penetration testing in accordance with specified methods.

What the QSA evaluates:

• Does the service provider have a policy for supporting customer pentesting?
• Are there defined procedures for customers to request and conduct testing?
• Are reasonable timeframes and methods specified?

How to satisfy it: Develop a customer penetration testing policy that defines: how customers request testing, what methods are permitted (external only, internal with coordination, automated scanning), scheduling procedures, and any restrictions necessary to protect other tenants. Communicate this policy to all customers.

Application-Layer Testing: The OWASP Alignment

PCI DSS 4.0 Requirement 6.2.4 defines the minimum set of application vulnerabilities that must be addressed in development, and Requirement 11.4 ties penetration testing to these same vulnerability categories. While the standard does not use the phrase "OWASP Top 10" directly, the vulnerability categories align closely:

• Injection attacks (SQL, LDAP, XPath, command injection)
• Buffer overflows
• Insecure cryptographic storage
• Insecure communications
• Improper error handling
• Cross-site scripting (XSS)
• Improper access control (including IDOR, forced browsing, privilege escalation)
• Cross-site request forgery (CSRF)
• Broken authentication and session management
• All other vulnerabilities identified in Requirement 6.2.4

Your penetration test must demonstrate that each of these vulnerability categories was tested. The QSA will review the test report to confirm coverage. If your report shows SQL injection testing but no evidence of authentication testing, the requirement will be partially met at best.

This is an area where automated testing platforms provide a significant advantage. AI-powered testing systematically checks every vulnerability category in the methodology with complete consistency, ensuring no category is missed due to time pressure or human oversight. Manual testers, under the time constraints of a fixed-scope engagement, may prioritize certain categories and give others cursory attention.

How AI-Automated Testing Satisfies PCI DSS 4.0

Mapping AI-automated penetration testing to each PCI DSS 4.0 requirement:

Requirement	What It Demands	How Automation Satisfies It
11.4.1	Documented methodology	Platform methodology documentation based on OWASP/PTES
11.4.2	Annual internal testing + after changes	On-demand internal testing, triggered by CI/CD or schedule
11.4.3	Annual external testing + after changes	On-demand external testing with same-day availability
11.4.4	Remediation and retesting	Immediate retesting after fixes with before/after evidence
11.4.5	Segmentation verification (semi-annual for SPs)	Automated segmentation testing on configurable schedule
11.4.6	Customized approach validation	Configurable test scenarios for custom controls
11.4.7	Multi-tenant testing support	Self-service tenant testing capability

The key advantage is frequency. PCI DSS 4.0 sets minimum testing frequencies (annually for most, semi-annually for service provider segmentation), but the standard also requires testing after "significant changes." In modern development environments where code is deployed weekly or daily, defining and tracking significant changes is operationally challenging. Continuous automated testing sidesteps this problem entirely: if you test continuously, every change is tested, and the "significant change" trigger becomes moot.

Preparation Checklist for 2026 Assessments

Use this checklist to evaluate your readiness for PCI DSS 4.0 penetration testing requirements in your upcoming assessment.

Documentation

• Written penetration testing methodology referencing PTES, OSSTMM, OWASP, or NIST SP 800-115
• Defined scope that maps to the current CDE boundary and all in-scope systems
• Definition of "significant change" that triggers retesting
• Remediation SLAs by vulnerability severity
• Testing schedule that meets minimum frequency requirements

Testing Coverage

• Internal penetration testing completed within the last 12 months
• External penetration testing completed within the last 12 months
• Segmentation verification completed (within 12 months for merchants, 6 months for service providers)
• Application-layer testing covering all Requirement 6.2.4 vulnerability categories
• Network-layer testing covering all operating systems and network functions in scope
• Retesting performed after all significant infrastructure or application changes since last assessment

Evidence Quality

• Test reports include exploitation evidence, not just vulnerability identification
• CVSS scores assigned to all findings
• Remediation evidence documented for all critical and high findings
• Retest results confirming remediation effectiveness
• Executive summary and methodology sections suitable for QSA review
• Clear scope statement in each report matching the CDE boundary

Service Provider Specific

• Semi-annual segmentation testing completed (two tests within the last 12 months)
• Customized approach controls validated through penetration testing (if applicable)
• Customer penetration testing support policy documented and communicated (if multi-tenant)

Process Improvements for 2026

• Evaluate AI-automated testing to increase testing frequency beyond minimums
• Implement continuous testing to address "significant change" testing requirements
• Integrate penetration testing into the change management and deployment pipeline
• Establish automated retesting workflow for faster remediation validation
• Review and update the testing methodology document at least annually

The Compliance Floor vs Security Ceiling

PCI DSS 4.0 sets a floor for penetration testing -- minimum requirements that must be met to achieve compliance. Meeting that floor is necessary. But as we discuss in detail in our article on compliance pentesting vs real security testing, compliance minimums are designed to establish a baseline, not to provide comprehensive security.

Organizations that treat PCI DSS penetration testing requirements as the ceiling rather than the floor leave significant risk unaddressed. The requirements do not cover testing of payment-adjacent systems that are out of scope but could serve as attack pivots. They do not require testing of business logic flaws specific to payment flows. They do not mandate social engineering testing or physical security assessments.

The most secure payment organizations use PCI DSS requirements as the starting point and extend testing to cover their actual risk profile. AI-automated testing makes this economically feasible because the marginal cost of testing beyond the compliance minimum is negligible when testing is automated. Running a pentest against out-of-scope systems alongside the mandated in-scope test costs little additional effort when the platform handles both simultaneously.

PCI DSS 4.0 raised the penetration testing floor significantly compared to 3.2.1. Meeting the new floor requires better documentation, broader scope, more frequent testing, and more rigorous evidence. Organizations that prepare now -- with documented methodologies, automated testing capabilities, and remediation workflows -- will navigate their 2026 assessments smoothly. Those that wait will find the gap between their current practices and the new requirements wider than expected.