Readers of my blog know I am opinionated, which I why I have so many non-readers I suspect. I find myself now with something of a mission, and that is to either train providers of PCI-related services to perform 12.9 correctly, or I will make available a responsibility mapping matrix of their Attestation of Compliance (AoC)-defined services. Merchants need to perform appropriate due diligence, without full disclosure and guidance from Service Providers (SPs), this is all but impossible for the majority of non-PCI experts.
I am not saying the SPs are doing anything nefarious,[mostly] they are not, it’s just clear that neither they, nor it would appear their QSAs, have taken the time to produce a responsibility mapping that makes sense.
I will not be posting names, but if you contact me on firstname.lastname@example.org and ask about a specific provider, I will tell you whether I have the mapping or not (just started this, so it’s unlikely, but stay tuned…). I am also happy to accept AoCs for your provider if you want a mapping done. Finally, I am also happy to help SPs directly if they would like to get ahead of this.
For Merchants: Regardless of the SAQ you complete, you are responsible for EVERY requirement in the PCI DSS, so any mapping and contract you have in place must be at that requirements level, not that of the SAQ, so if all you get is an AoC, there’s a very good chance your residual responsibility is significantly higher that you would like, and perhaps been led to believe.
At a minimum, your mapping will have 3 columns:
- AoC Mapping – This is the only ‘official’ recognition of the requirement numbers included that you have to go by, anything else the SP may say is irrelevant. If it’s not on the AoC, you cannot point your RoC/SAQ to it, and the requirements must still be assessed on your behalf. Note: Be VERY careful re: sub-requirements, if they are not SPECIFICALLY addressed, they are not included (Listing Req. 1.1.5 on the AoC does not necessarily mean Reqs. 1.1.5.a AND 1.1.5.b for example).
- Services YOU Require – This is where you specify EVERY requirement you’re looking to outsource, but you need to be reasonable. There are surprisingly few requirements you can fully outsource (depending on the service), and you must detail what partial responsibility must remain with you. For example; you can outsource the changes to your rule-set, but you will usually retain ownership of it (which is the majority of Reqs. 1.X).
- Residual Responsibility – This is what’s left for you to cover, and will represent an agreement between you, your service provider, and your QSA (if applicable). Anything NOT handled by your SP, is yours.
The above is not to say that an SP cannot provide significant support outside of their officially assessed services, but whatever they are doing needs to be noted, and included in your report.
For example; regardless of the services provided, EVERY policy requirement is owned by you, and followed by your SP. They may have their own policies, and even have them listed on their AoC, but those policies do not cover you as a merchant from a RoC/SAQ perspective.
Once complete and agreed by both sides, this mapping should form the basis of your contract. It does not matter if it’s an annex, addendum or in the main contract body, but the actual PCI DSS v3.0 requirement numbers must be part of any binding agreement. Whether or not you put SLAs around the services, or require full compliance on an ongoing basis, is a business decision, tying your SP to the DSS requirements they cover on your behalf is a PCI obligation.
I have uploaded an example of a Service Provider Responsibility Mapping that I recently provided to a client – help yourself. Hopefully it makes sense, but you are free to contact me if you would like more guidance.
This is actually a very simple process, as is everything else in security, it’s only not knowing yourself what to do that makes it difficult. So ask for help.
[If you liked this article, please share! Want more like it, subscribe!]