Scope decides how much PCI DSS work you do. The cardholder data environment (CDE) is only the starting point: systems connected to it also count. Map where account data is stored, processed or transmitted, find every connected system, then shrink the footprint with segmentation or by outsourcing card handling, before you write any control.
What is in scope for PCI DSS?
The PCI Security Standards Council's scoping guidance says the requirements apply to all system components included in or connected to the cardholder data environment. The CDE consists of people, processes and technologies that store, process or transmit cardholder data or sensitive authentication data.
The guidance, an information supplement from May 2017 written for an earlier version of the standard, gives scoping concepts that still read clearly:
- Systems inside the CDE are in scope regardless of function.
- Systems that connect to a system in the CDE are in scope regardless of why they connect.
- In a flat network, every system is in scope if any single system stores, processes or transmits account data.
The public internet is not itself in scope, but you must protect in scope systems from it. The version and date matter: PCI DSS v4.0 is fully in effect, v4.0.1 was released in June 2024 as a limited revision, and 51 of the 64 new requirements in v4.0 were future dated to 31 March 2025, according to a Council blog interview. Check the current standard on the Council's site.
How do you find the CDE?
Start from data, not from the network diagram.
- List every way a customer's card number enters your business: web checkout, mobile app, phone orders, point of sale, invoices, support emails.
- For each, trace where the data goes next: application servers, queues, logs, databases, backups, analytics, customer support tools, third party processors.
- Draw it. Boxes for systems, arrows for flows, a line around everything that touches account data.
Search logs, tickets and spreadsheets for card number patterns. Teams routinely find numbers in places nobody expected, and each one is a scope expansion.
What are connected-to systems?
Anything with a communication path to the CDE. The guidance says connectivity can be physical, wireless or virtualised, and notes that virtual devices often share hosts or hypervisors that can bridge logical partitions. Typical examples: shared authentication servers, patch servers, logging and monitoring platforms, jump hosts, admin workstations and DNS.
The guidance warns that compromises of connected-to components often lead to compromise of the CDE. Excluding them to save effort is the classic scoping mistake.
How do you reduce scope?
Three levers, in order of impact.
Do not touch the data. The guidance notes that scope can be reduced by outsourcing card handling to a third party service provider or using a PCI-listed point to point encryption solution. If your payment page is served entirely by a payment provider, much of your estate may fall out of the CDE. Confirm the provider's responsibilities in writing and check which requirements still apply to you.
Segment the network. The goal, per the guidance, is that an out of scope system cannot communicate with or affect the security of the CDE, even if an attacker gained administrative access to it. The guidance also says segmentation is not a silver bullet and does not replace implementing the requirements.
Delete data you do not need. Stored data that nobody uses is scope you pay for.
How do you prove your boundary holds?
Segmentation is a claim until tested. Run connectivity tests from out of scope networks toward the CDE, and keep the results. Re-test after any network change. Record the boundary decisions in a scope document: what is in, what is out, why, and who approved it.
Remember that an assessor or acquirer, not you, will decide whether your scope is accepted.
Where does scoping go wrong?
- Starting with controls before the diagram exists.
- Forgetting admin workstations and jump hosts.
- Treating a payment provider contract as a scope eraser without reading the responsibility matrix.
- A flat network that makes everything in scope.
- Logs that capture card numbers, pulling every logging system into scope.
- No process to update scope when new services ship.
What to do
- Inventory every channel that receives card data and trace each flow.
- Search logs, tickets and shared drives for stored account data, then remove it.
- List connected-to systems, including admin tools and shared services.
- Choose scope reduction: outsource, segment, delete, or a mix.
- Test segmentation from outside the boundary and keep the evidence.
- Write the scope document and get leadership sign off.
- Add scope review to your change process so new systems are classified at launch.
Quick check
Is a system out of scope just because it does not store card data?
No. The Council's guidance says systems that connect to a system in the CDE are in scope regardless of why they connect, and that a flat network brings everything into scope.
Who decides if our scope is acceptable?
Your assessor and the party you report to, such as your acquirer or card brand, decide. Raise your scoping decisions with them early.
Sources
- PCI Security Standards Council, Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation (May 2017)
- PCI Security Standards Council, PCI DSS v4.x resource hub
- PCI SSC blog, Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x
How Safeguard helps automate this
After scope is set, the work is proving it stays that way. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence for in scope systems is collected from connected systems and code, not by screenshot, and monitoring runs between assessments. For the secure software side, technical evidence comes from your real code and dependencies: scans, SBOMs and reachability. The remediation agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you decide which categories run automatically and with what approval level. A qualified assessor still validates your compliance; Safeguard helps you prepare and keep evidence ready. Book a call to see how.
Last reviewed: 18 October 2026.
