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 compliance and merchant compliance are pretty similar. The main difference is that service providers have a few more requirements that they need to comply with. On this page, we cover some of the basic things to help service providers understand why PCI compliance matters, what it means for you, and some help on how to get there.
What’s the Difference Between a Merchant and a Service Provider?
When it comes to PCI, the distinction is not always clear cut. An organisation can be both a merchant and a service provider. And an organisation may decide to only be assessed as a merchant but not as a service provider. That’s why it’s important for both merchants and service providers to understand what the difference is between these and why you might want to (or need to) be assessed as both.
At the heart of it, a merchant is anyone who directly accepts payments via credit or debit cards that have the logos of one of the five card brands that are members of the PCI SSC (American Express, Discover, JCB, MasterCard, or Visa).
A service provider is anyone who is not a payment brand that is directly involved in either:
- The storage, processing, or transmission of cardholder data on behalf of another entity OR
- Providing services that control or could impact the security of cardholder data.
Read more about the differences between merchants and service providers when it comes to PCI compliance and PCI assessments.
Why Should Service Providers Be PCI Compliant?
Service providers are responsible not only for their customers’ data, but also for their customers’ customers’ data. There are lots of reasons to look at becoming PCI compliant (beyond being required to be either 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, are you prepared to be included in every assessment for every customer that requires PCI compliance? And are you ready to change your business processes for your customers?
While you may have to change your processes to become PCI compliant, doing compliance yourself gives you the opportunity to drive how compliance fits into your processes rather than having to change things so that your customer doesn’t suddenly face the risk of non-compliance. A proactive approach to PCI is much easier than a reactive approach.
Read more about the benefits of becoming a PCI compliant service provider.
How Do I Become a PCI Compliant Service Provider?
The process of becoming a PCI compliant service provider is very similar to the process of becoming a PCI compliant merchant. There are a few differences and a few extra requirements. But overall, the process is the same. That means that you need to:
- Understand your scope
- Understand your current compliance state
- Undertake an assessment appropriate for the level of assurance you require or or the level of assurance your key stakeholders require.
Read more about the process of becoming a PCI compliant service provider here.
What’s My Scope?
As a service provider, your scope might be somewhat different from a merchant. The important thing to understand is how your scope for your assessment affects the scope for your customers. For example, if your customers are relying on you to be responsible for a requirement as part of the service, if it is not included in your Attestation of Compliance, you might need to be able to demonstrate that you are providing the service and providing it in a compliant manner to anyone who needs it. That’s why it’s so important to understand what your scope is as a service provider, since a gap in your scope might be a much bigger problem for your customers than you originally realised.
Scoping is a key part of PCI compliance, so understanding which systems are in-scope, how you can make systems out-of-scope, and what being in-scope actually means is vital to understanding your scope, documenting your scope, and hopefully, minimising your scope.
Read more about how to understand your PCI scope.
What Are my Reporting Requirements?
Service providers have a much more limited set of reports that they can use to attest to PCI compliance. Service providers must use either:
- SAQ D for Service Providers or
- Report on Compliance (Service Provider)
You can read more about the reporting requirements and what that means for you here.
Back to Basics
If you want to learn more about some of the specific requirements and go into more depth, head back to our PCI Basics page and read about some of the requirements that apply whether you are a service provider or a merchant.
And if you need some help with your PCI, Confide is here to help you.
Common Service Provider Questions
The simple answer is “no”. Vulnerability scans and penetration tests are two different things, both of which may need to be performed as part of your PCI requirements.
PCI defines the difference between penetration tests and vulnerability scans in their Information Supplement on Penetration Testing.
While penetration testing may include vulnerability scanning in the initial phases or as part of their testing, the primary difference is that vulnerability scans are primarily automated while penetration testing is primarily a manual task.
Yes – if you accept credit or debit cards for the purchase of goods or services and you signed up with a merchant agreement with your bank, you are probably required to be compliant as a merchant.
If you perform a service for other businesses and you are involved in their transactional activities or look after a service that affects their PCI compliance, you’re probably required to be compliant as a service provider (or be involved in every customer’s PCI assessment who needs one).
PCI DSS has different requirements for how you have to assess your compliance depending on the number of transactions that you store, process, or transmit on an annual basis. However, there may be other considerations, such as:
- The value of your transactions
- Whether you have had a breach
- The type of transactions (for example, higher risk transactions)
Typically though, your level will focus on the number of transactions you store, process, or transmit yourself or on behalf of your customers.
|Merchant Level||Number of Transactions (Annual)||Payment Channel||Assessment Requirements|
|Level 1||6+ Million||All Channels||Annual Onsite Assessment (RoC) by a QSA|
|Level 2||1 - 6 Million||All Channels||Self-Assessment Questionnaire (SAQ) by an ISA|
Onsite assessment by a QSA (MasterCard)
|Level 3||20,000 - 1 Million||E-Commerce||Self-Assessment Questionnaire (SAQ)|
|Level 4||Up to 1 Million||All Channels||Self-Assessment Questionnaire (SAQ)|
|Fewer than 20,000||E-Commerce||Self-Assessment Questionnaire (SAQ)|
Service Provider Levels
|Service Provider Levels||Transaction Volume (Annually)||Assessment Type|
|Level 1||More than 300,000 transactions||Report on Compliance (RoC)|
|Level 2||Fewer than 300,000 transactions||Self-Assessment Questionnaire (SAQ)|
A Report on Compliance (or RoC) is the report that is completed by your Qualified Security Assessor (QSA) documenting the outcome of your onsite assessment. A RoC is required for all Level 1 merchants and service providers. It may also be required for lower Level merchants and service providers if requested by your bank or by another entity.
You can find the reporting template used for assessments on the PCI SSC Website (search for Reporting Template). This document will help you understand each of the testing processes and types of documents and interviews that are required to be completed during the assessment. We will help you understand the material, but the easiest way to make your assessment as smooth as possible is to ensure that you’ve reviewed not only the PCI Standard, but also the testing procedures.
If you’ve ever heard the term SAQ (sometimes pronounced like “sack”), they are referring to a Self-Assessment Questionnaire.
PCI allows merchants who only process a certain number of transactions annually to complete a SAQ.
If you are a service provider and are able to self-assess, the only SAQ you are allowed to use is SAQ D (Service Provider).
Merchants are required to submit one or more SAQs based on the payment channel or channels that you support. You should always get confirmation from your acquiring bank on which SAQ or SAQs they need you to submit. Especially if you have multiple payment channels.
Each SAQ has a set of criteria that you must meet in order to use that SAQ. If you do not meet these criteria, you will need to use a different SAQ. If you aren’t sure, please contact your bank. For every SAQ except D, you must confirm that you do not store any cardholder data. A data discovery tool (for example, card scanning) can be used to demonstrate that you do not store cardholder data.
The table below provides a quick summary of each of the SAQs.
|SAQ||Summary of Payment Channels|
|A||Card-not-present merchants that have fully outsourced all cardholder data functions to PCI DSS validated third-party service providers. No storage, processing, or transmission of cardholder data on the merchant systems or premises.|
|A-EP||E-commerce merchants who outsource all payment processing to PCI DSS validated third parties and who have one or more websites that don't directly receive cardholder data but can impact the security of the payment transaction. No storage, processing, or transmission of cardholder data on the merchant systems or premises.|
|B||Merchants using either imprint machines and/or standalone, dial out terminals. No electronic storage of cardholder data. No e-commerce.|
|B-IP||Merchants using standalone PTS-approved payment terminals with an IP connection to the payment processor. No electronic storage of cardholder data. No e-commerce.|
|C||Merchants with payment application systems connected to the internet. No electronic storage of cardholder data. No e-commerce.|
|C-VT||Merchants who manually enter a single transaction at a time via a keyboard into an internet-based virtual terminal solution provided and hosted by a PCI compliant third party service provider. No electronic storage of cardholder data. No e-commerce.|
|P2PE||Merchants using only hardware payment terminals included in and managed via a PCI SSC listed P2PE solution. No electronic storage of cardholder data. No e-commerce.|
|D (Merchant)||All other merchants not included in the descriptions above. Merchants with multiple payment channels. Merchants that store cardholder data.|
|D (Service Provider)||All service providers who are eligible to complete a SAQ.|
PCI DSS stands for the “Payment Card Industry Data Security Standard”. It is a set of requirements that all organisations who store, process, transmit cardholder data must comply with. It also applies to organisations who have the ability to affect the security of the storage, processing, or transmission of cardholder data.
At a high level, there are 12 main requirements in PCI DSS which include over 200 individual requirements each with their own testing processes within them.
For more about the basics of PCI DSS, see What is PCI DSS?
Service providers are limited to using SAQ D (Service Provider) or having a QSA complete a Report on Compliance.
Service providers cannot use any of the other SAQs to demonstrate PCI compliance to their customers.