Evan Schuman's StorefrontBacktalk

The difficulty is that Requirement 12.8.2 is asymmetric. That is, the merchant needs service providers to acknowledge they “are responsible for the security of the cardholder data” they possess. That seems fair. Unfortunately, there is no corresponding PCI DSS requirement telling the service provider it has to provide that acknowledgement in its merchant agreement. We’ll see what the Council eventually decides, but I’m keeping my fingers crossed just in case.

The fourth feedback area contains suggestions for updating the SAQs. I think everyone agrees that the shortened SAQs need a fresh look. I’ve offered my own suggestions for updating the SAQs. (Indeed, I’ve done it more than once.) I know the Council has been looking at the SAQs, so this should be a great opportunity to hear where its thinking is taking us.

I was also surprised by the fifth feedback area, which is a request for clarification on PCI DSS Requirement 3.4. That requirement describes how to protect stored cardholder data. I am sure the Council knows that encryption and key management are complex topics, and that truncation/hashing and tokenization are not always convenient methods to store and retrieve data. Perhaps that is the whole point of the requirement: to make merchants think twice about storing electronic cardholder data in the first place.

I will be listening for clarification or updates on hashing and tokenization in particular. I’d specifically like more information on what constitutes a “high-value token.” (For more background, read “Tokens Are Not The Same As Encryption” and “The PayPal Problem.”)

The final feedback area the Council promised to address is PCI DSS Requirement 8.5, which goes into excruciating detail (there are 16 sub-sections) on passwords. I have a lot of sympathy for the POs that asked for a little mercy here. Passwords themselves are a problem area in more than just PCI DSS. I don’t know if the Council will simplify or shorten the requirements. What would be interesting to hear is whether it is willing to permit merchants and service providers more flexibility in determining their own password requirements, so long as they meet some generally accepted industry standard for being “strong.”

There is precedent for such a change in PCI DSS today. For example: Requirement 6.1 allows merchants to use “a risk-based approach” when installing security patches; Requirement 6.2 has merchants defining their own high-risk vulnerabilities; and much of Requirement 12 lets merchants set their own security policies.

The Council has taken great strides toward making the 2012 Community Meeting a “listening” meeting. It has provided complete information on every piece of feedback on the current version of PCI DSS, and it has included its response as to whether the suggested change or clarification was accepted for current consideration. You may not agree with all the answers, but nobody can criticize the Council for not listening. The next step is seeing what impact the feedback will have on the next version of PCI DSS (and PA-DSS).

Did your organization provide feedback on the current versions of PCI DSS and PA-DSS? Were your suggestions or comments accepted for current consideration or were they deferred? What do you think about the six feedback areas in the Council’s press release? I’d like to hear your thoughts. Either leave a comment or E-mail me.