I discussed requirement 12.8.2 in a prior post which applies to all organizations being PCI assessed. Let us now turn our attention to requirement 12.9 which only applies to organizations that are service providers. If you are unsure if you are a service provider, see this post and this post.
As a refresher, requirement 12.9 states:
“Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.
Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.”
The Guidance for 12.9 states:
“In conjunction with Requirement 12.8.2, this requirement is intended to promote a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities. The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients.
The service provider’s internal policies and procedures related to their customer engagement process and any templates used for written agreements should include provision of an applicable PCI DSS acknowledgement to their customers. The method by which the service provider provides written acknowledgment should be agreed between the provider and their customers.”
As with 12.8.2, we are told in the requirement’s Note that “exact wording” is not required. So those of you looking for “exact wording” need to move beyond that fact.
The key though to 12.9 is that the service provider’s contract, master service agreement or whatever other legal documents used need to ensure that they acknowledge their requirements to protect the payment card data they process, store, transmit or could affect the security of the payment card data.
It is that last statement that catches a lot of service providers. Like it or not, even if a service provider does not directly come into contact with sensitive authentication data (SAD) or cardholder data (CHD), if they can affect the security of that data, they need to be PCI compliant. This usually catches managed service providers (MSP) such as those that manage/monitor firewalls, network devices, servers and security incident and event management (SIEM) solutions and they will argue incessantly that they do not need to be PCI compliant. Unfortunately for them, the Council, the card brands and QSAs will tell them otherwise.
In the end requirement 12.9 is all about service providers providing the necessary information and documentation such that the organizations they provide those services can comply with requirement 12.8.2. To that end, there are two tests for 12.9 in the ROC Reporting Template and those tests state:
“Identify the service provider’s policies and procedures reviewed to verify that the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider possesses or otherwise stores, processes, or transmits cardholder data on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.” and
“Describe how the templates used for written agreement verified that the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider possesses or otherwise stores, processes, or transmits cardholder data on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.”
The first test is all about having some sort of legal agreement in place that the service provider acknowledges that they need to comply with all relevant PCI standards. Where this test broke new ground is the addition of the statement:
“… or to the extent that they could impact the security of the customer’s cardholder data environment.”
This statement came in as part of v3.2 of the PCI DSS. It was added to the test to clarify to QSAs/ISAs that service providers are also those that can influence the security of payment information (e.g., managed service providers with access to PCI in scope devices).
The second test is to ensure that service providers that rely on boilerplate agreements ensure that those boilerplates contain the necessary language that requires the service provider to maintain their PCI compliance. The idea being that if it is in the boilerplate, it is less likely to be removed.
I am sure a lot of you are questioning who ensures that the boilerplate language does not get removed or modified? That is one of the purposes of 12.8.2 on the customer’s side of the equation. This is why the testing meshes with each other. The service provider’s QSA/ISA makes sure that the language is in the standard agreements. The customers’ QSA/ISA makes sure that the language still remains in the agreements. Each are a check on the other.
I cannot stress enough the importance of QSAs/ISAs filling out the service provider’s AOC correctly let alone using the correct form and instructing their service provider clients to give the AOC to any customer that requests the AOC. There is nothing more frustrating than service providers who refuse to provide their service provider AOC. It is not a secret as many apparently believe. And please, do not refer your customers to either the Visa or MasterCard service provider lists. That is also not what your customer or their QSA/ISA needs for their assessment. Yes, it does confirm that your organization is PCI compliant, but tells the customer nothing about their PCI compliance responsibilities when using your services. That is the whole point of why customers need your AOC. Get over it and put your service provider AOC in your customer portal like you do your SOC1 and SOC2 reports.
There you have it about requirements 12.8.2 and 12.9.
PCI Guru 
“This usually catches managed service providers (MSP) such as those that manage/monitor firewalls, network devices, servers and security incident and event management (SIEM) solutions and they will argue incessantly that they do not need to be PCI compliant. Unfortunately for them, the Council, the card brands and QSAs will tell them otherwise.”
PCI is a contractual obligation and if those entities have not signed a contract affirming their PCI responsibilities they have none. The company engaging them does, but they do not. The Council can bluster all they want but if it’s not part of the contract it’s not part of the deal.
First and foremost, if you are an MSSP doing work for organizations that require PCI compliance, then you should be being asked by every one of those customers for an AOC. That is their responsibility. If you do not provide one and inform them that you never will provide one, then they should be leaving your service organization and finding an MSSP that is PCI compliant. Under their Merchant Agreement with Visa and MasterCard, they are contractually required to work ONLY with PCI compliant service providers. Again, it is their responsibility.
I totally agree with JJ. The PCI SSC stuff, while being very important to the overall security of the payment ecosystem, is not regulatory so adherence to it by a service provider is based on:
– The existence of such requirements in its contracts with customers.
– A desire from the SP to have built-in PCI DSS compliance to be seen as competitive advantage.
I’ve seen alot of organizations with PCI DSS requirements working with SP with contracts that have no reference at all to PCI DSS. And no, I’m not talking about “Mom & Pop” shops but large organizations.
We all know it is going on the way you both describe. At the end of the day though, it will be the Merchant Agreements with Visa and MasterCard that will win the day in court against the merchants working with non-PCI compliant SPs. Where that can bleed over is when the SPs’ management knew they needed to be compliant and were not as most contract these days have nebulous “regulatory and legal compliance” clauses. Those will come back and bite.