How to reduce your PCI scope

We’ll start by defining a few key concepts:

• CHD – Cardholder data i.e. the 16 digit number on a card.
• SAD – Sensitive authentication data i.e. PIN, CVV/CVC/CSC/CAV/CID numbers.
• Account Data – Cardholder data and/or sensitive authentication data
• CDE – Cardholder data environment. The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.

The Cardholder Data Environment

The CDE is the most important concept when it comes to scoping your environment.
“An organization’s CDE is only the starting point to determine the overall PCI DSS scope. Accurate PCI DSS scoping involves critically evaluating the CDE and CHD flows, as well as all connected-to and supporting system components, to determine the necessary coverage for PCI DSS requirements. .” Source: https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf

There are three categories your systems could fall into:

• CDE Systems – Systems processing, storing or transmitting CHD/SAD or systems on the same network as those devices. In scope for applicable requirements.
• Connected-to/Security-impacting – Systems that can connect to the CDE or could impact the security of the CDE. In scope for applicable requirements.
• Out-of-scope systems – Systems that don’t match any of the criteria of the first 2 categories. Not in scope.

The PCI SSC provides the following flowchart in the Scoping and Segmentation Guideline to help you categorize your assets.

That second box in CDE Systems is really something! If you have one computer processing cards on a flat network (no segmentation), that one computer has just dragged all other systems on the network into scope for PCI! You may often hear people refer to these machines as infectious. Conversely, systems in our Connected-to/Security-impacting category are not infectious. This means we can have a shared services environment providing support to both PCI and non-PCI systems and worry less about them bringing other systems into scope.

Reducing Your Scope – Segmentation

Let’s take a look at an example of scoping in a call centre environment that has not undergone any scope reducing measures.

In this organisation, customers call to an agent who processes cardholder data on their workstation. The carrier network is out of scope, as we have no control over that network, but all systems downstream are in scope because card data is being transmitted over the VOIP phones lines, processed on the workstation, stored in the form of call recordings in the call recorder server. We have now dragged the Finance / HR and probably many other departments into scope of our PCI assessment.

Now for some businesses, this may not be too much of a problem. PCI is a great descriptive security standard that if applied throughout the whole organisation should uplift your overall security posture. But, for a lot of businesses the cost of complying to PCI may become prohibitively expensive, especially if it is being applied on systems that could potentially be removed from scope.

A common practice is to segment your card processing systems away from the rest of your systems. Let’s say we only had a few cards being processed each day and could limit card processing to a few staff on a segmented network. Let’s take a look at what our call centre environment scope could look like.

We still have to apply controls to our CDE, but now our main corporate network is out of scope. We can now concentrate on securing a smaller environment at less cost and resource usage than if the whole network was in scope. Ok, this is good, but what if it could be better? What if we could get rid of our CDE altogether? Let’s take a look at another option we have here.

Reducing Your Scope – Outsourcing

In call centre environments we could outsource our CDE by using technical solutions such as an IVR or DTMF masking. These technologies intercept the tones sent when someone enters the card number on their phone and sends the data to a payment gateway for processing. Now no cardholder data touches our environment and we don’t have a CDE to protect! We are not completely out of the woods by implementing this system, we still need to comply, we have to make sure the third party we are using is a trustworthy Service Provider and have an Incident Response Plan in place in case something went wrong. By using this setup our efforts to meet compliance just became a lot easier and our risk of losing card data has dropped.

Outsourcing can also be achieved in other environments. For ecommerce sites, you could use an iframe or redirected payment page to reduce your scope and in brick and mortar stores you could use an E2EE or P2PE payment solutions. Talk to your bank or a QSA to see if any of these solutions make sense in your environment.

Key takeaways

• You must understand where your CDE is and what assets are your Connected-to/Security-impacting systems.
• You should read the full Scoping and Segmentation Guidelines and probably talk to a QSA before making any big decisions on network and process design.
• You can limit your scope by segmenting systems that do not touch card data away from those that do.
• There are options to outsource card processing that you should consider to reduce scope.