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.
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).
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).
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).
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:
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.
Systems accepted in scope PCI DSS controls include:
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:
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.
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:
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.
