How should organisations scope PCI DSS compliance when cardholder data moves through merchants and service providers?

Why This Matters for Security Teams

PCI DSS scope is not a paperwork exercise. When cardholder data passes through merchants, processors, gateways, cloud services, call centres, or managed service providers, every connected system that can store, process, or transmit that data can become part of the cardholder data environment. Under PCI DSS v4.0, scoping must reflect both data flow and security impact, which is why a narrow “we only touch it briefly” argument usually fails audit review.

The practical risk is that organisations often map only the obvious payment application and miss upstream identity systems, support tooling, logging platforms, and third parties with indirect access. That gap is especially dangerous when service accounts, API keys, and vendor credentials are reused across environments. NHIMG research shows Ultimate Guide to NHIs — Key Challenges and Risks documents how widely exposed non-human identities expand the attack surface, while the PCI DSS v4.0 library makes clear that scope follows trust boundaries, not organisational charts. In practice, many security teams discover scope inflation only after a vendor assessment or breach review has already exposed the omitted systems.

How It Works in Practice

Start by building a complete data-flow map from the point of capture through every hop that can touch cardholder data, including merchants, payment service providers, fraud tools, customer support platforms, storage layers, backups, and analytics feeds. Then identify the people, systems, and service providers that can alter security outcomes, even if they never see the full PAN. That is the core PCI scoping principle: if a component can affect the security of cardholder data, it belongs in scope.

In operational terms, scope should be tested against three questions:

• Does the system store, process, or transmit cardholder data?
• Does it connect to a component that does?
• Could its compromise affect confidentiality, integrity, or availability of the cardholder data environment?

That third question is where third parties often get missed. A managed service provider with remote admin access, a SIEM ingesting payment logs, or a support desk that can reset accounts may not handle card data directly, but each can affect its security posture. NIST guidance on security boundaries and control inheritance supports this broader view, and the NIST Cybersecurity Framework 2.0 is useful for mapping governance, asset visibility, and third-party risk. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is especially relevant where vendor-owned automations or service accounts sit inside payment workflows, because those identities often define the real trust boundary.

Best practice is to keep the in-scope environment as small as possible, but only after the full path has been documented and validated with evidence. That means contract clauses, access reviews, segmentation diagrams, tokenisation boundaries, and attestation from service providers all need to align. These controls tend to break down in multi-processor and marketplace environments because data paths change faster than scope registers are updated.

Common Variations and Edge Cases

Tighter PCI scoping often reduces audit burden, but it increases documentation overhead and demands continuous change control, so organisations must balance operational simplicity against the cost of maintaining boundaries. There is no universal standard for every architecture, especially where merchants outsource payment functions but retain control over integrations, logging, or reconciliation.

One common edge case is tokenisation. If a provider fully replaces cardholder data with tokens and the merchant never receives the PAN, scope can shrink significantly, but only if the tokenisation boundary is technically and contractually enforced. Another is hosted payment pages, where the browser still interacts with merchant infrastructure, making script control, redirect integrity, and page tamper monitoring relevant to scope.

Service providers add another layer of ambiguity. A processor may be out of the merchant’s direct network, yet still be in-scope for vendor management, segmentation validation, and shared-responsibility testing. This is where guidance from the OWASP Non-Human Identity Top 10 helps practitioners think about secrets, service accounts, and machine-to-machine trust paths that often sit underneath payment integrations. Where merchants rely on automation, the scoping question should also include which non-human identities can trigger payment-adjacent actions, because those identities can move data or alter controls even when no person is involved.

Current guidance suggests treating every trust boundary as provisional until evidence proves otherwise, especially when cloud services, outsourced support, and embedded checkout components are involved. If the organisation cannot demonstrate where cardholder data enters, where it is transformed, and who can affect those systems, the scope is already too narrow.

Related resources from NHI Mgmt Group

• Why do payment environments with cardholder data scope create ongoing compliance risk?
• Who is accountable for PCI SAQ compliance when organisations rely on third-party payment providers?
• How should teams automate PCI DSS scope validation for cardholder data?
• Who is accountable for PCI DSS compliance when cardholder data is stored in Office 365?