PCI DSS 4.0 Requirement 11.4: What Changed For Segmentation Testing And Scope?

Learn how PCI DSS 4.0 Requirement 11.4 covers penetration testing, segmentation validation, testing frequency, and cardholder data environment scope for compliance.

Updated 26 October 2026

PCI DSS 4.0 Requirement 11.4: What Changed For Segmentation Testing And Scope?

Under PCI DSS 4.0, PCI DSS Requirement 11.4 fundamentally redefines scope isolation by changing penetration testing from simple structural reviews into active, offensive validation. The updated standard mandates that organisations rigorously test all segmentation controls at least annually (or bi-annually for service providers) and immediately after any significant structural change. It strictly enforces continuous boundary verification to ensure out-of-scope systems cannot pivot or breach the Cardholder Data Environment (CDE).

In this blog, you will learn about the major shift from PCI DSS v3.2.1 to v4.0 under Requirement 11.4, key methodology updates, scoping mandates, and actionable strategies to ensure your segmentation controls remain audit-ready.

1. Overview of PCI DSS 4.0 Requirement 11.4

In previous iterations (PCI DSS v3.2.1, under Requirement 11.3), organisations often treated network segmentation validation as a passive checklist item or basic firewall port review. Under PCI DSS 4.0, all penetration testing mandates were restructured, expanded, and moved into Requirement 11.4.

The focus has shifted from high-level perimeter checks to proving that PCI DSS segmentation testing actively blocks every lateral movement path, unauthorised protocol, and out-of-scope connection attempt into the Cardholder Data Environment.

Key Mandates in Requirement 11.4

  • Documented Methodology (11.4.1): Entities must implement a fully documented, industry-accepted PCI DSS 4.0 penetration testing methodology (e.g., NIST SP 800-115, PTES, or OWASP).
  • Internal Penetration Testing (11.4.2): Must be performed annually and after any major application or infrastructure change by an independent, qualified resource.
  • External Penetration Testing (11.4.3): Must encompass all internet-facing CDE assets, payment gateways, APIs, and remote endpoints.
  • Mandatory Remediation & Retesting (11.4.4): Identified vulnerabilities require documented fixes and mandatory retesting to confirm resolution.
  • Segmentation Validation (11.4.5 & 11.4.6): Direct active testing to confirm complete isolation of out-of-scope networks from the CDE.

2. What Changed for Segmentation Testing in PCI DSS 4.0?

The transition to v4.0 eliminates common loopholes that previously allowed organisations to claim scope reduction without continuous proof. The key structural shifts directly affect how security teams plan, conduct, and report on segmentation effectiveness.

Comparing Legacy Requirements to PCI DSS 4.0

  • Legacy Standard (PCI DSS v3.2.1): Focused primarily on static firewall rule reviews, minimal retesting validation, annual testing schedules for service providers, and often unclear scoping guidelines for hybrid or cloud environments.
  • Updated Standard (PCI DSS v4.0 Requirement 11.4): Enforces active offensive traversal tests, mandatory retesting proof for identified vulnerabilities, a strict 6-month testing cycle for service providers, and explicit multi-tenant and API isolation controls.

Key Policy and Operational Shifts

  1. Active Traversal over Passive Review: Qualified Security Assessors (QSAs) no longer accept firewall rule exports or network diagrams alone. Testers must actively perform packet crafting, port scanning, and lateral movement attempts from out-of-scope segments toward the CDE.
  2. Frequency Mandates: While merchants must perform segmentation tests at least once every 12 months, service providers must perform segmentation testing every 6 months (under Requirement 11.4.6) and immediately after any changes to segmentation methods or controls.
  3. Triggered Testing on Changes: Any modification to firewalls, VLAN configurations, cloud security groups, or network routing mandates an immediate off-cycle segmentation test.
  4. Bidirectional Verification: Testing must verify that traffic cannot move from non-CDE to CDE, and that out-of-band or CDE-initiated connections to out-of-scope zones do not introduce covert exfiltration risks.

3. Scope Reduction & The CDE Boundary: What You Must Test

Network segmentation is the most effective approach to reducing PCI DSS scope, lowering compliance costs, and minimising risk exposure. However, if a single path exists from an out-of-scope asset to an in-scope asset, that out-of-scope asset immediately falls into scope.

Environment ZoneScope StatusRequirement 11.4 Testing Focus
Cardholder Data Environment (CDE)In-ScopeFull internal/external network & application-layer penetration testing.
Connected or Security-Impacting SystemsIn-ScopeMulti-factor authentication, jump servers, Active Directory, and logging infrastructure.
Out-of-Scope SegmentsOut-of-ScopeActive PCI DSS segmentation testing from these segments to ensure zero access to CDE.
Multi-Tenant / Cloud ServicesIn-Scope / SharedTenant separation testing (11.4.7) to verify logical isolation between customer environments.

Critical Assets to Include in Scoping

  • Web Applications & APIs: Any web interface processing, storing, or transmitting cardholder data or redirecting to payment processors.
  • Corporate Workstations: Testing lateral movement risks from standard user environments to the CDE.
  • Cloud Workloads & Microservices: Validating IAM roles, VPC peering, and cloud-native firewall boundaries.

4. The Role of Mandatory Retesting and Independence

Requirement 11.4.4 introduces strict accountability for remediation. Under v3.2.1, organisations frequently submitted a penetration test report alongside a simple action plan. Under v4.0, a penetration test is incomplete without documented proof of retesting.

Retesting Workflow

  • Step 1: Initial Penetration Test: Identify exploitable vulnerabilities and scope gaps across network and application layers.
  • Step 2: Risk-Based Remediation: Patch, reconfigure, or update systems based on CVSS scoring and internal risk thresholds.
  • Step 3: Verification Retesting: The penetration tester repeats specific attack vectors to verify that controls effectively mitigate the weakness.
  • Step 4: Assessor Sign-Off: Complete evidence, including initial findings, fix records, and successful retest logs, is provided to the QSA.

Organisational Independence Requirements

Requirement 11.4 permits internal staff to perform penetration tests only if organisational independence is maintained. The tester cannot be the administrator responsible for managing or configuring the targeted systems, and they must possess verifiable security credentials and expertise.

Secure Your Compliance Journey with Penva Security

Navigating the complexities of PCI DSS Requirement 11.4 requires technical mastery, deep offensive expertise, and assessor-ready reporting. At Penva Security, our specialised offensive security specialists deliver comprehensive PCI DSS 4.0 penetration testing and rigorous PCI DSS segmentation testing to help your organisation achieve seamless compliance.

Whether you need annual CDE testing, bi-annual service provider segmentation validation, or rapid retesting support, we provide detailed CVSS-scored reports, proof-of-concept evidence, and clear remediation guidance tailored to satisfy QSAs.

Partner with Penva Security Today for PCI DSS 4.0 Compliance Testing!

Frequently Asked Questions (FAQs)

What is the main difference between PCI DSS 3.2.1 and 4.0 penetration testing?

PCI DSS 4.0 restructures pentesting under Requirement 11.4, enforcing stricter methodology documentation, mandatory remediation retesting, explicit cloud/multi-tenant scoping, and active segmentation traversal attacks rather than simple administrative or configuration rule reviews.

How often must service providers perform PCI DSS segmentation testing?

Under Requirement 11.4.6, service providers must conduct PCI DSS segmentation testing at least once every six months, as well as immediately following any significant changes to network controls, security rules, or system infrastructure.

Can an internal employee conduct our PCI DSS 4.0 penetration test?

Yes, internal employees can conduct testing if they possess documented technical qualifications and maintain strict organisational independence, meaning they do not manage, configure, or administer the specific network segments or systems being assessed.

What happens if an exploitable vulnerability is found during the penetration test?

Under Requirement 11.4.4, identified vulnerabilities must be remediated according to risk levels. The penetration tester must then perform repeat testing to provide documented, verifiable evidence to your QSA that security fixes are active.

Does PCI DSS Requirement 11.4 apply to cloud and multi-tenant environments?

Yes. Cloud environments require full scope mapping and segmentation validation. Multi-tenant service providers must also fulfil Requirement 11.4.7 by proving effective logical isolation between distinct customer environments to prevent cross-tenant data access.

CONTINUE THE CONVERSATION

Share this insight

SEO

← Back to all insights