This is page 2 of:
Double-Check Your PCI Service Provider Contract
Pages: 1 2
July 28th, 2010
Have you read your contracts with all your PCI service providers lately? These are the third parties that store, process or transmit cardholder data for you. PCI Columnist Walter Conway thinks you should check your contracts to know whether your service providers are doing all they can to help you become PCI compliant. He is specifically thinking about one particular PCI Requirement.
That Requirement is 12.8.2, which states that merchants need to "maintain a written agreement that includes an acknowledgment that the service providers are responsible for the security of cardholder data the service providers possess." Some disappointing service providers seem to treat this requirement as an annoying inconvenience. They either pretend it does not exist or isn't their problem. The result is that you, the retailer, are caught in the lurch.
This Story Is Only Available For Premium Subscribers. Click Or Login In Below To Read The Rest Of This Story.
Already a Subscriber? Login Here
Pages: 1 2
4 Comments | Read Double-Check Your PCI Service Provider Contract
Leave a Reply
Readers, specifically those who want to comment on a story:
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk.com? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk.com? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.
-Christine
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.