In this blog, we turn our attention to service providers. The PCI Security Standards Council defines a service provider a ‘business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data’. So yes, a payment processor is a service provider! Other examples include managed service providers (MSPs) that provide managed network devices (firewalls, IDS), as well as any organisation that processes payments on behalf of others, for example, organisations offering fundraising services.
It’s important to note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider if the goods and/or services sold result in the storing, processing or transmitting of cardholder data (CHD) on behalf of other merchants or service providers. For example, an Internet service provider (ISP) is a merchant that accepts payments for the provision of Internet access i.e., its own services, but may also be considered a service provider if it provides hosting services to merchants processing their own payments.
Service providers, on the other hand, don’t always know that they are service providers and consequently, are not aware of their responsibilities. As we said above, a service provider is a business entity that is not a payment brand, directly involved in the processing, storing or transmitting of CHD on behalf of another entity.
The processes involved in the validation of compliance for service providers vary according to payment card brand. Validation and reporting requirements for service providers are defined according to the service provider level (i.e,. the transaction volume and/or type of service provider).
Visa, Mastercard, American Express, UnionPay and Discover categorise service providers according to these criteria. Additionally, these same brands have two or more distinct service provider levels that are defined by transaction volume. JCB does not categorise service providers according to transaction volume.
In general, there are 2 ways in which a service provider can validate its PCI compliance:
If a service provider processes, stores and/or transmits transactions for JCB, or if the service provider processes, stores and/or transmits more than 300,000 Visa, Mastercard, American Express, UnionPay or Discover transactions, it is considered a Level 1 service provider. These Level 1 service providers must obtain an annual RoC, prepared by a QSA, and undergo quarterly vulnerability scanning by an ASV.
If the service provider processes, stores and/or transmits fewer than 300,000 Visa, Mastercard, American Express, UnionPay or Discover transactions, it is considered a Level 2 service provider. These service providers must validate their PCI compliance by preparing SAQ D (variant specific to service providers) and undergo quarterly vulnerability scans by an ASV.
So, hopefully, that has provided some much-needed clarity. The key point is to understand what you are i.e., a merchant or service provider, and then your transaction levels per brand. It is important that you don’t just look at the volume of transactions you are doing today. What are your growth plans? Do you expect to fall into the next bracket next year? If yes, focus your compliance programme on the next level up.
If your organisation has received a request for a SOC 2 report and is looking to meet all the necessary requirements, URM can offer you informed guidance and practical support.
URM can help you achieve ISO 27001 certification
URM can provide a range of ISO 27002:2022 transition services including conducting a gap analysis, supporting you with risk assessment and treatment activities as well as delivering a 2-day transition training course.
URM is sharing its experiences on how the changes to the PCI DSS v4 affect the assessment process and how organisations can best prepare for the differences.
We are often asked, both by those new to PCI DSS and those who have been involved for a while....
URM’s blog drills down into the PCI DSS v4.0 requirements around forced password changes, with a particular focus on the addition of zero-trust architecture.