PCI-DSS Scope Identification Guidance

Scope is a critical aspect of Payment Card Industry Data Security Standard (PCI DSS) compliance and can be one of the most leaky and difficult parts of getting started on your compliance journey. It determines which components of an organization's infrastructure must be included in their Cardholder Data Environment (CDE), and can make or break how challenging and expensive achieving compliance is. It’s also often different from ISO 27001 or SOC II and needs a bit more of a deep dive even in environments where one of them is already in place.

An environment that is scoped too large will cost more to secure, manage and assess and an environment that is scoped too small can leave Cardholder Data exposed inappropriately resulting in breaches, fines, or super uncomfortable moments with your Assessor.

Accurately identifying scope is the key to minimizing cost, stress, time, and administrative burden related to PCI, and the following steps are your starting path to ensuring you know where to focus your efforts for maximum effect and minimum frustration.

Buckle up. This is a long one, but it’s a hugely valuable one. 

To begin, let's break this into steps:

1. Identify Cardholder data flows. This involves tracing the path of cardholder data from the moment it is entered into a system, through processing and storage, and finally to its ultimate destination. Include people, processes and technologies and see our blog post HERE for information on how to make a good Cardholder Data Flow Diagram.
2. Define your CDE. This includes point-of-sale (POS) devices, servers, databases, containers, applications, shopping carts, vendors and networks that are used to store, process, or transmit cardholder data. 
1. Remember to evaluate people, processes and technologies, not just technical artifacts or computer systems. 
2. Ask yourself “Does this directly store, process or transmit CHD or influence the security of the storage, processing or transmission of CHD?”
1. For example: GCP is clearly a service provider, and a Kubernetes cluster might be processing card data. Consider the administrators with access to that cluster. What about developers? Is that cluster sending logs to a centralized place? Etc.
2. Outsourcing your processing, tokenizing, or using another company's systems? How do you access those environments? Your systems like computers, subnets, etc. likely transmit (via human interaction) cardholder data and should be thought of as part of your CDE.
3. If you use a vendor for part of your flow, identify if they are already PCI compliant. If so, the service they provide is still in scope but is covered by their Compliance. You will need to demonstrate that it is provided in a compliant way. (See step 4)
3. Consider using segmentation to reduce scope. Segmentation is not required by PCI-DSS, but it can be a powerful tool to reduce scope and complexity. If a system is not directly part of the CDE but is able to communicate directly with CDE systems, it is often considered in scope, even if it doesn’t have anything to do with the CDE. By definition, it “impacts the security of the CDE” because it shares connections. 
1. Consider restricting these systems from having open communication with the CDE using Network Access Control Lists (NACLs), Firewalls or other pre-defined and enforced communication protocols such as services clustering, VLANs, VPCs, etc.
1. This can (and often should) include jump boxes, bastion hosts, and other ways to limit direct external access to systems and help remove end-user laptops from scope. 
1. Ex. The jump box or bastion host is in scope because it directly connects to the CDE, but the end user laptop now isn't because it is insulated by the jump box or bastion host.
4. Consider the use of third-party services. If an organization uses third-party services to handle cardholder data, these services must also be included in the scope of the assessment in some way. This can be a great way to reduce complexity or cost but it carries some challenges with it. 
1. Usually, this means requesting their Attestation of Compliance (AOC) and pointing at that to satisfy a requirement
1. For example, for a SaaS company using a cloud service provider like AWS, GCP or Azure, much of Requirement 9 is “In Place via compliant service provider X per AOC dated mm/dd/yy.”
2. In some scenarios, a critical vendor isn’t PCI compliant. In these cases, they must be assessed as if they are part of your assessment. This means PCI controls must be applied and validated in their systems as if they were being assessed directly, or you risk non-compliance. This applies even if the systems aren’t actually under your control. 
3. When using 3rd party services, it is important to document their compliance status annually, track when their AOC expires and request a new one, and maintain a clear responsibility matrix of what they handle for you and what you are responsible for as part of the relationship
5. Document. It is important to officially document the components that are in scope and those that are out of scope to clearly understand what is included in the assessment. 
1. This can look like many things. An inventory, sets of diagrams, a policy document, etc. It is important to write it down somewhere for internal use and reference and for assessors. 
6. Review and validate. This is an opportunity to check that all relevant components have been included in the scope and that the documentation accurately reflects the scope of the assessment. 
1. PCI is extremely complex, and its easy to miss things on the first pass as we dig in for the first time. Don’t be afraid to second guess yourself, and always err on the side of caution. If it's not 100% out of scope, it’s safer to include it. 
2. It is not uncommon for scope to change year over year. New business processes that weren’t known before are discovered, different needs or technical considerations arise, etc. This is totally natural and expected and why annual review is so important.
7. Update. As changes are made to the environment, it is important to update the scope to reflect them. PCI requires an official scope review and confirmation activity to be completed at least annually or after any significant change.
1. What significant change means is up to you, but it is generally agreed that major version updates to software or applications, infrastructure migrations or platform changes, etc. should be considered “significant” for the purpose of PCI. 

Once you understand your scope, the real work begins (I know…we are just getting started).

With your scope documentation and cardholder data flow(s) handy, go through each PCI requirement on your paperwork (Generally the ROC template or the appropriate SAQ based on your business model), and look at what is in scope. Ask yourself “does this apply to any of these people, processes or technologies?”
If the answer is “yes”, that requirement is something you will need to address for each CDE component that it applies. 

During this process, it can be hugely helpful to use the Prioritized Approach Tool from the PCI-SSC to help project manage the implementation of PCI-DSS. It gives all requirements and provides a phased (via filtered priority levels) way to ensure you complete the basics before the advanced stuff and incrementally build a strong PCI program as opposed to just playing whack-a-mole with controls.

Finally, consider what you provide to your customers and use that as a sanity check for what requirements you think you are responsible for.
Example 1: A BPO organization that exclusively uses their customers systems for cardholder data probably doesn’t need to consider application security or the passwords of those customer systems, but should think about the physical security of the production floor where their staff work, background checks for their team, maybe how they handle access to the customer systems, and probably the computers they are using to access their customers applications.
Example 2: A payment orchestration platform relying on an outsourced tokenization engine probably doesn’t need to stress about cryptography around the storage of cardholder data too much but should absolutely be thinking about access control to their back-end systems and ensuring they aren’t accidentally capturing CHD in logs from their website or APIs. They should also be thinking about policies and procedures a lot. 

For more detailed information, I strongly recommend reading this whitepaper from the PCI Council on how to think about scope and segmentation.

Don’t hesitate to lean on your QSA or another partner to help validate your scope during your pre-assessment work, and when in doubt Vanta has an extremely robust network of expert partners who can help you navigate the journey from beginning to end as well.

Welcome to PCI with Vanta. We’re glad to have you onboard.