PCI DSS network segmentation is one of the most commonly misunderstood requirements in the standard. Organizations spend significant engineering effort implementing segmentation controls, then struggle to produce the evidence auditors need during QSA assessments. Others implement segmentation that looks correct in documentation but has gaps in practice.
This guide focuses on what PCI DSS segmentation actually requires, how auditors evaluate it, and what evidence you need to demonstrate compliance effectively.
What PCI DSS Says About Segmentation
The core requirement appears in section 1 of PCI DSS v4.0 (Network Security Controls). While full cardholder data environment (CDE) isolation is technically an "optional but strongly recommended" approach for scope reduction, the standard is clear: if you claim segmentation, you must demonstrate it works.
Key requirements for organizations using segmentation for scope reduction:
Requirement 1.3.2: Outbound traffic from the CDE is restricted to that which is necessary for the operation of the cardholder data environment.
Requirement 1.3.3: NSC policies are implemented between all wireless networks and the CDE.
Requirement 11.4.4: The penetration testing program includes testing of segmentation controls to verify that out-of-scope systems cannot communicate with systems in the CDE.
Requirement 12.3.2: A targeted risk analysis is performed at least once every 12 months for each PCI DSS requirement where flexibility is provided.
What Auditors Actually Test
When a QSA evaluates your network segmentation, they're not just reviewing your architecture diagrams. They're looking for evidence that the segmentation actually works as documented.
Firewall Rule Review
The auditor will request firewall ruleset exports for all devices enforcing CDE boundaries. They're looking for:
- Rules are explicit, not implicit (no "any/any" rules that include CDE systems)
- All CDE outbound rules have a documented business justification
- Rules are reviewed at defined intervals (at least every six months per Requirement 1.2.7)
- Inbound rules to CDE are minimal and follow least privilege
A common finding: rules that were added for a temporary purpose years ago and never removed. The flow data view of what's actually traversing those rules is more authoritative than the rule documentation.
Segmentation Penetration Testing
Requirement 11.4.4 is where many organizations struggle. The requirement calls for active testing that systems outside the CDE scope cannot reach systems inside the CDE. This is more than a port scan — it's a validation that the segmentation controls hold against determined traversal attempts.
The segmentation test should cover:
- Attempts to reach CDE systems directly from out-of-scope networks
- Attempts to traverse through DMZ systems into the CDE
- Attempts to reach CDE systems via lateral movement from any system that could be reached from outside the CDE
Evidence of Ongoing Monitoring
QSAs increasingly ask for evidence of ongoing network monitoring, not just point-in-time assessment. Relevant evidence includes:
- Log retention demonstrating that all traffic at CDE boundaries is logged
- Evidence of periodic review of those logs
- Records of anomalies detected and how they were resolved
- Evidence that the monitoring configuration was in place throughout the assessment period
Demonstrating Segmentation with Flow Data
Flow data is one of the most compelling forms of evidence for PCI DSS segmentation because it's authoritative, continuous, and difficult to fabricate.
CDE Boundary Traffic Records
Flow records from devices enforcing CDE boundaries provide a complete audit log of every connection that crossed into or out of the CDE — including the source, destination, protocol, port, and timing. This is stronger evidence than firewall logs (which may be filtered to allowed traffic only) because it shows both allowed and denied traffic.
A query showing zero inbound connections from out-of-scope networks to CDE systems, over the assessment period, is compelling evidence that the segmentation is working.
Allowed Connection Inventory
Using flow data, you can produce an inventory of every connection type that was observed crossing the CDE boundary during the assessment period. This becomes:
- Evidence of the actual (not hypothetical) communication profile of the CDE
- Documentation for the "necessary traffic" justification required by Requirement 1.3.2
- A baseline for detecting scope creep (new connection types that appear later)
Anomaly Evidence
If anomalies were detected and investigated during the assessment period, that's evidence of active monitoring. QSAs look favorably on organizations that can produce:
- Log of anomaly events at the CDE boundary
- Evidence of investigation for each anomaly
- Resolution disposition (false positive, policy gap corrected, or confirmed incident)
Scope Reduction Through Segmentation
The primary business value of PCI DSS segmentation is scope reduction: systems not connected to the CDE are out of scope for PCI DSS controls, significantly reducing compliance burden and audit cost.
For scope reduction to hold, the segmentation must be complete and demonstrably effective. Partial segmentation — where some out-of-scope systems can reach CDE systems through indirect paths — doesn't achieve scope reduction and can increase audit findings if discovered.
Flow data helps ensure scope reduction claims are accurate:
Discovery: Running flow analysis on systems claimed to be out of scope, looking for any communication with CDE systems. If communication exists through any path, the scope reduction claim is at risk.
Continuous validation: After establishing scope, ongoing flow monitoring detects any new communication paths that would expand the CDE scope. These are caught during the year rather than at audit time.
FlowSight is particularly useful for PCI DSS environments because it produces the continuous flow record that constitutes evidence of ongoing monitoring, supports the segmentation testing requirement with historical communication data, and alerts on new communication paths that would affect CDE scope. Security teams can produce audit-ready reports of CDE boundary traffic on demand — without manual log aggregation at assessment time.
Preparing for the QSA Conversation
When your QSA asks about network segmentation, the strongest position is to have:
- Architecture documentation showing the CDE boundary and all enforcing controls
- Firewall rulesets reviewed and annotated with business justifications
- Flow data reports showing CDE boundary traffic over the assessment period
- Segmentation test results from the most recent penetration test
- Anomaly investigation records demonstrating active monitoring
- Evidence of periodic rule review (at least every six months)
Organizations that walk into the QSA conversation with flow-based evidence of continuous monitoring rather than point-in-time snapshots find the segmentation discussion dramatically more straightforward.
The standard isn't asking for the impossible. It's asking for proof that the controls you documented are actually working. Flow data provides that proof — continuously, automatically, and in a form that stands up to scrutiny.