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?

  • 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, 2014 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, 2014 at 16:08

2 Answers 2


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.

  • I would appreciate your feedback as a QSA to 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 7, 2019 at 19:43

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.

  • 1
    related answer on how to parse card information: ux.stackexchange.com/a/51349/21519
    – strugee
    Mar 24, 2014 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. Jan 15, 2016 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 7, 2019 at 18:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .