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.
Get Started with PCI ComplianceStart Here
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.
What makes me a service provider?
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.
We do not store, process, or transmit cardholder data for our clients. Why are they asking for an AOC?
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.
What options are there for service providers to validate PCI DSS compliance? What option is right for us?
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.
As a service provider, what documentation should I be providing to my customers to assist with their PCI DSS compliance efforts?
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.
How do service provider ROC assessments and merchant ROC assessments differ?
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.
These additional service provider-only requirements include:
- PCI DSS requirement 3.5.1: Service providers who store cardholder data are required to maintain a detailed description of the provider's cryptographic architecture
- PCI DSS requirement 8.5.1: Service providers who have the ability to authenticate systems within their customers' cardholder data environments are required to have separate authentication credentials for each customer. This would prevent a single stolen credential from being used to compromise the security of multiple merchant accounts.
- PCI DSS requirement 10.8: Service providers are required to have a process to detect and report failures of critical security controls in a timely manner. A process for responding to and correcting detected failures must also be in place.
- PCI DSS requirement 18.104.22.168: If a service provider makes use of network segmentation to decrease the scope of their CDE, they must perform segmentation validation testing at least every six months to ensure segmentation is functioning as expected.
- PCI DSS requirement 12.4.1: Service providers must establish a PCI DSS compliance program that assigns responsibilities of maintaining PCI DSS compliance and defines methods for communicating compliance status with executive management.
- PCI DSS requirement 12.9: As discussed above, service providers are required to provide in writing an acknowledgment of their responsibility to protect cardholder data they store, process, or transmit on behalf of their customer or to the extent that the provider can impact the security of their customers' data or CDE.
- PCI DSS Requirement 12.11: Service providers are required to perform quarterly staff responsibility reviews to ensure key security policies and operational procedures required to maintain PCI DSS compliance are being performed. Reviews must be documented and approved according to processes defined by the organization’s PCI DSS compliance charter.
As a Service Provider that has not been through PCI DSS compliance before, how do I get started?
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.