PCI DSS Compliance: Navigating the Scope without Confusion

The PCI DSS (Payment Card Industry Data Security Standard) is a global security standard that outlines 12 security requirements for:

a) merchants handling payment transactions (including both retail and online e-commerce) and
b) service providers.

The essence of the standard is to protect cardholder data (card number, card expiration date, cardholder’s full name, PIN/CVV). However, the practice of PCI DSS is focused on protecting cardholder data, primarily:

a) the full credit card number (all 16 or more digits),
b) authorization data (PIN, magnetic stripe, and/or CVV/CVC code).

In cases where an organization processes either incomplete data (e.g., in the form of 5543 – 21** – **** – 1234 or **** – **** – **** – 1234) or uses payment tokens or encrypted data (without having access to decryption keys)—such organizations are often outside the scope of PCI DSS certification (see FAQ for details).

Establishing the scope of certification is the initial step that each organization seeking PCI DSS certification must undertake. The certification scope is understood to encompass:

a) Technologies (Product),
b) Personnel (People),
c) Vendors (Partners),
d) Management Processes (Process),

which transmit, process, or store full card numbers or have access to these components, or could impact the security of cardholder data. In accordance with Requirement 12.5.2 of the PCI DSS v4.0 standard, the scope must be documented and at a minimum, it should be reviewed and updated annually.

Determining the scope of PCI DSS certification is the initial and most challenging step in approaching PCI DSS certification. The method described below has been successfully employed by us for over 15 years, and it is based on a document from 2012 (PCI DSS Scoping toolkit).

Step 1 – Let’s identify the business processes designed to process, transmit, or store cardholder data. It is crucial to distinguish between processes where access to cardholder data is intentional (e.g., a website processing online payments) and those where card numbers may appear incidentally (e.g., email systems) – usually, these systems are not within the scope of PCI DSS certification.

Step 2 – We are introducing three categories of devices and assigning a category to each device that supports business processes outlined in Step 1:

Category 1
These are systems, network devices, cloud components, and workstations that transmit, store, or process cardholder data in clear text. These are typically database servers, application servers, routers, switches, firewall and/or WAF devices, or other business applications, workstations of users working with these applications, etc.
Within Category 1, there are also devices that do not have access to cardholder data but are not segregated from it (e.g., through segmentation). These are designated as Category 1a devices (devices “contaminated” with cardholder data). While segmentation is not a requirement of PCI DSS, it is usually recommended to limit the scope and thus the costs of obtaining and maintaining PCI DSS certification. Category 1 devices constitute the so-called Cardholder Data Environment (CDE).

Category 2
These are systems, network devices, cloud components, and workstations that do not have access to cardholder data, are segregated from Category 1 devices (e.g., located in a different VLAN), but are responsible for their security. These are typically various types of “management” devices – administrative workstations, time servers, authorization servers (e.g., Active Directory), network scanning stations, logging systems, etc.

Category 3
These are systems, network devices, cloud components, and workstations that do not have access to cardholder data, are network-separated from them, and a breach of their security does not result in a compromise of the security of Category 1 devices. These are usually devices effectively isolated from the cardholder environment – for example, workstations connected to the same domain controller.

Step 3 – having established our IT and business environments, we now add the remaining elements of the 4 P’s, which are:

a) Vendors who have access to our card processing environment or with whom we can share cardholder data either directly or indirectly. Indirect sharing of cardholder data, for example, includes hosting or managing physical security – such providers do not have direct access to cardholder data, but they can impact the cardholder data.

b) Personnel who manage certain components, create, test, and deploy code. This also applies to employees or associates who handle payments, manage HR processes, vendor relations, and information security. The PCI DSS standard does not require dedicated teams to manage the Cardholder Data Environment (CDE).

c) Management processes – such as change management, risk management, vulnerability management, software development processes, and many others.

Should you have any questions regarding the scope of your certification, or if you’re unsure how to narrow it down, please do not hesitate to Contact us. With over 15 years of experience working with the PCI DSS standard, we are confident we can find a solution for your specific issue.