Defining Cardholder Data

Understanding the conditions under which a company is required to comply with the PCI DSS  (Payment Card Industry Data Security Standard for those of you who are neophytes to the subject) is critical to all organizations that work with payment card data.   It is not only important for those companies trying to determine whether or not they must comply with the standard, but it is also important for those companies trying to look for solutions to reduce the scope of their PCI DSS projects as well as for internal auditors and others involved in validating compliance with the standard.

It is not uncommon to hear companies, when first told of their requirement to comply with the PCI DSS to respond with: “I don’t have to comply with the PCI because I am ______ (insert here…”not a merchant,” “too small,”, “don’t support ecommerce,”, we use “EMV,” etc.).  As more than one unlucky company has found, none of these answers are accurate.  Business model alone does not determine whether a company must comply with the PCI DSS.

A quick and easy way to understand whether or not a company must comply with the PCI DS is to use the following as a guide:

Any organization (merchant, service provider, credit reporting company, backup provider, etc.) that stores, transmits, and/or processes Cardholder Data must comply with the PCI DSS. 

It is important to point out that ‘compliance’ with the standard is different from the obligation to validate compliance with the standard.  Whether or not a company is required to validate is dictated by the individual card brands (Visa, MasterCard, Discover, JCB, American Express).  Even if a company is not required to validate, they are still required to comply IF they store, transmit, or process Cardholder Data.

Some of the confusion around compliance derives from the actual PCI DSS requirements document.  On page 7 of the PCI DSS Standard it says:

“PCI DSS applies wherever account data is stored, transmitted, or processed.  Account data consists of Cardholder Data plus Sensitive Authentication Data.”

The standard then further clarifies by stating that:

“…the Primary Account Number is the defining factor in the applicability of the standard. PCI DSS requirements are applicable if a PAN is stored, transmitted, or processed. If a PAN is not stored, transmitted, or processed the requirements do not apply.”  

Finally, on page 8 of the standard, the PCI DSS makes the point once again by stating definitively:

“The PCI DSS only applies of PANS are stored, transmitted and/or processed.” 

Since the term cardholder data is consistently used within the PCI DSS document, it is easier to use this term as the determinant of compliance requirements.  The primary account number (PAN, or the 16-19 digit number printed on the front of the card, among other places) is the defining element that determines whether the data is defined as cardholder data and therefore whether a company must comply with the PCI DSS.

Cardholder data consists of, at a minimum, the primary account number (PAN) and may include cardholder name, service code and expiration date if they are stored in conjunction with the PAN.

Since a PAN alone is considered cardholder data, it is easiest to remember that any organization that stores, transmits, or processes cardholder data (PAN alone or PAN plus any other elements) must comply with the PCI DSS.   Again, the PCI DSS stresses the importance of the PAN:

“The PCI DSS only applies of PANS are stored, transmitted and/or processed.” 

Another way to remember is to remember the following: “If an organization stores, transmits and/or processes the primary account number, then the PCI DSS is applicable and they must comply.”


Is your company required to be PCI DSS compliant? Why or why not? If so, are you ready for the new standards?
Chris Mark PCI National Practice Lead AT&T About Chris