PCI DSS Scoping & Network Segmentation: The Evidence Checklist Auditors Expect

By Mindsec Content Team 5 July, 2026

Scope is the most expensive decision in PCI DSS — and the one most teams make by accident. Here’s how to shrink it, segment it, and prove it the way auditors actually want.

Ask any QSA where PCI assessments go sideways, and they’ll tell you the same thing: scope. Not the fancy controls — scope. A team swears their card environment is “just those two servers,” the assessor pulls a network diagram, and suddenly a jump box, a logging server, and a forgotten admin laptop are all in scope too.

Here’s the thing nobody tells you early enough. Every system you pull into scope is a system you now have to secure, monitor, and produce evidence for. Scope isn’t paperwork. Scope is your entire workload.

This guide is the practical version: how PCI DSS scoping actually works, how network segmentation shrinks it, and — the part that trips people up — the exact evidence an auditor expects you to hand over to prove all of it. If you want the full standard first, start with The Complete PCI DSS 4.0 Compliance Guide for Canadian Fintech, then come back here for the scoping deep dive.

What “Scope” Actually Means in PCI DSS

PCI DSS scope is the set of all system components that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD) — plus everything connected to or that could affect the security of those systems. Together, the in-scope systems make up your Cardholder Data Environment (CDE).

The golden rule from the Council: if you can’t prove a system is out of scope, it’s in scope. The burden of proof is always on you.

PCI 4.0 sorts every system in your organization into one of three buckets. Getting each system into the right bucket is the scoping exercise.

🔴 CDE systems

Anything that stores, processes, or transmits card data. Also any system component that sits in the same network segment as those. Full PCI controls apply.

🟡 Connected-to / security-impacting

Systems that connect to the CDE or could affect its security — jump servers, directory services, logging, patching, admin workstations, security tools. In scope, though a subset of controls may apply.

🟢 Out of scope

Systems with no connectivity to and no ability to impact the CDE. Out of scope — but only if you can demonstrate that isolation. No proof, no exemption.

The trap in that middle bucket. Almost everyone under-counts “connected-to and security-impacting” systems. Your identity provider, your SIEM, your CI/CD pipeline, the laptop your engineer uses to SSH into a card-processing box — all in scope. This category is where surprise findings live. Inventory it honestly.

Why Segmentation Is the Highest-Leverage Control You Own

Network segmentation isn’t technically required by PCI DSS. But skip it and you pay for it — literally. Here’s the choice in stark terms:

🚫 Flat network (no segmentation)

Card data lives on the same network as everything else
Your entire environment is in scope
Every server, laptop, and VLAN needs PCI controls
Evidence collection becomes enormous
One weak workstation can compromise card data

✅ Segmented network

The CDE is isolated behind its own controls
Only the CDE + connected systems are in scope
The other 90% of your estate drops out of scope
Far less to secure, monitor, and prove
A breach elsewhere can’t reach card data

That’s the whole game. Segmentation is the difference between an audit that covers 200 systems and one that covers 15. It’s the cheapest, most effective scope-reduction move available — which is exactly why it’s the first thing to get right.

How to Segment (Without Fooling Yourself)

Segmentation only counts if it genuinely prevents systems outside the CDE from reaching in. “There’s a VLAN tag on it” is not segmentation. Real isolation looks like this:

Isolate the CDE

Put card-handling systems in their own network zone with a firewall or equivalent network security control between them and everything else.

Default-deny

Block all traffic in and out of the CDE by default. Then permit only the specific, documented flows the business genuinely needs.

Control the connections

Force administrative access through hardened jump hosts with MFA. Minimize what connects in, and document every path that does.

Test the boundary

Prove the segmentation actually holds with penetration testing that specifically tries to cross from out-of-scope into the CDE.

PCI 4.0 requirement 11.4.5: if you rely on segmentation to reduce scope, you must run penetration testing on the segmentation controls at least every 12 months — and if you’re a service provider, at least every 6 months, and after any change to segmentation controls. Segmentation you never test is segmentation an auditor won’t credit.

The Evidence Auditors Actually Expect

This is the part people search for and rarely find laid out plainly. When a QSA or your acquirer reviews scoping and segmentation, here is the specific evidence they want to see. Treat this as your pre-audit checklist.

1. Scope & inventory evidence

Documented scope definition — a written statement of what’s in scope and what’s out, reviewed and confirmed at least every 12 months (Req 12.5.2; every 6 months for service providers).
Full system-component inventory — every in-scope system with its role and function (Req 12.5.1). No “we think that’s all of them.”
Account-data discovery results — proof you searched for card data across your environment and confirmed it only lives where you think it does.
Scope-change records — evidence that scope is re-evaluated whenever the environment changes, not just annually.

2. Network & data-flow diagrams

Current network diagram — shows all connections between the CDE and other networks, including wireless (Req 1.2.3). “Current” means it matches reality today, not last year.
Cardholder data-flow diagram — maps every flow of card data across systems and networks, so the assessor can see exactly where it goes (Req 1.2.4).
Diagram-to-reality match — be ready for the assessor to trace a flow on the diagram and verify it against actual firewall rules and configs.

3. Segmentation evidence

Firewall / network security control rulesets — the actual configs enforcing isolation, showing default-deny and only justified allow rules (Req 1.2, 1.3, 1.4).
Ruleset review records — evidence rules are reviewed at least every 6 months (Req 1.2.7).
Segmentation penetration test report — proof the boundary was tested and holds, within the required cadence (Req 11.4.5).
Remediation evidence — if the pen test found a way across, proof you fixed it and retested.

4. Access & monitoring evidence

Access lists for in-scope systems — who can reach the CDE, showing least-privilege and business need-to-know (Req 7).
MFA enforcement records — proof MFA guards every path into the CDE (Req 8.4.2 / 8.5).
Log coverage proof — evidence that all in-scope systems feed logging and monitoring (Req 10), with automated review in place.

The Annual Scope Confirmation (Don’t Skip This)

PCI 4.0 made scope confirmation an explicit, recurring obligation — not a thing you do once and forget. At least every twelve months (every six for service providers) you have to formally re-validate that your documented scope still matches reality.

What the annual confirmation must cover +

Identify all data flows for card data across the environment
Update the account-data inventory and locations
Confirm all in-scope system components are accounted for
Verify that segmentation controls still isolate the CDE as documented
Capture the whole thing as dated, signed evidence — not a hallway conversation

Why teams get burned here +

Environments drift. A new microservice starts calling a card-processing API, an engineer opens a firewall port “temporarily,” a logging change quietly bridges two zones. Any of these can silently expand scope. If your confirmation is an annual scramble instead of continuous monitoring, you find out about the drift from the auditor — the worst possible time.

⚡ The Scoping Cheat Sheet

🔎 If in doubt, it’s in scope
The burden of proof is on you.

✂️ Segment to shrink
Isolation drops systems out of scope.

🗺️ Diagrams must match reality
Network + data-flow, kept current.

🔁 Confirm scope on a cycle
12 months, or 6 for service providers.

Stop Guessing at Your Scope

The teams that breeze through PCI assessments aren’t the ones with the most controls — they’re the ones who scoped tightly, segmented properly, and had the evidence ready before anyone asked. A compliance automation platform keeps your system inventory, data flows, and segmentation evidence continuously up to date, so scope confirmation is a report you export — not a fire drill you survive.

Small scope. Solid proof. Boring audits.

See How Mindsec Handles PCI DSS

Frequently Asked Questions

What is PCI DSS scope and how is it defined?

PCI DSS scope is every system component that stores, processes, or transmits cardholder data, plus any system connected to or capable of affecting the security of those systems. Together they form your Cardholder Data Environment (CDE). PCI DSS 4.0 sorts systems into three groups: CDE systems, connected-to/security-impacting systems, and out-of-scope systems. The guiding principle is that any system you cannot prove is isolated from the CDE is considered in scope by default.

Is network segmentation required for PCI DSS compliance?

Segmentation is not strictly mandatory, but without it your entire network falls into PCI scope because card data shares the network with everything else. Segmentation isolates the CDE so the rest of your systems drop out of scope, which dramatically reduces the controls you must implement and the evidence you must produce. If you rely on segmentation to reduce scope, PCI DSS 4.0 (requirement 11.4.5) requires you to penetration-test the segmentation controls at least every 12 months, or every 6 months for service providers.

What evidence do auditors expect for PCI DSS scoping and segmentation?

Assessors expect a documented and annually confirmed scope definition, a full inventory of in-scope system components, a current network diagram showing all CDE connections, a cardholder data-flow diagram, firewall and network-security-control rulesets with review records, and a segmentation penetration-test report proving the boundary holds. They also expect access lists, MFA enforcement records, and logging coverage for in-scope systems. In short: proof that your documented scope matches your actual environment.

How often must PCI DSS scope be confirmed?

Under PCI DSS 4.0, scope must be documented and confirmed at least once every 12 months and whenever the environment changes significantly. Service providers must confirm scope at least every 6 months. The confirmation must identify all cardholder data flows, update the data inventory, verify all in-scope components are accounted for, and check that segmentation still isolates the CDE — all captured as dated evidence.

How can I reduce my PCI DSS scope?

The most effective levers are network segmentation (isolating the CDE so unrelated systems fall out of scope), not storing cardholder data at all where possible, and using tokenization or point-to-point encryption so card data never sits in your environment in the clear. Each of these shrinks the number of in-scope systems, which reduces both the controls you implement and the evidence you maintain. For the full picture of how scope fits into the twelve requirements, see The Complete PCI DSS 4.0 Compliance Guide for Canadian Fintech.

Mindsec Content Team

Mindsec staff

CISO Compliance PCI DSS