On October 27, 2009 the PCI SSC and the card brands issued a clarification on whether or not encrypted cardholder data is still in-scope (Article Number 10359). For such a simple clarification, there was a lot of verbiage, so I thought it might be good to take a closer look at the FAQ in question.
The FAQ starts out stating the obvious facts regarding encryption that we all know.
“Encryption solutions are only as good as the industry-approved algorithms and key management practices used, including security controls surrounding the encryption/decryption keys (“Keys”). If Keys are left unprotected and accessible, anyone can decrypt the data. The DSS has specific encryption key management controls (DSS 3.5 and 3.6), however, other DSS controls such as firewalls, user access controls, vulnerability management, scanning, logging and application security provide additional layers of security to prevent malicious users from gaining privileged access to networks or cardholder data environments that may grant them access to Keys. It is for this reason that encrypted cardholder data is in scope for PCI DSS.”
The FAQ then goes on to give an exception.
“However, encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it. Any technological implementation or vendor solution should be validated to ensure both physical and logical controls are in place in accordance with industry best practices, prohibiting the entity, or malicious users that may gain access to the entity’s environment, from obtaining access to Keys.”
It appears that the PCI SSC and the card brands have recognized that if you do not have the ability to decrypt, then the data cannot be treated as in-scope.
However, if an encryption algorithm is used, there must be a way to decrypt. As a result, the next sentence addresses this fact.
“Furthermore, service providers or vendors that provide encryption solutions to merchants who have administrative access and controls to Keys along with the management of termination points for encryption to process transactions, are required to demonstrate physical and logical controls to protect cryptographic keys in accordance with industry best practices (such as NIST referenced in PCI DSS requirement 3.6), along with full compliance with PCI DSS. Merchants should ensure their solution providers who provide key management services and/or act as the point of encryption/decryption are in compliance with PCI DSS.”
While we now have an exception, it appears to be only valid if the merchant do not have access to the encryption keys. Notice, this exception does not include service providers that may also not have access to encryption keys, only to merchants. In addition, the exception specifically calls out that vendors and service providers that have control of the encryption keys must prove that the keys are protected in accordance with industry best practices such as the NIST standards called out in requirement 3.6. Notice, they MUST prove. Therefore this nonsense of “trust us, we do this” is no longer acceptable. They must provide proof that they are managing encryption keys under industry best practices.
Finally, merchants do not necessarily get off scot-free if their encryption keys are managed by a third party and the merchant does not have access to the keys. The final statement in the FAQ covers this point.
“Merchants should be aware that encryption solutions most likely do not remove them completely from PCI DSS. Examples of where DSS would still be applicable include usage policies, agreements with service providers that deploy payment solutions, physical protection of payment assets and any legacy data and processes (such as billing, loyalty, marketing databases) within the merchant’s environment that may still store, process or transmit clear text cardholder data, as that would remain in scope for PCI DSS.”
So, in my opinion, here is the bottom line for this FAQ. You can rule encrypted cardholder data out as long as the merchant does not have access to the encryption keys and the third party in control of the encryption keys can prove that it is properly managing the keys. However, all other relevant PCI DSS requirements still apply.
UPDATE: It has been pointed out to me that as long as there is an independent internal party available to manage the key, that that would also satisfy the exception. While I agree with that assessment, with most small and mid-size merchants and service providers, I would argue that the only way they can comply with this exception is to use an external, third party to manage the keys. Therefore, I stand by my interpretation that a third party needs to manage the keys.