I have had a number of questions recently regarding how to deal with the occasional customer that sends cardholder data (CHD) or sensitive authentication data (SAD) to the merchant via email or instant messaging in blatant disregard to security.
Most people point to requirement 4.2 in the PCI DSS v3 and say it is not allowed for PCI compliance. However, that is wrong. Requirement 4.2 states:
“Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).”
The operative word is “send”. Requirement 4.2 does not say a merchant or service provider cannot receive PANs by end-user messaging technologies, only that they cannot send them by those same messaging technologies.
The Council has always recognized that there were always going to be a small percentage of people that would ignore security and will send their CHD/SAD via any number of insecure methods all in the name of expediency or convenience. As a result, the PCI DSS has been structured to allow for those occurrences, something a lot of QSAs refer to as “incidental contact”. What is important to a QSA is how you handle incidental contact.
The first important point to make is that once CHD/SAD is received via an end-user messaging technology, the merchant or service provider cannot then forward the information on using email or similar technologies. The merchant or service provider must break the chain of that communication as soon as possible.
Security purists will point to the fact that deleting such messages from their sources is not secure. In some cases a message could exist overnight and therefore exist on backup tapes of some technologies. While this is all true, we are not talking about a consistent flow of CHD/SAD, we are talking about an occasional occurrence. Organizations will have to accept the risk that their end-user messaging systems will have some CHD/SAD in them but that the amount is trivial because of how they deal with such occurrences. If your organization is not willing to accept this risk, then you will have come up with an approach that will allow you to stop such occurrences.
The other key point to make is that incidental contact does not necessarily bring the end-user messaging technology into scope for PCI compliance. In my opinion, what a merchant or service provider needs to prove to their QSA is that such occurrences are not condoned by the organization (i.e., by policy, such exchanges are not recommended), employees are trained to handle such exchanges securely, and that the exchanges occur only occasionally. The term “occasionally” is the tough one and is up to the organization to define for the QSA. I have dealt with large organizations that could receive around 50 such messages a day on bad days, but the annual total of incidental contact was well below 1% of the total number of transactions. The rule of thumb that I use is that as long as the volume of transactions received over end-user messaging never exceeds 1% of the total I consider that as incidental contact. However, I could see acceptable arguments for a 2% threshold based on the type of customers of the organization. However, going higher than that value would, in my opinion, be too great.
With that stated, what is an organization to do with such messages?
Some organizations prefer to not act on any end-user messaging that contains CHD/SAD. They prefer to record the sender’s communication account information, delete the message and then send a message back to the sender explaining that they cannot accept CHD/SAD through the communication method and tell the sender to use one of their approved methods for communicating CHD/SAD.
Other organizations are all about customer service and will reluctantly accept such communications. They will print out the communication and delete the original message. Once they have processed the transaction, they redact the CHD/SAD, take a copy of the redacted original and then securely destroy the original. I recommend redaction using a Sharpie marker or similar. The reason for taking and retaining a copy of the original is so that, when held up to a light, the redacted digits cannot be determined as would be the case if the redacted original were retained.
Some organizations will use the transaction confirmation process as an opportunity to remind their customer that the sending of CHD/SAD via the end-user messaging technology should be avoided in the future.
We live in an imperfect world where people are not necessarily as security conscious as the world sometimes demands. As a result, merchants and service providers need to be flexible in how they approach situations where their customers communicate with them through insecure channels. Hopefully I have given you some ideas as to how to approach these situations and deal with them in as secure a manner as possible.
PCI Guru 