PCI DSS v1.2.1 – No PAN, No Cardholder Data
The PCI SSC quietly released version 1.2.1 (July 2009) and some very minor wording changes. The following is a list of those minor changes:
- Oct. 2008 | v1.2 |=> To introduce PCI DSS v1.2 as “PCI DSS Requirements and Security Assessment Procedures,” eliminating redundancy between documents, and make both general and specific changes from PCI DSS Security Audit Procedures v1.1. For complete information, see PCI Data Security Standard Summary of Changes from PCI DSS Version 1.1 to 1.2.”
- July 2009 | v1.2.1 |=> Add sentence that was incorrectly deleted between PCI DSS v1.1 and v1.2.
- July 2009 | v1.2.1 |=> Correct “then” to “than” in testing procedures 6.3.7.a and 6.3.7.b.
- July 2009 | v1.2.1 |=> Remove grayed-out marking for “in place” and “not in place” columns in testing procedure 6.5.b.
- July 2009 | v1.2.1 |=> For Compensating Controls Worksheet – Completed Example, correct wording at top of page to say “Use this worksheet to define compensating controls for any requirement noted as ‘in place’ via compensating controls.”
So, pray tell what is that sentence incorrectly deleted?
PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.
This is a rather minor clarification. Many people read the cardholder data matrix and think that all elements including the name and expiration date are considered cardholder data (CHD). With this update from the PCI SSC we are reminded that these are only considered CHD if they are stored with the PAN.
Translation? No PAN, no cardholder data!
This leaves us with only one remaining question…
Now that we are completing the In Place / Not In Place areas for requirement 6.5.b, what are the necessary validation steps? Perhaps documentation review, observation of process/action/state, and interview staff.
Yes that is a very “minor” omission on their part! What would you consider “stored with”? Would name/exp need to be just in the same database, separate database same machine, different machines, etc? If a company stored the name and exp in one database and the PAN in a different database would they be considered “stored with” the PAN? The server would still be in scope, but would the name/exp. Great catch!
I’m in some agreement, BUT I have always said that you also need to not store or shoe the expiration date. There have been several examples where a valid PAN can be created using a combination of the last 4, Name and expiration date. So I have always advised, not showing, storing or transmitting the expiration date.
Julio, you ask a very good question. We could debate the question of separation but why? The PCI DSS does not state that the name or expiration data need to be encrypted, just that they are “protected”, which could mean a wide range of things.
I would keep focusing on the PAN and how to secure it.
Although it’s very important to limit the amount of data on a system and restrict access to that data based on least privilege, this may not apply the way you think it does.
I don’t see how anyone can create a valid PAN based on just the last 4 digits. The name and expiration data have nothing to do with creating a valid PAN so they are irrelevant.
I recently underwent a PCI-GAP Analysis. I had to argue the point above because the analyst (QSA) had our whole company (and every PC in it!) in scope.
v1.2.1 of the PCI DSS standard p.5 “PCI DSS Applicability Information” clearly indicates that Cardholder Name is an e l e m e n t of the Cardholder Data.
I think they could have been equally clear of what constitute the PAN (other than the obvious). As it is not uncommon to store the cardholder name with the last four of the PAN – as in the CC receipt.