Outsourcing PCI DSS controls to third parties can hugely support a merchant (or service provider) PCI DSS compliance program and can be a great thing if you want to leverage any SAQ reduction criteria, meaning you have less controls to complete yourself so less costs and less complexity; always a good thing, BUT you must have a handle on service providers if you want to take this route.

In this blog, we’ll look at some of the common pitfalls that can lead to non-compliance or a false sense of security, and advise on how to address and prevent these.

Requirement 12.8 of the PCI DSS describes what you as a consumer of a service must do in order to meet the PCI DSS requirements as a mechanism for compliance, but could you answer these questions confidently as a measure of good security:

• How are you using this area of the PCI DSS to shape your security and compliance program?
• Have I got information to confirm those requirements which a service provider does on my behalf?
• How is this information contributing to your compliance assessment? Are you relying wholly upon the third party without question because they provide you with an Attestation of Compliance (AoC)?

Not all Service Providers are equal, and this can be for various reasons.  Payment Service Providers rarely take on your own requirements, you either redirect the consumer to them, or receive card data and inject it into their platforms.  

When this is the case, you still need to obtain an Attestation of Compliance (nothing else will do, not even a PCI DSS certificate) and obtain their written confirmation/assurance that they will maintain the security of the cardholder data they process on your behalf or the degree to which they can affect your security. If they grumble at this request, and QSAs we experience this frequently, bear in mind that service providers must demonstrate it to their QSA as requirement 12.9 - so it must exist if they are truly compliant!

Other Service Providers actually take on responsibility for your requirement as part of a service offering; this is the focus of this blog. 

Pitfall #1 - Initiating due diligence

Due diligence needs to be performed BEFORE you start to use a service provider in any capacity, rather than as an afterthought; failure to do so may cause you to enter a contract which could leave you:

• Short of documentation;
• Short of a formal commitment by the third party to be responsible for a control;
• Owning a control which you think you're paying somebody else to look after.

Also remember that with other legislative requirements, will you be doing enough just following the PCI DSS requirements?

To prevent this, what should you be doing?

Pitfall #2 - Performing the due diligence

Performing due diligence for PCI DSS service providers isn't just about the AoC, or looking them up on MasterCard or Visa’s websites.  Like any other organization you use, you should perform standard due diligence at a minimum. An AoC doesn't give them any automatic 'pass'; think about other security regimes, think about your company’s standard vendor management practices; as credit card information is now deemed personal information under the GDPR - are they cutting the mustard? 

It really should be more than just the AOC. If you don't address this, you're going to struggle to meet requirement 12.8.3.

Pitfall #3 - You're missing a contractual agreement

For some of the larger and more well-known service providers, the devil can be in the detail through documents such as master services agreements.  In all cases, it is important that some type of agreement or contract is established which can be referred to in order to confirm that both parties understand their relationship and ultimately who does what.  Without this in place, a QSA will be unable to document this as being handled by a third party and will then look to you to meet the requirement yourself.  Requirement 12.8.2 can't be met unless you're on top of this.

Pitfall #4 - You check the calendar only once per year for their ongoing compliance.

The PCI DSS itself sets an absolute minimum, but should you be happy with that?  In the event that a service provider goes out of compliance, you may want to take steps (through your contract or otherwise) to address this. If you're only checking once per year, you may have given yourself a false sense of security and at worse you’ve made yourself accountable if there is a breach, particularly for those using PCI DSS-compliant providers to reduce you to another SAQ. 

As a minimum, the contact with the service provider ought to be on the anniversary of their AOC expiration but do consider service management activities to supplement this.  If you do this better, then 12.8.4 is easily addressed.

And finally - Pitfall #5 - "Oh that's the service provider’s responsibility"

This is really where you must have a handle on things. If you haven't got this right, the QSA must look to you to meet the intent of all PCI DSS requirements for these systems components or processes, and this can present you with major challenges.

More and more service providers are proactively producing a document which describes their PCI DSS responsibility, often called an 'Assertion of Responsibility'.  By reviewing this up front, it should articulate the requirements they are performing on your behalf, and what elements of compliance they are taking responsibility for.  At this point, everybody should know ‘who, what and where’ and your own efforts can be designed appropriately.

If the third party doesn't do this then create your own for each service provider, being sure to include the requirement and the system components.  This might take some time at first and it's not worth combining these into a single view as it can cause confusion - different service providers may hold different responsibilities for different system components.  Once you have this understanding, check it against your own scope to see if you're completely covered.  If there is a gap, then the responsibilities remain live with you.  It's also really important that the AOC aligns with this documentation, referencing back to a contract.  If you have this in place, then 12.8.5 is all set (and by definition, 12.8.1 too).

Organizations may often have procurement teams, service management teams, and compliance areas - this is bread and butter stuff for them, so be sure to engage with them in the normal way.  If your company growth means you've not yet got these areas, set aside some time to get this right.  In all scenarios, Nettitude can provide support in this area and all areas of the PCI DSS; please get in touch.