Encrypted Cardholder Data – Out Of Scope?

I had an interesting exchange on Google+ the other day regarding whether or not encrypted data is in scope for PCI compliance.  In the end it was suggested that I write a blog entry regarding this topic as they said how to treat encryption has not been articulated very clearly by the PCI SSC.  I would argue that the rules regarding encryption and scope have been very clearly articulated in the PCI SSC’s FAQ #1086.  However, based on the conversation we had, it was obvious that this is not the case.  So here are the rules as practiced by most QSAs.

The key to how to interpret whether or not encrypted cardholder data is in-scope is in the FAQ.  Encrypted cardholder data (stored or transmitted) being out of scope is based on whether or not that data meets the following definition.

“It is possible that encrypted data may potentially be out of scope for a particular entity if, and only if, it is validated (for example, by a QSA or ISA) that the entity in possession of the encrypted data does not have access to the cleartext cardholder data or the encryption process, nor do they have the ability to decrypt the encrypted data.”

The important phrase in the aforementioned definition is “if, and only if.”  The only way encrypted cardholder data (CHD) is out of scope is if the entity being assessed for PCI compliance cannot decrypt the encrypted CHD.  This is a very important concept that gets constantly misinterpreted by QSAs and their clients.  However, it is up to the QSA to confirm that the organization being assessed cannot decrypt the encrypted CHD and to document the procedures conducted to prove that fact.

With that as background, let us look at storing and transmitting encrypted data and how they can be out of scope and what that means.  As you will see, out of scope can mean different things depending on the implementation of encryption.

Stored Cardholder Data

Under requirement 3.4, one of the methods recommended for the storing of the primary account number (PAN) is:

“Strong cryptography with associated key-management processes and procedures“

One of the ways organizations accomplish this is through a hardware security module (HSM) that manages the cryptographic key process.  The HSM generates the keys, manages the keys and provides an application programming interface (API) for code to access the keys.  Since the HSM is a “black box” a lot of organizations point to that fact as the reason their encryption is out of scope.

There is an additional condition to the encryption out of scope definition that usually gets forgotten.  This is what allows for the scope of the cardholder data environment (CDE) to be reduced.

“Systems performing encryption and/or decryption of cardholder data, and any systems performing key management functions, are always in scope for PCI DSS. Scope reduction for encrypted data may only be considered when that data is isolated from these processes.”

As such, since the organization using the HSM technically has access to the cryptographic keys through the HSM’s APIs, the encryption is in-scope.

Where stored encrypted CHD is out of scope is when a third party controls the encryption keys.  This most often occurs with tokenization.  Under a tokenization scheme, the CHD is sent to a third party who then securely stores the CHD and returns a token that links the CHD at the third party to the token stored by the merchant.  If the merchant needs to make any subsequent charges to the account, the merchant sends the stored token to the third party and the third party substitutes the stored CHD for the token and the transaction is completed.  But since the merchant does not have access to the token creation process, the token is out of scope because it is no longer considered CHD.

Transmitted Cardholder Data

Secure transmission of CHD can be accomplished through a number of methods.  The most common of these methods is secure sockets layer (SSL) or transport layer security (TLS).  In either case, if the organization being assessed has one of the endpoints in the SSL/TLS encryption, then the SSL/TLS process is in scope.  This is obviously most common in the conduct of e-Commerce when the merchant’s Web site has an SSL/TLS certificate for securing the transmission of the CHD to pay for the customer’s purchases from the Web site.

However we are also seeing SSL/TLS used more and more as the encryption method of choice for point-to-point encryption (P2PE) solutions.  Again, if either of the endpoints in the P2PE environment are under the control of the organization being assessed, then the endpoint or endpoints are in-scope for the PCI assessment.

One way we do see to get everything but the merchant’s endpoint out of scope is terminals that are encrypted from the terminal to the processor and the processor controls the encryption keys for the P2PE.  This is most often used in the gas station environment where the pump card reader does P2PE to the processor using derived unique key per transaction (DUKPT) or similar techniques to create an encrypted connection.

That said, what happens to the users and devices in between the two encryption endpoints on an encrypted communication link?  They are out of scope as long as they do not have the ability to decrypt the data stream.  This is another misunderstood interpretation of the FAQ.  While some personnel inside an organization have access to encryption keys, if a user or device does not have access to the encryption keys or the communication endpoints, they too are out of scope.  This is how an SSL/TLS/IPsec connection can be used for isolating the transmission of CHD from the rest of the network and satisfy network segmentation.

Another issue that comes up with managed service providers (MSP) is when the MSP has access to firewalls or routers that are encryption endpoints.  Even if the MSP does not have access to the encryption keys, they do have access to the encryption endpoint(s) and cleartext CHD, therefore their personnel and relevant device management practices are in-scope for PCI compliance.

The bottom line in all of this is; if your organization has the ability to decrypt either the stored CHD or transmissions of CHD, then you are in-scope for PCI compliance.

And as a reminder to everyone, just because something is out of scope it does not mean that it does not need to be assessed.  It is always necessary for a certain amount of testing procedures to be conducted to determine that the item is out of scope.

Hopefully we can now all operate from the same set of rules.


35 Responses to “Encrypted Cardholder Data – Out Of Scope?”

  1. February 25, 2016 at 3:58 PM

    Hi, you may skip my last post on February 24, 2016 at 2:26 PM.

    My new question is which SAQ do I have to use for Micros TansactionVault tokenized CDE (tokenization starts at POS) mixed with other apps in the same VLAN? SAQ-C or SAQ-D? I can collect evidence to show that no other apps/processes can touch the tokens and tokenization process.

    • February 26, 2016 at 6:57 AM

      Starts at the POS or starts at the swipe/dip of the card? HUGE difference.

      If it is tokenizing at the swipe/dip, what evidence do you have to prove that beyond the vendor’s claims? If you can prove that the solution is truly tokenizing at the swipe/dip, then you should be able to document all of that and present that evidence to get your acquiring bank to agree to scope reduction to the requirements in SAQ P2PE-HW for that solution.

      • February 26, 2016 at 10:20 AM

        Really appreciate your feedback.

  2. 4 DS_180
    November 23, 2015 at 9:35 AM

    Thanks for the great description. I do have one question. If the CHD is encrypted by a PCI validated card machine (terminal) before it gets passed through to the point of sale machine (PC), does the PC itself still fall within scope? If so, why, and does the network segment that the PC sits on fall within scope also? Bear in mind that there is no way for a user of the PC to unencrypt the data.


    • November 23, 2015 at 3:13 PM

      As long as only the endpoints CAN decrypt the cardholder data (CHD) and the devices in between that transmit the CHD CANNOT decrypt the information, then the devices in between are out of scope. That said, you must be able to provide evidence/documentation that this is the case in order for those devices in between to be declared out of scope.

      • 6 DS_180
        November 23, 2015 at 3:26 PM


        Thanks for that. It sounds like the PC will be out of scope then (once verified by the QSA). However, just a thought, if the PC is not maintained (ie patched) properly, is there not a risk of the PC, and then the COM port attached terminal being compromised?

      • November 23, 2015 at 4:12 PM

        This is where things can get messy. Are you absolutely sure that the encryption occurs at the point or interaction (POI), aka the card terminal? If the POI does not have an Ethernet connection and only a USB connection, then the encryption is likely occurring on the PC, not the terminal. This is how Target got breached. The cardholder data (CHD) was being encrypted on the POS PC and not at the terminal so the attackers could get the CHD out of the PC’s memory. I am not aware of a solution that does encryption at the POI yet still goes through the PC for transmission to the processor.

        With encryption at the POI there is an Ethernet connection and a USB connection. The USB connection is for the POS to communicate purchase information (i.e., receipt detail, total cost, advertising, etc.) to the POI as well as to know if the transaction is approved or declined. However, no CHD ever traverses the USB connection.

        That said, if the POI does do the encryption at the swipe/dip, then the PC would would be out of scope and would not have to comply with the PCI DSS. While not the best practice, the POS would not have to be patched monthly or whenever the vendor issued updates.

      • 8 DS_180
        November 24, 2015 at 12:30 AM


        Thanks for your comprehensive and extremely helpful responses. I will try to confirm that the Verifone VX820 terminals encrypt at POI before passing only encrypted data to the PC, and that only the endpoint can decrypt also.

        Thanks again.

      • November 24, 2015 at 7:41 AM

        The Verifone Vx820 Duet point of interaction (POI) will be using VeriShield for encryption at the swipe/dip if the POIs are doing encryption.

      • 10 DS_180
        November 24, 2015 at 9:49 AM

        Thanks. That’s sounds good thing 🙂

  3. 11 Rootloco
    October 25, 2015 at 8:14 AM

    Hi there, consider the following scenario: A Client side encryption solution is used where the encrypted Cardholder data passes through the merchants systems and are decrypted at the third-party payment service provider. The merchant does not have any access to the decryption keys. Which SAQ would apply is such a scenario? I am assuming either SAQ A-EP or SAQ D.


    • October 25, 2015 at 8:52 AM

      Your scenario will never exist because the client side cannot be trusted.

      However, from the transaction processor side, there are a lot of these sorts of solutions. The merchant’s Web site invokes the processor’s payment page (redirect) which then makes a connection to the customer’s browser. The merchant is entirely out of the payment process. That is what SAQ A is designed. However, if the redirect on the merchant’s page gets changed, it’s the merchant’s responsibility to secure that, so the merchant still needs to do some basic security and monitoring.

      • 13 Brian Olesen
        October 25, 2015 at 9:17 AM

        Hi again, I probably haven’t described it clearly enough. The form is hosted at the merchants website (Payment page), so no redirect is being used. The cardholder data is encrypted client side (via javascript) using a public key provided by the “transaction processer”. The encrypted cardholder data is then returned to the merchants webserver and forwarded to the “transaction processer” where it is decrypted and the transaction is processed. I hope it makes more sense now.

        Date: Sun, 25 Oct 2015 14:52:21 +0000 To: hbrian82@hotmail.com

      • October 25, 2015 at 12:41 PM

        What you describe is covered by SAQ A-EP. See my post on SAQ A and SAQ A-EP Clarification for an explanation.

  4. October 8, 2015 at 6:57 AM

    @PCIGuru, that was a very clear explanation. I am however confused over the use of the term “Entity.”

    Say we have a single organization. This is a very large, multinational corporation, but it is a single organization.

    This organization operates three systems: a payment gateway, a service bus and a transactional switch. Both the payment gateway and the transactional switch deal with “plaintext CHD,” so they are in scope of PCI. The service bus however, is used to connect the payment gateway to the transactional switch. That is, the payment gateway sends financial transactions through the service bus, and the service bus routes them to the switch. These financial transactions include CHD.

    Would it be possible to leave the service bus out of PCI scope if the CHD is encrypted before being transmitted through it, provided the encryption keys are not accessible to the team managing the service bus?

    Thanks for your help again!

    • October 9, 2015 at 7:27 AM

      It does not matter what my opinion is on your question. This is a question only your acquiring bank(s) and/or the card brands can answer. I think you have a good case for leaving your service bus out of scope, but that is not my decision to make. If you are allowed to keep it out of scope, you will still have to have it assessed to prove that all data remains encrypted through it and that the keys are not available to that team. So do not be surprised when a QSA asks to prove those facts.

  5. 17 shalini
    September 30, 2015 at 3:09 AM

    hi, how can we find encrypted credit card data while defining the CDE? are there any basic pointer which we should consider while defining CDE?

    • September 30, 2015 at 7:15 AM

      You will not find encrypted cardholder data because it is encrypted unless you know where it is stored. That is the whole point.

    • 19 Shalini
      October 1, 2015 at 7:03 AM

      Thanks for the response. However I am still confused, as if I want to define my card holder data environment, and I am not sure where all it is stored. Then how to find encrypted data? Bottom line is we cannot find such data. So merely defining card flow will not help I think.

      • October 1, 2015 at 5:08 PM

        You need to define dataflow regardless of whether or not the data is encrypted. The reason this needs to be done is so that you can make sure that the cardholder data is never decrypted along the way. I cannot tell you the number of times I have encountered similar situations and when the dataflows are generated, I find that there are one or more points where the data ends up decrypted for whatever reason.

        That said, encrypted data typically cannot be identified without file or protocol layouts because it no longer resembles a PAN.

  6. 21 Bob
    June 18, 2015 at 9:13 AM

    Hi, just wondering with the statement “The standalone IP-connected POI devices are not connected to any other systems within the merchant environment (this can be achieved via network segmentation to isolate POI devices from other systems);”. If I have an Ingenico ICT 250 and it is connected to my router which also has the likes of an IP camera and Windows 8.1 operating system. Does this mean I cannot select this unless it resides on a VLAN or it is on its own segmented network/

    • June 19, 2015 at 5:19 AM

      Are you using a P2PE approved solution that was implemented properly? If so, then you should be fine. Otherwise, you will need to VLAN off the Ingenico with ACLs so that any other netowrk segments cannot access it and it can only access your processor via the Internet.

  7. 23 Laban
    June 10, 2014 at 2:55 PM

    Good post! One question re. scope: What about VMware ESXi hosts with VMs that handle credit cards? The ESXi hosts do not have ability to decrypt the card data.

    Are the ESXi hosts in scope?

    • June 11, 2014 at 6:02 AM

      Yes, the ESXi and any other hypervisor are always in scope. In June 2011, the PCI SSC issued an Information Supplement on virtualization that explains why hypervisors are always in scope.

  8. 25 Michelle A.
    April 15, 2014 at 4:20 PM

    We are a relatively small company and a Level 4 merchant, however we need to do a SAQ-D. We’ve sliced and diced the network, invested a lot in hardware and monitoring software, but there are still a few areas where we just “aren’t sure” that all our bases are covered. Are you able to recommend any QSAs we could talk to who wouldn’t charge 5+ digits to go over our concerns? The merchant provider’s PCI compliance service just seems to be urging us to sign the thing, but we don’t want to take on that kind of legal potential.

  9. 26 Mr. D
    March 13, 2014 at 4:04 PM

    My set up is a FD100 terminal that is connected to my LAN. The FD100 tokenizes and encrypts the card data automatically as the cards are swiped. The LAN is behind a firewall that is connected to the internet. There are other devices on the LAN (but no other device besides the FD100 touches card data–we have a personal computer, IP cameras, etc.) I have no way to decrypt the data from the FD100. I believe I should use SAQ C–sound right? Would the rest of my network be out of scope as well?

    • March 27, 2014 at 5:56 AM

      SAQ C sounds right, but that final decision needs to be made by your acquiring bank.

      • March 30, 2014 at 5:23 PM

        Why not B-IP?

      • March 31, 2014 at 4:18 AM

        The third bullet is the problem.

        “The standalone IP-connected POI devices are not connected to any other systems within your environment (this can be achieved via network segmentation to isolate POI devices from other systems);”

        The terminals are not the only devices on the network and there was no segmentation implied except that the terminal encrypts its communications. The other devices on the network could be used to breach the terminal.

  10. 30 QSAmike
    March 11, 2014 at 2:47 PM

    A PTS POI will only reduce PCI DSS scope if it can be validated that the entity being assessed does not have access to the encryption process or decryption keys. Given that most PTS POIs utilize internal key management and encryption processes, does this mean that all encrypted cardholder data generated by a POI is still in scope? Is there a way for all key management related to the POI to be performed by a third party?

    • March 12, 2014 at 4:45 AM

      Most POI that are doing encryption have their key management with the processor or at the merchant’s transaction switch. If the processor is injecting the key, then only the POI is in-scope because the merchant does not have access to the key (that would have to be validated). If the merchant’s transaction switch is injecting the key, then the POI and the merchant’s transaction switch are in-scope as well as any connected systems.

  11. 32 QSAsteve
    February 12, 2014 at 4:29 AM

    Thanks for another insightful post. I’d like to explore the implications further.
    A merchant who uses only a dial out card reader termimal can use SAQ-B. But a merchant using only a card reader terminal connected to a local store LAN and then going out over the internet would presumably have to use SAQ-C (although SAQ-C doesn’t really appear to have been designed for this). Taking your comment that ‘SSL/TLS/IPsec connection can be used for isolating the transmission of CHD from the rest of the network and satisfy network segmentation’ then if the card reader is establishing an SSL channel from the reader to the acquirer or payment service provider would you say that the requirements 1 and 2 in SAQ-C would be Not Applicable? i.e. that the only additional requirement in SAQ-C that would apply would be 4.1?

    • February 27, 2014 at 6:03 AM

      I would concur with your analysis and approach to using SAQ C.

      BTW SAQ C was designed for the organization that has brick and mortar locations that have a LAN with POS at the location. The LAN is implemented so that the POS can securely connect to the processor over the Internet. No other remote connectivity to the LAN is allowed.

  12. December 9, 2013 at 6:24 PM

    Yes, it is true the tokenized data is out of scope.

    However, the card data had to be originally processed somehow and the process of getting the cardholder data to the processor is still in scope because it is transmitted and, potentially, processed because it does not get tokenized until it is processed. So there are still things that are in scope, it’s just that your applications are not storing cardholder data.

    This is the tidbit that seems to get missed by merchants. Merchants hear “out of scope” and stop hearing the rest.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


March 2013
« Feb   Apr »

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,775 other followers

%d bloggers like this: