Reducing PCI Scope

The cost of maintaining PCI-DSS compliance can have a significant impact on the operating costs of any merchant. Whether a merchant is trying to attain and remain at the highest point— Level 1—or play by the rules at a lower transaction level, they must pay close attention, and dedicate significant resources to everything they do that includes customer personally identifiable information. 

Merchants are always looking for ways to reduce their PCI scope and resource drain of PCI-DSS compliance efforts because every dollar not spent on compliance is available to be deployed to revenue-generating programs. 

PCI DSS scope, or simply known as PCI scope, refers to the set of networks, hardware, applications, and databases used to store, process, or transmit cardholder data. To be compliant, everything considered "in scope" must have its controls reviewed and validated against the 300+ PCI requirements. 

What is PCI-DSS 

PCI-DSS is the Payment Card Industry Data Security Standard and is a set of processes, requirements, and measurements that ensure merchants properly secure their customers’ payment details. PCI-DSS was first introduced in 2004, as online payments started to ramp up when both merchants and payment system operators recognized that data breaches, hacking, and other criminality would dampen a rapidly growing e-commerce industry: users who were afraid their cardholder data could be stolen and used without their permission were leery of paying for goods and services online. 

While Visa had its own set of requirements since 2001, the large amount of fraud committed during the early years of the century (in 2000, as much as 3.6% of purchases were fraudulent) meant that the industry needed to come together and agree upon a standard set of rules.

Since 2004, the PCI-DSS standard has been updated a dozen times, with the latest version (PCI-DSS version 4.0) becoming the latest official version in March of 2025. All merchants seeking to accept payments via credit card are required to adhere to the PCI-DSS standard, which has four levels, based largely on volume. As merchants’ volume grows, they are required to move from the lower level 4 progressively up to level one, with the complexity, resource requirements, and cost increasing steadily at each phase. This cost is the primary reason merchants seek ways to reduce their PCI scope—the smaller the proportion of their payment system that comes under PCI-DSS scope, the lower the drain on business economics.

Return to Top

Which payment systems fall under PCI-DSS scope? 

Any part of a system that touches or provides access to consumer personally identifiable information falls under PCI-DSS's scope. The implications are significant, as this information may be made available to, for instance, customer service representatives, triggering a need to ensure a range of physical restrictions (locked doors with electronic tracking of entries and exits to the workspace, for instance) that can be onerous.

By contrast, systems that do not provide access to cardholder data may be held to a lesser standard. If representatives do not, for instance, have access to meaningful cardholder data, their workspace may not need the same level of scrutiny; similarly, databases that do not hold any PII are unlikely to require the same level of security as those that do.

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

1. System Components
2. Connected-to Systems
3. The Human Factor

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 cardholder data environment (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

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

Also in-scope are 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. 

Return to Top

Ways to Reduce PCI-DSS Scope 

There are a range of ways for merchants to reduce PCI-DSS scope, including:

• Don’t store primary account numbers (PAN): These are the actual numbers stored on credit cards, which can be used to make purchases. One way to avoid storing these is using a full-service payment services provider (PSP), who will keep control of the numbers on your behalf. 
• Segment your networks: Store PAN only in a hard-to-reach corner of your system, and keep it away from other systems and people who might otherwise need to be considered in scope.
• Use a programmable payment vault: contract with a provider to collect and securely manage PII, providing you with a token to use for future transactions without limitation to a single PSP.

A programmable payment vault eliminates the risk of a systems breach, as the information you store there is tokenized and cannot be returned to its original plain text form. It also allows the merchant to limit the information shared with employees and contractors, providing enough for quality customer service without exposing data unnecessarily.

For instance, you can collect the PII in your vault and receive a token to use. You can then:

• Programmatically instruct the vault to submit a transaction to your choice of PSP. You can switch between PSPs as you prefer, taking advantage of the best fee schedules, volume discounts, and specialty services, without the concern that you might lose control of your customer data (as would be the risk with committing to a single PSP.)
• Allow your customer service team access to only the information you need them to have to service support requests—even obscure them entirely by, for instance, having them type the last four digits of a credit card number into the system as dictated by the customer and have the system decide whether the entry is correct—without revealing the numbers you have stored.
• Direct the vault to deliver select information to any approved end point for a variety of reasons. Anything you store that should remain protected within your system, to avoid it coming into PCI-DSS scope, can be managed and redirected by your payments decisioning engine.

Each merchant will still be required to complete an SAQ for the PCI Security Standards Council to validate PCI compliance. Service providers like Basis Theory provide the cardholder data environment (CDE) and developer tools to collect, store, and transmit this sensitive information.

The benefits of decoupling cardholder data information from any single PSP leads to time-savings and cost-savings. Make sure you are choosing the right PCI DSS SAQ.

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. 

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%. 

Return to Top