The PCI-DSS (Payment Card Industry Data Security Standard) is a set of policies and procedures focused on securing payment card transactions and protecting cardholder data.
The PCI-DSS requirements are broken down into 12 specific requirements or goals which represent the minimum security features that a merchant should have in place in order to safeguard payment data.
The PCI-DSS applies to all entities that store, process or transmit payment card account data and/or those entities that could affect the security of that data.
What is PCI Scope?
The PCI requirements apply to all systems and personnel that store, process, or transmit payment card account data as well as any systems that are connected to or could affect the security of those systems.
The system components that are in scope are referred to as the “Cardholder Data Environment” or CDE. All systems that are in scope are subject to the PCI-DSS requirements as a way to limit the possibility that sensitive payment card account data is compromised. Malicious individuals and groups are constantly looking to compromise this data through the use of malware, phishing, and social engineering attacks. The type and complexity of these attacks is always changing and the PCI-DSS requirements are intended to limit the success of these attacks.
How to Reduce or Eliminate PCI Scope
The first step in any PCI-DSS assessment is to determine the scope of the assessment. The PCI-SSC has released a guide for scoping and network segmentation. This guide helps organizations to identify those systems that should be considered in scope for the PCI-DSS assessment. Understanding the proper scope with the ultimate goal of reducing scope allows the validating entity to focus on those systems directly involved with providing security for payment card account data. Systems that are not connected to and/or could not affect the security of said data are not evaluated for PCI compliance and are said to be “out of scope.”
There are many ways of reducing the PCI scope for a validating entity. This article will discuss some common examples of scope reduction techniques used in the industry today.
Understand the Flow of Cardholder Data
The first step to defining, and ultimately reducing, PCI scope is to understand how and where cardholder account data flows through the environment. How and where is cardholder account data entered, processed, and ultimately stored?
Validating entities are required to create a cardholder data flow diagram in order to capture and visualize these data flows. Cardholder data can enter a merchant’s environment through a myriad of entry points including:
- E-commerce websites
- Mail order systems
- Telephone orders (both operator assisted and IVR - Interactive Voice Response)
- Point-of-sale systems (both stationary and mobile)
- Virtual terminals
- Standalone card terminals
- Kiosks
It is also important to understand any outflows of cardholder data. Some examples where cardholder data may be flowing out of the CDE include:
- Updates to back office servers
- Data backup processes
- Data flow to the payment processor
- Any sharing of cardholder data with third parties and/or service providers
Don't Store Primary Account Numbers (PAN)
One of the most effective ways to reduce scope is to eliminate all storage of cardholder data, including the 16-digit Primary Account Number (PAN). PCI-DSS requirement 3.1 guides validating entities to keep data retention to a minimum by implementing a robust policy that limits storage and retention of said data, along with policies for identification and secure deletion.
Validating entities that do store cardholder data qualify for the most rigorous self assessment questionnaire- (SAQ D). This questionnaire is lengthy and requires the merchant to validate against all PCI-DSS requirements. Eliminating storage of cardholder data will allow a merchant to become eligible for other reduced levels of the SAQ which only speak directly to a smaller number of requirements. The depth of complexity of an SAQ D validation is much greater compared to some of the reduced SAQs (SAQ C, SAQ P2PE, etc.).
Outsource Aspects of PCI
Outsourcing certain aspects of your CDE or cardholder data flow can reduce scope and overall PCI burden for a validating entity. Common examples include Managed Firewall Services, Log Monitoring and Management, Server Hosting Facilities, and Payment Solutions offered up as Software as a Service (SaaS).
This allows validating entities to leverage the secure services provided by these third parties to meet certain PCI-DSS requirements. It is the validating entities’ responsibility to understand which PCI requirements are covered by the services provided and which remain their responsibility.
Validating entities must validate the PCI-DSS compliance of the services offered by these third party service providers and perform due diligence as required by PCI-DSS requirement 12.8. The PCI-SSC provides additional information on performing due diligence.
P2PE Implementation
The PCI-SSC lists and validates payment solutions that are certified as Point to Point Encryption (P2PE) solutions. These solutions leverage the use of a secure Point-of-Interaction (POI) device to encrypt cardholder data. The data can only be decrypted by the solution provider and at no point does either the merchant or payment solution have access to unencrypted account data, either in-transit or at-rest. Validating entities must have no access to unencrypted account data or encryption keys in order to take advantage of the scope reduction provided. These entities are eligible to complete a P2PE SAQ which provides the maximum scope reduction available.
The PCI-SSC provides guidance for use and scope reduction provided by non-listed encrypted solutions. Merchants that use encrypted solutions that are not listed as P2PE solutions should work directly with their acquiring bank to determine the scope reduction provided by those solutions.
Tokenization
Tokenization refers to the process by which Primary Account Data (PAN) is replaced with non-sensitive data with no value to an attacker if compromised. This allows a validating entity to store the token for later use in card-on-file or recurring billing solutions.
Providers of tokenization services must comply with all applicable PCI-DSS requirements around creation of the tokenized data and storage of the PAN data. Reverting tokenized data to PAN data can only occur at the service provider’s secure PCI validated systems.
Validating entities that utilize tokenization to reduce scope must ensure that tokenization is implemented correctly. They must no longer continue to collect or store PAN, they must comply with the requirements for quarterly data discovery of PAN, and they must also replace any PAN discovered with tokenized data.
Network Segmentation
Network segmentation is an effective way to reduce the scope of a PCI-DSS assessment. The storage processing and transmission of payment card data may only occur on a small number of systems within a validating entity’s internal network environment. If that environment is a flat network, meaning there is no segmentation, all systems would be in scope because they can communicate and affect the security of account data. If you can segment the network adequately, you can reduce the scope of the PCI assessment to only those systems directly involved in processing account data.
Conclusion
Understanding the proper PCI scope with the ultimate goal of reducing scope allows the validating entity to focus on those systems directly involved with providing security for payment card account data. The techniques listed above are effective ways of reducing the PCI scope for a validating entity. Contact us today to learn more.
Richard Rohena
Manager of PCI Compliance Services
