PCI DSS Knowledge Hub – Compliance Resources & Best Practices | Q.V. LLC

December 8, 2023
PCI-DSS ESSENTIALS, TERMINOLOGY CLARIFICATIONS

The PCI-DSS uses certain abbreviations and terms that are important to clarify before moving further. These can be related to data, networks, systems, and other elements.

Key terms in the PCI-DSS documentation include:

• The CDE, or Card Data Environment. This is the set of networks and systems where cardholder data (CHD) is stored or transmitted, as opposed to the non-CDE. For example, you have 2 WiFi networks. Only one is used for payments. That one is in the CDE. The other isn’t.
• CHD, or Cardholder Data. This is account numbers, expiration dates, and other card data. CHD must be secured in storage and transit.

In terms of CHD, it’s important to go deeper and clarify what is the type of cardholder data that can be stored. There are usually two categories of data in a credit/debit card:

• CHD is the data usually on the front of the card:
  • The full card number (known as the PAN, or Primary Account Number)
  • The expiration date
  • The cardholder name, tier, other elements
• SAD (Sensitive Authentication Data) is usually the data on the back of the card:
  • The 3-digit card security number (CVV, CVV2, etc)
  • The magnetic stripe (or PIN)
  • SAD cannot be stored at all under PCI-DSS

This was a brief review of the subject, let us dive into PCI DSS v4 and see what the standards stipulate.

PCI DSS is intended for all entities that:

• store,
• process, or
• transmit cardholder data (CHD) and/or sensitive authentication data (SAD),
• or could impact the security of the cardholder data environment (CDE).

This includes all entities involved in payment card account processing — including merchants, processors, acquirers, issuers and other service providers.

Defining Account Data, Cardholder Data, and Sensitive Authentication Data

Cardholder data and sensitive authentication data are considered account data and are defined as follows:

• Cardholder Data includes:
  • Primary Account Number (PAN)
  • Cardholder Name
  • Expiration Date
  • Service Code
• Sensitive Authentication Data includes:
  • Full track data (magnetic-stripe data or equivalent on a chip)
  • Card verification code
  • PINs/PIN blocks

If an entity stores, processes, or transmits PAN, then a CDE exists to which PCI DSS requirements will apply. Some requirements may not be applicable, for example if the entity does not store PAN, then the requirements relating to the protection of stored PAN in Requirement 3 will not be applicable.

Even if an entity does not store, process, or transmit PAN, some PCI DSS requirements may still apply. Consider the following:

• If the entity stores SAD, requirements specifically related to SAD storage in Requirement 3 will be applicable.
• If the entity engages third-party service providers to store, process or transmit PAN on its behalf, requirements related to the management of service providers in Requirement 12 will be applicable.
• If the entity can impact the security of a CDE because the security of an entity’s infrastructure can affect how cardholder data is processed (e.g., via a web server that controls the generation of a payment form), some requirements will be applicable.
• If cardholder data is only present on physical media (e.g., paper), requirements relating to the security and disposal of physical media in Requirement 9 will be applicable.
• Requirements related to an incident response plan are applicable to all entities.

Use of Account Data, SAD, CHD, and PAN

It is important to note that each of these types of data is different and the terms are not interchangeable. Specific references within requirements to account data, CHD, or SAD are purposeful, and the requirements apply specifically to the type of data that is referenced.

You can read more about scoping and CDE: LinkedIn article

Elements of Account Data and Storage Requirements

This table identifies the elements of CHD and SAD, whether storage is permitted or prohibited, and whether unreadability (e.g., via strong cryptography) is required. If PAN is stored with other elements of CHD, only the PAN must be rendered unreadable according to Requirement 3.5.1.

SAD must not be stored after authorization, even if encrypted. This applies even to environments where there is no PAN present.

Scope of PCI DSS Requirements

PCI DSS requirements apply to:

• The CDE — systems, people, processes that store/process/transmit CHD/SAD, or have connectivity to such systems
• Systems, people, and processes that could impact the CDE’s security

Examples of system components include:

• Systems that store/process/transmit account data (e.g., POS terminals, payment gateways)
• Security systems (e.g., SIEMs, access control servers, anti-malware)
• Segmentation infrastructure
• Web redirection servers
• Virtual machines, containers, hypervisors
• Cloud infrastructure, private/public
• Switches, routers, firewalls, VoIP devices
• Servers (web, database, DNS, NTP)
• Workstations, tablets, mobile devices
• Printers and multifunction devices
• Applications (including SaaS, custom apps)
• CI/CD systems and code deployment tools

Encrypted Cardholder Data and PCI DSS Scope

Encryption alone does not exclude data from PCI DSS scope. The following are still in-scope:

• Systems that encrypt/decrypt data or manage encryption keys
• Systems containing both encrypted data and keys
• Systems that can access encrypted CHD and keys

PCI DSS v4 Requirements (Summary)

• 3.2: Storage of account data is minimized
• 3.3: SAD not stored after authorization
• 3.4: Access to PAN is restricted/masked
• 3.5: PAN is rendered unreadable via strong cryptography
• 3.6: Cryptographic keys are secured
• 4.2: PAN is protected during transmission (TLS, etc.)

Conclusion: Ensuring Cardholder Data Security

A meticulous understanding of PCI DSS Requirements 3 and 4 is crucial for securing CHD. From encryption to scoping and system classification, the standard lays out a comprehensive framework for protection. Compliance is essential not only for meeting requirements but for preserving trust and security across the payment ecosystem.