One of the worst things you can hear during your PCI assessment (aside from maybe finding out about unprotected cardholder data) is your service provider saying “That’s not my responsibility”. Suddenly, you find yourself pushing your service provider to do things differently, facing unforeseen costs, and facing a potentially long remediation period.

Having a responsibility matrix isn’t a silver bullet to avoiding this sort of thing happening, but it’s a good starting point and service providers are often a vital part of your PCI. So it’s important that both you and your service providers understand what their responsibilities are.

One of the key things to understand from PCI DSS is that every requirement must be met by at least one party. SAQs only show some of the requirements because as part of the SAQ you are attesting that you meet all the requirements for having third parties that look after the requirements that have been excluded.

In this article, we use the term responsibility matrix, but you may also hear it referred to as a RACI matrix or by another term. What’s important is that you understand how your PCI DSS requirements and service providers fit together.

Why Does PCI Care?

Regardless of what type of assessment you are doing, every self-assessment questionnaire (SAQ) and report on compliance (RoC) requires you to have a programme for managing your service providers. Specifically:

Requirement 12.8.1: Maintain a list of service providers including a description of the service provided.

Requirement 12.8.5: Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

PCI cares about service provider management because so many organisations use service providers, and so many of these service providers could affect the security of the cardholder data environment. Almost everyone has heard of the Target breach where credentials were stolen from a third-party service provider and used to attack the system, but in New Zealand, the government is cracking down on web hosting providers for government sites because of the risk, and third parties have been responsible for other recent data breaches in New Zealand. Service providers not only have access to your sensitive data, but many customers sensitive data making them a prime target. Even if it’s your service provider that is ultimately responsible for the breach, the reputation damage is usually not just limited to them. So it’s important to pick service providers who can demonstrate a commitment to security.

Shared Versus Sole Responsibility

PCI has over 250 individual requirements, so understanding who is responsible for each of them is vital. There are a few different ways that responsibilities can be separated:

  • Sole responsibility of your organisation (whether you are a merchant or service provider).
  • Sole responsibility of your service provider.
  • Shared responsibility between you and your service provider where you are individually responsible for different parts of the requirement.
  • Responsibility of both you and your service provider where you are both responsible for meeting the requirement.

Sole Responsibility: An Example

One example of a sole responsibility for you as a service provider might be your responsibility for creating a cryptographic architecture (Requirement 3.5.1) for the protection of your keys. Even if you are using a cloud service, the underlying architecture, design, and management of the keys as well as the documentation is your sole responsibility as the cloud service provider would not have any insight into how you have configured your cryptographic processes.

An example of a sole responsibility for a cloud service provider may be ensuring that anti-spoofing is configured for network connections (Req. 1.3.3) and that there is no way for the customer to change or disable this.

Shared Responsibility: An Example

Consider the example of a hosting provider where there is a shared responsibility for change management. The customer is responsible for submitting the change and ensuring that it has appropriate approval within the organisation and documenting the impact, while the service provider is responsible for verifying that the change came from the expected organisation, that the change has been tested, and the change has been implemented. In this situation, both parties have responsibilities under the same requirement, but not for the same parts of the requirement.

Responsibilities of Both Parties: An Example

Regardless of the service you provide, there is almost always going to be a requirement to ensure that general security awareness training (Req. 12.6) is carried out. And in many cases, there will also be a responsibility by both parties to ensure that personnel are screened and background checks are carried out (Req. 12.7). Both the customer and the organisation would need to ensure that their personnel meet these requirements, and it is unlikely (though not impossible) that both organisations would need to carry these tasks out individually.

How Do You Figure Out Who is Responsible?

This part of the process can be very easy or potentially difficult.

Check the Attestation of Compliance (AoC)

If your service provider has an Attestation of Compliance (or AoC), check the AoC to verify what requirements have been excluded from their testing. They will usually tell you if something has been excluded from their service and if it is the sole responsibility of their customers.

Sometimes things you might expect to be covered are not. We often see that data centres do not conduct rogue wireless scanning (Req. 11.1) on behalf of their customers. This means that in order to meet this requirement, the customer must have processes in place to check for rogue access points at least quarterly.

If the service is not covered in the AoC, you will need to do more work.

What if there Isn’t an Attestation of Compliance?

If there isn’t an attestation of compliance, and your service provider is non-compliant, then you need to work with your service provider to understand:

  • Exactly what services they provide for you.
  • Which PCI requirements are the responsibilities of each party.

In a perfect world, you would go through each of the requirements to understand which requirements (and sub-requirements) are the responsibilities of each party. But start at the high level of the 12 primary requirements. Understand which requirements might be applicable to each provider, and then within those start looking at the detail. It can be a long process, but once you have this documented your assessment will be smoother and you and your service providers will have a better understanding of who is responsible for what.

What Next?

Eventually you will need to get to a point in the process where you have documented who is responsible for each of the requirements (your responsibility matrix).

The next step is to have a process for getting a written agreement with your service providers including their acknowledgement of their responsibilities. This might be as part of your contract, or it might be a separate acknowledgement on behalf of the customer. The form and wording of the agreement isn’t mandated as part of PCI, so it will depend on what is right for you and your service providers. The important thing is that they understand what they are agreeing to.

It’s not necessarily a short or easy process, but it will pay off in the long run when you avoid running into situations where someone says “That’s not my responsibility!”

Need More Help?

Confide can help you map your service providers and understand how they affect the scope of your PCI DSS. Contact us for more information.