PCI DSS v4.0 Requirement 11.4: What Changed for VAPT

PCI DSS v4.0 became fully enforceable on March 31, 2025, and the 2026 assessment cycle is the first in which merchants and service providers are held to the v4.0 standard without transition allowances. Requirement 11.4 — the penetration testing requirement — received one of the more substantial revisions in the update, restructuring what was previously a small number of requirements into a set of specific sub-requirements with distinct testing and evidence expectations. This document describes the structural changes and what Qualified Security Assessors are now looking for.

Restructuring of Requirement 11

In v3.2.1, penetration testing lived under Requirement 11.3 as a small number of requirements — 11.3.1 for external penetration testing, 11.3.2 for internal penetration testing, 11.3.3 for remediation, and 11.3.4 for segmentation testing. In v4.0, vulnerability scanning consolidated under Requirement 11.3 while penetration testing moved to its own Requirement 11.4 with six sub-requirements. This structural change alone requires updated policy documentation, updated engagement scoping, and updated audit evidence organisation for organisations transitioning from v3.2.1.

Requirement 11.4.1 requires a documented penetration testing methodology aligned to industry-accepted standards such as NIST SP 800-115, OWASP, OSSTMM, or PTES. The methodology must cover the full scope of testing, define the qualifications required of testers, describe the testing approach, and specify how findings are documented. QSAs assess whether the methodology document is genuine and applied rather than boilerplate; assessments where the observed testing does not match the documented methodology receive findings.

Requirements 11.4.2 (internal penetration testing) and 11.4.3 (external penetration testing) are the direct successors to v3.2.1's 11.3.2 and 11.3.1. The testing frequency remains annually plus after significant changes, but v4.0 has clarified what constitutes a "significant change" and expanded the definition to include changes to segmentation controls. Organisations that previously only re-tested after changes to systems in the cardholder data environment (CDE) now need to re-test after changes to systems that provide segmentation between the CDE and out-of-scope networks.

Segmentation Testing Under Requirement 11.4.5

Requirement 11.4.5 is the successor to v3.2.1's 11.3.4 and remains one of the most commonly misunderstood PCI penetration testing requirements. It requires documented testing of the segmentation controls that isolate the CDE from other networks. The testing must confirm that segmentation controls are operational and effective — vulnerability scanning is explicitly not sufficient.

The evidence expected for segmentation testing is documented attempts to traverse from out-of-scope networks to the CDE and back, with each attempt's result recorded. This is fundamentally penetration testing evidence, not vulnerability scanning evidence. A common finding in QSA assessments is that the organisation ran vulnerability scans from out-of-scope networks that produced no findings against CDE hosts and treated this as segmentation validation — but the absence of vulnerability findings does not demonstrate that segmentation is enforced.

Segmentation testing frequency is annually for merchants and every six months for service providers. The definition of "service provider" for this purpose is broader than many organisations realise and includes any entity that stores, processes, or transmits cardholder data on behalf of another entity. Software-as-a-service providers whose applications handle payment tokens, payment processors, hosting providers whose customers store cardholder data, and managed security service providers with access to cardholder environments all fall under service provider requirements.

Requirement 11.4.6 and Multi-Tenant Service Providers

Requirement 11.4.6 is new in v4.0 and specifically addresses multi-tenant service providers. It requires validation that segmentation controls between customer environments are effective, in addition to the existing 11.4.5 requirement for CDE-to-out-of-scope segmentation. Software-as-a-service providers whose customers each have their own logical tenant within a shared platform must now demonstrate that tenant isolation actually holds under adversarial testing.

Tenant isolation testing methodology is different from network segmentation testing methodology. Network segmentation testing focuses on connectivity between network segments; tenant isolation testing focuses on whether authenticated users of tenant A can access data or perform actions in tenant B. The tests are typically executed at the application layer through the platform's normal API surface using tenant-scoped credentials.

For service providers pursuing multi-tenant certification, Requirement 11.4.6 represents one of the more substantial testing expansions in v4.0. Tenant isolation issues are pervasive in multi-tenant platforms, and adversarial testing consistently finds broken object-level authorization patterns that produce cross-tenant data access. Organisations that have not previously conducted formal tenant isolation testing should assume that findings will emerge in the first v4.0 assessment cycle.

Remediation and Retesting Requirements

Requirement 11.4.4 covers remediation of penetration test findings. All exploitable vulnerabilities identified must be corrected, and the corrections verified via repeat testing. This has always been an implicit requirement, but v4.0 makes it explicit and expects documented evidence of the remediation-and-verification cycle for every finding.

The definition of "exploitable vulnerabilities requiring correction" deserves attention. Not every finding from a penetration test is exploitable in the operational environment; some findings may be theoretical, applicable only under conditions not present in production, or already compensated by other controls. The methodology under 11.4.1 should describe how findings are triaged for exploitability, and the assessment package should include the triage rationale for each finding not remediated.

Retesting evidence must be produced for each remediated finding. The retesting can be integrated into the next scheduled penetration test cycle or performed as a targeted engagement immediately following remediation. AI-augmented VAPT platforms that offer unlimited retesting have become common in organisations pursuing PCI compliance specifically because the retesting obligation would otherwise require additional external engagements for each remediation.

Application-Layer Testing Expansion

Application-layer testing under 11.4.2 and 11.4.3 has been expanded to include testing of custom application code deployed in cloud environments and applications accessed via the CDE-facing web presence regardless of where they are hosted. Organisations that previously scoped application-layer testing to a specific list of CDE-hosted applications should reassess whether cloud-deployed application code and third-party applications in scope need to be added.

The relationship between Requirement 11.4 application-layer testing and Requirement 6.5 secure coding validation is clarified in v4.0. The 6.5 requirements address secure development practices during application build; the 11.4 requirements address runtime security testing of deployed applications. Both are required — evidence for one does not substitute for the other. Reports produced by application security testing tools should be organised to satisfy both requirements distinctly.

Coverage of OWASP Top 10 categories is explicitly expected in application-layer testing. The current OWASP Top 10 (updated to 2025) is the reference. Testing that produces no findings under specific Top 10 categories should include methodology documentation explaining what tests were performed in that category and why no findings emerged. Absence of findings without corresponding methodology evidence typically produces QSA follow-up questions.

Evidence Organisation for QSA Assessments

QSAs assessing v4.0 compliance expect penetration testing evidence organised to a specific structure: methodology documentation (11.4.1), scope definition and coverage evidence for internal testing (11.4.2), scope definition and coverage evidence for external testing (11.4.3), finding remediation and retesting evidence (11.4.4), segmentation testing evidence (11.4.5), and for service providers, multi-tenant isolation testing evidence (11.4.6). Reports that mix these evidence types together generate follow-up requests during assessment fieldwork.

Tester qualification evidence is a growing area of QSA scrutiny. The methodology under 11.4.1 must describe the qualifications required, and evidence must exist that the actual testers met those qualifications. For automated VAPT platforms, this includes evidence of the platform's methodology validation, the qualifications of the platform operators, and the human review process for platform-generated findings. Purely automated testing without any documented human oversight raises assessment questions.

The 2026 assessment cycle is the first where organisations that transitioned to v4.0 on the deadline are being fully assessed against the new requirements. QSAs are actively developing their assessment approaches for the newer sub-requirements, and organisations that engage early with their QSA about evidence expectations typically have smoother assessments. The organisations that will struggle in 2026 are those treating v4.0 penetration testing evidence as equivalent to their v3.2.1 evidence — the structural changes require a corresponding restructuring of the evidence they produce.