What is PCI DSS Scope? (How to create one)

The PCI scope is a combination of identifying processes, people, and technologies that directly interact with or could otherwise influence the security of cardholder data (CHD). PCI scope states that your Cardholder Data Environment (CDE) must meet all 12 requirements within the PCI Data Security Standard (DSS). Many organizations find it hard to understand PCI DSS policies and controls and which systems should be protected. Let us understand the PCI DSS scope better and the scope of its coverage.

What is PCI scope?

PCI scope refers to all of the processes, people,  and technologies that interact with cardholder data or could impact its security. Any component that’s part of your cardholder data environment (CDE) is considered “in scope.” You have to employ more complex systems to secure and manage your CDE if you have more in-scope systems.

Before starting your PCI compliance journey, you’ll need to first lay out your business’s scope by identifying all of the system components that are connected to or included in the Cardholder Data Environment (CDE). The systems and areas where customers’ data is stored or transmitted are called cardholder data environments (CDE). These components should be secured through applicable compliances as per the PCI DSS standard.

The systems covered in scope imply that they interact with or influence cardholder data or systems containing it and must be assessed for their compliance with security standards laid down by PCI. 

Your security team can clearly identify the proper scope for protection by assessing the way cardholder data flows through a specific organization. PCI DSS has over 300 requirements, so understanding which components and systems are identified in a company’s PCI scope is critical.

When determining the overall scope, mapping out your CDE is a great place to start. 

Accurate PCI DSS scoping also necessitates understanding how cardholder data flows within the system components and environment:

Internal Systems and Networks

Whatever assets store,  transmit, or process payment card data are defined as “in scope” for PCI Compliance. All system components that store,  process, or transmit payment card information are considered a part of CDE.

The PCI DSS security requirements are applicable to all organizations involved in the payment card process, including merchants, issuers, processors, and service providers. The cardholder data environment (CDE) is comprised of processes, people, and technologies that process, store, or transmit cardholder data or sensitive authentication details.

Service Providers and Other Third Parties

All business partners and enterprises providing remote support services, as well as other service providers connected to cardholder data environment (CDE) or may be vulnerable to potentially compromising an entity’s CDE, are also covered in PCI DSS scope.

Types of PCI Scope

At the beginning of your PCI compliance journey, during the scoping exercise, you’ll need to categorize systems into three buckets: out of scope, in scope, and connected to. Let us understand the meaning of these terms below.

In-scope

Systems that are directly impacting, connected to, or involved in some manner with cardholder data and its security. These must be assessed against all PCI DSS requirements to establish the applicability of each requirement.

Out-of-scope 

Systems that have no access to the cardholder data environment; if there is any form of access, then the system is in scope. These systems are regarded as untrusted or public since there is no assurance that they have been properly secured.

If the out-of-scope system has access through the same network(or VLAN or subnet ) or otherwise has access to a connected-to or security influencing system, controls must be in place to forbid the out-of-scope system from getting access to the CDE through the in-scope systems.

Connected-to

Systems connected to the CDE but involved indirectly in processing a transaction and card details are under the scope of PCI DSS as well. Even where a connection is limited to specific services or ports on specific systems, those systems are included in the scope to establish that the applicable security controls are in place. Also, an access path between out-of-scope systems and CDE systems must not be provided.

How to create a PCI-DSS scope?

The PCI Security Standards Council (SSC), in December 2016, issued a supplemental guide for scoping and network segmentation. Accurate scoping involves determining the necessary coverage for PCI DSS requirements by critically evaluating the CDE and connected-to-system components.

As per the PCI Security Standards Council’s (SSC) supplementary guidance for scoping and network segmentation, reviewing the following key activities will warrant proper PCI scope as the initial step in a PCI DSS assessment.

Identify where and how you obtain cardholder data (CHD).

Establish all payment channels as well as methods of accepting CHD, from the point of receipt of the CHD to the point of disposal, destruction or transfer.

Record where account data is stored, processed, and transferred

Record all CHD flows to identify the processes, individuals, and technologies that are all part of the CDC and involved in processing, storing, or transferring CHD. 

Identify, within the scope of PCI, all other system components, processes, and people.

Make a note of all processes, system components, technical as well as commercial and personnel authenticated to interact with or influence 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. These technologies, people, and processes all fall within the scope of PCI because they either have a direct link to the CDE or could otherwise influence the security of CHD.

Implement controls to minimize PCI scope.

Limit communication between the CDE and other PCI in-scope systems that do not need to interact with or affect the CDE by implementing controls to separate the CDE from people, processes, and technologies.

Follow all applicable PCI DSS requirements.

Identify and administer PCI DSS requirements that apply to in-scope processes, system components, and personnel.

Regularly verify that PCI DSS is complied with and that information is secure.

Implement processes to make sure that PCI DSS controls are effective consistently.

Ensure that you accurately define the processes, people, and technologies included in the scope whenever making changes.

What is not required to be in PCI DSS scope?

Out-of-scope systems are defined as components, persons, software programs, or network areas that are prohibited from accessing cardholder data, process store or transmitting cardholder data, or affecting the security of those components or systems in any way.

In order to be considered out-of-scope of PCI DSS, each component must be segregated either technologically or physically from the parts of the network that handle sensitive data, and this partitioning must be complete and impenetrable.

Specifically, out-of-scope systems must meet the following requirements:

• Systems components must not store, transmit, or process SAD or CHD
• They must not share a network segment, VLAN, or subnet with systems that store, process, or transmit SAD or CHD
• Components must be prohibited from accessing any part of the CDE
• They must have no authentication to the CDE or influence any security controls for the CDE using an in-scope system
• They must not meet any criteria defined for security-impacting, connected-to, or in-scope systems, as well as system components.

You can help your clients improve their security while avoiding restrictive requirements by carefully keeping your software products out-of-scope, strong segmentation, and integrated access to payment providers without accessing the CHD. 

This doesn’t imply that out-of-scope software, networks, or components should feel insecure or lax about the protective measures they provide. Instead, these can be crafted carefully to provide the highest level of security without getting in touch with the vulnerable cardholder data that could expose any organization to a network breach or serious liability.

Get the PCI-DSS compliance advantage with Sprinto

For any organization that comes into contact or processes with Card Holder Data or CHD, having a PCI attestation of compliance certificate or an equivalent testimonial of PCI compliance is essential.

Becoming PCI compliant is essential to business needs, but doing so without help is not easy, especially with over a dozen security requirements and 300 rigorous security controls(as required by PCI) consuming an organization’s significant time and resources.

Sprinto puts tour PCI compliance on auto-pilot, helping cut hundreds of hours off of the compliance process, helping your organization meet all necessary operational controls and implementing security best practices.

To know more about how Sprinto can help your organization become and remain PCI compliant, get in touch with us now.

FAQs

How do I know my PCI DSS scope?

Evaluate how cardholder data flows through your organization to determine the appropriate scope of protection. The systems and areas where customer data is stored, processed or transmitted are called cardholder data environments (CDE). PCI DSS compliance is a must for any system that is part of your CDE.

What is the difference between in-scope and out-of-scope in PCI?

In-scope systems are directly connected to, influencing, or involved with cardholder data or its security, whereas out-of-scope systems have no access to the cardholder data environment or any of its networks or components.

What systems are considered in scope?

Systems that are directly influencing, connected to, or involved in some manner with cardholder data and its security aspects.

What systems are out of scope?

Systems that are prohibited from accessing the cardholder data environment or any of its networks or components directly or indirectly.