Frequently Asked Question
If an entity uses a service provider that is not PCI DSS compliant, how does this impact the entity’s compliance?
Each payment brand may have their own requirements for using compliant service providers. Entities should contact their acquirer (merchant bank) or the payment brands directly to understand any requirements they have. Whether a service provider is required to validate PCI DSS compliance is determined by the individual payment brands.
There are many different scenarios where an entity, such as a merchant, may share cardholder data (CHD) or outsource elements of their cardholder data environment (CDE) to a service provider. In all scenarios, the entity must manage their service providers in accordance with Requirement 12.8. This includes performing due diligence, having appropriate agreements in place, identifying which requirements apply to the entity and which apply to the service provider, and monitoring the compliance status of service providers at least annually. Requirement 12.8 does not specify that the entity’s service providers must be compliant, only that the entity monitor their compliance status. Service providers do not need to be validated as PCI DSS compliant in order for the entity to meet Requirement 12.8.
If, however, a service provider provides a service that is in scope for the entity’s PCI DSS requirements, then the compliance of that service will impact the entity’s compliance. For example; if an entity engages a service provider to manage their firewalls, and the service provider is not meeting the applicable requirements in PCI DSS Requirement 1, then those requirements are not in place for the merchant’s compliance. As another example, service providers that store cardholder data on behalf of other entities would need to meet the applicable requirements related to access controls, physical security etc., in order for their customers to consider those requirements in place.
A service provider may be able to demonstrate that they’ve met the applicable requirements without undergoing a formal compliance validation. Refer to the “Use of Third-Party Service Providers / Outsourcing” section in PCI DSS v3 for guidance on how service providers may provide evidence of their compliance to their customers.
There are many different scenarios where an entity, such as a merchant, may share cardholder data (CHD) or outsource elements of their cardholder data environment (CDE) to a service provider. In all scenarios, the entity must manage their service providers in accordance with Requirement 12.8. This includes performing due diligence, having appropriate agreements in place, identifying which requirements apply to the entity and which apply to the service provider, and monitoring the compliance status of service providers at least annually. Requirement 12.8 does not specify that the entity’s service providers must be compliant, only that the entity monitor their compliance status. Service providers do not need to be validated as PCI DSS compliant in order for the entity to meet Requirement 12.8.
If, however, a service provider provides a service that is in scope for the entity’s PCI DSS requirements, then the compliance of that service will impact the entity’s compliance. For example; if an entity engages a service provider to manage their firewalls, and the service provider is not meeting the applicable requirements in PCI DSS Requirement 1, then those requirements are not in place for the merchant’s compliance. As another example, service providers that store cardholder data on behalf of other entities would need to meet the applicable requirements related to access controls, physical security etc., in order for their customers to consider those requirements in place.
A service provider may be able to demonstrate that they’ve met the applicable requirements without undergoing a formal compliance validation. Refer to the “Use of Third-Party Service Providers / Outsourcing” section in PCI DSS v3 for guidance on how service providers may provide evidence of their compliance to their customers.
May 2015
Article Number: 1312
