How to reduce PCI DSS Scope: An overview

Jordan Lampe · February 1, 2023

PCI Compliance

Understanding PCI scope is the first step to reducing it. Get the basics and learn how to reduce scope by as much as 93%.

The Payment Card Industry Data Security Standard (PCI DSS) outlines over 300 requirements that your cardholder data environment (CDE) must satisfy to process credit and debit cards. Prevent it from paralyzing and distracting your teams by learning how to manage it.

What is PCI Scope, and what do I need to know about it?

PCI DSS scope, or simply PCI scope, refers to the set of networks, hardware, applications, and databases used to store, process, or transmit cardholder data (CHD). To be compliant, everything considered “in-scope” must have its controls reviewed and validated against the PCI DSS’ 300+ requirements.

The purpose of the security standard is to ensure that your environment and data are covered by the comprehensive risk assessment and remediation program outlined by the PCI DSS.

Whether intentional or not, PCI scope tends to expand as a company scales. A product or a partner requirement here and there can quickly lead to cardholder data everywhere. This “creep” is the bane of most CISOs’ existence and can happen if a strong compliance culture isn’t properly in place or supported.

What does it mean to “descope”?

Any piece of your environment that is storing, processing, or transmitting cardholder data must comply with those 300+ requirements mentioned earlier. Unfortunately, depending on your implementation, that level of compliance can take a long time and a significant amount of money and resources to build, support, and demonstrate compliance.

Decreasing your PCI scope reduces the breadth and depth, and thus requirements, of your CDE. Descoping refers to the activities aimed at reducing that breadth and depth. The more you descope, the more you reduce the burden of PCI compliance on your organization.

Let’s take a closer look at those benefits.

What are the benefits of reducing PCI scope?

While you can’t reduce your PCI merchant level, you can significantly reduce the time, costs, and distractions required to be considered compliant and operate without fines. Let’s take a closer look at this and other benefits that come with decreasing scope:

Reduced costs. The cost to be PCI compliant varies wildly depending on many factors. Still, by reducing the number of systems exposed to cardholder data, you reduce the costs required to build and support your CDE, and demonstrate compliance with the PCI SSC. Depending on the size of your organization and implementation, this could save hundreds of thousands of dollars.
Reduced complexity. By reducing scope, you eliminate the unnecessary applications, processes, and restrictions that, while rightfully helping protect in-scope systems, might otherwise hinder your team, products, or partners.
Increased velocity. By reducing the compliance surface area, you’re also reducing the number of approvals and levels of complexity that teams must navigate to ship anything. That predictability can increase the delivery rate without adding unnecessary risk to your organization.
Reduced risk. The more you expose your systems to CHD, the more risk you generate from would-be attackers and internal mishaps. These can have serious reputational and financial consequences that many organizations cannot bounce back from.
More focus. PCI compliance has a real opportunity cost. If you’re allocating resources or portions of your roadmap to be compliant, that’s time you’re not allocating to differentiating your product.

What is considered to be “in PCI scope?”

Let’s take a deeper look at how the PCI SSC defines a Cardholder Data Environment (CDE):

“The cardholder data environment (CDE) is comprised of people, processes, and technologies that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD).”

To break this down further, we like to think about “People, processes, and technologies” in three areas of focus:

System components
Connected-to systems
The human factor

Important!

It’s important to note the difference between eliminating requirements and scope—mostly because there’s no such thing as "eliminating the PCI DSS requirements." That’s because all organizations MUST be compliant with the PCI DSS requirements in order to work with credit card data.

You can, however, use a service provider, like Basis Theory, to inherit its compliance posture and CDE to reduce your scope and, thus, the burden of PCI scope. Of course, each provider is different, but some reduce your CDE/compliance scope by as much as 93%.

System components of a CDE (with examples)

Your system components refer to those services used to directly collect, store, process, or transmit cardholder data. For many, that CDE may look like a combination of the following:

Physical devices. These can include Point-of-sale devices, mobile phones, and any other device with a processing unit that handles sensitive data.
Applications. From card capture to return processing, applications or programs are at the heart of every payment lifecycle and must be protected.
Databases. Locations where plaintext cardholder data is stored. This could be on-prem or in the cloud.
Network infrastructure. If applications are the heart and databases are the brains of your CDE, the network is your circulatory system and critical entry point for adversaries. If left unsecured, you could allow access to data that is stored on any system connected to them (which would mean all systems).

“Connected-to” systems (with examples)

Also in-scope is connected-to components, or “Systems with connectivity or access to or from the CDE.” These systems may use a communication path to one or more system components in the CDE to support other activities. These may not necessarily be connected to the actual processing of card payments but are used to support other business functions.

For example, a card loyalty program may not need cardholder data (CHD), but it may rely on and be connected to the systems that process it. Shared services are another good example. For example, anti-virus software and monitoring tools need access to your CHD to protect it. Some of these “connected-to” systems may be your own or those of your third-party service providers. While the control requirements for “connected-to” systems are typically less than those required for the full CDE, it is important to ensure that all CDEs and connected environments are properly reviewed and scoped.

The human factor of PCI scope

Software security measures aren't enough. People use your CDE to conduct day-to-day operations, analyze data, build new products, and so much more. These folks and their processes are also considered in-scope and must have controls, like documented policies, training programs, and assessments, in place to mitigate the threats they expose or are likely to incur while working with CHD.

Defining your PCI Scope

Your first step in defining the scope should be identifying your core components, connected systems, and human touchpoints. The sum total of these parts makes up your CDE and your PCI scope.

How to reduce scope and prevent scope creep

The #1 way to descope and avoid scope creep

More and more companies are getting out of building and supporting their own CDE and using their payment service provider (PSP), like Stripe, to manage the CDE and reduce scope. Tokenization service providers, like Basis Theory, are also emerging. Unlike PSPs, these services decouple cardholder data from their payment service providers, providing the same levels of in-house flexibility and control over cardholder data without as much as 93% of compliance scope or 99% of the costs, time, and distractions to support it.

Simple tips for reducing your PCI Scope

Stop storing cardholder data (CHD) and Sensitive Authentication Data (SAD)

As discussed, CHD is any information that can be used to validate a payment card or track its use. This includes obvious things like Primary Account Number (PAN), card expiration date, and cardholder name. PCI protects Sensitive Authentication Data (SAD) such as CVV and PIN as well, which merchants are generally not allowed to store anyway.

Storing any CHD in any system instantly brings that system into scope, so if you get an email, slack, or text message with a customer’s CHD, those systems are now considered in scope.

Using tokenization

Tokenization is a process that replaces sensitive data with non-sensitive equivalents. Instead of exposing their systems and storing the cardholder data, tokenization converts it into an irreversible string of characters (i.e., token) and passes it back to the merchant to store it. The original cardholder value is stored in a secure “token vault.” When a merchant needs to use the card, for example, to complete a purchase, it provides the token (and some authorization credentials) to the vault where downstream logic, like initiating a purchase with a payment gateway, can be executed.

By using tokenization, you can significantly reduce scope. For example, if you use a tokenization service provider, you can reduce it by order of magnitude.

Segmenting your CDE

One way to reduce your PCI DSS scope is to segment your environment. This means creating separate, isolated networks for different parts of your organization, such as your cardholder data environment (CDE) and your non-CDE.

Here are some steps to segment your environment:

Identify the systems and networks that store, process, or transmit cardholder data. This is your CDE.
Create separate, isolated networks for your CDE and non-CDE. This can be done using firewalls, VLANs, or other network segmentation techniques.
Limit access to the CDE to only those individuals and systems that need it. This can be done by using access controls, such as authentication and authorization mechanisms.
Regularly monitor and test the segmentation controls to ensure they function as intended.
By segmenting your environment in this way, you can reduce the number of systems and networks that need to be compliant with PCI DSS, which can help to simplify your compliance efforts and lower your overall risk.

Segmenting is important in preventing “scope creep” too, so let’s dig into that next.

Preventing “scope creep”

Starting and maintaining a strong compliance posture is the best way to reduce costs and complexity from getting out of hand.

Proactive measures

While less efficient and direct, basic IT hygiene can reduce the risk of unnecessary or accidental scope creep. Here are a few things you or your team should be doing, especially if you store your own cardholder data.

Remove redundant components. To reduce the scope of your PCI DSS compliance, you should remove any unnecessary software or hardware components in your environment.
Remove unnecessary services. Ensure that all network services are needed and configured according to their intended use case. If a service is not relevant to your organization’s business needs, consider disabling it together until you can investigate further how it fits into your current IT strategy.
Remove unnecessary software packages and install only the necessary ones on each server in the infrastructure.

Strong developer experiences and tools

Engineers will always find and take the path of least resistance. By making it simpler for developers to do the right thing than doing the wrong thing, you increase your odds of compliance and prevent the scope creep that comes with a shadow IT organization. Here's where providing developers with the tools, services, and patterns they prefer helps significantly. Check out our developer docs to see it in action.

Final word on PCI scope

Whether you’re using Stripe, Basis Theory, or your homegrown solution, there’s no way to eliminate 100% of PCI scope. Your goal should always be to find the right mix of cost, effort, and flexibility that make sense for your business. Fortunately, thanks to many great platforms out there, it’s simpler and faster than ever to descope your systems by as much as 93%.

In fact, you can spin up your own PCI Level 1 CDE infrastructure in a matter of minutes with our PCI Blueprint. It contains everything you need to compliantly collect, store, transform, and transmit cardholder data without exposing your systems to CHD.