To keep cardholder data safe, you must first understand all the aspects of your business that relate to cardholder data security. The process of identifying all of these components is known as PCI scoping. 

PCI scope refers to all of the people, processes, and technologies that touch cardholder data or could impact its security.  

Any system that’s part of your cardholder data environment (CDE) is referred to as “in scope.” The more in-scope systems you have, the more difficult it is to secure and manage your CDE.

Understanding your scope and reducing it where you can is key to minimizing the time and cost of becoming PCI compliant.

In this article, we break down what makes a system in scope or out of scope and offer tips for how you can reduce scope to simplify your compliance process.

What is PCI scope?

PCI scope refers to the people, processes, and technologies that interact with or impact the security of cardholder data. Simply put, if an aspect of your business processes, stores, or transmits cardholder data, it’s considered in scope.  

Before embarking on your PCI compliance journey, you’ll need to first determine your business’s scope. To do this, identify all of the system components that are included in or connected to the CDE. These components should be secured through applicable requirements per the PCI DSS standard. 

Mapping out your CDE is a great place to start when determining the overall scope. However, there’s more to it than that. 

Accurate PCI DSS scoping also requires understanding how cardholder data flows within the environment. 

During the scoping exercise, which will happen at the beginning of your PCI compliance journey, you’ll categorize systems into three buckets: in scope, out of scope, and connected to. We break down the meaning of these terms below.

When is a system considered in scope?

A system is considered in scope when it connects to, impacts, or is involved with cardholder data and its security. 

A rule of thumb for PCI scoping is to consider everything in scope at the beginning, before systematically ruling out the out-of-scope components. This helps to ensure you haven’t overlooked any critical systems, people, or processes. 

There are a few “rules” around scoping that apply in all scenarios:

• Systems located within the CDE are in scope, regardless of their function or why they’re in the environment. 
• Systems that connect to a system in the CDE are in scope, regardless of their function or the reason for their connection.

There are two categories of systems that are considered in scope: CDE systems and connected-to and security-impacting systems. 

Cardholder data environment systems

CDE system components include network devices, servers, computing devices, and applications. These are considered in scope by PCI DSS because they directly link to and impact cardholder data security. 

These systems should be evaluated against all relevant PCI DSS requirements. Controls put in place to protect in-scope systems should be examined at least annually. 

Connected-to and security-impacting systems

Connected-to or security-impacting systems are also considered in scope. These types of systems have a communication path (whether physically or logically) to one or more systems in the CDE. 

Implementing these technologies can be complicated. The PCI Security Standards Council (PCI SSC) recommends consulting with an expert to help determine the potential security impact that connected-to systems have on your scope. 

When is a system considered out of scope?

Out-of-scope systems don’t have access to any CDE components, which makes it unnecessary to implement PCI security controls. 

Systems considered out of scope are also called “untrusted systems” because there is no guarantee that they are sufficiently protected.  

For a system to be considered out of scope, it must meet all of the following requirements:

• Components must not store, process, or transmit cardholder data or sensitive authentication data (SAD).
• They must not share a network segment, subnet, or virtual local area network (VLAN) with systems that store, process, or transmit cardholder data or SAD.
• Components cannot connect to or access any part of the CDE.
• They cannot gain access to the CDE or affect its security controls through an in-scope system.
• They must not meet any criteria defined for connected-to, security-impacting, or in-scope systems or system components.

If a system does not meet even one of the above requirements, it’s considered in scope. 

Just because a system is considered out of scope does not mean it doesn’t deserve security measures. It’s recommended that you employ security best practices to protect your out-of-scope systems and networks.

What is segmentation?

You may be wondering if there’s any way to reduce your PCI scope. The answer is yes. This process is known as segmentation. 

Segmentation allows a business to apply additional security controls to isolate systems that deal with cardholder data from those that do not. Segmentation is similar to building a fence around your home. It not only keeps your family and home safe, but it also keeps intruders out. 

Segmentation allows you to “wall off” your CDE from out-of-scope networks. Common segmentation methods include VLANs and firewalls. 

When implemented correctly, a compromised out-of-scope network will not have an effect on your CDE.

PCI SSC encourages businesses to use segmentation to help reduce the cost of PCI compliance, simplify the process of implementing and maintaining PCI controls, and reduce organizational risk by consolidating cardholder data into fewer, more secure locations. 

Without segmentation (also known as a flat network) your entire network is considered in scope by the PCI DSS standard. 

There are two types of segmentation methods: 

• Physical segmentation isolates CDE systems from out-of-scope systems with physically separate network devices, firewalls, or servers. 
• Logical segmentation isolates CDE systems from out-of-scope systems using internal network firewalls, routers, or other technologies that restrict access to or from a specific network segment.  

A business may decide to use either of these segmentation methods or a combination of the two.

How to scope your CDE

PCI SSC released a helpful scoping guide in 2016 that includes a six-step scoping exercise to help you determine and manage your scope. 

1. Identify all payment channels

Start by identifying how and where your organization receives cardholder data. Consider the entire life cycle of cardholder data from the point you receive it to when it’s disposed of. 

2. Map cardholder data flow

Next, document how cardholder data flows through your organization. 

Also identify and document the people, processes, and technologies that are involved with storing, processing or transmitting data. These people, processes, and systems are all considered part of your CDE. 

3. Identify other connected-to and security-impacting systems

Examine your processes, system components, and personnel that have the ability to interact with or impact the security of cardholder data. These people, processes, and technologies are also considered in scope. 

4. Implement controls to minimize scope

After identifying all of the in-scope people, processes, and technologies, begin segmenting your network to limit connections between cardholder data and in-scope systems to only what’s necessary. 

5. Implement all applicable PCI requirements

After reducing your scope, identify and implement the PCI DSS requirements that are applicable to your in-scope systems, processes, and personnel. 

6. Maintain and monitor your scope

Once PCI requirements have been met for all in-scope systems, ensure that the controls you’ve put in place will remain effective. You should also create a process for updating your scope when any changes are made to systems, processes, and personnel.

PCI scoping considerations

The PCI SSC has issued some additional guidance for understanding and maintaining your scope. Here are a few important considerations to keep in mind. 

• Segmentation does not automatically reduce your scope. Instead, segmentation must be built with purpose and intention to ensure the CDE is sufficiently protected. 
• PCI scope should be re-assessed on an annual basis. During this review, the company should conduct another PCI scoping exercise to examine the flow of cardholder data and identify any new in-scope systems. Documentation should be kept year over year as evidence during audits. 
• Network segments should undergo annual PCI penetration testing. These tests will ensure the effectiveness of your segmentation methods and help identify any vulnerabilities before they impact cardholder data security.

Other ways to reduce your PCI DSS scope

While segmentation is one of the most common methods for reducing PCI scope, there are additional steps you can take. 

Not storing data you don’t need

This one is simple: If you don't need cardholder data, don’t store it. 

Cardholder data storage leads to rigorous regulations under PCI DSS Requirement 3 that involve creating and enforcing policies related to identification, retention, and deletion. 

By avoiding unnecessary cardholder data storage, you not only reduce your scope but also simplify your PCI compliance process.

Tokenization

Tokenization converts cardholder data into algorithmically generated letters and numbers. 

Once the process is finished, tokens are not considered cardholder data. This means that the systems that process, store, or transmit tokens are not considered in scope. 

Use a PCI-listed P2PE solution

If your organization conducts payments in a physical store, using a point-to-point encryption (P2PE) solution at the point of sale helps reduce your scope.

A P2PE tool encrypts cardholder data, and only the solution provider is able to decrypt it. This means the merchant never has access to the unencrypted account data. 

Businesses that use a P2PE solution are required to complete a P2PE SAQ, which is a significantly less stringent assessment process compared to other SAQ types. 

Outsource to a third-party service provider

You can also opt to outsource certain aspects of your cardholder data management to a third-party service provider. 

However, you’re still ultimately responsible for protecting cardholder data and must do your due diligence to ensure third parties you work with are in compliance with applicable PCI requirements.

How Secureframe can help scope your CDE

If determining your scope still sounds overwhelming, we’re here to help. 

Secureframe’s team of PCI DSS experts will walk you through the entire scoping process before helping you through the rest of the compliance journey. 

Ready to get started? Request a demo with our team today.