In-scope systems store, process, transmit, connect to, or can affect the security of cardholder data, so PCI DSS controls apply to them. Out-of-scope systems have no access to CDE components, do not share the same network environment, and cannot influence CDE security through any connection. If a system fails even one criterion, it becomes in scope.
What PCI DSS Means by “In Scope”
PCI DSS scope is driven by exposure to the cardholder data environment, not by whether a system directly stores card data alone. If a system can store, process, transmit, connect to, or influence the security of that environment, it is treated as in scope because a weakness there can become a path to cardholder-data compromise.
The practical test is whether the system can change the confidentiality, integrity, or availability of the CDE, either directly or through connectivity, shared services, administrative paths, or control dependencies. That is why systems that look “indirect” on paper can still inherit PCI obligations when they can affect the security boundary.
Scope also matters operationally because it defines where evidence, hardening, logging, vulnerability management, and access control need to be demonstrable. A clean network diagram or an internal ownership label does not remove scope if the system can still affect the CDE through a real technical connection or trust relationship.
What Makes a System Out of Scope
Out-of-scope systems are those that have no access to CDE components, do not share the same network environment, and cannot affect CDE security through any connection or dependency. In other words, they are separated strongly enough that a failure or compromise elsewhere cannot reasonably be used to reach or weaken the payment environment.
That distinction is narrower than many teams expect. A system is not out of scope simply because it does not handle card data directly, nor because it is “business support” rather than payment-facing. If it shares authentication paths, admin tooling, flat networking, or other control planes with scoped systems, PCI scope can still extend to it.
For practitioners, the key question is not “Does this server touch card data?” but “Can this server influence a scoped asset or the controls protecting it?” If the answer is yes, then the system belongs in the PCI control boundary until the dependency is removed or convincingly isolated.
Boundary Testing, Risk, and Practitioner Guidance
Scope decisions fail most often at the edges: shared identity paths, shared administration, poorly segmented networks, third-party connectivity, and hidden service dependencies. A system may appear out of scope at the application layer while still being able to weaken authentication, pivot into adjacent networks, or alter logs, backups, or configuration used by the CDE.
Failure mechanism: Weak segmentation or shared control paths allow a non-CDE system to influence a CDE component, which pulls that system into scope and expands the audit boundary. The same issue can also hide materially risky trust relationships, especially where privileged access or shared infrastructure is involved.
Impact: Misclassified scope leads to missed controls, incomplete testing, and a false sense of compliance. It can also leave a compromise path unaddressed, so the organisation protects the payment system on paper while leaving adjacent systems able to undermine it in practice.
What to verify: Validate network isolation, administrative separation, account and credential boundaries, and whether any service, jump host, logging pipeline, backup path, or API can reach the CDE. If a system can affect the security of a scoped asset, document it as in scope and assess it accordingly.
Practitioner takeaway: The most reliable scope decision is based on real technical reach and control dependency, not application labels or organisational ownership. If a system can influence the CDE, treat it as in scope until you can prove that influence has been removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
PCI DSS v4.0 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 7 — Restrict Access by Business Need to Know | Scope and control reach hinge on limiting access to CDE-adjacent systems. |
| 8.6 — System and Application Accounts and Authentication Data | Shared or exposed account paths can pull adjacent systems into PCI scope. | |
| 1 — Install and Maintain Network Security Controls | Network segmentation determines whether a system can affect the CDE and remain out of scope. | |
| Recommendation — Apply least-privilege access so only necessary systems and users can reach the CDE. Secure system accounts and authentication data to prevent cross-boundary access. Enforce segmentation and trust boundaries to keep non-CDE systems outside the cardholder-data environment. | ||
Related resources from NHI Mgmt Group
- What is the difference between PCI DSS scope validation and remediation-in-place?
- What is the difference between scope validation and data discovery in PCI DSS 4.0?
- What is the difference between periodic scope validation and targeted risk analysis in PCI DSS 4.0?
- What is the difference between Strong Customer Authentication and PCI DSS for payment security?
