The Definition of Cardholder Data
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.
At this year's community meeting, 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 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. 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!
- 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, CAV2/CVC2/CVV2/CID, and PIN/PIN Block. So if you see this stored in a file, and you know the card has already been authorized, you have other issues you need to deal with and are probably not complying with PCI DSS.
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?
