While it’s very tempting as consultants to just sometimes approach a customer requiring PCI-DSS and after identifying all their service providers, declare: “I need all your service providers to also be PCI-DSS compliant and certified!”, the truth of the matter here is, that you don’t need to. As in you (undergoing PCI) do not need to have all your service providers compliant and it will not affect your own compliance.

PCI SSC made it very clear with the publication found in their Third Party Assurance supplementary document. 

If you have time, it’s a very good read.

Service provider compliance comes in requirement 12.8. As per document:

 

When engaging with a service provider, the PCI DSS compliance must be verified with one of the following methods:

  • For providers that have undergone their own PCI DSS assessment: request and review the Attestation of compliance, scope, date
  • For providers that have not undergone their own PCI DSS assessment: include the provider’s environment as part of the entity PCI DSS assessment (increase your own assessment scope). You may need to request your own QSA to perform the provider’s review.

For the second part, it’s of course, a bit tough, seeing that you are actually paying a QSA to perform an audit for someone else, when you would think they should be paying for it.

Basically, we do need to ensure that PCI DSS clauses are present in all contracts, especially for ensuring compliance maintenance, liability, right to audit, and right to terminate in case of non-compliance to PCI-DSS. This might be a good time to call your contracts personnel and start drawing up another one. (Address 12.8.2)

It’s 12.8.4 that stuffs us up: Maintain a program to monitor service providers’ PCI DSS compliance status at least annually. This generally means, it has to be either a level 1 or SAQ verification of the service provider.

The document above actually provides a guidance for different scenarios in section 6.2: Other Considerations. It’s certainly worth the read. We have a scenario where the service provider is compliant but refuses to provide information. In 6.2.2 we also have a scenario very relevant to many: Third-party Service Provider has not Validated PCI DSS Compliance.

This is quite troublesome, but unfortunately, this is much more common than you think. A lot of providers don’t even have a clue what PCI-DSS is all about.

So if you do end up with a provider without any PCI but its too difficult to change, there is still a way out:

  • “If the TPSP (Third Party Service Provider) has not yet completed PCI DSS compliance, ask for a detailed plan with deadlines for finalizing the PCI DSS compliance process; make sure the TPSP provides status checks on a regular frequency until it achieves PCI DSS compliance.”

It really doesn’t sound that great to be honest. It’s like babysitting a misbehaving child and you just want to get it over with and have other things to do later that night but this kid is just not wanting to sleep and you feel like getting some cough syrup to mix into his milk…that sort of feeling, not that we have any first hand experience on that kind of inhumane stuff. Pftt. Of course not. We all have perfect children.

But for these service providers, you do find yourself wondering if you ended up with the short end of the stick.Extract below:

  • “If an agreement exists between the entity and the TPSP, the entity may consider an examination of the contract or agreement with the TPSP to determine which party is responsible for mitigating the non-compliant data or process.
    • Consider whether the non-compliant service or process is essential and the impact of stopping it as soon as possible until a solution can be developed.”
    • For business-critical issues, the entity and TPSP should work together to determine who will be accountable for the cost and responsibility for correcting the issue, if necessary. Discuss with legal counsel to ensure the entity or the TPSP and any nested TPSP use appropriate agreement/contract change provisions or clauses to negotiate a fair and reasonable timeframe to remediate the non-compliance issue.
    • Discuss with the TPSP and agree on introducing compensating controls as soon as possible that mitigate the risk of continuing with the non-compliant process or data exchange—while work continues on its remediation.
    • Prepare a remediation plan that can be provided to the entity or the TPSP in a form that can be used as evidence (e.g., Compensating Controls Worksheet) to provide a QSA if a PCI DSS compliance review is due within the remediation timeframe.
    • Ensure any nested TPSPs meet the agreed obligations with regard to remediating the non-compliant issue and keeps the TPSPs informed of progress.”

That’s a lot of stuff. “Nested” TPSPs in the last point doesn’t mean they have the same nest, it simply means that if there are dependence on remediation of this TPSP (i.e the TPSP of the TPSP), these guys also need to understand they are pulled into scope. It’s very headache.

In conclusion, it’s probably better to start looking out for TPSPs who are already compliant or who understands their PCI compliance obligations, and for those who refuse to put in their effort on this compliance, well, be prepared to get left behind. Because once one or two of the same industry TPSP gets compliant, it will no longer be the norm to be NON-COMPLIANT and this TPSP will stand to lose out customers in the future.

For information on how to handle your PCI-DSS requirements, please drop us an email at pcidss@pkfmalaysia.com and we will get right back to you ASAP!