Chip, by Declan Jewell

Chip, by Declan Jewell

The definition of cardholder data for most of us usually stops at the Primary Account Number, or PAN.  Those pesky digits that we have to protect as they run through our systems cause CIOs to cringe and security professionals to salivate over potential budget money.  Before you can embark on your information security journey, you need to understand what you must secure, and where it is.  I’ve posted about this before.

As this is one of my most popular posts, I wanted to go back and revisit this post. When I wrote this post, we were still dealing with PCI DSS v1.2.1. While the definition has not changed in more recent versions, the landscape has quite a bit. I’ve updated the text for PCI DSS 3.0 as well as added a few new items.

At the 2009 community meeting (although, it seems like every once since has the same issue), the definition of cardholder data was a hot topic in both general sessions and one of the Special Interest Groups (SIGs).  I’ve always thought the definition of cardholder data was quite clear, but here’s a good rule of thumb.  This information is pulled directly from the PCI DSS that can be found on the Council’s website:

The primary account number is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment, they must be protected in accordance with applicable PCI DSS requirements.

OK, this makes sense. The Council even includes two tables that help illustrate the differences between the types of data, and what the storage requirements are. See page 7 and 8 of the DSS for more details. Now, for some additional information for those who may be new to this complex ecosystem.

Credit Cards, by Andres Rueda

Credit Cards, by Andres Rueda

  • The PAN.  That’s the 13-16 digit number that you see on the payment card itself.  I don’t think that’s ever been in question that this is considered cardholder data. As illustrated in the tables and text above, it is pretty much the defining factor.  A truncated number (123456XXXXXX1234, whereby X represents MISSING data, not MASKED data) is NOT considered a PAN.  Encrypted card data is still considered card data, hashed data (in some cases) is not.
  • If you store the Cardholder Name, Service Code, and/or Expiration date in conjunction with the PAN (such as in a database table), those items are also considered cardholder data and must be protected in the same way you would protect a PAN under PCI DSS.

Let’s apply this to some situations.

  • A database stores the Cardholder Name and Service Code ONLY.  Are those items considered cardholder data?  NO, because they are not stored in conjunction with the PAN.
  • A VSAM file on a mainframe contains an Expiration Date and the PAN.  Are all elements considered cardholder data?  YES, because the Expiration Date is stored in conjunction with the PAN.
  • A flat file contains the PAN, Cardholder Name, Address, and Expiration Date.  Is the Address considered cardholder data?  NO.  It is not one of the three elements noted as considered cardholder data when stored in conjunction with the PAN.  What about the Expiration Date and Cardholder Name?  You bet! That said, let’s not delude ourselves into thinking that an address isn’t immune from its own protections under various nation and state level privacy laws. Encryption is fairly easy to do nowadays.
  • A database stores PAN, CVV2, and Cardholder Name.  Is CVV2 cardholder data?  YES, but it falls under a different category of data that must not be stored post-authorization.  Other types of data that may never be stored include Full Magnetic Stripe Data (or equivalent on a chip), CAV2/CVC2/CVV2/CID, and PIN/PIN Block.  So if you see this stored somewhere and you know the card has already been authorized, you have other issues you need to deal with as you are probably not complying with PCI DSS (and are also a juicy hacking target).

The definition of cardholder data is key to understanding the scope of PCI DSS, but it is not as complicated as some folks are making it.  Let’s keep this part simple, and let the rest of PCI DSS be complex.  Mmkay?

This post originally appeared on BrandenWilliams.com.