PCI Descoping: The Ultimate Guide to PCI Compliance

Want more content?

By subscribing to our mailing list, you will be enrolled to receive our latest blogs, product updates, industry news, and more!

How to Reduce Controls and Streamline Compliance

As long as payments have existed, so too has the need to secure them. From bank vaults and cash registers to the data protection technologies we use to safeguard digital transactions today, security methods continue to evolve. In this ongoing pursuit to protect payments from theft and fraud, card brands have established guidelines for ensuring organizations handle sensitive payment data properly. The most prominent of these requirements is the Payment Card Industry Security Standards Council’s (PCI SSC) Payment Card Industry Data Security Standard (PCI DSS).

PCI DSS compliance is required of any organization that wishes to process, store, or transmit cardholder data issued by the five major card brands. This stipulation is simple enough, but the compliance process itself is a complicated task. PCI DSS compliance is an ongoing endeavor that requires organizations to regularly maintain and assess their network systems to ensure they are meeting the latest compliance obligations of the payments industry.

If your organization stewards payment card information (PCI) and has attempted implementing PCI compliance solutions before, you more than likely are familiar with the painstaking nature of this process. An environment that is compliant during one annual assessment could be non-compliant the next, and even when compliance is achieved, a compliant environment isn’t necessarily a secure one. Simply aiming to satisfy minimum compliance obligations is not a sufficient security posture. Instead of positioning you for the future, it will put you at the mercy of ever-changing industry regulations, and you’ll always be chasing a moving goal line.

An effective way to ensure you’re meeting compliance obligations as efficiently as possible is to simplify your cardholder data environment (CDE). This is primarily done by reducing the amount of cardholder data (CHD) in your systems—and in turn, the scope of PCI DSS controls within your network. This can be accomplished in myriad ways, but before we dive into compliance methods, let’s first review the PCI DSS, its definitions, and its requirements.

Background Check: Five Introductory Questions

What is the Payment Card Industry Security Standards Council?

The Payment Card Industry Security Standards Council (PCI SSC) is the governing organization and forum that oversees the PCI guidelines, including the Payment Card Industry Data Security Standard (PCI DSS).

The PCI SSC was formed by the five major card brands in 2006 to help reduce payment fraud. It consists of the founding card brands as well as a number of participating organizations, such as service providers, merchants, and large organizations that help maintain, evolve, and promote the PCI security standards.

What is the Payment Card Industry Data Security Standard (PCI DSS)?

The PCI DSS is an information security framework intended to protect cardholder data (CHD). It was created by the PCI SSC because the card brands were concerned about the number of data breaches occurring, particularly as they related to the loss of credit card data.

What are PCI Controls?

The PCI DSS is composed of more than 300 controls, each of which includes testing procedures and corresponding guidance on how to implement them. Controls are the items used to measure an organization’s compliance, such as establishing a required length or complexity for passwords. They make up the standard’s requirements, and the number of them that are applicable to a particular environment can be decreased by reducing an organization’s compliance scope.

What is PCI Scope?

Scope is the portion of your organization’s environment that includes not just technology but the people and the processes that are involved in the storing, processing, and transmitting of credit card data. The parts of your systems that are in scope are known as the cardholder data environment (CDE).

PCI DSS scope applies to all systems that are connected to or could impact the security of the CDE, such as authentication servers, patch servers, AV firewalls, routers, cryptography systems, and more. It also includes call center operators, IT personnel, human resources employees, and anyone else who has access to card data.

To whom does the PCI DSS apply?

The PCI DSS applies to any entity that stores, processes, or transmits payment card account data. This typically includes merchants, acquiring banks, card issuers, payment processors, and service providers.

It’s not just about the cardholder data in a given organization’s environment, though. You could be a merchant that has a point-of-sale system that’s applied by your acquiring bank, and you’re still subject to PCI DSS because you’re involved in the processing of credit card information. It applies to all acquiring banks, card issuers, payment processors, and service providers that store, process, or transmit credit card data.

Overview: PCI DSS Requirements

As we’ve mentioned, the PCI DSS is a set of controls governing the secure handling of payment card account data. It was created to provide a base level of security for cardholder data to combat payment card fraud. If you work for an organization that does not have a robust or mature data security program, the PCI DSS can function as a template or roadmap for working toward compliance. If your organization has a better-established program, the PCI DSS requirements will likely overlap with or apply to your other regulatory compliance obligations.

Practically speaking, the PCI DSS is essentially a list of information security best practices. Six categories and 12 requirements (and their numerous sub-requirements) comprise the PCI DSS:

Build and Maintain a Secure Network

  • Install and maintain a firewall configuration to protect cardholder data
  • Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

  • Protect stored cardholder data
  • Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

  • Use and regularly update anti-virus software or programs
  • Develop and maintain secure systems and applications

Implement Strong Access Control Measures

  • Restrict access to cardholder data by businesses need to know
  • Assign a unique ID to each person with computer access
  • Restrict physical access to cardholder data

Regularly Monitor and Test Networks

  • Track and monitor all access to network resources and cardholder data
  • Regularly test security systems and processes

Maintain an Information Security Policy

  • Maintain a policy that addresses information security for all personnel

When first approaching the compliance process, it’s important to take a step back and look at the overarching categories to understand what each set of requirements is trying to accomplish. Here’s a high-level rundown.

Build and Maintain a Secure Network and Systems

This outlines requirements for network security. Specifically, it requires organizations to install and maintain firewalls and routers and not to use vendor-supplied defaults. All of the controls in this category are about securing your network and implementing proper network security mechanisms.

Protect Cardholder Data

This is a data security category. It’s concerned with the protection of the data elements themselves, regardless of their form. That could be data in storage, in transit, in processing, or even in physical form, such as paper records like invoices or receipts. All of that data would be in scope, making tokenization and encryption appropriate measures for obfuscation.

Maintain a Vulnerability Management Program

This category is concerned with application security, so it details how an organization should protect its systems against malware, viruses, coding exploitations, and other items that affect application security.

Implement Strong Access Control Measures

The first two requirements here address identity and access control measures. Identity refers to how to authenticate a user, and access control determines the user’s permission or access level to certain resources within your environment, specifically to cardholder data. The third aspect covers controls for physical access, such as requiring locks, cameras, etc., to prevent unauthorized physical access to a server room or data center.

Regularly Monitor Test Networks

This requirement is not so much concerned with implementing new security mechanisms as it is with maintaining your existing ones and ensuring they are sufficient. You need to be able to monitor your own network and detect security incidents if and when they occur. You also need to test your security systems and coding to ensure they are secure and functional, update and patch applications, and keep up with threat management for malware and viruses.

Maintain an Information Security Policy

This is essentially a policy that sets the tone for your entire organization’s information security strategy. It needs to address all of your employees and reflect your attitude toward PCI compliance and overall data security. This includes training programs and continuing education to ensure proper practices.

These six categories provide an overview of the security controls required for PCI compliance. As essential as these individual concepts are, it’s important to remember that compliance and security are not the same thing. However, by prioritizing security—specifically a data-centric approach—compliance will likely follow.

About PCI DSS: How Do I Know if I’m Compliant?

What does it mean to be PCI compliant? If an organization can prove it has met all of the requirements of PCI DSS, either on its own or with the assistance of third-party providers, it is considered to be compliant.

Depending on the state of an organization’s environment, it might qualify for a self-assessment or require an external audit from a qualified party. Here are definitions for terms used for different aspects of the compliance verification process.

  • Self-Assessment Questionnaire (SAQ) — validation tool intended to assist merchants/service providers who are permitted by the payment brands to self-evaluate their compliance with the PCI DSS.
  • Report on Compliance (ROC) — a form that must be completed by merchants and service providers not eligible for an SAQ. The ROC is used to verify that the merchant being audited is compliant with the PCI DSS. The ROC must be filled out by a qualified security assessor (QSA) who has audited the merchant.
  • Attestation of Compliance (AOC) — a form that must be completed by a QSA or merchant (if the merchant internally audits) as a declaration of the merchant’s compliance status with the PCI DSS.
  • Approved Security Vendor (ASV) scan — a scan of your network by an approved external entity to search for vulnerabilities.
  • Qualified Security Assessor (QSA) — an individual employed by a QSAC (which is an organization that specifically performs PCI audits) who is responsible for evaluating CDEs.
  • Internal Security Assessor (ISA) — an individual within your organization who can complete SAQs and otherwise assist with PCI compliance.

Again, not all of these items will be relevant to every organization. The type of environment your organization is operating and the way it processes, stores, and transmits its cardholder data will ultimately determine which document(s) are required for compliance.

See below for a full list of SAQ types and descriptions of the environments that qualify for them.

SAQ Types



Card-not-present merchants (ecommerce or mail/telephone-order) that have fully outsourced all cardholder data functions to PCI DSS—validated third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.

Not applicable to face-to-face channels.


Ecommerce merchants who outsource all payment processing to PCI DSS–validated third parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.

Applicable only to ecommerce channels.


Merchants using only:

  • Imprint machines with no electronic cardholder data storage; and/or

  • Standalone, dial-out terminals with no electronic cardholder data storage.

Not applicable to ecommerce channels.


Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage.

Not applicable to ecommerce channels.


Merchants who manually enter a single transaction at a time via a keyboard into an internet-based virtual terminal solution that is provided and hosted by a PCI DSS–validated third-party service provider. No electronic cardholder data storage.

Not applicable to ecommerce channels


Merchants with payment application systems connected to the internet, no electronic cardholder data storage.

Not applicable to ecommerce channels


Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC–listed P2PE solution, with no electronic cardholder data storage.

Not applicable to ecommerce channels


SAQ D for Merchants: All merchants not included in descriptions for the above SAQ

SAQ D for Service Providers: All service providers defined by a payment brand as
eligible to complete an SAQ.

Source: PCISecurityStandardsCouncil.org

Credit Card Security: Levels for Merchants and Service Providers

Although many of the requirements comprising the PCI DSS are applied and enforced in the same fashion across the board, the PCI SSC does not necessarily administer a one-size-fits-all approach to compliance.

Instead, because organizations operate differently depending on their size, merchants are broken out into four PCI compliance levels based on the volume of their transactions. Each level brings with it its own set of requirements for compliance and potential penalties if compliance is not met.

  • Level 1 – 6 million or more transactions
    • Network scan by an approved scanning vendor (ASV)
    • Annual QSA ROC
    • Complete an AOC
  • Level 2 – 1-6 million transactions
    • Network scan by ASV
    • Annual SAQ
    • Complete an AOC
  • Level 3 – 20,000 to 1 million transactions
    • Network scan by an ASV
    • Annual SAQ
    • Complete an AOC
  • Level 4 – Less than 20,000 transactions
    • Network scan by an ASV
    • Annual SAQ
    • Complete an AOC

The card brands define levels for merchants and service providers. Merchants are any entity that accepts card payments as a part of the payment process. Service providers, such as payment processors, are those organizations that are providing some payment-related functionality to merchants.

The four levels are based on the number of annual transactions because, in theory, the greater the volume of your transactions, the greater the difficulty of securing them, and therefore, the greater the risk of a data breach or exposure. As such, level one contains the strictest requirements for PCI DSS compliance.

It’s also important to note that some card companies will escalate your PCI compliance level if you suffer a breach or are otherwise found non-compliant. So just because you might have a higher level of compliance doesn’t necessarily mean QSAs, auditors, or the PCI SSC will be lenient with your organization.

PCI Rules: What’s in Scope?

The scope of an organization’s environment is the extent to which payment card data exists within its systems. Any portion of a network that stores, processes, or transmits payment card data is considered to be within the scope of PCI compliance. The best way to determine this is to perform a scoping exercise.

This entails creating a data flow that maps how payment data travels through your environment. From there, you can see who and what is interacting with cardholder data and where those interactions are occurring. In the process, you will identify which assets along the data flow are in scope and therefore need to be examined to ensure security and compliance.

What is Descoping?

Descoping is the concept of minimizing an organization’s compliance scope by reducing the number of security controls applicable to its environment. The people, processes, and technology not involved in the storage, processing, or transmitting of payment card account data are out of scope for PCI DSS. So, by limiting the number of people, processes, and technology that interact with payment data, organizations can reduce their scope

In addition to simplifying compliance and reducing cost, descoping also minimizes your attack surface. The PCI DSS designates certain areas of your environment as in scope because they pose serious security risks. By removing those areas from scope, in effect, they’re no longer considered a risk, reducing the negative potential impact associated with a breach.

Benefits of Descoping

  • Reduce the financial cost associated with PCI DSS audits
  • Reduce the time needed to perform the PCI DSS audit
  • Reduce the level of effort to implement and maintain the controls necessary for PCI DSS compliance
  • Reduce the impact of a potential data breach
PCI Compliance: Strategies for Scope Reduction

Descoping a data environment by decreasing the amount of CHD traversing is one of the simplest and most effective ways of complying with the PCI DSS. Often, organizations choose to meet PCI requirements by utilizing a combination of segmentation and encryption, but tokenization has emerged as a simpler scope-reducing alternative with minimal disruption to vital operations and business intelligence.

Cloud-based PCI tokenization even outsources the handling of sensitive payment information to security experts, further reducing compliance and operational costs while mitigating the risk and liability associated with a potential data breach. Let’s examine a few common examples of techniques for reducing scope.

Network Segmentation

Network segmentation is the process of separating your computing assets, either logically or physically, so cardholder data interacts with as few of your network-attached resources as possible. After segmenting the portion of your environment that interacts with payment card data, all cardholder data ideally would be stored in a network isolated from your other business applications and systems. This ensures that only a limited number of computing assets and environments are in scope.

Common methods of network segmentation include firewalls, virtual local area networks (VLANs), and routers, but the effectiveness of these solutions can be limited by an increasingly mobile environment that enables employees to access sensitive information from multiple devices and locations. As such, the process of segmentation has become increasingly complex, difficult, and expensive.


Encryption uses mathematical algorithms with cryptographic keys to encrypt and decrypt data. Asymmetric algorithms use a pair of public and private keys, whereas symmetric algorithms use a single key for encryption and decryption.

Encryption can protect sensitive data, but it does not reduce scope unless a secure third party manages the aforementioned encryption keys. If you possess the keys or store them in your environment, then a breach of your system could potentially make them available to hackers. Thus, all of the CHD encrypted by keys stored in your system is still in scope.

However, on-premises encryption can reduce scope when it is deployed in the form of point-to-point encryption, which ensures the immediate security of all the payment data entered via card swipes or a PIN-pad device. This is a useful application for point-of-sale systems and call centers.


Tokenization is the process of converting sensitive data into nonsensitive, mathematically unrelated data called tokens. Once data is tokenized, it is no longer considered cardholder data, so a placeholder token can flow through your environment without bringing any of the elements that store, process, or transmit it into scope.

Ideally, tokenization occurs outside of your environment so cardholder data in its original, sensitive form is never introduced. If this is the case, organizations can virtually remove their networks from scope and greatly increase the likelihood that they’ll be able to maintain compliance between annual assessments.

To push compliance boundaries out to the farthest edge of your environment, you can use technologies such as load balancers to tokenize data at the earliest point in the payment card acceptance process, maximizing the reduction of scope. Additionally, tokenization requires neither the key management of encryption nor the significant infrastructure costs of network segmentation.

PCI Data Compliance: Closer Look at Tokenization

Tokenization vs. Encryption

As previously mentioned, tokenization technologies such as TokenEx’s Cloud Security Platform can remove sensitive data from an organization’s environment, whereas encryption can only obfuscate data.

By removing sensitive data from your environment, you can virtually eliminate the risk of data theft and minimize the damage resulting from a security incident, and working with a security provider–such as a cloud tokenization platform–can reduce risk by creating abstraction via storing your data with security experts.

Differences From Encryption

  • No keys or key management
  • Length- and format-preserving
  • Retains portions of the original data
  • Removes the credit card PAN from the environment
  • Reduces the impact of a security breach
  • Shifts liability and risk associated with sensitive data to a service provider

Even though encryption replaces the PAN with cipher text, the data is considered sensitive by the PCI DSS if the encryption keys are stored inside of your environment. Unlike cipher text, tokens can retain portions of the original data for added business utility and still not fall within PCI scope. This is because the token is not mathematically related to the original data.

Tokenization Platforms

Cloud- Based

  • Shifts liability to the service provider
  • Maximum risk reduction
  • Maximum scope reduction

Although tokenization itself is generally the same regardless of provider, its implementation, integration, and functionality can differ dramatically, especially in terms of scope reduction and compliance. Cloud-based tokenization–the type TokenEx both champions and offers–is the ideal scope-reducing solution.

Because cloud tokenization secures CHD before it enters an organization’s internal systems, it can completely remove credit card data from your environment. For TokenEx, this means storing the credit card PANs securely offsite and providing our customers with tokens. This shifts all technical liability to TokenEx, for minimum scope and maximum risk reduction. It won’t completely eliminate PCI scope, but it can reduce it more than segmentation without the additional cost or technical debt. It also increases security by making data inaccessible to thieves and hackers in the event of a security incident.


  • Requires a CDE
  • Less risk reduction
  • Less scope reduction

Some organizations choose on-premises tokenization, which occurs within their network and typically involves purchasing both software and hardware. Unlike a cloud deployment, on-premises solutions require you to store cardholder data within your environment, ideally a single CDE. This CDE will be subject to all of the more than 300 controls of the PCI DSS, and since it exists within your internal systems, it makes you liable in the event of a data breach.

On-premises tokenization also is typically more expensive and labor-intensive than other options, but it does give you direct control over implementation and data management. This can be a requirement in certain industries and could potentially be less disruptive to business operations.


  • Provided by the card brands and card issuers
  • Limited business utility
  • Limited functionality

Network tokens are single-use or low-value tokens. Because they can be used only once, if you perform multiple transactions with the same credit card, you would receive a different token each time. This makes it difficult to track transactions and greatly increases the number of tokens to be created.

Some tokenization providers, such as TokenEx, offer persistent tokens, which use the same token for a given credit card number, regardless of the number of transactions performed.


  • Provided by a payment processor or payment gateway
  • Siloed data
  • Processor- or gateway-specific

Yet another option is to use the tokenization services of a third-party payment processor or the acquiring bank. Although it might seem like sticking with a processor’s tokenization service would be the simplest, most convenient option, it can often be more expensive and difficult to implement due to restrictive data-retention policies and limited deployment options.

Additionally, payment processor tokenization is often restricted to only payment information and the information being sent to that specific processor. If a company uses multiple processors, it is forced to manage multiple token sets, which can become difficult to maintain. If a company wants to switch processors, the processor will typically make it difficult to obtain the data in its original, detokenized form–or require the company to pay a fee in order to retrieve its own data.

PCI Solutions: Five Questions for Evaluating Tokenization Providers

So, if you choose tokenization as your preferred method for working toward PCI compliance, you’ll need to then determine which provider is the best fit for your organization. Here are some important things to consider when researching solutions.

How holistic is the solution? Can it address all your payment channels?

  • Does it have siloed data, processor lock-in, limited functionality?

You need to consider which channels you’re using to ingest data. Ecommerce, mobile, POS, and call centers are popular acceptance channels. You should make sure your potential tokenization provider can address the specific needs of these use cases.

How much control will you have over tokenized data?

  • Can you get your data back? What is involved in the process?
  • What is the structure, format, and functionality of the token?

Because processors commonly withhold your tokenized data or restrict the use of your tokens to only their platform, it’s important to understand how a potential provider will manage your data. In the event that you want to switch processors, it’s helpful to have a processor that will work with you, not against you.

Token functionality is also important to consider. Different organizations have different needs in terms of what portions of the original data are retained or preserved during the tokenization process. In short, the data should look and function the way you need it to.

What data types are supported?

  • Consider the PCI, personal data, PHI, and any other sensitive data elements in your environment.

Determining whether the tokens can be used to secure structured or unstructured data, payments or privacy information, etc., also is a key factor in the decision-making process. This often depends on which industry your organization is in and what its data-processing needs are.

Can the provider’s solution addess anticipated future states?

Compliance and security are not “set it and forget it” operations. Your organization, your providers, and your regulatory compliance obligations are fluid. Because they change over time, your solution needs to be flexible enough to anticipate future needs.

How well does the system scale?

  • What are its pricing models, throughput estimates, etc.?

Similar to your organization’s future states, your future pricing will likely change, too. Try to determine where your organization is headed and whether it might be wise to work with a provider that has a flexible pricing structure and platform that encourages growth and scalability.

Can the solutions integrate with your third-party services?

Integration and the ease of adding parties to your payment stream can be crucial capabilities if you work with multiple processors or service providers.

PCI Use Case for Descoping an Ecommerce Solution

Ecommerce or mail-order/telephone-order merchants who outsource all cardholder functions to validated third parties are eligible for an SAQ A or an SAQ A-EP. An SAQ A contains 22 controls, compared to the more than 300 controls for the full PCI DSS. This represents the maximum scope reduction available with cloud-based tokenization.

Qualifying for an SAQ A

  • Use a hosted iFrame or payments page provided by a validated service provider to capture and tokenize CHD
  • Do not transmit, process, or store CHD via any other acceptance channel
  • Utilize payment services of tokenization provider to process transactions
  • Maintain appropriate policies and procedures

Our goal is to tokenize as early as possible within acceptance channels to keep cardholder data from ever entering an organization’s systems. So if we can replace that card number with a token before it ever touches your environment, we’re essentially removing your environment from scope.

However, even if you outsource all cardholder data to a PCI service provider, some compliance obligations still remain. For example, if you’ve removed all sensitive cardholder data from your environment–maximizing your reduction of PCI scope–you’ve successfully exempted yourself from all technical controls, but the controls concerning people and processes (requirements 2, 8, 9, and 12) will still apply to your organization.

PCI Compliance: Cloud-Based Tokenization for Descoping

When beginning your organization’s journey to PCI compliance, you can save yourself significant time, money, and effort by pursuing a descoping solution. This efficient and effective method for compliance uses proven techniques for segmentation and data minimization to isolate sensitive data and to store only what is absolutely necessary.

Of the descoping technologies available, tokenization offers maximum scope and risk reduction by emphasizing a data-centric approach to security and compliance. It also preserves much of the business utility of the original data while minimally disrupting your existing processes. Cloud-based models in particular provide the greatest scope-reducing potential, so contact TokenEx today to learn more.