What is the difference between in-scope and out-of-scope systems in PCI DSS?

What makes a system in scope for PCI DSS?

PCI DSS scope is determined by data flow and trust impact, not by ownership or convenience labels. A system is in scope if it stores, processes, transmits, or can affect the security of cardholder data or the cardholder data environment. That means direct CDE hosts, connected systems, shared services, and any component that can influence CDE security must be treated as in scope.

That definition matters because scoping is not a paperwork exercise. If a system can reach the CDE, assist with administration, or alter a control that protects cardholder data, it can expand the assessment boundary even if it never touches payment data itself. The scope question is therefore about exposure, privilege, and trust relationships, not just data storage.

PCI scoping also depends on how segmentation is designed and proven. NHI Management Group’s PCI DSS Scoping and Network Segmentation Guide is useful here because it covers the three PCI SSC categories, segmentation testing, and scope confirmation. In practice, the boundary is only as strong as the controls that prevent an adjacent system from reaching or influencing the CDE.

What does out-of-scope really mean?

Out-of-scope systems are not simply systems that “do not store card data.” They must have no access to CDE components, must not share the same network environment in a way that creates implicit trust, and must not be able to influence CDE security through any connection path. If even one of those conditions fails, the system is no longer out of scope.

That makes out-of-scope status conditional, not permanent. A server, endpoint, jump host, directory service, monitoring tool, or shared administrative platform can move into scope if it can affect segmentation, authentication, logging, patching, or privileged access to the CDE. The practical test is whether the system is truly isolated from security-relevant influence, not whether it happens to process payment data today.

This is why organisations often pair scoping decisions with formal testing and evidence capture. A good penetration test scoping checklist helps teams define targets, exclusions, authorisation, and data handling so that “out of scope” is defensible rather than assumed.

Why the boundary changes more often than teams expect

The main reason PCI DSS scope expands is hidden connectivity. Shared identity services, admin jump servers, backup tooling, endpoint management, cloud control planes, and third-party integrations can all create a path into the CDE even when the system owner believes the asset is isolated. Once a path exists, the system may be in scope because it can affect security, not because it holds cardholder data.

That is also why tokenisation, masking, and architectural separation are often discussed alongside scoping. NHI Management Group’s Data Masking and Tokenisation Buyer’s Guide is relevant when organisations want to reduce the amount of sensitive data exposed to surrounding systems. Reducing data exposure can help reduce scope, but only if the supporting systems and trust paths are also controlled.

Scope decisions also change when the environment changes. A previously out-of-scope workstation becomes in scope if it gains a management channel into the CDE, a shared authentication path, or access to logs or secrets that protect cardholder data. The same logic applies to cloud and hybrid architectures, where segmentation must be demonstrated across account, network, and control-plane boundaries.

Risk and Threat Considerations

The biggest risk is treating scope as static and underestimating trust paths that let an apparently “non-CDE” system influence cardholder data security. That creates audit failure risk, but more importantly it can leave a weakly managed system positioned as a stepping stone into the CDE.

Failure mechanism: A shared service, admin path, or connected network segment lets an attacker pivot from an out-of-scope system into the CDE, or lets a control failure on that system weaken the protection of cardholder data.

Impact: The environment can lose its out-of-scope status, control coverage becomes incomplete, and a compromise that began outside the CDE can become a payment-data incident or a PCI assessment finding.

Practitioner Guidance

What to verify: Verify not only data flow, but also administrative reachability, shared authentication, remote management paths, and any system that can alter segmentation or security tooling. If one of those paths exists, do not accept an out-of-scope label until the boundary is proven.

Decision rule: If a system can authenticate to, administer, monitor, or reconfigure a CDE-adjacent control, treat it as scope-relevant until segmentation evidence shows that the connection cannot influence cardholder data security.

What good looks like: The boundary is documented, tested, and repeatable, with clear proof of what is excluded, why it is excluded, and which controls prevent drift. NHI Management Group’s PCI DSS 4.0 Guide is a useful companion for understanding how scope, customised approaches, and assessment expectations fit together.

Practitioner takeaway: In PCI DSS, “out of scope” is earned by isolation and lack of influence, not by assertion; the safest boundary is the one you can prove cannot reach or weaken the CDE.

Related resources from NHI Mgmt Group

• How should teams separate Linux systems in scope from out-of-scope systems for PCI DSS?
• How should security teams validate PCI DSS 4.0 scope when cardholder data moves across systems over time?
• How should organisations scope PCI DSS compliance across connected systems and cloud services?
• What are the best practices for implementing PCI DSS across in-scope systems?