If you’re a merchant accepting credit card payments, you’ll have to familiarise yourself with a whole list of terms that appear in the Payment Card Industry Data Security Standard (PCI DSS). From SAQs and ROCs, to QSAs and everything in between, anyone on the journey towards achieving or maintaining PCI DSS compliance knows that there is no shortage of acronyms that often leave both beginners and veterans scratching their heads as to what their definitions could be. However, one of the most basic ideas that also serves as a great starting point for newcomers to wrap their heads around is the concept of cardholder data (CD).
What Is Cardholder Data?
Margaret Rouse puts it most simply in her definition on SearchSecurity: “Cardholder data (CD) is any personally identifiable information (PII) associated with a person who has a credit or debit card.”
The PCI Security Standards Council (PCI SSC), the body that administers the PCI DSS, is a bit more specific in their official definition, citing, “At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiry date and/or service code [found on the magnetic stripe]. Sensitive Authentication Data are additional data elements that may be transmitted or processed (but not stored) as part of a payment transaction.”
To further clarify these additional terms, the PCI SSC defines them in their official Glossary as follows:
PAN – Acronym for “primary account number” and also referred to as “account number.” Unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account.
Service Code – Three-digit or four-digit value in the magnetic-stripe that follows the expiry date of the payment card on the track data. It is used for various things such as defining service attributes, differentiating between international and national interchange, or identifying usage restrictions.
Magnetic Stripe Data – Also referred to as “full track data” or “track data.” Data encoded in the magnetic stripe or chip used for authentication and/or authorisation during payment transactions. This can be the magnetic-stripe image on a chip or the data on the track 1 and/or track 2 portion of the magnetic stripe.
Sensitive Authentication Data – Security-related information (including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs, and PIN blocks) used to authenticate cardholders and/or authorise payment card transactions.
Card Verification Code – Also known as Card Validation Code or Value, or Card Security Code. This refers to either: (1) magnetic-stripe data, or (2) printed security features.
PIN – Acronym for “personal identification number.” Secret numeric password known only to the user and a system to authenticate the user to the system. The user is only granted access if the PIN they provide matches the PIN in the system. Typical PINs are used for automated teller machines (ATMs) for cash advance transactions. Another type of PIN is one used in EMV chip cards where the PIN replaces the cardholder’s signature.
All these elements constitute cardholder data, and therefore fall under the jurisdiction of the PCI DSS.
Common Misconceptions About Cardholder Data
There are several misconceptions among merchants about what constitutes data. Primarily, many believe that cardholder data only includes the PAN and CVC, but as the PCI SSC points out, it includes any combination of the aforementioned elements.
In addition, as Matt Crane points out in his article over at CompliancePoint, “A common misconception is that all of these elements must be encrypted when stored. Only the PAN has to be encrypted when at rest. On the other hand, sensitive authentication data can never be stored, unless for the purposes of issuing cards.”
The distinction that Crane makes is a very important point and forms a crux for meeting PCI DSS compliance obligations.
How Cardholder Data Factors into PCI DSS Compliance
The purpose of the PCI DSS is to protect cardholder data at all times, so naturally, Requirement 3 is “Protect cardholder data,” and all of its subrequirements dictate how merchants must handle that data.
As Crane points out, subrerequirement 3.4 states, “Render PAN unreadable anywhere it is stored – including on portable digital media, backup media, in logs, and data received from or stored by wireless networks. Technology solutions for this requirement may include strong one-way hash functions of the entire PAN, truncation, index tokens with securely stored pads, or strong cryptography.” At the same time, subrequirement 3.2 reads, “Do not store sensitive authentication data after authorisation (even if it is encrypted). Issuers and related entities may store sensitive authentication data if there is a business justification, and the data is stored securely.”
It’s important to note that in its guide titled PCI Data Storage Do’s and Don’ts, the PCI SSC highlights an significant distinction: “Requirement 3 of the Payment Card Industry’s Data Security Standard (PCI DSS) is to ‘protect stored cardholder data.’ The public assumes merchants and financial institutions will protect data on payment cards to thwart theft and prevent unauthorised use. But merchants should take note: Requirement 3 applies only if cardholder data is stored. Merchants who do not store any cardholder data automatically provide stronger protection by having eliminated a key target for data thieves.”
For the purposes of PCI DSS compliance, the PCI SSC makes it very clear: at the end of the day, merchants should do their best to minimise the storage of cardholder data as much as possible, and when they do, they must take proper precautions to protect it.
What is the Cardholder Data Environment?
When working towards PCI DSS compliance, you’ll often hear about the cardholder data environment (CDE). The PCI SSC defines the CDE as, “The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.” This is a very broad definition by design and has sweeping consequences. The CDE encompasses anything and everything that touches cardholder data, and for that reason can make what might seem as a straightforward project from the outset into a seemingly endless sprawling and complex initiative.
For example, if your organisation operates a call or contact centre that takes payments over the telephone, your CDE might comprise of the telephone itself, the payment terminal, and a call recording system. But that’s not all. The agents themselves; any tools like a pen and paper, a cell phone, or even a wipe board, that agents could use to record cardholder data; the telephony network; the desktop computer; and even a CCTV system that might inadvertently capture visual cardholder data, are all in scope and considered part of the CDE. As you can see, the scope can spiral out of control quickly.
For this reason, many organisations use descoping technologies in order to restrict the size of their CDE and therefore significantly reduce the number of applicable PCI DSS controls they are liable to uphold. As in the example above, many companies have begun to employ DTMF masking technologies, like Semafone’s Cardprotect to keep cardholder data out of the contact centre entirely.