How to Define PCI DSS Scope?

1. Cardholder Data Environment

Finding where PCI DSS controls/safeguards are required and which system needs to be protected are the principal keys of success in executing PCI DSS compliance. Many organizations still have problems to figure out which systems are in PCI DSS scope and which systems are not. This guideline provides guidance to help organizations identify the systems that, at a minimum, need to be included in the scope of PCI DSS.

Before start talking about this subject, we have to be familiar with the following terms and acronyms:

CHD — Cardholder data
SAD — Sensitive authentication data
CDE — Cardholder data environment (people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data.

When we talk about PCI DSS scope, we are talking about how the PCI standard and its supplementary document: Guidance for PCI DSS Scoping and Network Segmentation, define what parts of your environment must meet the requirements stated in the PCI standard.

PCI DSS applies to all entities involved in payment car process including merchants, processors, issuers and service providers. Also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.

To make it more understandable, let’s talk about the definition of cardholder data and sensitive authentication data. Primary Account Number (PAN), cardholder name, expiration date and service code are counted as cardholder data. Full track data (Magnetic-strip data or equivalent on a chip), CAV2/CVC2/CVV2/CID, and Pins are counted as Sensitive Authentication data.

If any of the above information are stored, processed, transmitted or present in the CDE, they must be protected in accordance with applicable PCI DSS requirements.

The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. “System components” include network devices, servers, computing devices, and applications. For example, systems that provide security services, and virtualization components such as virtual machines, virtual switches/routers.

So any system component that stores or processes, or transmits payment card information are considered as a part of CDE. In my belief, the best way to determine your CDE is to document or map how payment information flows throughout your environment in order to determine all systems along the data flow which are subject to PCI compliance as CDE. Then you can find the connected systems aka tier two systems (explained later in this document) based on the guidelines that I introduce later in this document. “In Scope” systems are nothing but CDE Systems plus Connected-to and Security-Impacting Systems. The former is also called tier one systems and the latter is also called tier two systems in the industry. After finding the proper scope, you can start implementing PCI safeguards to ensure the data is secured in transit and/or at rest.

In addition to the systems that store or process or transmit cardholder data or sensitive authentication data, any systems that are inside the same physical or logical network are also part of the CDE. This is a very important rule. So you cannot easily exclude some systems by declaring that the systems do not store, process or transmit payment card information.

In this document I solely focus on digital systems but you need to bear in mind that when we talk about credit card storage in PCI DSS, printed or even handwritten credit card or debit card receipts, where you write or print more than the last four digits of full credit card numbers, are also in scope in addition to any type of digital media that cardholder data may be held. These digital media can be hard disk drives, flash memories, floppy disks, magnetic tapes and any kind of backup media.

In another word, if you for example record the card numbers in full (or any part of the number other than last four digits) on a piece of paper, you are responsible for store the receipts/records securely and they are subject to the same PCI security requirements as electronic cardholder data.

PCI DSS not only applicable if you store or process or transmit credit card information but also applicable if you are responsible for third parties that store or process or transmit credit card information. Let’s say you are a web hosting company that hosts a web commerce website which stores or processes or transmits cardholder data. In this case the commerce company is responsible to check your PCI compliance once a year in one of these 3 methods:

• By asking you to provide SAQ
• By asking you to provide the AOC (Completed by a Qualified Security Assessor aka QSA)
• By extending their scope and add your infrastructure and systems in their assessment!

Almost all PCI DSS security requirements/controls apply to people, processes, and technologies that interact with or could otherwise impact the security of CHD. I said “almost” because for example MFA just applies for CDE systems not the 2nd tier systems.

2. Connected-to and Security-Impacting Systems

So far we understood that PCI DSS applies to all processes, people and system components that process or transmit or store cardholder data. But PCI DSS goes further and ask us to implement almost all of its security requirements to the systems that are connected physically or logically to the CDE and those that can affect the security of cardholder data. That’s why PCI council calls them “connected-to and security-impacting systems”.

According to the latest version of supplement guidance for PCI DSS scoping, connectivity may occur over various technologies including physical, wireless and virtualized.

I strongly advise that you consult with a PCI DSS QSA or a PCI subject matter expert prior to define your PCI scope.

3. PCI DSS Scope Document

It’s important to understand that confirming that PCI DSS scope is a shared responsibility. PCI DSS provides the following direction:

At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of its PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers) to ensure they are included in PCI DSS scope.
The entity retains documentation that shows how PCI DSS scope was determined. The documentation is retained for assessor review and/or for reference during the next annual PCI DSS scope confirmation activity. For each PCI DSS assessment, the assessor is required to validate that the scope of the assessment is accurately defined and documented. [PCI DSS v3.2.1, page 10]

So assessed entity is responsible for determining PCI DSS scope in an annual basis and confirming its accuracy before each assessment. The PCI DSS QSA is responsible to confirm that the scope is defined and documented accurately. The QSA may question scoping decisions if any are not clear in the assessed entity’s documentation. If you use network segmentation, tokenization or any other technique in order to reduce the scope of the PCI DSS assessment, the QSA may verify that by conducting some kind of tests or ask some kind of reports like penetration test reports to make sure the controls are in place. For example PCI DSS requirement 11.3.46 requires an annual penetration test to ensure effective network segmentation is in place.

4. Scope Reduction

As I discussed earlier, we should think about PCI DSS scope reduction because it may help us to avoid some risks and reduce our compliance costs and complexity. Interestingly, the size of the organization generally dictates which reason is most applicable. You need to focus on PCI DSS scope reduction because it may decrease the PCI ancillary requirements like network penetration testing, application testing, licensing fees and so on. It may also help you to decrease the level of risk of handling the volume of sensitive data in your environment and the possible repercussions of breaches.

Network segmentation, tokenization, encryption, and outsourcing are some scope reducing strategies available to you. You have many other options in order to reduce the scope and exposure to PCI DSS compliance.