9

I work for an insurance company who will randomly (3-5 times per year) have a consumer who emails their credit card to our customer service department. We don't ask for the number, they just send it over to "expedite" their transaction.

From a PCI-DSS perspective, how should this be handled by the customer service agent? So far, all that I have come up with is "don't hit reply, create a new message", so we're not sending it back out. However, should we be expunging this from our system? Include a disclosure to the customer?

Jack M.
  • 193
  • 5
  • A crucial piece on information is indeed; do other parts of your system directly store/handle payment card data? If no, then (in my inexperienced opinion) I don't see how PCI-DDS is relevant or applicable here. The part of the system isn't designed to receive payment card information nor it asks the users (implicitly or explicitly) to provide such information. I'd suggest a message on the contact page stating that they don't need provide such information. However, if other parts of your system store/handle such information, then this _might_ translate into liability, – Adi Mar 24 '14 at 15:59
  • At the moment, we are switching from Authorize.net (we handle credit card data) to Braintree.com (we do not touch it) for our production website. We also have a call center which takes the CC over the phone. So at the moment, our company is handling the account number data. – Jack M. Mar 24 '14 at 16:08

2 Answers2

7

As a QSA, here is how I would expect you to handle this situation:

  1. Have a policy, that is strictly enforced, stating that no card data is to be sent or received via email.
  2. Have a procedure in place to handle incidents of unsolicited emails containing card data. This should include a process for securely deleting the offending email, and notifying the customer of how to properly transmit the payment information.
  3. Implement a method to validate that the policy and procedures are being followed. This can include:
    • Periodic scanning of your email server for credit card data.
    • Implement a DLP solution that will monitor your email server for offending data and redact it or not allow it to be sent or stored.

point #3 above is important when considering your PCI assessment. Your QSA will validate the scope of your CDE at the start of the assessment. Part of the scoping exercise may include cardhold data discovery scans, and an email server is a common offender when it comes to storing card data. If the QSA discovers card data on the server then it will be considered part of the CDE. This might cause some problems if you weren't expecting it to be included in the assessment, so the system might not be up to PCI standards. This also makes it difficult to prove that you are following your own policy. A policy alone isn't enough to protect you from PCI requirements. It must be enforced as well.

Timee
  • 591
  • 2
  • 9
  • I would appreciate your feedback as a QSA to https://security.stackexchange.com/q/214866/5002 ... If an organization solicits users for information that *may* contain private information, is it sufficient to strip such information upon receipt (in RAM, before anything gets stored)? – Gili Aug 07 '19 at 19:43
4

From what I understand of the applicability of PCI-DSS 3(PDF), if you actively reject (i.e. don't accept credit card data via e-mail), your e-mail system isn't considered part of the CDE, or Cardholder Data Environment. It sounds like you have to be very strict about this - 100% compliance, or your e-mail system is now part of your CDE and has to maintain PCI-DSS compliance.

I'd recommend that you institute a policy to discard e-mails that have any credit card data in them, and create an new e-mail to the customer like you're doing. The difference here is that you absolutely can't accept credit card data through e-mail and use that data for verification or processing of payments. Have policies in place for your customer service agents that they can not solicit card data via e-mail or ask for it to be returned in an e-mail, including as an attachment. If possible, I'd put a filter on your incoming e-mail that looks for CC number patterns (starts with 4, 5, or 6; 16 digits, may be split in 3 or 4 groups...), and removes the CC info.

Keep in mind that I'm not a PCI professional, but have been subject to it for several years. It's always better to play it safe considering the liability, although if you don't allow use of e-mailed credit card information your liability would go down significantly.

Mat Carlson
  • 386
  • 1
  • 4
  • 1
    related answer on how to parse card information: http://ux.stackexchange.com/a/51349/21519 – strugee Mar 24 '14 at 19:01
  • +1 for suggesting that your email system need not be covered by PCI. PCI is often about interpretation, not about following the strictest possible interpretation of the rules. – Steve Sether Jan 15 '16 at 21:45
  • Please clarify which sections of PCI-DSS 3 imply that it is not applicable if the system actively strips credit card numbers out of incoming data. – Gili Aug 07 '19 at 18:51