21 Oct 2026 By CISO Consulting team 18 views 4 min read

PCI DSS Network Segmentation Validation Methods for QSAs

Requirement 1.4.2 expects proof that segmentation actually blocks access to the cardholder-data environment, not just a firewall export. This article sets out four test methods, the evidence format for each and how to choose between them.

A network engineer reviewing a segmented network diagram on a monitor in a quiet server operations room.
In this article
  1. What the requirement asks for
  2. The usual gaps
  3. Method 1: Penetration testing from out-of-scope segments
  4. Method 2: Automated scanning across boundaries
  5. Method 3: Firewall rule review with traffic simulation
  6. Method 4: Continuous network-traffic analysis
  7. Choosing a method
  8. A sensible order of work
  9. How we help
  10. Next step

Many assessments stall at the same point. The entity hands over a firewall rule export and says the cardholder-data environment (CDE) is segmented. The assessor then asks how anyone knows those rules stop lateral movement. This article describes the PCI DSS network segmentation validation methods that assessors commonly accept, and the evidence format, success criteria and sampling approach for each, so you can choose the one that fits your architecture and budget.

Note on scope: the PCI Security Standards Council publishes PCI DSS, and your QSA interprets how evidence is judged. Confirm the exact acceptance criteria with your assessor before you commit to a method.

What the requirement asks for

Under PCI DSS v4.0, segmentation is optional, but if you use it to reduce scope, you must show it works. The expectation is that controls separating the CDE from out-of-scope networks are validated at least annually and after significant change, and that they prevent unauthorized access into the CDE. A configuration export proves intent. Validation needs evidence of behavior: traffic that should be blocked was attempted and did not pass.

The usual gaps

  • Rule exports submitted as the only evidence.
  • Testing performed from one convenient segment rather than from every out-of-scope segment that touches the boundary.
  • Tests that cover TCP only and ignore UDP, ICMP and management protocols.
  • No record of the tester, the date, the source and destination addresses, or the tool version.
  • Validation that predates a network change, so the evidence no longer describes the live environment.
  • Failed tests closed without a retest.

Method 1: Penetration testing from out-of-scope segments

Testers sit on out-of-scope networks and attempt to reach the CDE, including through any systems that connect the two. This is the strongest evidence for complex or flat-adjacent environments.

Evidence format: a report stating scope, source segments, target CDE ranges, methodology, tools, dates, tester identity and findings, plus raw logs or screenshots of blocked attempts.

Success criteria: no path from any tested out-of-scope segment to the CDE except those documented and in scope; any finding is remediated and retested.

Sampling: test from every distinct out-of-scope segment type, such as user, guest, development, management and third-party links. Do not sample within a segment type where the controls differ.

Method 2: Automated scanning across boundaries

Scanners run from each out-of-scope segment against all CDE address space, covering all 65,535 TCP ports and the relevant UDP ports. This is cost-effective and repeatable, and suits stable architectures.

Evidence format: scan configuration (source, targets, port ranges, protocols), scanner version, timestamped raw output and a summary of any open or reachable ports.

Success criteria: zero reachable CDE hosts or ports from out-of-scope sources, other than documented, justified flows.

Sampling: cover the full CDE range, not a subset of hosts. Where segments are many, scan from at least one source per boundary firewall interface.

Method 3: Firewall rule review with traffic simulation

A rule review is paired with simulated or crafted traffic, so each deny rule is shown to work. The review alone is not enough, and the simulation turns it into validation.

Evidence format: the rule set export with review notes, a test matrix of source, destination, port and expected result against actual result, and packet captures or logs from the firewall.

Success criteria: every test case matches its expected outcome, rules are traceable to a business justification, and there is an explicit default deny.

Sampling: test every rule that permits traffic across the boundary, plus a representative set of deny rules for each firewall pair and each rule group.

Method 4: Continuous network-traffic analysis

Flow data or network monitoring is analyzed over time to show that no unauthorized traffic crosses the boundary. It suits large or fast-changing environments, but it only proves what traffic occurred, not what would be blocked, so assessors often want it combined with another method.

Evidence format: flow or sensor configuration showing coverage of every boundary, a defined observation period, alert rules, and reports of boundary-crossing flows with disposition.

Success criteria: every observed flow into the CDE maps to an approved, documented rule, and anomalies are investigated and recorded.

Sampling: coverage must be complete across boundary points. Sampling of time periods should include peak, batch and maintenance windows.

Choosing a method

  1. Start with architecture. Flat or loosely controlled networks lean toward penetration testing.
  2. Consider change rate. Frequent change favors scanning or continuous analysis.
  3. Consider budget. Scanning plus a rule review with simulation is often the lowest-cost combination that gives behavioral evidence.
  4. Agree the method, scope and evidence format with your QSA in writing before testing starts.

A sensible order of work

  1. Document the CDE, its data flows and every boundary.
  2. Review the current segmentation design for gaps.
  3. Select and agree the test method or combination.
  4. Run the tests, remediate failures and retest.
  5. Package the evidence with dates, scope and sign-off, and repeat after significant change and at least annually.

How we help

Our PCI DSS Readiness & Compliance service prepares you for PCI DSS v4.0: scoping and segmentation, gap assessment, remediation support and readiness for your QSA assessment or self-assessment questionnaire. We work in four stages: scope card-data flows and segmentation, assess requirements gaps, support closing those gaps, and review evidence before assessment. Features include card-data flow mapping and scoping, and a segmentation review. Deliverables include a scoping document with data-flow diagrams, a gap assessment report, a remediation plan and an evidence pack for the assessment. The project typically runs 6–12 weeks.

Where adversarial testing is the right method, our Penetration Testing service identifies exploitable weaknesses before attackers do, with fixes your team can act on.

Next step

If you are unsure whether your current evidence would satisfy a QSA, begin with a segmentation review. It shows which of these methods fits your environment and what to produce before your assessment.

Tags: PCI DSS Network segmentation QSA assessment Penetration testing Saudi Arabia Payment security
Readiness self-check

How ready are you? Find out in two minutes

Answer a few questions for your framework. You get a score, your biggest gaps and — if you want it — a detailed assessment from our team.

Ready to talk about your compliance?

Tell us where you stand. We will show you the shortest path to what your regulator expects.

Regulatory updates in your inbox

SAMA, NCA and SDAIA changes and what they mean for your institution — once a month.

E-mails in

We confirm by e-mail; unsubscribe any time. Manage your subscription · Past issues

Schedule a Free Assessment