This is page 2 of:
Double-Check Your PCI Service Provider Contract
Equally unacceptable is a service provider that simply refers its customers to the lists maintained online by Visa and MasterCard. Being on the list is a good first step, but it is not the same as committing to protect the data in the provider’s possession. How is a retailer supposed to be PCI compliant if Requirement 12.8.2 is not in place? I’m not sure the service provider in this case qualifies as a “lying vendor”, because it may well be secure, but it sure is a disappointing vendor.
Based on my experience, many merchants encounter some level of resistance when it comes to asking their service providers to acknowledge their responsibility to protect the cardholder data they possess. I can think of two possible solutions the PCI Council can take to address this situation.
One option would be to add a PCI Requirement just for service providers to require that they include the language in their contracts. The additional requirements for shared hosting providers (Appendix A of the PCI-DSS) form a good precedent for such a service-provider-only requirement.
Alternatively, the PCI Council could make a single addition to the Attestation of Compliance (AOC) for Service Providers (Appendix E) to include an item noting whether the 12.8.2 contract language is provided to their merchants. This item would fit nicely in Section 3, and it would only apply to service providers.
I do not hold out much hope for this approach right now–the Council is pretty busy revising the DSS. It is looking at the SAQs and other documents, however, so it may not be beyond hope that the Council could include a relatively small change like the one I am suggesting to help merchants of all sizes.
Because neither of these solutions is likely in the near future, the answer rests with the merchant. Retail CIOs need to include this item when they issue an RFP or meet with prospective service providers. These CIOs need to know up front whether they are dealing with a disappointing service provider. If a retail CIO decides to use a disappointing service provider anyway, I suggest that CIO start working on a compensating control for 12.8.2 right away.
Personally, I cannot figure out why these disappointing service providers work so hard to achieve and maintain their PCI compliance and then drop the ball at the very end. I’m only guessing, but maybe their lawyers won’t let them acknowledge their responsibility for fear of lawsuits. If that’s the case, do merchants really want to work with a service provider that is run by lawyers and that will leave its clients holding the bag if they suffer a data breach?
Do you have any disappointing service providers? How have you addressed Requirement 12.8.2? What has been your experience with getting your service providers to include the required language in your contracts? I’d like to hear about your experiences. Either leave a comment or E-mail me at wconway@403labs.com.
-Marc
July 28th, 2010 at 3:44 pm
Another important question is: Who will be liable if the service provider’s system is breached, or if the software or systems provided to the merchant contain vulnerabilities that enabled a breach?
In almost ever case, it is the merchant who will be held responsible by the acquirer and card brands, because those parties have no contractual relationship with the service provider. In theory, the merchant might be able to file a claim against the service provider, but many service providers require merchants to waive the right to such claims. Some even require merchants to indemnify the service provider against claims from third parties (i.e cardholders and acquirers).
Even assuming the merchant did sue, and win, it would probably be a hollow victory: Most service providers lack sufficient resources to pay tens of millions of dollars (or more) in claims that could be made against them by the hundreds or thousands of merchants they service.
Using a service provider does not automatically provide a merchant with a “free pass” to avoid liability, regardless of what the merchant’s agreement with the service provider might state.
July 29th, 2010 at 7:23 am
I believe we need better consistency use of the term service provider. I’m familiar with QSAs and CIOs who expand the definition beyond storing, processing and transmitting cardholder data to anyone who accesses the cardholder environment. This wider net catches those who provide remote help desk support, on-site PC technicians and more. There doesn’t seem to be any issue having these entities agree to 12.8.2; however, enforcing strict interpretation of 12.8.4 – “maintain a program to monitor service providers’ PCI-DSS compliance status” – is tough. I don’t believe the PCI-SSC will process a ROC for Jim’s PC Rescue in Butte, Montana. Apologies if you’re a computer tech in Butte. Hopefully, the merchants controls limit risk from these other groups, but it seems that we need better tools and processes to help both the merchants and the vendors maintain secure operations.
July 29th, 2010 at 7:48 pm
This is a very timely article for me. I work in franchise/independent dealer model. Some our our retailers have seen advertisements from LogMeIn (web based remote control software) that suggests PCI compliance is no problem. However, upon contacting them about 12.8.2, we’ve learned they’re unable/unwilling to agree. Hence, not really PCI compliant as far as our QSA is concerned. It’s confusing to our retailers who see the ads for this and other software and then challenge us on why they can’t use the solutions. This article helps provide some “evidence” to our customers regarding this situation.
July 29th, 2010 at 8:57 pm
@ PCI Guy and Chris,
Many thanks for your comments (and sympathies, Chris, for your plight!).
My recommendations to my clients is that their vendor “agreement” have at least the following points:
• They attest that they are responsible for maintaining their compliance with all applicable payment card association rules including PCI DSS. (This can also help you meet 12.8.4.)
• They accept responsibility for the security of all payment card data (as defined in the PCI DSS) in its possession.
• They will notify you within _____ hours if they have a data breach (e.g. within 24 or 48 hours; I like 24).
• They are responsible for 100% of any financial fines, penalties, and costs if they are solely responsible for a breach.
Now, to be fair, they will want some commitment from you that you will follow all your security policies, update your systems and links to them as appropriate, that you will remain PCI compliant, too, and that you report any problems immediately.
Maybe these can address some of the issues raised.
I find it interesting that the Council changed the requirement from a “contract” to an “agreement” with version 1.2. This gives you and your service provider some room, although not being a lawyer I won’t pretend to comment on the difference between the two. What you want, though, is the service provider’s commitment in writing by a responsible officer of the company.