Third parties have always been a challenge for PCI DSS. In fact, a tidbit from some Visa CISP lore suggests that this whole PCI DSS mess stemmed from the lack of Visa’s visibility into the third parties that may be handling data on behalf of merchants. PCI DSS 3.0, and now 3.1, is focusing more closely on those third parties, but third parties have always been an issue for PCI DSS. There have always been requirements for managing relationships with third parties through contracts and risk assessments, and the last few versions of the standard have gradually stepped up these requirements. I would be wary of a QSA who didn’t ask to see lots of documentation from your third parties. In some instances, he should suggest (and perform) a site visit. In the next section, we will cover the clarification as well as review all the third-party requirements.
Keen PCI DSS gurus might be wondering why I’m even calling this out as a separate section. No, I am not paid by the word (wouldn’t that be nice!), but I still see a lot of confusion around third parties and how to handle them. The clarification for third parties in PCI DSS 3.1 is pretty minor, and almost looks more like a formatting change than a requirement change. The Summary of Changes document simply suggests a clarification of how a third party can demonstrate compliance. On the surface, I’m not sure what party was complaining about this, but it is fairly clear now. Third parties must either have their own yearly assessment performed, which probably should lead to registration with a sponsor bank and being listed on a compliant service provider list, or they can respond to assessment requests on behalf of their customers. These were present in PCI DSS 3.0, however, they are more explicitly stated in 3.1 with terms like “Annual Assessment,” and “Multiple, On-Demand Assessments.”
If you are a third party who is reading this book wondering why your customers are constantly coming to you with assessment requests, please read page 12 of PCI DSS 3.1. I would also strongly suggest you choose the first path so that you can go through the process one time
PCI DSS 3.1. DOI: http://dx.doi.org/10.1016/B978-0-12-804627-2.00003-5 © 2016 Elsevier Inc. All rights reserved.
per year instead of many, many, many times as you respond to these on-demand requests. I would also strongly suggest going through the process to get listed as a compliant service provider. After going through an assessment, the process to get registered and listed is not too difficult and is mostly a paperwork exercise. Getting on these lists varies by payment brand, but your QSA should know how to help you here. If not, work with your customer (who is probably a merchant) to get listed through their acquiring institution.
This is not a new requirement, but as we mentioned in the last book, there are some new teeth to it as of PCI DSS 3.0. After June 30, 2015, service providers must demonstrate that their contracts are updated to include PCI DSS compliance responsibility and language. Most of them should have this as Requirement 12.8.2’s PCI DSS 3.0 clarification requires that the language exists in some document that supports the business relationship between the two firms.
If you are still struggling with this because of a stubborn service provider, it’s time to start looking for alternatives. Today, there are tons of firms that would love to compete for your business and happily include that language. I realize there are other constraints such as price, technology integrations, and business relationships that may be problematic, but this is a protection that you need for PCI DSS compliance and should want for your own risk-management peace of mind.
CALL THE BALL
I was recently on a panel with some PCI DSS experts and an audience member asked how she was supposed to comply with PCI DSS with shrinking budgets and headcount constraints. I know how serious of a problem this can be for institutions. PCI DSS and compliance simply are not areas where the business wants to invest. Paraphrasing our back and forth in front of the audience, I asked her if she ultimately has control over how she processes cardholder data. Meaning, could she change her processing agreement to get a more favorable outcome? She said she did, and I responded with something like, “You should look for a processor that you can outsource all of your responsibility or PCI DSS to.” It might be a P2PE solution or an encrypting, leased
Third Parties 17
terminal. Will she be paying more per transaction? Probably, but her organization will be able to attach the cost of processing, which should include securing the transaction and complying with PCI DSS, more closely to the action of processing a card.
Wherever you are out there, I hope you found a great new vendor that could solve your problem!