Service Provider Segmentation Testing Frequency

PCI DSS 4.0.1 Requirement 11.4.6 requires service providers that use network segmentation to reduce PCI scope to penetration test the effectiveness of segmentation controls at least every six months and after any change to the segmentation controls or methods. To operationalize it, you need a defined trigger-based testing process, a semiannual test cadence, and retained evidence that proves segmentation still isolates the CDE. ¹

Key takeaways:

• If you rely on segmentation for CDE isolation, you must validate it with penetration testing on a fixed cadence and after changes. ¹
• “After changes” needs a real change-control trigger, not an informal promise to “test later.” ²
• Auditors will look for proof: test scope, methods, results, remediation, and retest tied to your segmentation boundary. ¹

“Service provider segmentation testing frequency” is a scoping control requirement. If your organization is a PCI service provider and you use segmentation to isolate the cardholder data environment (CDE) from other networks, you only get the scoping benefit if you can prove the segmentation actually works and keeps working over time. PCI DSS 4.0.1 makes that proof time-bound and change-bound: test at least once every six months and again after changes to segmentation controls or methods. ¹

For a CCO, GRC lead, or compliance officer, the operational problem is rarely the idea of testing. It’s governance: defining what counts as a “segmentation control,” what counts as a “change,” who owns the trigger, how the test scope maps to the CDE boundary, and what evidence will satisfy a QSA or internal audit without rework.

This page translates the requirement into a practical operating model: roles, procedures, decision points, artifacts, and exam-ready evidence. Where helpful, it also shows how to connect third-party risk management to segmentation testing, since many service providers depend on hosting, managed network services, or SaaS components that can affect segmentation outcomes.

Regulatory text

PCI DSS 4.0.1 Requirement 11.4.6 (service providers only): If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls at least once every six months and after any changes to segmentation controls/methods. ¹

Operator meaning: you must (1) run penetration testing that specifically attempts to bypass or defeat the segmentation boundary, (2) do it on a recurring cadence that meets the minimum frequency, and (3) do it again any time you change segmentation-relevant designs, tools, or configurations. ¹

Note: This requirement is explicitly “additional” and “for service providers only.” If you are not a service provider, confirm which segmentation validation requirements apply to your environment under your applicable PCI DSS obligations. ¹

Plain-English interpretation (what the requirement is really asking)

If you claim “the CDE is isolated,” you must continuously earn that claim. Penetration testing is the independent check that your segmentation controls still prevent access paths from non-CDE networks into the CDE.

Two clocks drive compliance:

1. Calendar clock: run segmentation penetration tests at least every six months. ¹
2. Change clock: re-test after any change to segmentation controls or methods. ¹

Practically, this means your change management process must know which changes “touch segmentation,” and your security testing program must have capacity to execute (or contract) a segmentation-focused pen test on demand.

Who it applies to

Entity scope

• PCI service providers that store, process, or transmit account data, or whose people/processes/systems can affect the security of the CDE, and that rely on segmentation to isolate the CDE. ¹

Operational scope (what systems and teams are involved)

You should expect to coordinate across:

• Network/security engineering (firewalls, ACLs, routing, microsegmentation)
• Cloud platform teams (VPC/VNet design, security groups, NACLs, transit gateways)
• Infrastructure/endpoint teams (jump hosts, bastions, management planes)
• Change management / CAB
• Pen test provider or internal offensive security
• GRC/compliance to set policy, evidence standards, and audit response

Common segmentation controls/methods in scope

Treat these as “segmentation controls/methods” unless you can clearly justify otherwise:

• Firewalls and rule sets separating CDE and non-CDE
• Network ACLs, security groups, routing controls that enforce isolation
• Microsegmentation policies (e.g., host-based or SDN controls)
• Jump/bastion access paths into CDE-adjacent networks
• VPN and remote administration paths that could bridge networks
• Shared services that straddle zones (directory services, logging, monitoring)

What you actually need to do (step-by-step)

Step 1: Declare the segmentation boundary you are defending

Create (or refresh) a CDE segmentation boundary package:

• Current network diagrams showing CDE and connected networks
• Inventory of segmentation enforcement points (devices/services/policies)
• Allowed communications matrix (source zone → destination zone, ports/protocols, purpose)
• List of “trusted management paths” and administrative access methods

This package becomes the anchor for both testing scope and audit evidence.

Step 2: Define “segmentation change triggers” in change management

Write a short standard that says which changes require a segmentation pen test re-run. Minimum categories:

• Firewall/ACL/security group policy changes affecting CDE paths
• Routing changes, peering, gateway changes, SD-WAN changes
• Network architecture changes (new subnets, new zones, new shared services)
• Identity/remote access changes that could create bridging paths (bastion redesign, VPN changes)
• Tool/method changes (moving from on-prem firewall to cloud-native controls)

Operationalize it with:

• A change ticket tag (e.g., “Segmentation-impacting: Yes/No”)
• A required security review for “Yes”
• A required test plan or test scheduling task for “Yes”

Your goal: no segmentation-impacting change closes without either (a) evidence of completed segmentation testing or (b) a documented, approved exception with a dated plan.

Step 3: Build the semiannual test schedule (and don’t let it slip)

Set a recurring calendar commitment for segmentation pen tests that meets the “at least once every six months” minimum. ¹

To keep it exam-proof:

• Assign a control owner (named role, not a team alias)
• Pre-book testing windows with engineering and your pen test resource
• Ensure the scope aligns to the current segmentation boundary package

Step 4: Execute penetration testing focused on segmentation effectiveness

Your pen test plan should explicitly include segmentation validation activities, such as:

• Attempting network path traversal from non-CDE to CDE segments
• Testing rule misconfigurations, shadow rules, and overly broad access
• Validating management-plane isolation (admin networks can be a bypass)
• Cloud-specific route and security policy evaluation (security group/NACL/routing combinations)

Make sure the report clearly states:

• What was tested (zones, pathways, enforcement points)
• Test methods and constraints
• Results: confirmed isolation or identified bypass paths
• Evidence: commands, tool outputs, screenshots, packet captures where appropriate

Step 5: Remediate findings and retest to closure

Treat segmentation bypass findings as high urgency because they can:

• Expand PCI scope unexpectedly
• Break your compliance attestation logic
• Increase the risk that non-CDE compromise reaches CDE systems

Your closure package should include:

• Remediation tickets
• Change approvals
• Retest evidence proving the bypass is closed
• Updated diagrams/ruleset documentation if the boundary changed

Step 6: Tie third-party dependencies into the control (service provider reality)

If third parties manage parts of your network or cloud environment, your control still has to operate.

• Contractually require cooperation for segmentation testing (access, testing windows, support).
• Ensure third-party change notifications feed your segmentation-change trigger.
• Retain due diligence and follow-up actions showing decisions and oversight were documented and revisited. ¹

A practical way to run this in Daydream: track segmentation-impacting third parties as “scope-critical,” attach the semiannual testing commitment as a control obligation, and collect test reports, change triggers, and exceptions in one audit-ready record.

Required evidence and artifacts to retain

Keep evidence that answers: “Did you test on time, and did you test after changes, and did you test the right boundary?”

Minimum artifact set:

• Segmentation boundary package (diagrams, comms matrix, enforcement inventory)
• Testing schedule and completion records (invites, work orders, statement of work)
• Penetration test plan showing segmentation controls in scope
• Pen test report(s) with segmentation results and supporting evidence
• Change tickets flagged as segmentation-impacting, with required approvals
• Remediation and retest records tied back to findings
• Exceptions (if any) with approval, rationale, compensating controls, and dated remediation plan
• Third-party coordination evidence where applicable (communications, access approvals, contract clauses)

Common exam/audit questions and hangups

Auditors and QSAs tend to press on these points:

• “Show me the last two segmentation tests and the exact dates.” They are checking cadence compliance. ¹
• “What changes occurred since the last test, and where is the post-change test?” They are checking your trigger mechanism. ¹
• “How do you know your pen test actually tested segmentation?” A generic external pen test often fails to prove segmentation validation.
• “Does your test scope match your current CDE boundary diagrams?” If diagrams are stale, your testing evidence looks mis-scoped.
• “Who owns this control?” If ownership is split across network, security, and compliance without a single accountable role, cadence slips.

Frequent implementation mistakes (and how to avoid them)

1. Relying on vulnerability scans instead of penetration testing. The requirement calls for penetration tests on segmentation controls. Keep the activity explicitly pen-test oriented. ¹

2. Testing “the environment” but not the segmentation boundary. Fix this with a test plan section titled “Segmentation control validation” and map each attempted path to a control.

3. No operational definition of “change to segmentation controls/methods.” Write the trigger list and embed it in change templates so engineers can’t miss it.

4. Treating cloud routing/security policy changes as “low risk.” Cloud changes are segmentation changes if they affect reachability into the CDE.

5. Closing findings without retesting. A closed ticket is not proof. Keep retest evidence tied to the original finding.

Risk implications (why operators care)

Segmentation is a scoping control. If it fails:

• Your CDE may be reachable from broader networks, increasing compromise paths.
• Your PCI scope may expand beyond what you assessed and secured.
• Your attestation story becomes fragile under audit because the control you used to reduce scope was not validated on the required cadence. ¹

Practical 30/60/90-day execution plan

Use this as an execution sequence. Adjust based on your current maturity and upcoming assessments.

First 30 days: get audit-safe on paper and build triggers

• Name a control owner and backup.
• Publish the segmentation boundary package (even if imperfect, make it current).
• Add segmentation-impacting tags and required security review steps to change management.
• Select the pen test resource (internal or third party) and confirm they can test segmentation paths.
• Create an evidence checklist folder structure for reports, change triggers, and remediation.

Days 31–60: run (or schedule) the next segmentation pen test and close gaps

• Finalize the segmentation pen test plan mapped to your boundary package.
• Execute testing or lock a confirmed testing window with a signed scope statement.
• Open remediation tickets for any bypass paths and track them through change control.
• Build a simple control dashboard: last test date, next test due, open findings, outstanding post-change tests.

Days 61–90: make it repeatable and resilient

• Run a tabletop with network, cloud, and GRC: simulate a segmentation-impacting change and validate the trigger-to-test workflow.
• Tune the change trigger list based on false positives/false negatives.
• Add third-party coordination steps where a third party can change routing/firewalling or remote access.
• Prepare an “audit response packet” that contains only what a QSA needs, with a one-page index.

Frequently Asked Questions

Does this apply if we don’t use segmentation and keep everything in scope?

Requirement 11.4.6 is specific to service providers that use segmentation to isolate the CDE from other networks. If you are not relying on segmentation for isolation, document that scoping position and confirm which other PCI DSS testing requirements apply. ¹

What counts as a “change to segmentation controls/methods”?

Any change that could affect reachability between non-CDE networks and the CDE should be treated as in-scope. In practice this includes firewall/ACL/security group changes, routing/peering changes, and architecture changes that introduce new paths. ¹

Can we satisfy this with an annual penetration test plus continuous monitoring?

The requirement sets a minimum penetration testing frequency of at least once every six months and also after changes. Continuous monitoring can support detection, but it does not replace the required testing cadence. ¹

Do we need a separate report just for segmentation testing?

You need evidence that segmentation controls were tested and the results are clear. That can be a standalone segmentation test report or a clearly labeled section in a broader penetration test report with explicit segmentation test cases and outcomes. ¹

If the change is “emergency,” can we test later?

Emergency changes still count as changes if they affect segmentation controls or methods. If you must implement first, document the emergency approval, then schedule and complete the post-change segmentation penetration testing as part of closing the change. ¹

How do we manage this when a third party controls parts of our network?

Put cooperation and notice requirements into contracts and operating procedures, then connect third-party change notifications to your segmentation-change triggers. Keep evidence of due diligence, exceptions, and follow-up actions to show governance over third-party dependencies. ¹

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ³

Footnotes

1. PCI DSS v4.0.1 Requirement 11.4.6

2. PCI DSS v4.0.1 Requirement 11.4.0.1 Requirement 11.4.6

3. Just Published: PCI DSS v4.0.1