pci dss compliance for service providers is necessary if your organization provides services to merchants that may affect the security of their merchant payment data.
As the name implies, a service provider, in regards to PCI DSS, is an entity that provides services to its customers. Some service providers are directly involved in the capture, processing, storage, or transmission of cardholder data for their merchant clientele.
Examples of these types of service providers include payment gateways, tokenization providers, hosted e-commerce shopping cart providers, etc. Some service providers do not store, process, or transmit cardholder data directly but focus on providing services designed to simplify or secure their client’s payment environments.
If your organization provides services to merchants that may affect the security of their merchant payment data, there are PCI DSS implications that should be considered. Let’s take some time to answer some of the most common questions we receive from service providers.
According to the PCI DSS Glossary of Terms, Abbreviations, and Acronyms, a service provider is a:
“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities.”
If your business can affect the security of payment data belonging to another organization, you are considered a service provider. This is true even if your organization doesn’t store, process, or transmit cardholder data directly.
As was discussed above, a service provider who can affect the security of a merchant’s cardholder data environment (CDE) is considered “in-scope” for the merchant assessment. When a merchant chooses to engage a third party to provide services that can impact the security of their CDE, they are responsible for ensuring their third-party providers are following applicable PCI DSS requirements.
For example, if a merchant has engaged a company to provide managed firewall services, the merchant will either need an Attestation of Compliance (AOC) from their provider demonstrating that the provider is in compliance with the firewall-related PCI DSS requirements, or they will need to include their provider when performing their merchant assessment.
Similarly, companies who provide data center services, web hosting, web application firewall (WAF) services, software development, or patch management services may also be asked to provide a copy of their AOC or be included in a merchant’s PCI DSS assessment if the services being provided affect the security of the merchant’s data or their CDE.
See also: Get my free SecurityMetrics PCI Guide
Service providers can have their environment assessed to validate its compliance with the PCI Data Security Standard and then provide either an SAQ D for Service Providers or Report on Compliance (ROC) AOC to their customers to demonstrate their PCI DSS compliance status.
Level 1 service providers are required to have a Qualified Security Assessor (QSA) perform a ROC-based assessment annually, while Level 2 service providers have the option of performing a self-assessment of their compliance status using the SAQ D for Service Providers. No other self-assessment questionnaire can be used for service provider attestation.
The card brands (Visa, Mastercard, American Express, and JCB) determine service provider levels. As a general rule of thumb, if your organization assists in the transmission or processing of over 300,000 transactions in a given year, you are likely a Level 1 service provider. Some service providers, like data center providers, may be able to self-validate based on transaction volume but will often validate as a Level 1 service provider if they support customers who are required to undergo a Level 1 ROC assessment by a QSA.
Merchants are required to validate the PCI DSS compliance status of their service providers on an annual basis. This is typically accomplished by receiving a copy of the service provider's Attestation of Compliance (AOC) or SAQ D for Service Providers AOC for Level 2 service providers.
In addition to evidence of compliance, service providers must also acknowledge in writing their responsibility to protect the cardholder data the service provider has access to or can otherwise impact the security of (see PCI DSS requirement 12.9).
Merchants are also required to document which PCI DSS requirements are managed by each of their service providers (PCI DSS requirement 12.8.5).
In cases where the line between provider and customer responsibility may not be obvious, many providers have opted to create a detailed PCI DSS responsibility matrix that lists each PCI DSS requirement and assigns responsibility for that requirement to either the provider, the customer, or both. Public cloud providers are a great example of this type of nuanced relationship that could use a well-documented approach to responsibility assignment.
If a merchant were to experience a data security breach, the attacker could potentially gain access to all payment data collected by that merchant.
If a service provider were to experience a severe data breach, it could potentially put cardholder data from multiple merchants at risk.
To help address the increased risk a service provider environment could bring to payment card data, service providers have several additional security requirements that must be validated as part of their assessment. While these are service provider-only requirements, merchants would be well served to implement many of these same controls in their merchant environments.
The best place to start any internal PCI DSS compliance review is by performing a scoping exercise. The PCI Security Standards Council has developed a guide (Guidance for PCI DSS Scoping and Segmentation) that explains the process for performing a scoping exercise.
During a scoping review, you will identify any data flows that contain cardholder data. This flow review will help to identify the systems, processes, and people involved in the capture, processing, storage, or transmission of cardholder data. Once you have appropriately defined the scope of the environment, you can then begin to review security controls defined in the PCI DSS to determine if the appropriate controls are in place to protect these data flows.
For service providers who are not directly involved in the transmission or processing of cardholder data, focus your attention on defining how your services may affect the security of your customer’s payment card environments. Identify which PCI DSS requirements you are managing on behalf of your customers then focus your internal review on verifying those requirements are being met in accordance with the standard.
SecurityMetrics provides consulting services with Qualified Security Assessors who can help guide your internal review. PCI Gap Assessments can be used to help you identify where your PCI DSS compliance is lacking and provide you with suggestions for addressing compliance gaps.
.svg)
