Many organizations have trouble understanding where PCI DSS controls should be applied and which systems should be protected. Many organizations still have trouble figuring out which systems are in scope by PCI DSS and which are not.
Debit and credit cards, which are part of the Payment Card Industry, are used in most online transactions (PCI). The Security Standards Council established the Payment Card Industry Data Security Standards (PCI DSS). Compliance with these standards is a self-regulated industry process.
See Also: How is the PCI Network Segmentation Affecting the PCI Scope
The PCI DSS standard applies to all entities involved in the payment card process, including merchants, processors, issuers, and service providers.
While not a legal requirement, compliance with the PCI standard is essential, and PCI compliance is critical for many customers and end-users. One of the most critical tools to ensure a fully compliant PCI process is PCI scoping.
The PCI DSS scope of a business or organization includes all people, processes, and technologies that can affect and interact with cardholder data security. Therefore, a proper understanding of your PCI scope will help you increase your payment security.
At least once a year, organizations should double-check the scope of the PCI DSS by identifying all locations and cardholder data flows and any systems that rely on or may affect the cardholder data environment (CDE).
What is “PCI DSS Scope”?
PCI Scope is the part of your environment that must meet the 12 requirements outlined in the PCI Data Security Standard (DSS). PCI scope combines people, processes, and technologies that interact with or otherwise affect cardholder data security (CHD).
See Also: How to Reduce the PCI Scope for Easier Compliance
Companies that store, process, or transmit payment card data are in scope for PCI Compliance. In addition, any system component that stores, processes, or transmits payment card information is considered part of the cardholder data environment (CDE).
All businesses participating in the payment process, including merchants, processors, issuers, and service providers, are subject to the PCI DSS security requirements. All PCI DSS-compliant system components must be included in or connected to the cardholder data environment. People, procedures, and technology store, process, or transport cardholder data or sensitive authentication data make up the cardholder data environment (CDE).
See Also: Scoping and Segmentation for PCI DSS
The PCI Council (PCI SSC) defines scoping as a method for identifying all system components, people, and procedures evaluated under the PCI DSS. The first step in a PCI DSS audit is to establish the scope of the audit appropriately.
All in-scope systems, that is, systems that interact with or affect cardholder data or systems containing it should be evaluated for their compliance with these security standards. By examining how cardholder data flows through a particular organization, you can determine the appropriate scope of protection.
The areas and systems where customer data is stored are called cardholder data environments (CDE). PCI DSS compliance is required for any system that is part of your CDE. You must adhere to about 300 standards of the PCI DSS. As a result, knowing whether company’s PCI in-scope systems and components is crucial.
Some systems may leave cardholder data unsafe if the scope is not broad enough, increasing the likelihood of a security breach and a significant data problem. On the other hand, excessive security restrictions might result in additional expenditures and unfriendly systems, limiting a company’s capacity to operate its operations regularly.
When evaluating a company for PCI DSS compliance, keep the following terms in mind:
- In-scope: In-scope systems directly relate to, affect, or connect to cardholder data and security.
- Out of scope: Out-of-scope systems indicate systems that do not have access to the cardholder data environment.
- Connected: Connected systems refer to systems linked to the CDE without being directly involved in processing a transaction and card details.
It should be emphasized that PCI DSS applies to all business partners, firms that provide remote support services, and other service providers who rely on the cardholder data environment (CDE) or are at risk of possibly compromising an organization’s CDE.
Suppose an organization outsources in-scope functions or facilities or uses a third-party service that affects how it meets PCI DSS requirements. In that case, the organization must work with the third party to ensure that the functional aspects of the service are complete, and those functions and facilities are also in-scope by PCI DSS.
According to the PCI DSS standard, “System components” include network devices, servers, computing devices, and applications. Just because a system component is in-scope does not mean that all PCI DSS requirements apply to it. The PCI DSS requirements that apply are determined by the function or location of the system component.
PCI describes how system components can be categorized using three types of system categories and how scope applies to them, and these categories are hierarchical.
- CDE Systems
- CDE systems are in-scope by PCI DSS.
- CDE systems should be evaluated against all PCI DSS requirements to determine the viability of each requirement.
- Controls for PCI in-scope systems should be validated at least annually.
- Connected or Security Affecting Systems
- Connected or security-impacting systems are in-scope by PCI DSS.
- Even if a connection is restricted to specific ports or services on particular systems, PCI inspects these systems to ensure that adequate security controls are in place.
- Requirements should be evaluated against all PCI DSS requirements to determine applicability.
- It should not provide an access path between CDE systems and out-of-scope systems.
- Out of Scope Systems
- Out-of-scope systems are not in-scope by PCI DSS. Therefore, it is not necessary to implement PCI DSS controls.
- Out-of-scope systems do not have access to any CDE components. If there is any access, the component is within the scope of PCI.
- Out-of-scope systems are considered “untrusted systems” because there is no assurance that they are adequately secured.
- If the out-of-scope system is on the same network, subnet, VLAN, or otherwise connected to a connected or security-impacting system, controls should be in place to prevent it from getting access to the CDE.
- Excluded systems are not in-scope by PCI DSS but can still pose a risk to the CDE if they are not secured.
- It is strongly recommended to apply security best practices for all out-of-scope systems and networks.
When Are Systems Considered In-Scope?
Systems accepted in scope PCI DSS controls include:
- PCI DSS applies to systems that store, process or transmit cardholder data (CHD) or sensitive authentication data (SAD).
- Systems that do not themselves store, process, or transmit CHD, but are networked or otherwise connected to systems that do, are in-scope by PCI DSS.
- Connected systems or components that affect the CDE or its security are considered in scope.
- Businesses can use systems connected to the CDE to decrease their vulnerability to PCI DSS obligations and potential security breaches to the greatest extent practicable. Systems connected to the CDE can do any of the following:
- They can connect to or access the CDE directly or indirectly through a jump server.
- They can affect the security or configuration of the CDE, such as a name server that provides DNS resolution for the CDE.
- They can provide security services to the CDE, such as an authentication server such as Active Directory.
- They can support the requirements of PCI DSS, such as audit log servers.
- They can provide segmentation that distinguishes CDE from out-of-scope systems.
When Are Systems Considered Out of Scope?
Out-of-scope systems should be prevented from accessing cardholder data or affecting the security of these components or systems. To be considered out of scope, each element, software, person, or network domain must not process, store or transmit cardholder data.
Non-PCI systems must be physically or technologically separated from parts of the network that process sensitive data, and this separation must be complete and insurmountable.
Out-of-scope systems must, in particular, meet all of the following requirements:
- Excluded components must not store, process, or transmit CHD or SAD.
- Out-of-scope components must not share a network segment, subnet, or VLAN with systems that store, process, or transmit CHD or SAD.
- Out-of-scope components must not be able to connect to or access any part of the CDE.
- Excluded components must not access the CDE through an in-scope system or affect any security controls for the CDE.
- They must not meet any of the interconnected, security-related, or in-scope systems or system components criteria.
How to Perform a PCI Scope Practice?
The PCI Security Standards Council’s (SSC) supplementary guidance for scoping and network segmentation states that reviewing the following key activities will ensure proper PCI scope as the first step in a PCI DSS assessment.
- Identify how and where you obtain cardholder data (CHD).
- Identify all payment channels and methods of accepting CHD, from the point of receipt of the CHD to the point of destruction or transfer.
- Find out where account data is stored, processed, and transported, and make a note of it.
- Document all CHD flows to identify the individuals, processes, and technologies involved in storing, processing, or transferring CHD. The CDE includes all of these people, processes, and technologies.
- Within the scope of PCI, identify all other system components, processes, and employees.
- Identify all processes, system components, technical and commercial, and personnel capable of interacting with or affecting the CDE. These people, processes, and technologies are all within the scope of PCI because they have a link to the CDE or could otherwise affect the security of CHD.
- Implement controls to minimize PCI scope.
- Limit communication between the CDE and other PCI in-scope systems to what is necessary.
- Implement controls to separate the CDE from people, processes, and technologies that do not need to interact with or affect the CDE.
- Follow all applicable PCI DSS requirements.
- Identify and enforce PCI DSS requirements that apply to in-scope system components, processes, and personnel.
- Regularly verify that PCI DSS is complied with and that information is secure.
- Implement processes to ensure that PCI DSS controls remain effective day-to-day.
- Ensure that the people, processes, and technologies included in the scope are accurately defined when making changes.
What Are PCI DSS Scoping Considerations?
There are some special considerations to ensure an organization’s PCI scope is understood correctly. PCI SSC states that using separate VLANs or network segments does not automatically reduce scope. Instead, segmentation must be purposefully and effectively structured to ensure proper separation of the CDE.
Any company that receives payments must reassess PCI scope at least annually. During this scoping review, all cardholder data flows must be redefined, along with any systems that connect to or potentially compromise the CDE.
During a PCI audit, the documentation used in the scoping process should be kept to demonstrate completeness and correctness. Evaluators verifying PCI DSS compliance are responsible for adequately providing the PCI scope definition for any component.
Network segmentation should be subjected to an annual penetration test as part of this process. Because the rules for effective network segmentation are subject to change, make sure your PCI infrastructure is ready to endure periodic audits.
You can use a variety of approaches to achieve and maintain PCI-compliant network segmentation. Physical controls can isolate CDE systems from out-of-scope components and systems through installation on physically separate servers, firewalls, and devices. It is impossible to violate physical segmentation in this way, as there is no logical or direct link.
Likewise, logical controls can be used for effective partitioning using firewalls, routers with strong access control instructions, and other methods to restrict access to a network segment. This type of segmentation should be tested regularly to ensure it remains intact.
Network segmentation can be done in two ways, but it should be noted that some segmentation processes can involve both aspects:
- By physically blocking a networked connection between systems not part of the cardholder data environment (CDE).
- Logically use firewalls and other technological security systems.
You can help avoid many forms of attacks, including those originating from less secure systems, by following appropriate security rules on a company’s network and firewalling off the in-scope areas.
As a rule, unless a system needs to process credit card or other customer data, it should not touch it. Users’ computers on a network must be securely out of range, protect companies from excessive security procedures that can interfere with day-to-day operations, and protect customers’ data from a catastrophic breach.
Computers and other devices can communicate through shared networks using Ethernet, Wi-Fi, Bluetooth, or direct connections like FTP or SSH. As a result, any networked organization may discover that its devices are included in the scope.
While PCI standards explicitly reject the notion that public networks such as the internet can be considered the scope for any business, many of the most severe risks to cardholder data come from unauthorized access and attacks from the public domain.
Standard network partitioning methods that reduce the number of in-scope applications and network nodes include firewalls that limit connections to CDE systems, cut off connections between out-of-scope and in-scope devices, or complete separation of networks. When cardholder data is partitioned only logically, this is a less secure choice than physical partitioning.
Businesses may store cardholder data on their servers in some instances. This keeps them within the scope of PCI DSS compliance. By choosing a cloud or hosted storage format, along with high-level encryption and tokenization, servers and any software products that enable operations can be isolated from the need for in-scope processing. Using PCI-DSS certified service providers helps reduce the scope and complexity of the assessment.
Credit card terminals, point-of-sale systems, payment gateways, online payment systems, and customer management software with payment data on file are examples of apps that can obtain cardholder data directly.
Any component interacting with cardholder data must adhere to a high-security requirement to protect customer data and return it to a solution provider. Point-to-point encryption (P2PE) and tokenization can significantly reduce a business’s PCI DSS compliance needs.
A solid understanding of PCI scope can ensure the protection and safety of your customers. It can put your customers at ease when you have a PCI-compliant system that excludes their servers.
You can refer to the “PCI DSS Scoping and Segmentation” guidance published by PCI SSC for detailed information.
