Eek! Is My Email System in PCI Scope!

I once saw a t-shirt that read: You Can't Patch Stupid.

It is tough to argue with the wisdom of that statement or its directness, particularly when it comes to receiving unsolicited emails containing cardholder data.  The real issue, though, is what is a merchant to do when they receive such unsolicited orders or gifts?  Did the sender just put the institution's email system in scope?  Can they process the transaction "just this once?"

I encounter this situation often enough that I developed an approach for my clients, which I'll describe below.  Just recently, the PCI Council addressed this issue in their Assessor's Newsletter.  That perspective, too, we'll explore.  The fact that the Council feels the need to address this issue should at least make readers of this blog feel they are not alone.  

Let's start by defining PCI scope.  You can think of your scope as being in two parts.  The first part is the Cardholder Data Environment (CDE), which includes all the systems, people, and processes that store, process, or transmit cardholder data.  The second part of your PCI scope is any system connected to the CDE.

Most institutions have successfully segmented -- which in PCI-speak means isolated -- their email and administrative systems from the CDE.  However, just when you think you are safe along comes a student, parent, donor, alum, ticket holder, or whoever sending you an email with their card information (and the security code too, just for fun).

Did this kind soul just throw your entire email system into scope?

The answer is: it does not have to.  My advice to clients is that they need to do a few things when this happens.  Here is where annual PCI training comes in to play.  The big thing is that you cannot process the transaction.  If you do, then regardless of any policy you may have, your practice demonstrates that you do indeed use email as a payment channel, so that system is part of your CDE (and every device connected to your email system is in scope...think about that!).

Instead, merchants must purge the email and contact the sender to tell them how they can complete their transaction. If you follow this procedure, you should be able to keep your email system out of scope.  Smart institutions make this part of their annual training to make sure.

Lest you think this is only me talking or that your merchants are the only ones with this problem, read on...

The following is from the June 2012 Assessor Update.  The FAQ of the Month deals with this precise issue:

What should a merchant do if cardholder data is accidentally received via an unintended channel? 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.

There you go.  The best advice directly from the source: delete the data and don't process the transaction.  You may not be able to "patch" your customers, but you can keep them from expanding your PCI scope.

Now, about some of those other t-shirts I've seen...