PCI SSC scoping guidance sorts system components into three examples of categories: CDE systems that store, process or transmit account data, connected-to or security-impacting systems, and out-of-scope systems. A system is out of scope only if it meets every out-of-scope condition and none of the higher ones. The categories are an example, not a requirement.
What scoping means
The Council describes scoping as identifying the people, processes and technologies that interact with or could affect the security of cardholder data. Segmentation is the separate step of adding controls to separate systems with different security needs. Scope is your starting point for every other PCI DSS decision, since the number of in-scope systems drives cost.
The three categories
The Council's information supplement lays out one way to sort components, and says entities may use another method:
- CDE systems. They store, process or transmit CHD or SAD. This category also includes components that support PCI DSS requirements, such as time servers and audit log storage, and components that provide segmentation of the CDE from out-of-scope networks, such as firewalls.
- Connected-to or security-impacting systems. They can reach the CDE or affect its security even though they do not handle card data themselves.
- Out-of-scope systems. They do not store, process or transmit CHD or SAD, are not on the same network segment, subnet or VLAN as systems that do, and cannot connect to or access any CDE system.
The categories are hierarchical. Check CDE first, then connected-to, and only then ask if a system is out of scope. Being in scope does not mean every requirement applies to a component. The relevant requirements depend on its function and location.
Where hidden scope hides
For software teams, these are frequent surprises:
- A CI system or deployment server with credentials into the CDE.
- A logging or monitoring platform that receives payloads containing PAN.
- A shared identity provider or admin jump host.
- A database replica or backup in a different account.
- A developer laptop that can reach production by VPN.
- A third party script on a payment page that can affect the CDE.
Each of these is either a connected-to or a security-impacting system, so each pulls scope outward.
The annual check
Requirement 12.5.2 expects scope to be documented and confirmed at least once every 12 months and on significant change. The confirmation includes identifying data flows for each payment stage and channel, updating data-flow diagrams, finding every location where account data is stored, processed or transmitted, listing components in or connected to the CDE, naming segmentation controls with justification for out-of-scope environments, and listing third party connections with CDE access. The applicability notes say this is the entity's own activity and differs from the assessor's scoping confirmation.
A tidy approach is to keep a living inventory and diff it against reality quarterly. Asset discovery and dependency inventories help with the software side. See segmentation myths for what segmentation does and does not buy you.
Quick check
Is a system out of scope just because it has no card data?
No. It must also not share a segment with CDE systems and must not be able to connect to or access any CDE system.
How often do I confirm PCI DSS scope?
At least once every 12 months and upon significant change to the in-scope environment, under Requirement 12.5.2.
Sources
- PCI SSC Guidance for PCI DSS Scoping and Network Segmentation
- PCI DSS v4.0 SAQ D for Merchants, requirement 12.5.2
Last reviewed: 19 October 2026.
