Service Provider PCI DSS Compliance: How to Review an Attestation of Compliance
As a PCI DSS QSA we frequently see both merchants and service providers that are failing to adequately validate their supplier chain’s compliance with the PCI DSS. This is always worrying, considering the inter-connected nature of many payment environments and the distributed systems they are built atop.
With an increasing market shift towards outsourcing in-scope services (with services ranging from secure telephony platforms through to outsource Security Operations Centres), conducting proper due-diligence has never been more vital to the protection of cardholder data. This is especially true when we look at the PCI DSS definition of a servicer provider:
“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.”PCI Data Security Standard, version 3.2.1
The days of receiving and filing an AOC without studying it should be long-gone. In this resource, we look at a fictitious service provider’s Attestation of Compliance, and provide insights and examples of what checks you should be performing.
If you are following the advice set out here, you will have a solid foundation on which to verify your service provider’s compliance with the PCI DSS.
How to review a Service Provider AOC
The AOC has three sections, each of which contains a number of sub-sections. For an AOC to be valid, these sections must be completed according to the PCI DSS reporting requirements, as outlined below.
Type of AOC
The first and most important part of an AOC to verify is the type and version. Before proceeding to other sections, ensure that you are reviewing the Attestation of Compliance for Onsite Assessments – Service Providers with a version that matches the current version of the PCI DSS (currently 3.2.1):
Section 1: Assessment Information – Part 1a
Part 1a of the AOC contains details of the service provider. This section must be completed:
Section 1: Assessment Information – Part 1b
Part 1b of the AOC contains details of the PCI Qualified Security Assessor (“QSA”) that performed the onsite assessment. This section must be completed with the details of the QSA:
Additionally, the reviewer may wish to verify the credentials of the PCI QSA company by searching for the company name on the PCI SSC website.
Section 1: Assessment Information – Part 2a
Part 2a of the AOC contains details of the service that is validated using this document. To meet your own compliancy requirements, the name of the service that has been assessed, must match the service (or services) that you are purchasing from the service provider. This field must be completed:
As an example, if the AOC has been issued by a PCI QSA to attest to the compliance of the service provider’s DTMF Platform, but you had actually purchased an e-commerce gateway from the provider, the AOC could not be used to verify compliancy of that e-commerce gateway. Instead, the reviewer must request another AOC from the service provider that attests to the compliance of the e-commerce gateway.
Section 1: Assessment Information – Part 2b
Part 2b of the AOC contains details of services that have not been assessed by the PCI QSA as part of the provider’s onsite assessment. It is usual here to see a response of “Not applicable”. However, if a service has been named here, the reviewer must enquire as to whether this service is being used within the scope of compliance:
Section 1: Assessment Information – Part 2b (continued)
Part 2c of the AOC contains a high-level description of the service provider, including details of whether they are involved in the storage, processing, or transmission of cardholder data, or whether they have the ability to impact on the security of cardholder data in any way.
This section must always be completed with enough detail for the reviewer to fully understand the impact that a service provider may have on your own compliancy with the PCI DSS. One, or both, of these fields may be completed. For example:
Section 1: Assessment Information – Part 2c
Part 2c of the AOC contains a description of the locations that have been included in the onsite assessment. This section must contain at least one location:
Section 1: Assessment Information – Part 2d
Part 2d of the AOC includes details of any Payment Applications that are in-use by the service provider. It is quite usual here to see a response of “Not applicable”:
However, if a Payment Application has been named here and the AOC states that it is ‘PA-DSS Listed,’ the reviewer may wish to verify the payment application on the PCI SSC website.
Section 1: Assessment Information – Part 2e
Part 2e of the AOC provides a high-level description of the service provider’s cardholder data environment. This field must be completed with enough detail for the reviewer to understand the service provider’s scope of compliancy. For example:
Section 1: Assessment Information – Part 2f
Part 2f of the AOC lists the third-parties that are utilised by the provider in delivering its services. It is quite usual here to see a response of “Not applicable”:
Section 1: Assessment Information – Part 2g
Part 2g of the AOC provides details of the PCI DSS Requirements that have been tested. This is perhaps the most important part of the entire document: by reading this section, you are able to understand those PCI DSS Requirements are maintained by the service provider, and those that you should maintained.
Within this section, the AOC must identify whether a Requirement has been fully met, partially met, or not assessed. For all responses other than ‘Full,’ a justification must be provided.
Importantly, the AOC should contain a Part 2g form for each service that is identified in Part 2a:
Section 2: Report on Compliance
Section 2 of the AOC contains details of the onsite assessment. This section must be completed:
Note: the responses in this Section 2 should match those responses contained within Part 2g. Additionally, the assessment date should not be greater than the date of the AOC.
Section 3: Validation and Attestation Details – Part 3
Part 3 of the AOC contains the service provider’s validation details. This section must be completed, however if a response other than ‘Compliant’ is documented here, the reviewer must investigate further:
Note: The assessment date should match that which is contained within Section 2.
Section 3: Validation and Attestation Details – Part 3a
Part 3a of the AOC contains further details on the service provider’s validation details. This section must be completed, and the responses should match the details contained in the preceding sections of the AOC:
Note: The versions of the PCI DSS documented in this section should relate to the currently-published version of the PCI DSS, unless we are within a sunset period where merchants and service providers are transitioning between versions of the PCI DSS.
Section 3: Validation and Attestation Details – Part 3b
Part 3b of the AOC contains the Service Provider Attestation. This section must be completed by an officer of the service provider:
Section 3: Validation and Attestation Details – Part 3c
Part 3b of the AOC contains the PCI QSA Acknowledgment. This section must be completed by an officer of the PCI QSA company. Importantly, this section must contain a description of the QSA’s assessment:
Section 3: Validation and Attestation Details – Part 3d
Part 3d of the AOC contains details of the involvement of an Internal Security Assessor. It is quite usual here to see a response of “Not applicable”:
Part 4: Action Plan for Non-Compliant Requirements
Part 4 of the AOC contains details of where the service provider has failed to achieve compliancy with a PCI DSS Requirement. It would be very usual here to see any content in this section. If any of the Part 4 page has been completed, the reviewer must investigate further:
What are you waiting for?
Discover our programmatic solutions to your complex security challenges: contact the team at Data Security People for an informal chat.