To become PCI DSS compliant, organizations are obligated to implement the right security measures to protect payment/cardholder holders. However, at times, it can be unclear which measure needs to be applied and in which areas. Fortunately, this confusion can be cleared by understanding the PCI DSS scope. In this article, we’ll discuss it in detail.
In 2008, Heartland, a famous payment processing service provider, fell victim to an SQL injection attack that comprised their entire payment transaction system. What was worse, this attack remained undetected for months (the attackers attacked the Heartland system in 2007 and found it in October 2008). During this period, several customers' card details were exposed to the attackers.
Why did this incident occur? It happened because Heartland failed to implement the right set of security measures and configure the application setting properly. On top of that, they didn’t maintain intrusion detection and monitoring systems properly, which further allowed the attackers to remain unnoticed in the system. These are basic security practices that PCI DSS mandates to implement, and they failed to comply. As a result, they ended up paying a $2.4 minion fine for PCI DSS non-compliance.
Now, if you don’t want to be the next victim— you need to find out which areas are prone to such attacks and implement security measures that can prevent and withstand them. And for that, you need to understand the PCI DSS scope. So, let’s dive in.
PCI DSS scope includes all your organization's processes, people, and technologies related to cardholder data or that can impact its security. The scope helps you ensure that your organization's cardholder data is protected throughout its lifecycle. Moreover, the scope applies to your internal systems, networks, service providers, and other third parties.
Internal Systems and Networks
The PCI DSS scope covers internal systems and networks that store, process, or transmit your organization's cardholder data. These can include payment applications, databases, servers, and network devices. Systems that connect to your in-scope systems, like monitoring tools or backup servers, may also fall under the scope.
Service Providers and Third Parties
In addition, the scope extends to all your service providers and third parties involved in your organization's payment processing. This involves payment gateways, cloud hosting providers, and outsourced IT services used in your organization. Further, any third party that handles the cardholder data on behalf of your organization is also a part of the PCI DSS scope.
Let’s discuss the various types of PCI DSS scope.
In-scope systems are those that can handle cardholder data. These systems can store, process, or transmit your organization’s payment information. For example, a payment gateway that processes your various credit card transactions, a database that stores your organization’s cardholder data, and more.
When are the systems considered as in-scope?
Systems are considered in-scope when they directly interact with your organization’s cardholder data. Since these data are sensitive to payment processing, they require strict security measures, such as encryption and access control, to ensure PCI DSS compliance.
Out-of-scope systems are those types of PCI DSS scope that do not interact with your organization’s cardholder data by any means. These systems are not involved in payment processing or storing your organization’s data. For example, out-of-scope systems include a company’s internal email system, a human resources management system, or a file server that doesn’t store your organization’s cardholder data.
When are the systems considered out-of-scope?
The systems are considered out-of-scope when they are fully isolated from in-scope systems. Also, these systems do not store or process your organization’s cardholder data. However, they must still be protected from unauthorized access to prevent indirect risks to cardholder data.
Connected-to-scope systems are those that are not directly involved with your organization’s cardholder data but are connected to in-scope systems. These systems can potentially impact the security of your in-scope systems.
For example, a backup server that stores copies of your organization’s transaction data, which could be connected to in-scope systems but does not directly process or store cardholder data.
When are the systems considered connected-to?
The systems are considered connected-to when they have a direct or indirect link to your in-scope systems and can also influence data security. While they are not fully in-scope, they must still meet some PCI DSS requirements, such as securing communication channels and limiting access.
The steps below define and help you understand your organization's PCI DSS scope.
This is the first step in defining your organization's PCI DSS scope. It involves identifying how and where your organization receives cardholder data.
How to find out that?
This will give you a complete picture of your cardholder data environment (CDE) and help you determine which systems are within the PCI DSS scope.
In addition, this step helps you identify risks early. For example, you might discover unsecured channels or unnecessary data storage. Addressing these issues reduces the risk of data breaches and streamlines your compliance efforts by focusing on the right systems.
After identifying how and where your organization collects cardholder data (CHD), the next step in PCI DSS scope is to find out where this data is stored, processed, and transported. This involves identifying all the locations your cardholder data flows through and documenting these pathways. This will help you define CDE and ensure compliance with PCI DSS.
But how to identify these locations?
Note: Include all transfer methods, such as APIs, encrypted file transfers, or email. List every individual, process, and technology involved in these workflows.
This step identifies all the other system components, processes, and people within the scope of PCI DSS. These include any systems, technologies, or personnel capable of interacting with or affecting the CDE in your organization. Identifying these will help you ensure that all potential risks to cardholder data (CHD) security are accounted for and addressed.
Moreover, including these systems are important because they have a direct or indirect link to the CDE. For example, a misconfigured firewall in a non-CDE system could expose the CDE to external threats.
Similarly, a third-party vendor with inadequate security practices could put your CHD at risk. Identifying these elements will help you implement appropriate controls and reduce vulnerabilities.
After identifying all in-scope people, processes, and technologies, the next step is implementing controls to minimize your PCI DSS scope. This will involve limiting the connections between cardholder data (CHD) and in-scope systems to only what is necessary for your organization.
Consider that your organization uses a shared network for different teams. Connecting your payment processing system to this network increases the risk of unauthorized access.
You can create a separate network segment for systems handling cardholder data to fix this. This will ensure that only authorized users and systems have access to your organization’s sensitive data.
You can also use firewalls to block unnecessary traffic to and from the CDE. For instance, you might restrict access to the CDE only to devices and applications that require it for their tasks. This will reduce the number of systems that fall under PCI requirements.
Thus, segmenting your network and limiting access simplifies compliance and reduces risks. It also makes audits less overwhelming for your team.
To ensure PCI compliance, you are required to identify and meet the relevant PCI DSS requirements. For this step of PCI DSS scope, you need to review your in-scope system components, processes, and personnel and ensure that each follows the necessary security measures.
For example, if your finance team handles credit card transactions, you must apply strict access control measures. Only authorized users should have access to your organization's cardholder data.
To do this, you require strong passwords, two-factor authentication, and regular monitoring of user activities. Ensuring that these access controls are followed will help prevent unauthorized access to sensitive payment information.
Moreover, you should evaluate the components of your systems. For instance, if you store, process, or transmit cardholder data, you need to protect that data with encryption. Thus, you might use technologies like SSL/TLS to do this. This ensures data is secure when transmitted between systems or across the Internet.
Note: Encrypting cardholder data during transmission over open networks is a common requirement for PCI DSS compliance.
Overall, carefully following all applicable PCI DSS requirements can significantly reduce the risk of data breaches and ensure your organization remains compliant.
Ensuring compliance is not a one-time process. It requires continuous effort, and to achieve this, you need to implement processes that will verify PCI DSS controls remain effective every day. Further, this step of the PCI DSS scope will ensure that your organization’s security measures are working as intended, even if any changes occur.
How can you do this?
Note: Also, update your documentation and keep an accurate record of any changes made.
There are a few important considerations for ensuring that your organization understands the PCI DSS scope.
Let's understand the various ways to reduce your PCI DSS scope.
Segmenting your network is one of the most effective methods to reduce PCI DSS scope. By isolating systems that handle cardholder data, you can separate them from unrelated systems.
For example, a point-of-sale system can be placed on a dedicated network segment. This ensures that non-payment systems, like HR or email servers, stay out of scope. Proper segmentation requires strong firewall rules and strict access controls.
Tokenization can replace your cardholder data with a unique, meaningless token. This will ensure that your organization's sensitive data is not stored in your systems. For example, when your team member makes a payment to purchase an app's subscription, a secure service converts the card number into a token. Since your systems don't store the real card data, they fall out of scope.
Using P2PE will help encrypt your cardholder data immediately upon capture. For example, the POS terminal encrypts and securely transmits data to the payment processor, ensuring that uncached data never passes through your network. Therefore, using P2PE can significantly restrict your organization's policies within your PCI DSS approach.
Outsourcing your organization's billing process to a PCI DSS-compliant service provider is one way to reduce PCI size. Providers, such as payment gateways, will process cardholder data on your behalf. Your systems will only contact them for any payment authorizations.
Since your infrastructure doesn't store or cannot handle cardholder data, it's extremely overwhelming. Therefore, it's important to ensure the provider maintains full PCI DSS compliance.
Once your organization's PCI DSS scope is set, implementing proper security measures becomes essential to staying compliant with PCI DSS. But how do you do it? There are several ways, such as regular audits, timely updates, security protocols, etc., to help your organization stay ahead of the threats.
One important way to stay compliant with PCI DSS is to conduct regular access reviews in your organization. These reviews will help you ensure that only authorized users have access to sensitive payment data in your organization.
However, various tools are available to streamline your access review process. One such tool is Zluri. It offers an automated access review solution that allows you to create access certifications to review users' access.
Note: Access certifications can be created for multiple apps.
Zluri provides visibility into users' access, identifying who has access to what in your organization. This helps you identify risky access and review and adjust user permissions across your organization.
Later, you can auto-remediate the risky accounts identified during the review process. This remediation includes modifying or revoking access as required.
For instance, if an employee of your “Marketing” department has access to finance-based tools like Quickbooks, this access can be revoked during the access review process. This will restrict access to your organization's payment data and protect it from risks like data breaches.
Let’s take Microsoft 365 as an example to see how you can automate access review in Zluri.
Also Read: You can review the PCI DSS Compliance Checklist to ensure it meets PCI requirements.
Network segmentation splits big networks into smaller parts to boost security and control. This allows your admin to use specific security measures, create custom security rules, and restrict who can access what.
The components of PCI DSS scope include identifying processes, people, and technologies, provided they should directly interact with or influence the security of CHD.
Look into how customer card information moves through your company to determine what needs protection. The places where you keep, handle, or send customer data are called cardholder data environments (CDE). Any system that's part of your CDE has to follow PCI DSS rules.
PCI DSS is a set of security standards that ensure the protection of your cardholder data. It covers four main areas:
Tackle all the problems caused by decentralized, ad hoc SaaS adoption and usage on just one platform.