Before a single PCI DSS control is implemented, before a policy is written, before a QSA is engaged — there is one decision that determines the size, cost, and complexity of your entire compliance programme. That decision is scope.
Your PCI DSS scope is the set of systems, people, processes, and network infrastructure that must comply with the standard. Scope too broadly and you are applying PCI DSS controls to systems that have no meaningful relationship to cardholder data — adding cost and complexity without adding security. Scope too narrowly and you leave cardholder data flowing through systems that are not covered by your controls — creating both compliance gaps and genuine security risk.
Getting scoping right is not a compliance technicality. It is the foundation on which every subsequent decision in your PCI DSS programme rests.
How PCI DSS Defines Scope
PCI DSS scope covers all system components that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), as well as system components that could impact the security of those systems. This second category is where most scoping disputes arise — it is broader than many organisations initially assume.
The standard identifies three categories of system components:
In-scope systems. Systems that directly store, process, or transmit cardholder data. These are in scope regardless of any other factors.
Connected systems. Systems that are connected to in-scope systems — even if they do not directly handle cardholder data — where those connections could impact the security of the CDE. A management server that administers in-scope systems, an authentication server that handles access to in-scope systems, a monitoring platform that receives logs from in-scope systems — all potentially in scope because of their connection, not their data handling.
Out-of-scope systems. Systems that have no connection to in-scope systems and are fully isolated from the CDE. Achieving genuine out-of-scope status requires verified segmentation, which most organisations need to demonstrate through network testing.
The Most Common Scoping Mistakes
Failing to account for all cardholder data flows. Scoping starts with mapping where cardholder data actually flows — not where it is supposed to flow or where you think it flows. Cardholder data has a habit of appearing in unexpected places: log files, email attachments, spreadsheets used by customer service teams, backup systems, development and test environments that were seeded with production data. The scoping exercise must begin with a thorough data flow discovery, not an assumption.
Underestimating connected system scope. Organisations frequently scope their CDE correctly but fail to account for connected systems. A vulnerability management platform that scans in-scope systems, a SIEM that receives security events from the CDE, an identity provider that handles authentication for CDE access — these are commonly missed. Your QSA will ask about them, and discovering mid-assessment that significant systems were out of your compliance programme is a costly finding.
Assuming cloud provider compliance covers your obligations. Using a PCI DSS-certified cloud provider for your payment infrastructure does not transfer your compliance obligations to the provider. The provider’s certification covers the infrastructure they manage. Your applications, configurations, access controls, and processes that run on that infrastructure are your responsibility. The shared responsibility model in cloud PCI DSS compliance must be explicitly documented and understood.
Scope Reduction Strategies That Work
Reducing PCI DSS scope is a legitimate and effective compliance strategy — not a shortcut. The standard explicitly encourages scope reduction as a way to focus compliance effort where it matters most.
Tokenisation. Replacing cardholder data with tokens that have no value outside your specific payment context removes that data from systems that do not need it. A system that handles tokens rather than PANs (Primary Account Numbers) may be out of scope, depending on the architecture. Tokenisation, properly implemented, can significantly reduce the number of systems that handle real cardholder data.
Point-to-point encryption (P2PE). PCI-validated P2PE solutions encrypt cardholder data at the point of interaction and do not decrypt it until it reaches a secure decryption environment outside your control. Merchants using validated P2PE solutions may qualify for a significantly reduced scope — the encrypted data flowing through their systems is not cardholder data under PCI DSS definitions.
Network segmentation. Effective network segmentation isolates the CDE from the rest of the organisation’s network, reducing the number of connected systems that fall into scope. Segmentation must be verified — QSAs will test that the segmentation is effective, not just that it exists in a network diagram.
At Bitsecura, we conduct PCI DSS scoping workshops that map cardholder data flows, identify connected systems, and assess scope reduction opportunities before your compliance programme is designed. Getting scope right at the start is significantly less expensive than discovering scope problems at assessment. If you want a rigorous scoping exercise, talk to us here.
Bitsecura provides PCI DSS compliance support, gap assessment, and QSA readiness services. Learn more about our PCI DSS services.