Storing PAN with other cardholder data

One of the more common questions that I get from clients is whether other cardholder data elements such as name, expiry date, etc. need to be encrypted when stored in conjunction with the PAN (Primary Account Number) to be PCI compliant. As with most PCI DSS requirements many people, including QSAs, insist that anything that is stored in conjunction with the PAN need to be encrypted or otherwise rendered unreadable.

First, a couple of clarifications regarding terminology. Unreadable can mean truncation, hashing, or encryption. Conjunction means being connected. If the PAN is connected with the card holder’s name and expiration (by a table, by a view, a linked list pointer, through a query, or in any other way) then they are in conjunction, irrespective of whether the name and expiration are in different tables, different data bases, or even on different servers. The most pertinent point is that they are stored in conjunction and accessible in the same environment.

The following table says that whenever information such as Name, Expiry Date or Service Code is stored in conjunction with the PAN, it needs to be protected.

Every QSA that I have run into has told me that all the data (stored in conjunction with PAN) needs to be rendered unreadable to be compliant with PCI DSS. But if you look at the clarification provided below the table (1), it states that “This protection should be per PCI DSS requirements for general protection of the cardholder data environment”. I have always taken it to mean that the data had to be protected with access control, anti-virus, anti-malware and other standard protections that the cardholder environment is secured with. The PAN has to be rendered unreadable whenever it is stored.

For people who still insist that all the data elements need to be rendered unreadable, please refer to the FAQ (ID 5417) on the PCI SSC website that states:

Does cardholder name, expiration date, etc. need to be rendered unreadable if stored in conjunction with the PAN (Primary Account Number)?
For PCI DSS requirement 3.4 and protection of specific cardholder data elements, please refer to the table included in the PCI DSS on page 2 (www.pcisecuritystandards.org). The table illustrates that, if the cardholder name, expiration date, or other cardholder data is recorded in conjunction with the PAN, even if the PAN is rendered unreadable, these additional cardholder data elements are still required to be “protected”. This means that all other requirements in the PCI DSS must be adhered to for protection of those cardholder data elements stored in conjunction with the PAN, such as firewall, patches, anti-virus, access controls, policies and procedures, etc., but only the PAN must be rendered unreadable. Please note that if the PAN is not stored, processed, or transmitted, even if other non-sensitive cardholder data is stored, PCI DSS does not apply.
-( PCI Security Standards Council – 3.6 kb – 12/29/2008 )

PCI DSS compliance is hard enough for most organizations without the additional complexity of rendering all these data elements unreadable. I did an online search to find out what websites/blogs/forums say about this topic and without exception, every one says that that all data stored in conjunction with the PAN need to be rendered unreadable. I did notice one pattern though. Most of the postings referred to the same one or two resources as the sources for their opinion.

Goes to show how information online, whether right or wrong, can shape opinions and impact so many people and organizations.

The PDF file that contains the table mentioned above is here.