There seems to be a lot of confusion regarding third parties that provide networking or hosting services and their obligations regarding PCI compliance. This confusion is not uncommon as merchants and their service providers have not necessarily been provided enough guidance to understand their obligations. I hope this post will clarify those obligations for all involved.
If you learn nothing else from this post, if a third party is providing your organization a service that has access to your cardholder data environment (CDE) or the third party could come into contact you’re your cardholder data (CHD), then that third party must ensure that the service complies with all relevant PCI requirements. As a result, the third party needs to either allow you or your QSA to assess the services that they are providing or provide you with an Attestation Of Compliance (AOC) that documents that those services have been assessed and they are PCI compliant.
In the past, I have stated that third parties could also submit a letter signed by an officer of the third party stating that all of the services provided to their customer are PCI compliant. Now that v2.0 of the PCI DSS has a separate AOC and the PCI SAQs have the AOC built into the SAQ, there should be no reason to need such a letter or to ask for one. If a letter is what your third party is offering, it is better than nothing, but you should be pushing them hard for an AOC. If they are reluctant to get you an AOC, as part of your vendor management process, you should take that into account and probably begin looking for a new vendor that will provide an AOC for their services.
The most common issue we run into with third parties is that their AOC or other representations of PCI compliance do not cover all of the services provided to the customer. In case after case, we see the AOC covering requirements 9 and 12 and nothing else even though the services provided may require compliance with some or all of PCI requirements 1, 2, 3, 4, 5, 6, 7, 8, 10 and 11.
In a lot of cases, it is not that the third party does not want to comply with PCI; it is they are taking the lowest common denominator approach and only picked those services where all customers requiring PCI compliance are asking for an AOC. That way they have reduced their costs of a QSA to assess their environment. These third parties are accepting the fact that any customer that needs more services assessed will have to do it themselves.
Related to this issue is the third party that offers their SSAE 16 Service Organization Control (SOC) 1 report has proof of PCI compliance. While a SOC 1 report can cover a few PCI requirements, people must remember that the SOC 1 report is structured specifically for financial auditors to ensure that the controls at a third party are properly constructed to support financial reporting at the customers. As a result, a SOC 1 report is not going to be a substitute for an AOC that covers all services. There is an alternative to this and that is to have the third party go through a SSAE SOC 2 report that focuses on the security controls of the PCI in-scope services provided. We are hearing from third parties inquiring into the SOC 2 report, but cost and a lack of customers requesting such a report are driving why we do not see more SOC 2 reports available.
Another common issue we encounter is the refusal of the third party to cooperate in assessing the services provided to ensure they are PCI compliant. There are still third parties that argue their services are not in-scope for PCI compliance even when it is painfully obvious that the third party’s personnel have access to their customer’s CDE and/or CHD.
The most common third party relationship we encounter is the management of routers or other layer 3 devices. Where we encounter the most confusion in this relationship is in regards to the use of encryption to keep the network services organization out of scope for PCI compliance. The key here is if the network services organization manages the encryption of the network, then they are in-scope for PCI compliance. The reason is that the employees of the network services organization have access to the encryption keys and therefore could decrypt the communications and gain access to CHD transmitted over the network. As a result, at a minimum, the network services organization is responsible for complying with some or all of requirements 1, 2, 4, 6, 7, 8, 9, 10 and 12. If you receive such services and are not getting an AOC that covers these requirements, then you should be doing more work on your own as well as asking the third party why they are not covering more of the necessary PCI requirements.
The next most common service we encounter is the network services firm that is managing or monitoring an organization’s firewalls, remote access or intrusion detection/prevention. Such services always put the third party in-scope for PCI compliance. Some or all of requirements 1, 2, 6, 7, 8, 9 and 12 will need to be assessed for compliance with the PCI DSS. The log capture and analysis requirements in requirement 10 may also be complied with if your organization is not capturing and analyzing the log data from these devices.
Another group of third parties we encounter a lot are records retention vendors. Organizations like Iron Mountain have conducted their own PCI compliance project and readily hand out their AOC to customers. However, where we see issues is with such vendors that provide their own tape library for their customers to use for backup. We have encountered a number of third party’s doing the encryption at their library which puts them in-scope for PCI compliance, at a minimum, for requirements 3, 4, 6, 7, 8, 9, 10, 11 and 12.
We encounter outsourcing the data center a lot with large organizations, but small and mid-sized organizations are also hopping on the data center outsourcing bandwagon. Where this puts the third party in-scope for PCI compliance is when the third party is responsible for maintaining the environment such as applying patches, managing servers or any other activities that would allow the third party’s personnel to potentially have access to CHD. In such situations, at a minimum, the third party is responsible for complying with some or all of requirements 2, 5, 6, 7, 8, 9, 10 and 12. Compliance with some or all of requirement 1 may be applicable if the third party is managing your firewalls or routers. Compliance with some or all of requirements 3 and 4 may also be applicable if the third party is responsible for managing encryption keys for encrypting CHD or encrypting communications.
Where the most confusion regarding third party responsibilities occurs is in regards to “The Cloud.” The most common reason for this is that every vendor seems to have a different definition for what “The Cloud” is, based on their particular services. Using the definitions provided by the National Institute of Standards and Technology (NIST) in their publication SP800-145, ‘The NIST Definition Of Cloud Computing’, I can provide the following guidance.
If your organization is purchasing Infrastructure as a Service (IaaS), then the third party providing these services will typically be out of scope for PCI compliance except for requirements 9 and 12. There are some instances where IaaS implementations may require compliance with the PCI DSS if the third party is managing network infrastructure that comes into contact with CHD as is usually the case with private cloud environments.
For Platform as a Service (PaaS) and Software as a Service (SaaS), the third party will have to provide PCI compliance for the services they are providing to your organization. That is because with either of these service offerings, the third party must have access to the CDE and will have the potential of coming into contact with CHD.
The problem with the majority of PaaS and SaaS vendors is that they only deal with your organization through a Web-based interface, i.e., everything is automated – contracts, support, etc. As a result, the contract is a “take it or leave it” situation that does not usually cover everything needed for PCI compliance, there is no way to independently verify the representations made by the third party as well as the fact that the AOC provided by the third party typically only covers only the physical security requirements in requirement 9 and possibly some of requirements 11 and 12 and nothing related to the other requirements, even though the third party may have responsibilities for PCI compliance outside of what is represented in their AOC.
If this is the case, there is little you or any QSA can do to properly assess the environment to ensure it is truly PCI compliant. As a result, we have a lot of organizations that try to develop compensating controls for these cloud implementations. These organizations very quickly and frustratingly find out that there are very few, if any, controls on their side of the equation that can get them to “above and beyond” the original requirement.
I know there are a lot of other examples of services being provided to merchants. But, hopefully these examples can assist you in clarifying what you need or do not need from your third parties when it comes to PCI compliance.
PCI Guru 
Thank you for the great examples. Can I ask for one more? What about third-parties that provide development (programming) to an application in the CDE?
The application is hosted by a different service provider that has already given us its own AOC.
I know the third party developers could impact the security of the CDE, however, I am not sure how to approach them for an AOC. What is your recommendation?
Does the application process, store or transmit SAD/CHD?
If it does, is the application bespoke to a single customer or is it sold to multiple customers?
If it is bespoke, then the developers only need to go through the PCI DSS assessment. If the application is not bespoke, then the application needs to go through the PA-DSS validation process.
If going the developer goes through the PCI DSS process, then their environment would be assessed based on how it could impact the processing, storage or transmission of SAD/CHD. That would include not only the CI/CD environment but potentially developers workstations as well as sysadmin workstations.
Thanks for the quick response. The application used is an online eCommerce platform that can be customized. It is PA-DSS compliant. It only transmits CHD not SAD. The third party developers work on those customizations.
As a level three merchant (SAQ), would we be responsible for assessing the third-party developers environment or are they responsible for hiring an QSA? As an assessor, what would you expect to see? I suspect the latter but let me know.
A PA-DSS validated application does NOT retain that validation if the payment process is customized. So when you talk about customization it needs to NOT affect the processing of card payments.
Does your organization contract with the developers or are they contracted through the eCommerce hosting provider? If they are through the service provider, then their activities should be covered by the third party’s AOC. Regardless, if the developers have not been assessed, then you need to assess their activities as part of your assessment which will likely force you to use SAQ D so you can capture section 6 requirements.
What about the service providers used by a service provider? As the end user of Hosted Ecommerce Service A, I got an AOC that covers Service A’s code/systems, but does not include the hosting where the code is running. They are using Service B for the hosting of the CDE. So as the end user, do I need to get an AOC from their hosting provider as well? How far am I required to go in getting AOCs to prove that our business is doing it’s due diligence regarding our customer’s credit card info and the selection of reputable service providers?
You are only required to get the AOCs for the service providers you directly contract. Any service providers used by those service providers are their responsibility.
One of our activities use a “service provider” who actually owns the software running on own system. They access via secure remote procedure and are validated when they access the system and software. They have full access to the application once on the system. To me, I consider them as a service provider, but our activity disagrees stating that they don’t touch credit card data, or manage a service such as firewall. Their access could possibly take the system down. What are your thoughts?
As I think you are relating, you have an outside, third party accessing a system that is either in your cardholder data environment (CDE) or connectivity into the CDE. If that is the case, then that third party needs to be compliant with PCI as well as the systems that they are using to connect to your system(s). We encounter this the most with managed service providers (MSP) that manage routers/firewalls that encrypt network connections and the cardholder data (CHD) traverses the internal network in clear text until it hits the router/firewall.
Great summary abd exactly the information I ma trying to clarify as an ISA for a bank. However at the end you mention “…examples of services being provided to merchants.” Does your description above also apply to service providers for a bank, not a merchant?
Yes, those descriptions would apply to banks or any entity that is relying on an outside, third party to provide services that could come into contact with sensitive authentication data (SAD).