Segmentation Control Testing

PCI DSS requires you to penetration test your segmentation controls to prove they actually isolate the Cardholder Data Environment (CDE) from out-of-scope networks. Do this on a defined cadence and whenever segmentation changes, and make sure testing covers every segmentation method in use and produces evidence that the CDE cannot be reached from non-CDE systems (PCI DSS v4.0.1 Requirement 11.4.5).

Key takeaways:

• If you use segmentation for PCI scoping, you must validate it with penetration testing, not diagrams or intent statements (PCI DSS v4.0.1 Requirement 11.4.5).
• Testing must cover all segmentation controls/methods, and you must re-test after changes to segmentation (PCI DSS v4.0.1 Requirement 11.4.1).
• Your fastest path to passing an assessor review is clean proof: defined methodology, test scope, results, remediation, and re-test evidence (PCI DSS v4.0.1 Requirement 11.4.5).

“Segmentation” is a scoping decision as much as it is an engineering design. If you claim systems are out of scope because network controls isolate the CDE, you are also claiming those controls are effective in practice. PCI DSS 4.0.1 makes that claim testable: you must run penetration tests that target segmentation controls and show they truly block access between out-of-scope networks and the CDE, including any isolation used to separate systems with different security levels (PCI DSS v4.0.1 Requirement 11.4.5).

For a CCO, GRC lead, or security compliance owner, the operational problem is predictable. Network teams maintain firewalls, VLANs, security groups, microsegmentation policies, and routing rules. Cloud teams change security groups weekly. App teams request new connectivity paths. Over time, “segmentation” becomes a patchwork of controls and exceptions. Auditors then ask the simplest question: “Prove an out-of-scope system can’t reach the CDE.” If you cannot produce a repeatable testing package, your PCI scope expands, your compliance posture weakens, and remediation work balloons.

This page translates the requirement into an execution plan: who owns what, what to test, what evidence to retain, and how to avoid the failure modes assessors see most.

Regulatory text

Requirement (operator view). If you use segmentation to isolate the CDE from other networks, you must perform penetration tests of the segmentation controls:

• on a defined cadence and after changes to segmentation controls/methods,
• across all segmentation controls/methods in use,
• following your defined penetration testing methodology,
• to confirm segmentation is operational and effective and isolates the CDE from all out-of-scope systems, and
• to confirm the effectiveness of any isolation used to separate systems with differing security levels (PCI DSS v4.0.1 Requirement 11.4.5).

What that means in practice. Your assessor is not looking for “we have firewalls” or a Visio diagram. They want a test plan and results that demonstrate attempted access paths from out-of-scope networks into the CDE were blocked, plus evidence you re-tested when segmentation changed (PCI DSS v4.0.1 Requirement 11.4.5).

Plain-English interpretation

If segmentation is part of how you keep PCI scope small, you need to prove it works. That proof is a penetration test designed to break or bypass segmentation boundaries. Passing results show no reachable pathways from out-of-scope systems to the CDE beyond explicitly authorized and documented flows. Failing results trigger remediation and re-test until isolation is demonstrably effective.

This is control validation, not vulnerability scanning. A clean vulnerability scan report does not prove isolation; it proves patching and exposure management.

Who it applies to

Applies to:

• Merchants and service providers that store, process, or transmit account data, when they rely on segmentation to separate the CDE from other networks (PCI DSS v4.0.1 Requirement 11.4.5; PCI DSS v4.0.1).
• Environments where “segmentation” is implemented through any combination of:
  • on-prem firewalls, ACLs, routing rules
  • VLANs/VRFs with enforcement points
  • cloud security groups/NACLs
  • software-defined networking and microsegmentation
  • jump hosts / bastions and management plane separation

Operationally, this hits the intersection of Security Engineering, Network/Cloud Infrastructure, and GRC. GRC sets the requirement, engineering provides the segmentation inventory, and a qualified internal or third-party testing function executes the penetration test under an approved methodology (PCI DSS v4.0.1 Requirement 11.4.5).

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

1) Decide whether you are “using segmentation”

If your PCI scope statement says non-CDE networks are out of scope because they are segmented away, you are using segmentation for PCI purposes. Treat this as a compliance dependency and track it like one.

Output: a scoping note that explicitly states which networks are out of scope because of segmentation, and what the segmentation mechanisms are.

2) Build a segmentation controls inventory (the “what to test” list)

Create a single list of every control or method enforcing CDE isolation, including:

• control type (firewall, cloud SG, microsegmentation policy, routing)
• location (data center, cloud account/VPC/VNet, Kubernetes cluster)
• rule/policy sources of truth (e.g., firewall policy set, IaC repo, SDN controller)
• boundary definition (what is “out-of-scope,” what is “CDE,” what is “shared services”)
• permitted flows with business justification (e.g., app-to-db, logging, patching)

You are aiming for completeness: the requirement expects coverage of all segmentation controls/methods in use (PCI DSS v4.0.1 Requirement 11.4.5).

Practical tip: include “invisible” segmentation such as transit gateways, peering routes, shared DNS, and management network paths. Those are common pivot points during a segmentation test.

3) Define (or adopt) a penetration testing methodology that includes segmentation testing

The requirement ties segmentation testing to “the entity’s defined penetration testing methodology” (PCI DSS v4.0.1 Requirement 11.4.5). Your methodology should specify:

• tester independence and authorization
• rules of engagement and safety constraints
• test approach for segmentation validation (sources, targets, tooling classes, evidence)
• how to document attempted paths and outcomes
• retest expectations after remediation

Daydream fit (where it earns its place): Use Daydream to standardize the required artifacts across teams: segmentation inventory, change triggers, testing tickets, and evidence packaging. The common failure is not the test itself; it’s missing operating evidence at assessment time.

4) Set test scope: “from out-of-scope to CDE” and “between security levels”

Your segmentation pen test scope should include:

• representative footholds in out-of-scope networks (user VLANs, corporate subnets, dev/test, partner connections)
• attempted network access into CDE address space and services
• attempts to reach CDE administration planes (management interfaces, orchestration tools)
• isolation tests between different security levels where you claim separation (PCI DSS v4.0.1 Requirement 11.4.5)

Example: If your CDE is in a cloud VPC and “shared services” hosts logging and monitoring, prove shared services cannot initiate connections into CDE except the explicitly allowed ports and endpoints.

5) Execute the segmentation penetration test and record evidence like an assessor will read it

Your testers should produce results that clearly show:

• the starting point(s) in out-of-scope networks
• the attempted routes, ports, and protocols to CDE assets
• the enforcement point that blocked access (or the misconfiguration that allowed it)
• whether any path allowed lateral movement into CDE

Avoid “black box” outputs that require interpretation. If the report says “segmentation appears effective” but does not show the attempted paths and failures, expect audit friction.

6) Remediate and re-test until isolation is proven

If any out-of-scope system can reach the CDE in an unapproved way, treat it as:

• a segmentation control failure,
• a scoping risk, and
• a potential security incident precursor.

Track remediation through tickets, approvals, and post-fix validation. Retest the specific failed path and keep evidence that the issue is closed.

7) Trigger re-testing after segmentation changes

The requirement explicitly includes testing “after any changes to segmentation controls/methods” (PCI DSS v4.0.1 Requirement 11.4.5). Operationalize this with change management:

• define what counts as a segmentation change (firewall policy updates, routing changes, SG/NACL changes, SDN policy changes, new peering)
• map those changes to a required validation action (targeted retest or full segmentation test depending on impact)
• enforce a gate: changes are not “done” until validation evidence is attached

Required evidence and artifacts to retain

Keep an assessor-ready package with:

• Segmentation architecture and scope statement: CDE boundary, out-of-scope networks, trust zones.
• Segmentation controls inventory: complete list of controls/methods in use (PCI DSS v4.0.1 Requirement 11.4.5).
• Penetration testing methodology: document version in effect during testing (PCI DSS v4.0.1 Requirement 11.4.5).
• Rules of engagement and authorization: who approved, what was tested.
• Pen test report focused on segmentation: test cases, source networks, targets, results, evidence excerpts.
• Remediation records: tickets, change approvals, implemented configuration changes.
• Re-test results: proof that fixes closed the path.
• Change-trigger mapping: evidence you identify segmentation changes and invoke testing (PCI DSS v4.0.1 Requirement 11.4.5).

If you want this to run smoothly, store artifacts in a single system of record with consistent naming (e.g., “Segmentation PT – FY – Environment – Report + Retest”). Daydream can act as the evidence hub that ties together test reports, change tickets, and control narratives for assessment.

Common exam/audit questions and hangups

Expect assessors to ask:

1. “Show me all segmentation methods you rely on for scope reduction.” If you omit cloud controls or SDN, you will get a gap (PCI DSS v4.0.1 Requirement 11.4.5).
2. “How do you know your segmentation still works after changes?” You need a trigger and evidence of re-testing (PCI DSS v4.0.1 Requirement 11.4.5).
3. “What were the test starting points?” If you only test from a single subnet, they may question coverage.
4. “Do you validate isolation between different security levels?” Especially relevant when “shared services” sit adjacent to CDE (PCI DSS v4.0.1 Requirement 11.4.5).
5. “Is this a vulnerability scan or a penetration test?” Be ready to explain methodology differences and show adversarial path testing (PCI DSS v4.0.1 Requirement 11.4.5).

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Avoid it by
Treating segmentation as “documented design,” not a testable control	PCI DSS asks you to confirm operational effectiveness via penetration testing (PCI DSS v4.0.1 Requirement 11.4.5).	Run segmentation-focused test cases that attempt to traverse boundaries and record outcomes.
Testing only one firewall while cloud and SDN controls also enforce segmentation	Requirement expects coverage of all segmentation controls/methods in use (PCI DSS v4.0.1 Requirement 11.4.5).	Maintain a living inventory and map each control to test cases.
No formal trigger after rule changes	You cannot prove ongoing effectiveness after changes (PCI DSS v4.0.1 Requirement 11.4.5).	Add a change type that automatically requires validation evidence before closure.
Reports that say “pass” without showing attempted paths	Auditors cannot evaluate test sufficiency.	Require screenshots/log excerpts, tested routes, port lists, and blocked evidence.
Ignoring “different security levels” isolation	The requirement calls it out explicitly (PCI DSS v4.0.1 Requirement 11.4.5).	Define security levels and include test cases between them, not only “internet to CDE.”

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is scoping and exposure: if segmentation fails, systems you treated as out of scope may be in scope, and pathways into the CDE may exist. That increases remediation workload and can force architectural changes under assessment pressure (PCI DSS v4.0.1 Requirement 11.4.5).

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Assign a single owner for “CDE segmentation effectiveness” across network and cloud.
• Build the segmentation controls inventory and boundary diagram set.
• Confirm your penetration testing methodology explicitly includes segmentation control testing (PCI DSS v4.0.1 Requirement 11.4.5).
• Define what counts as a segmentation change and add it to change management triggers.

Days 31–60 (test and close gaps)

• Run the segmentation penetration test covering all methods in the inventory (PCI DSS v4.0.1 Requirement 11.4.5).
• Triage findings with clear “scope impact” flags.
• Remediate failures via controlled changes with approvals and evidence attachments.

Days 61–90 (operationalize and make it repeatable)

• Perform retests for remediated paths and package evidence for the assessor.
• Establish an ongoing calendar for the next segmentation test and a lightweight “change-driven retest” workflow (PCI DSS v4.0.1 Requirement 11.4.5).
• Centralize artifacts and status reporting in Daydream so GRC can produce evidence without chasing engineers across tools.

Frequently Asked Questions

Do we need segmentation control testing if we include everything in PCI scope?

This requirement is triggered when you use segmentation to isolate the CDE from other networks for scoping purposes (PCI DSS v4.0.1 Requirement 11.4.5). If you do not rely on segmentation for scope reduction, confirm that decision with your assessor and document your scope rationale.

Does a quarterly vulnerability scan count as segmentation control testing?

Vulnerability scanning does not usually prove isolation between networks. PCI DSS calls for penetration tests on segmentation controls that confirm the CDE is isolated from out-of-scope systems (PCI DSS v4.0.1 Requirement 11.4.5).

What counts as a “change to segmentation controls/methods” that triggers re-testing?

Any change that can alter allowed paths into or out of the CDE should trigger validation, including firewall rule changes, routing updates, cloud security group/NACL changes, SDN/microsegmentation policy updates, and new network interconnects (PCI DSS v4.0.1 Requirement 11.4.5). Define this in your change taxonomy so it is enforceable.

Can an internal team perform the segmentation penetration test?

The requirement specifies penetration testing according to your defined methodology (PCI DSS v4.0.1 Requirement 11.4.5). Your methodology should address independence, competence, and authorization; many organizations use a third party for stronger independence, but the key is that the test is credible and evidence-rich.

How do we test segmentation in cloud environments where security groups change frequently?

Treat cloud segmentation controls as first-class segmentation methods in your inventory and build test cases around them (PCI DSS v4.0.1 Requirement 11.4.5). Operationally, pair scheduled testing with change-driven targeted retests when security group or routing changes affect CDE boundaries.

What evidence is most likely to satisfy a QSA quickly?

A complete segmentation control inventory mapped to test cases, a documented methodology, a report that shows attempted out-of-scope to CDE paths and results, and remediation plus retest artifacts for any failures (PCI DSS v4.0.1 Requirement 11.4.5). Put it in a single evidence package so the assessor can trace claim → test → proof.