PCI DSS
Do Third Party Service Providers Impact PCI DSS Compliance Status?

Published On: October 8th, 2020Categories: PCI DSS

Do Third Party Service Providers Impact PCI DSS Compliance Status?

I have heard it said by a fellow QSA that the PCI DSS has a mini vendor management process built into it; found in requirement 12.8. For those of you not familiar with requirement 12.8, it has five sub-requirements that cover the major PCI DSS points of dealing with a third party service provider, and the impact that partner can have on your compliance. The guidance column found in the PCI DSS coupled with a very good information supplement document released in 2016 should provide you all you need to manage your controls for compliance.

So why the big deal over service providers?

Of course, the simple word is ‘Security,’ but the bigger picture is more like, ‘Everything.’ By that I mean that everything in your company’s existence can hinge on a service provider. Think of your third-party service providers as an extension of your company, even if they are a separate entity. If a breach happens, and hits the news like it always does, all your stakeholders see is your company name splashed across the screen saying card data was released. Even if that breach was the result of a third-party service provider, it is your company in the news, not theirs. I have rarely seen the point made that a third-party vendor caused a breach even though I know of huge releases of cardholder data, that started with a third-party service provider. We need to take this very seriously and apply appropriate effort to make sure you have all the required items for compliance.

So, what does 12.8 cover?

As said, there are five sub-requirements, but the top level, 12.8, is to have a policy for dealing with third-party service providers. This does not have to be elaborate, in fact its better if it is just to the point. That policy needs to provide control statements on how you manage your third-party service providers, and it needs to incorporate language around each of the five sub-requirements detailed below.

The first, 12.8.1 states, “Maintain a list of service providers including a description of the service provided.” What they are looking for is just a list. The simplest and most effective way I’ve seen this managed is a spreadsheet with each third-party service provider down the left column and columns for service(s) they provide, PCI DSS compliance status, and possibly requirements covered. Other data I have seen in the list that is helpful is contact information and embedded copies of contracts used for 12.8.2. The idea being that you have one place to go and find what is necessary on that third-party vendor. When I am in the assessment, my clients will hand me the spreadsheet, and I review it is maintained with up to date information.

12.8.2 is “Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s CDE.” There is also a statement that the document does not have to contain the exact wording of the requirement. As a QSA, I am looking for something to the effect that they take your security very seriously and will protect card data entrusted by you to them, or they will protect the security of your environment. I need to emphasize that I am looking for some form of acceptance of responsibility by the third-party. What I get sometimes is a contract with either confusing language, or nothing at all in the way of responsibility acceptance, or I will get a PCI DSS Attestation of Compliance (AoC) for the third-party. A PCI DSS AoC is not a legal contract between you and the third-party, and it does not have anything at all to do with acceptance of responsibility. The AoC will come into play for requirement 12.8.4, but for the purposes of 12.8.2’s acceptance of responsibility, it is not compliant. Where the contract has confusing language that ‘sort-of’ hints they will accept responsibility, or that doesn’t have acceptance language at all, you should push back on the third-party vendor because they are required to supply it to you per requirement 12.9.

Requirement 12.8.3 states, “Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.”

This is where you want to have a policy driven process that conducts checks to make sure you want to do business with the third-party. I encourage my clients to involve all branches of the organization, finance, legal and technical teams. What the PCI DSS wants to see is a risk analysis is performed on that vendor. The risk analysis should touch on all areas of PCI, like are they compliant or have they provided a matrix of responsibilities for 12.8.5; and general vendor management topics like how solvent is the company, does it have a good reputation in the industry and do you think they can deliver on what they claim they can do. The guidance column of the PCI DSS is helpful for a high-level overview, and the before mentioned information supplement is a really good treatment on this topic.

The PCI DSS Attestation on Compliance is key to 12.8.4.

This is more than a simple, ‘Do they have one,’ this is to ‘monitor’ their compliance, as in you solicit and they provide you their current AoC. Where this is important is say you have a third-party vendor who has not been assessed and is PCI compliant. Are you going to be non-compliant too? In a word, ‘No.’ You do not have to use compliant third-party service providers, but you are required to be compliant to the PCI DSS.

So, what happens when you get into your assessment?

Those areas of the PCI DSS that are covered by the third-party will have to be tested alongside the testing for your compliance. That means you will have to reach out to that third-party and get evidence from them, and your assessor may want to talk to the external third-party as part of the assessment. What happens if the third-party does have an AoC, but it shows a non-compliant result? Again, your ship is not going to sink, but you must review the third-party AoC and see if the areas where they are non-compliant are the services that you are using. If they are failing in those areas, you will need to include the vendor in your assessment testing by the QSA to make sure compliance is maintained, which could mean remediation by the third-party service provider. If this happens to you, reach out to your acquirer, and involve them in the decision making. They can help you steer a course to completing your assessment.

The last sub-requirement in this requirement is 12.8.5.

“Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.” That means you need a list of which requirements are the responsibility of the third-party, which requirements are yours, and which requirements are shared between you and the third-party. QSAs sometimes call it a responsibility matrix because it looks like that in tabular form. As a QSA, I want to see a list of requirements that covers the entire PCI DSS. Sometimes I see it coming from the third-party, and sometimes I see it provided by the assessed entity. My preference is to see it from the third-party because that signifies that they have acknowledged that they own a given requirement, and it helps the assessed entity fully understand what the service provider covers. Where you have a shared requirement, I want to see a clear line of demarcation on who is doing what. I know that sounds like I’m stating the obvious, but I’ve seen situations where the third-party states they are covering a portion of a requirement and the assessed entity claimed they covered another portion, and there is a gap on coverage of all provisions of the requirement as stated in the PCI DSS. Gaps like that can lead to non-compliance.

So, is the PCI DSS a mini vendor management program?

Not really. I think it covers very specific items that apply to the PCI DSS ecosystem, and not necessarily to other aspects of vendor management. 12.8.3 touches on the other parts of vendor management that a company would be interested in, but from an assessment standpoint, all I’m doing as a QSA is assessing against the requirements 12.8 in the PCI DSS, and making sure you have a process in place and are following it. In other words, the evidence I review as part of that assessment involves looking at the end-results and not necessarily the value it provides your organization.

My last thought to share is the policy I mentioned in 12.8. Not explicitly stated in the PCI DSS, but outlined in the before mentioned information supplement is a good idea to have policy controls around an annual review of the third-party service provider, with a risk assessment, or if you feel its warranted by changes in that company. Historical service delivery problems with the third-party could also push you to conduct a risk assessment. The annual review is also a great time to get their current AoC, responsibility matrix, and any updated contract addendums.

_____________________

SecureTrust, a Sysnet company, leads the industry in innovation and processes for achieving and maintaining compliance and security. SecureTrust delivers world-class consulting, compliance and risk assessment services and solutions for the enterprise market as well as tailored merchant risk management programs and solutions for merchant program sponsors around the globe.

CLICK HERE to contact us for all Enterprise Compliance, Merchant Risk Management and Compliance Technology needs.