Service Provider PCI Basics

Service Provider PCI DSS Basics

As a service provider, you are responsible not only for your customers’ data, but also your customers’ customers’ data. This means that you play an important role in PCI DSS. 

Service provider and merchant compliance requirements are pretty similar. The main difference is that service providers have a few more requirements that they need to comply with. And unlike merchants who have a number of different Self-Assessment Questionnaires (SAQs) that they could complete, service providers can only complete SAQ D (Service Provider) or a Report on Compliance (ROC). 

With version 4.0, the difference between SAQ D (Service Provider) and the ROC is getting smaller. In SAQ D (Service Provider), each requirement needs a description of how the conclusion was reached, and some of the key features of the ROC are included such as diagrams, and a list of critical hardware and software in the environment. 

On this page, we will cover some of the basic things to help service providers understand:

  • Why PCI DSS matters
  • What PCI DSS means for you as a service provider
  • How you can work to become PCI DSS compliant

Are You a Service Provider?

A service provider (TPSP) is any business entity that is not a payment brand, but that is directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity.

Other reasons an entity could be a service provider include:

  • If the TPSP provides a service that controls or could impact the security of cardholder data
  • If the TPSP is responsible for one or more PCI DSS requirements on behalf of another entity

Common examples of service providers include:

  • Payment gateways
  • Payment service providers (PSPs)
  • Independent Sales Organisations (ISOs)
  • Managed firewall services
  • Managed SOC/SIEM services

There’s also a special category of service provider called a Multi-Tenant Service Provider which is covered in it’s own basics article.

What’s the Difference Between a Merchant and a Service Provider?

When it comes to PCI, the distinction doesn’t always feel clear cut. This is because it’s possible for an organisation to be both a merchant AND a service provider at the same time. And an organisation could assess only as a merchant and not as a service provider meaning that they have validated how they accept payment for their services, but not validated that the services that are provided are PCI DSS compliant. 

This becomes a very important thing to understand if you are a merchant and asking about your service provider’s PCI DSS compliance. If they provide you with any document other than SAQ D (Service Provider) or the AOC for SAQ D (Service Provider), then you have no guarantee the services you are using are compliant or that they have been been assessed.

You can read more about the differences between merchants and service providers when it comes to PCI DSS compliance and assessments. 

What’s Covered on This Page?

Why Should Service Providers Be PCI Compliant?

Service providers are not only There are a lot of reasons to look at becoming PCI DSS complaint, beyond being required to either by your bank or your customers. As more businesses move online, they are looking for ways to minimise the risk to their PCI compliance. The easiest way for them to do this is to use PCI compliant service providers.

Compliant service providers can make their customers’ compliance requirements easier. But if you aren’t compliant and your customer needs you to be, are you prepared to be included in every assessment for every customer that requires PCI compliance? Are you ready to change your business processes for each and every one of your customers?

While we aren’t saying that you won’t have to change your business processes to become a PCI compliant service provider, doing compliance yourself gives you the opportunity to drive how compliance fits into your processes rather than having to suddenly change things so that your customer doesn’t suddenly face the risk of non-compliance and blame it on you. A proactive approach to PCI DSS is much easier than a reactive approach.

You can read more about the benefits of becoming a PCI compliant service provider.

How Do I Become a PCI Compliant Service Provider?

The process for becoming PCI compliant is pretty similar for both merchants and service providers. There are a few extra requirements, but overall the process is the same. This means you need to:

  • Understand the services you want to demonstrate compliance on
  • Understand your scope
  • Understand your current state
  • Undertake an assessment appropriate for the level of assurance you require or for the level of assurance your key stakeholders require

You can read more about the process of becoming a PCI compliant service provider.

What’s My Scope?

As a service provider, scoping is still just as important as it is for merchants. In fact, in PCI DSS v4.0, service providers are expected to document and validate their scope every six months.

As a service provider, correctly defining your scope to cover the services you provide to your customer is vital. Otherwise the risk is that if you exclude a service your customer expected to be PCI DSS complaint, you’re back to almost square one since this could cause a problem for your customers and suddenly you have to participate in their assessment taking time away from the rest of your regular jobs.

You can read more about how to understand your scope.

What Are My Reporting Requirements?

As a service provider there’s a much more limited set of reports that can be used to attest to PCI compliance. Service providers must use either:

  • SAQ D (Service Provider)
  • Report on Compliance with Service Provider AoC

While there may be some controls that do not apply if you do not store cardholder data, you cannot leverage the same scope reduction controls that merchants use.

One new approach in PCI DSS v4.0 is the concept of “partial assessment” which may be used by service providers who test a sub-set of controls and have the remainder as “Not Tested”. The ROC Template suggests that this could be appropriate where:

“A service provider organisation might offer a service that covers only a limited number of PCI DSS requirements – for example, a physical storage provide may want only to validate the physical security controls per PCI DSS Requirement 9 for their storage facility.” – p. xii, PCI DSS v4.0 ROC Template Instructions

While a partial assessment can demonstrate compliance, it’s important to ensure that you’ve clearly defined which requirements are:

  • Your responsibility
  • Your customers’ responsibility
  • A shared responsibility between yourselves and your customers

If you aren’t clear on these responsibilities, there’s a risk that your customers may expect you to be responsible for something you are not.

You can read more about reporting requirements here.

Back to Basics

If you want to learn more about the specific requirements and go into more depth, we recommend heading back to our PCI Basics page to read about some of the requirements that apply regardless of whether you are a merchant, service provider, or multi-tenant service provider. 

And if you need some help on your compliance journey, Confide is here to help.