There seems to be quite a bit of confusion about the ‘new’ requirements for service provider contracts. I say ‘new’ sarcastically because this should have been part of your vendor due diligence processes from the beginning.
From a merchant’s perspective, unless they have hired a QSA (or other PCI expert) to help define the service requirements and contractual obligation, it’s very difficult for them to ask the right questions. From a service providers perspective, I’ve seen the gamut from complete ignorance of their obligations, to out-and-out lies in terms of what they are and are not providing.
The DSS v3.0 requirements of 12.8.X go a long way to resolve this, but not far enough in my opinion. The bottom line is that someone has to be responsible for each requirement, and there are only the following choices;
- SP agrees to be fully responsible for the requirement;
- SP agrees to be partially responsible, and;
- SP pushes the entire requirement back on you.
The above list is fairly obvious, but for the service provider’s clients the challenges are now twofold:
- If the service provider accepts full responsibility, are they PCI compliant for the service(s)?
- If they are only partially responsible, EXACTLY what part of the requirement is left?
Does the service provider need to be fully PCI compliant for you to achieve compliance? The answer is no, but if they are not, you have just doubled your assessment scope. Again, someone has to answer the questions, so if your service provider has not validated compliance for the services they are offering, you need to add them to your validation efforts.
As for the partial responsibility, that’s easy, get your service provider to tell you what they’re doing. For example;
|DSS Req. #||
|Service Provider Responsibility||Client Responsibility|
Examine data-flow diagram and interview personnel to verify the diagram:
* Shows all cardholder data flows across systems and networks.
* Is kept current and updated as needed upon changes to the environment.
SP will provide initial diagrams in Visio format for the pre-production environment but will not own, manage, or keep up-to-date the data-flow diagrams post-production.
This requirement is not part of SP PCI Report on Compliance dated [Mmm dd, yyyy]
Client must own, manage, and keep up-to-date all data-flow diagrams for inclusion into their own PCI compliance efforts once services have reached a production state.
You must repeat the above for EVERY requirement in the PCI DSS v3.0, then add this as an addendum or annex to your signed service contract. This applies not only for the services they are providing DIRECTLY, but the SP has a responsibility for any SUB-contractor they may bring in, and so on down the line.
Again, SOMEONE has to answer the questions!
However, let’s back up a bit and handle each DSS Requirement in turn:
12.8.1 Maintain a list of service providers
Easy, just maintain a list of Service Providers, with – at a minimum – the following detail;
- Company Name
- Service Description
- Is [CONFIDENTIAL] Data Shared?
- Regulatory Compliance Date
- Status Verified By
12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.
Even easier, they wrote it down for you!! Include – again, at a minimum – the language in red in your contracts. You will likely want significantly more than this as there is no declaration of LIABILITY, or even SLAs.
12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.
If you don’t have robust vendor due diligence and vendor on-boarding/off-boarding processes you are really asking for trouble. For PCI services, if you have not ensured they are PCI compliant for the services they are providing AND you have the full details written into contact, then you have created a world of pain for yourself.
12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.
Does this say anything about the service providers actually working towards PCI compliance? No, it doesn’t, so the status could be; “They will never achieve PCI compliance.” and this is good enough for PCI. This should NEVER be good enough for you.
12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.
This we’ve already covered, all you need is a table, like the above, of every PCI requirement handled by each of your service providers and their sub-contractors. Your QSA can then tell you precisely what is left for you to cover for full compliance.
Whether you’re assessing for the first time, or re-assessing under v3.0, you need to start these conversation with your service providers NOW, as while this may be simple, it is not easy.
Advice for Merchants:
- Only choose PCI compliant service providers (start here; Visa Europe Merchant Agent List)
- Only choose service providers who have already addressed 12.8.2 and 12.8.5 up-front. You should not have to ask for this from SP worth their salt
- If you have existing SPs and don’t know where to start, hire a decent consultant who is familiar with the PCI DSS to help
Advice for Service Providers:
- Get your responsibility mappings and your contract language sorted out now, BEFORE you are asked
- If you need help, ask for it, ignorance is not an excuse your clients can accept, nor can the card schemes