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 
We are missing one thing – what should we do with the CHD received in the emails? Can we still use the CHD and then immediately (and securely) delete the emails or just immediately (and securely) delete the emails? Provided we will follow the PCI requirements to further secure/adjust/improve the process.
It is up to your organization to determine if you are willing to use the CHD received via email. I have some clients that send a nice message back to their customers saying they received the message but cannot process it due to security and privacy issues. I have other clients that send back a message that reminds the customer of the security and privacy issues of such practices and then confirms that whatever transaction has been completed. In all cases, no CHD is returned in any messages.
In either case, you should immediately print out the message and then delete it from the inbox. Once you follow your other processes related to the message (if any), you should securely destroy that printed copy. If you need to retain the message, redact the PAN to first six and/or last four, take a copy of the redacted message and securely destroy the original and place the copy in your files.
Thanks PCI Guru, for an excellent article as usual.
This has particular relevance in contact centers, where I work. When evaluating processes for taking card payments over the phone using DTMF (which will mask CHD from call recordings and/or agents), I often hear merchants ask this question:
“But if a customer cannot use their telephone keypad to type in their card number (because they are old, infirm or disabled), doesn’t that bring me back into scope for PCI DSS?”
I have found that every QSA who addresses this question has adopted a pragmatic approach like you’ve outlined above. Essentially, the reduction from (say) 10,000 calls containing CHD to (say) 3 where customers cannot/will not use DTMF, is a huge benefit from a scoping/fraud perspective. The benefit to hackers for stealing card data so sparsely scattered throughout databases/recordings/etc outweighs the cost of obtaining it.
Any thoughts?
Thanks,
Cam.
If we take the PCI SSC at its word that PCI assessments are risk-based, then I would agree. However, the one caveat is that the Council’s FAQ on call recordings clearly states; if there is technology available to stop recording CHD, it MUST be implemented and used.
There is an FAQ on this topic and it seems somewhat more restrictive to me than the advice you gave. A search on the word “email” finds these articles: https://www.pcisecuritystandards.org/faq/
JJ
—————————
Can unencrypted PANs be sent over e-mail, instant messaging, SMS, or chat?
FAQ Response
PCI DSS Requirement 4.2 prohibits the sending of unprotected primary account numbers (PANs) via end-user messaging technologies, whether sent internally or over public networks. E-mail, instant messaging, SMS, and chat are all considered end-user messaging technologies and thus required to meet PCI DSS Requirement 4.2. Per PCI DSS requirement 4.1, strong cryptography and security protocols must be used when cardholder data is sent over open, public networks.
For guidance on what to do if PAN is inadvertently received via an end-user messaging channel, refer to FAQ #1157 – What should a merchant do if cardholder data is accidentally received via an unintended channel?
8/21/2014
————————-
Note the August 2014 date on that one that refers to this one from 2012:
————————-
What should a merchant do if cardholder data is accidentally received via an unintended channel?
Frequently Asked Question – Article Number: 1157
FAQ Response
Merchants sometimes find themselves in a situation where a customer provides their cardholder data unsolicited via an insecure communication channel that was not intended for the purpose of capturing sensitive data.
In this situation, the merchant can choose to either include the channel into the scope of their cardholder data environment (CDE) and secure it according to PCI DSS, or implement measures to prevent the channel from being used for cardholder data.
Some suggestions for merchants to prevent any further capture of cardholder data via unsecured methods include:
Implementing controls to prevent acceptance of cardholder data via unsecured channels
Responding to customers in a manner which does not propagate any further unsecured transmissions of cardholder data
Implementing best practices and customer communications to proactively prevent customer use of unsecured channels for cardholder data
Cardholder data received via an unintended channel should be either immediately removed or secured according to PCI DSS and incorporated into the merchant’s CDE. If a merchant does not wish to bring a communication channel and its supporting systems into the scope of their CDE, controls should be in place to prevent the capture of cardholder data and/or to securely delete cardholder data from this channel before the data can be further stored, processed or transmitted.
If unsolicited cardholder data is received via an insecure method, the merchant should take immediate steps to minimize the security impact and prevent further exposure of that data. For example, if a merchant receives cardholder data in an email from a customer, the merchant’s personnel should be trained to not ‘reply’ using the same email that contains the cardholder data. Instead, the merchant’s personnel should respond in a manner that does not further propagate the unsecured transmission of cardholder data. This may be accomplished by removing all sensitive data from the email response before replying or by contacting the customer via an alternative communication channel to complete the transaction.
Merchants are encouraged to communicate with their customers on the risks of sending cardholder data through insecure channels, and to ensure their customers are aware of the merchant’s secure methods for submitting payment information. By proactively encouraging their customers to use only secure payment methods, merchants can reduce the amount of cardholder data received via unsolicited or insecure channels.
10/2/2012
In a perfect world, the FAQ would work. But we live in a very imperfect world and while it would be great to block all inbound cardholder data (CHD), that just is not always possible. What I am saying and what is stated in the FAQ are virtually one in the same based on statements made by the Council at QSA training and Community Meetings. Why the FAQ has never been updated is probably because the Council wants a hard line published, but in the real world, allow for some flexibility.
I don’t usually respond to general posts, but your advice and commentary is really outstanding.
Matt Kiger | Senior Analyst, IT Governance 12 Greenway Plaza, Suite 250 | Houston, TX 77046 Phone: 713.904.7202 | Mobile: 832.544.3142