How to define PCI DSS Scope?

When it comes to scoping for PCI DSS, many organizations struggle to understand where PCI DSS controls are required to be implemented and which systems need to be protected. Many organizations still have problems figuring out which systems are in PCI DSS scope and which systems are not. PCI DSS applies to all entities involved in the payment card process including merchants, processors, issuers and service providers. “At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their 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 the PCI DSS scope.” - [PCI DSS v3.2.1, page 10]

What is “PCI scope?”

PCI Scope is nothing but part of your environment that must meet the 12 requirements stated within the PCI Data Security Standard (DSS). The scope is a combination of people, processes, and technologies that interact with or could otherwise impact the security of cardholder data (CHD).

Internal systems and networks

Whatever assets store, process, or transmit payment card data are “in scope” for PCI Compliance. any system component that stores or processes or transmits payment card information are considered as a part of CDE. The PCI DSS security requirements apply to all entities involved in the payment car process including merchants, processors, issuers, and service providers. It applied to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data.

Service Providers and other Third Parties

All business partners, entities providing remote support services, and other service providers connected to cardholder data environment (CDE) or may have risk of potentially compromise an entity’s CDE are also considered in PCI DSS scope. If an entity outsources in-scope functions or facilities to a third party, or utilizes a third-party service that impacts how it meets PCI DSS requirements, the entity will need to work with the third party to ensure the applicable aspects of the service are included in scope for PCI DSS.

How to do PCI Scoping exercise?

In December, 2016, the PCI Security Standards Council (SSC) released a supplemental guide for scoping and network segmentation. Accurate scoping involves critically evaluating the CDE and connected-to system components to determine the necessary coverage for PCI DSS requirements. It has provided following important activities as a first step of a PCI DSS assessment is to accurately determine the scope of the review.

Activity	Description
Identify how and where the organization receives cardholder data (CHD)	1. Identify all payment channels and methods for accepting CHD, from the point where the CHD is received through to the point of destruction, disposal or transfer.
Locate and document where account data is stored, processed, and transmitted	2. Document all CHD flows, and identify the people, processes, and technologies involved in storing, processing, and/or transmitting of CHD. These people, processes, and technologies are all part of the CDE.
Identify all other system components, processes, and personnel that are in scope.	3. Identify all processes (both business and technical), system components, and personnel with the ability to interact with or influence the CDE (as identified in 2, above). These people, processes, and technologies are all in scope, as they have connectivity to the CDE or could otherwise impact the security of CHD.
Implement controls to minimize scope to necessary components, processes, and personnel.	4. Implement controls to limit connectivity between CDE and other in-scope systems to only that which is necessary. 5.Implement controls to segment the CDE from people, processes, and technologies that do not need to interact with or influence the CDE.
Implement all applicable PCI DSS requirements.	5. Identify and implement PCI DSS requirements as applicable to the in-scope system components, processes, and personnel.
Maintain and monitor.	6. Implement processes to ensure PCI DSS controls remain effective day after day. 8.Ensure the people, processes, and technologies included in scope are accurately identified when changes are made

As per PCI DSS standard, “System components” include network devices, servers, computing devices, and applications. A system component being in scope does not mean that all PCI DSS requirements apply to it. The applicable PCI DSS requirements depend on the function and/or location of the system component. The information supplement explain how system components can be categorized using three system category type and how scope applies to them. These categories are hierarchical.

• CDE Systems
  • These are in scope for PCI DSS.
  • These must be evaluated against all PCI DSS requirements to determine the applicability of each requirement.
• Connected-to and/or Security-Impacting Systems
  • Are in scope for PCI DSS. Even where a connection is limited to specific ports or services on specific systems, those systems are included in scope to verify that the applicable security controls are in place.
  • Must be evaluated against all PCI DSS requirements to determine the applicability of each requirement.
  • Must not provide an access path between CDE systems and out-of-scope systems.
• Out-of-scope Systems
  • Are not in scope for PCI DSS; therefore, PCI DSS controls are not required.
  • Have no access to any CDE system; if there is any access, then system is in scope.
  • Are considered untrusted (or “public”)—there is no assurance they have been properly secured.
  • If on the same network(or subnet or VLAN)as, or otherwise has connectivity to, a connected-to or security impacting system, controls must be in place to prevent the out-of-scope system from gaining access to the CDE via the in-scope systems. These controls must be validated at least annually.
  • Note: These systems are not in scope for PCI DSS but could still represent a risk to the CDE if not secured. It is strongly recommended that security best practices be implemented for all out-of-scope systems/networks.

How can I reduce PCI DSS scope?

1. If you do not need it, do not store it!

Do not store cardholder data unless it is absolutely necessary. Running cardholder data discovery tool help you find PANs, processes, and flows you did not know existed. That way, you discover systems which are storing card data whereas they are not supposed to. In such cases, you delete the card data and ensure that the system will never store card data.

2. Network segmentation

Network segmentation is a method of separating systems that store, process, or transmit cardholder data from those that do not. The adequacy of a specific implementation of network segmentation is highly variable and dependent upon several factors, such as a given network's configuration, the technologies deployed, and other controls that may be implemented. It is strongly recommended as a method that may reduce:

• The scope of the PCI DSS assessment
• The cost of the PCI DSS assessment
• The cost and difficulty of implementing and maintaining PCI DSS controls
• The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations)

While segmentation may help reduce the number of exposure points to the cardholder data environment (CDE), it is not a silver bullet; implementing segmentation is no replacement for a holistic approach to securing an organization’s infrastructure.

3. Tokenization 

Tokenization is the process of converting sensitive data into non-sensitive data, (called tokens). It completely replaces the PAN in your environment so you can store tokens in your database which is not considered as cardholder data. Once data is tokenized it can flow through your environment without bringing any of those devices that store, process, or transmit the token into scope for PCI compliance requirements.

4. Using a PCI-listed P2PE Solution

Point to Point Encryption 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. These entities are eligible to complete a P2PE SAQ which provides the maximum scope reduction available.

5. Outsourcing to a third-party service provider

If correctly done, outsourcing certain aspects of your CDE or cardholder data flow can reduce the scope and overall PCI burden for an 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). When an entity outsources in-scope functions or facilities to a third party or utilizes a third-party service that impacts how it meets PCI DSS requirements, the entity will need to work with the third party to ensure the applicable aspects of the service are included in scope for PCI DSS—either for the entity or the service provider. It is also important for both parties to clearly understand which PCI DSS requirements are being provided by the service provider and which are the responsibility of the entity using the service. The details provided in this blog can be used by both large and small entities to reduce PCI DSS scope. To discuss your specific PCI DSS Audit requirements or other security services, contact us here.