The Art of Reading a PCI Attestation of Compliance (AoC)

PCI Attestations of Compliance (AoCs) provide organizations with a tool that helps with the all-important aspects of third-party due diligence.  Yet many organizations don’t pay enough attention to the details of the AoCs they rely upon. AoCs are critical when engaging with and monitoring third-parties for PCI compliance. Running an effective compliance program requires at a minimum that you:

• Collect current AoCs from your third party service providers
• Understand the details of the AoC and how they impact you.

Waiting for your annual assessment to discover errors and omissions in these documents may result in delays, changes to your PCI DSS scope, and/or additional assessment activities. In turn this can lead to additional costs, and even non-compliance. This article will help you better understand AoCs and how they support your compliance journey.

Taking proactive steps can pay benefits through smoother validation. We show you key indicators to look for when reading and interpreting an AoC and we provide you with a detailed checklist to evaluate the quality of the AoC and assurance of your third parties. This article was inspired by many organizations and individuals that struggle with this task during assessments. The advice presented here is generally DSS version agnostic and applies equally to 3.2.1 and 4.0 unless specifically called out.

Outsourcing can be one of the simplest ways to reduce your PCI scope. While you can’t outsource the overall accountability for compliance, you can often outsource a lot of the detailed tasks and responsibilities. PCI DSS third party due diligence requires organizations to prove three things:

• Formal contracts exist covering PCI requirements and responsibilities
• Formal and detailed documentation of the responsibility split between your organization and your third parties (note DSS v4.0 raises the bar here)
• Ongoing evidence of third-party compliance monitoring

Without a clear understanding of what services your third party service providers perform for you and if they are validated, you may find you needing to exercise your “right to audit clause” (hopefully you have one) and bear the cost and effort of including that third party within the scope of your PCI assessment. If you are forced down this path, many service providers may resist and be ill prepared to address any non-compliant findings that may arise. 

We trust you will find this article and the supporting links at the end under "Learn More" both informative and useful.

What is an AoC?

An AoC (Attestation of Compliance) is a formal document that attests to the state of compliance of an entity at a point in time.  There are different attestation forms that reflect the level of validation and several special self-attestation forms where organizations may be eligible for simplified compliance using a subset of the full requirements of the Data Security Standard (DSS). 

AoCs for different compliance footprints: 

• The simplified use case AoCs apply only to merchant organizations completing Self-Assessment Questionnaires (SAQs).  Additionally, AOCs for large merchants completing Reports on Compliance (RoCs) can leverage the SAQ approach within the context of a RoC. These are typically submitted to acquirers, processors, and/or card brands who have teams that understand how to read and interpret these documents.
• Service Providers (third parties or TPSPs) must complete full assessments reporting on either an SAQ D-Service Provider or Report on Compliance. If your organization is relying upon a third-party’s compliance, then you will need to request and review AoCs from each TPSP to ensure they meet your requirements.

All AoCs appear similar but they reflect different levels of validation:

• Reports on Compliance (RoCs) are required for high volume merchants and service providers.  These comprehensive assessments validate documents, records, observations, test results, and samples and are performed by an approved assessor (i.e. QSA or in some cases an ISA) who documents the results in a RoC and AoC.
• SAQs are for organizations deemed lower risk due to factors like acceptance channels and transaction volume.  They are more concise and tend to be less thorough than a RoC. These assessments can be completed by an organization on their own or with assistance from a QSA or an ISA. The results are documented in an SAQ and AoC.

You can look at AoCs as reflecting a level of assurance of PCI compliance.  These aren’t a formal classification but are used as examples:

• Gold - where the AoC indicates a RoC was completed and countersigned by a PCI Security Standards Council trained and accredited professional (i.e. a QSA or ISA where permitted),
• Silver - where the AoC indicates an SAQ was completed with assistance by a QSA/ISA and countersigned. While still a self-assessment the QSA/ISA typically ensures consistency and advises on scope and other key matters. The AoC will clearly describe how the QSA assisted,
• Bronze - where the AoC was completed without a QSA/ISA.  There are no requirements on the person completing the AoC for any accreditation or formal training. Consequently there is greater risk of mistakes, misunderstandings, and inaccuracies. Note that we include the use of non-accredited consultants and PCIPs in the bronze category as there is no place for them to sign.

An AoC summarizes the scope and results of the assessment which is documented in more detail in the RoC or SAQ. These are generally considered confidential documents and not shared.  Note: DSSv4 SAQ’s will require more detail previous versions. Simply checking off requirements will no longer be acceptable.

When accepting AoCs from your service providers PCI does not mandate the type of AoC you must accept, only that you have reasonable assurance it has been completed correctly and covers the services your TPSP is providing. We recommend, as a best practice, that our customers seek TPSPs that perform regular RoCs. We also caution our customers that undergo their own RoCs on the risks of accepting service provider SAQs. While PCI and the card brands do not mandate which type of service provider AoC are accepted, some organizations contractually require their TPSPs to undergo RoCs. 

The AoC will tell you many important things including:

• What services they perform, which were assessed, 
• When the assessment was performed,
• The QSA company (or ISA) that signed off on their assessment,
• To what extent companies completing SAQ's were advised by a qualified assessor,
• If the service provider is leveraging a nested service provider relationship by outsourcing any functions of their service (ex: leveraging underlying cloud infrastructure),
• If the assessed service has been fully assessed in alignment with the PCI SSC scoping guidelines (Note: that PCI DSS v4 allows for compliant partial RoCs),
• If the service provider has excluded anything from the scope of their assessment for any reason.

 Why do we have signed AoCs and formally documented responsibilities:

• While third party assurance has been part of PCI since its inception, formal signoff wasn’t originally part of the standard. Early on, SAQs weren’t signed and as a result they weren’t taken seriously. Industry veterans have stories of service providers checking off yes to everything and sending it along, only to be breached with virtually none of the required controls in place. Their legal defense, that it’s just a questionnaire and they weren’t required to sign anything, can be filed under why we can’t have nice things. AoCs signed by company executives are better for the payment industry. Additionally in some countries, knowingly signing false documents is a criminal offence.
• Formal documentation of how responsibilities are divided (e.g. RACIs or similar) are a direct result of misunderstandings, assumptions, and sloppy due diligence. A simple example: Company X contracts with datacenter Y.  Y has an AoC for colocation but also provides services (e.g. OS patching) not covered by the AoC. If company X assumes datacenter service provider Y is compliant for all services, then patching could be overlooked and lead to breaches. More complex services often have more complex responsibilities.

Intent 

PCI and the card brands clearly want you to be able to rely on the compliance of third parties. Many processors and acquirers are required to register all service providers to ensure they are aware of the impact they may have to their merchants. Several of the card brands maintain lists of registered third-party service providers and their compliance status.

Provided compliance is properly demonstrated and documented in an AoC, there should be no need to challenge an AoC or inquire further. If you intend to rely upon this documentation, it is your responsibility to review it to ensure it is reasonable and consistent for your organization’s purposes. If there are problems or concerns with the AoC, then we recommend that you get clarification until you are comfortable.  You can always contact a QSA company to assist you in understanding the AoCs before your assessment or even as part of your onboarding risk assessment for new third-party service providers. 

AoC Quality Assurance – how hard can they be to read?

Surprisingly, many organizations struggle with correctly reading an AoC. Often people simply collect third-party AoCs for their annual assessment. Many barely look past the form for a current date and a signature. Others wait till their assessor reminds them. AoCs are far more than just a tick-box, there is a lot packed into these documents and even assessors can miss nuances.

Here are the things you should be looking at:

• Is it on the right form?  Service Providers must complete AoCs for RoCs or SAQ D-Service-Provider, anything else is a red-flag! We’ve seen countless examples of service providers presenting SAQ-A AoCs because they further outsource (nest) to other TPSPs – reject these. These are not valid compliance documents as service providers can only complete the SAQ D-Service-Provider or RoC AoCs.
• Is it for the correct DSS version?  With PCI DSS v3.2.1 being in effect since 2018, we don’t often see attestations on older forms; however, we expect to see more errors after PCI DSS v3.2.1 sunsets in March 2024 and v4.0 comes into effect. Wrong versions could be a red flag.
• Is it current?  Another red flag. If it’s not within the last 12 months, it’s expired. Your TPSP may still be compliant but your validation documentation is not. 
• Is it complete? Were any sections left blank? Missing information could be red flag. Missing dates or justifications for Not Applicable responses are common errors. Note this can be trickier as some parts can be blank (e.g. action plan if the entity is compliant or checking with a payment application vendor if the entity uses a service or has a custom application).
• Is it signed by an appropriate authority in the company? Is the signer an executive or officer who can legally bind the company? Obviously, this will vary between smaller, larger, or enterprise companies.
• Are the correct legal entities named? For example, if you contracted with “Awesome Acme Services, Inc.” but your AoC says “Awesome Acme Services Corporation”). This could be a red flag and you may not be covered. There is a place in the form for "Does Business As" (DBA) to cover other names an entity operates under. An assessor should flag any discrepancy here and require a solid clarification at a minimum. Assessors aren’t lawyers, we recommend that you should check with your legal or contract management team before accepting the AoC.
• Does it cover the services they are providing you? Incomplete or inconsistent services are another red flag. Follow the contracts and cross-check all the responsibilities.  A service provider needs to stand up for all the services they offer to you including the ones they outsource to their nested third parties! You have no direct relationship with their third parties, which means you have no effective means to manage them.  For example, if you outsource to Y and they don’t take responsibility for control H which they then outsource to Z then you are accountable for control H. Worse still, you have no direct relationship with Z and no leverage to demonstrate the compliance of service H.   
• Are they excluding any services or controls? This is closely related to the previous point. If they are certified only for a terminal gateway and are providing you e-commerce or other online services then you need to ensure that you obtain assurance over their additional service(s) through an additional or updated AoC. Note customizations and special use cases are often not covered by an AoC. 
• Were requirements evaluated as being “Not Applicable” or "Not Tested"?  Does the AoC document these with reasonable justifications and explanations. Note: that partial assessments using "Not Tested" are treated very differently between DSS 3.2.1 (non-compliant) and 4.0 (compliant). It is ok to ask your provider why they answered not tested or not applicable if the AoC does not clarify why. 
• Are they eligible for any claimed simplified compliance? A special case of the previous point. If the third party is aligning with a simpler compliance form, does their “Not Applicable” justification address the SAQ eligibility requirements (see Learn More).
• Are any documented dependencies clear and consistent? For example, does the payment application/solution reference correctly refer to a PA-DSS, Secure Software, P2PE, SPoC entry, etc (see below).  

Compliance “Certificates”

Some organizations provide compliance “certificates”. Let’s dispose of these quickly - these are wall art at best, or paper for lining the circular file in your office – they have no actual value or authority and are not recognized by the PCI council, card brands, or QSA/ISA companies. They don't replace an AoC.  If your service provider gives you one instead of an AoC, this is a red flag (see below). 

REDACTED AOC’S

If you receive a redacted copy of an AoC from a service provider, you should understand that this is allowed. There is an FAQ (see below) on this that talks about what is and is not permissible to hide. You should review this to make sure it meets your requirements. If needed information has been removed, you need to request a more complete document. 

• To service providers, we prefer to see documents that are blacked out, or include some marker of the redactions. Nothing is more confusing than seeing blank fields as these are guaranteed to generate a back-and-forth three-way discussion to clear things up.  
• Also, rather than redacting everything in a field or row, please be more selective e.g. Instead of “Toronto West Data Center; 1313 Mockingbird Lane for CDE Hosting”, “Toronto West Data Center (Address redacted) for CDE Hosting”, or “West Data Center (Address redacted)” rather than just blanks.

Are more third-parties requiring compliance?

As a trend, we have been seeing more third-parties that need to demonstrate compliance. Part of this has been due to organizations realizing the implications of security impacting services. However, increasingly this is due to a market shift from on-prem to as-a-service solutions. One challenge we see is that some organizations don't realize that shifting who-does-what represents a significant change with compliance implications. This should be caught by an organization's due diligence before the third-party or service is engaged. Beyond understanding how to read an AOC, engaging with your organization's procurement processes is one of the most important thing you can do to protect yourself. 

Uncertain about an AoC? 

What can you do if you have questions or concerns about an AoC you intend to rely on? It's helpful to remember that problems with AoC’s are usually due to misunderstandings or and assumptions and can be clarified by working through the problem.

• Your QSA can help articulate what you need and possible alternatives.
• Your service provider should be engaged to ensure they understand what is expected and what they can provide.
• Work with your acquirer (or other compliance accepting entity) to resolve the problems and keep them in the loop about delays and problems. They may also be able to help provide options. Your acquirer can also engage the card brands on your behalf if needed.
  

If things don’t work out, you may need to temporarily cover the issue inside your own PCI assessment.  If it cannot be resolved, you may need to consider changing providers. We’ve seen service providers that will admit they can impact security but steadfastly claim that they don’t need to comply with PCI DSS and refuse to validate. These can be challenging and may take time to resolve.

Patience may be required as we have also seen cases where a service provider just didn’t get it and repeatedly submitted incorrect documentation (expired, incomplete, wrong form, wrong entity, etc.) over an extended period.

In extremely rare cases, you may suspect something further is amiss - in these cases, don’t jump to conclusions, engage all relevant stakeholders including possibly legal.

Failure?

What happens when none of the options above work.  Your service provider won't or can't provide a usable AoC and responsibility document, you can't audit them, or including them in your audit finds non-compliance. Does this result in your organization failing PCI DSS? In short, if you exhaust all options and can still not show compliance - then yes. Note this topic is discussed extensively in the PCI Information Supplement: Third-Party Security Assurance.

Surprisingly, there is confusion in the industry over this possibly because people remember what they want to hear. A careful reading of FAQ #1312 includes:

• Your third party isn't required to validate independently, i.e, "Service providers do not need to be validated as PCI DSS compliant in order for the entity to meet Requirement 12.8" 
• Any services they perform for you need to be compliant, i.e. "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."
• Provides the authoritative reference to "Use of Third-Party Service Providers" in the PCI DSS Standard (either v3.2.1 or v4.0)

So, while you may not fail 12.8 as long as you're monitoring compliance, you could still fail other requirements. 

While no one wants an organization to fail because of a third party, this needs to be acknowledged as a possibility. At this point, involve your compliance accepting entity, e.g., merchant acquirer, card brand, etc. in a discussion about the path forward. Your service provider will need to be in the loop. Ultimately, whether you  continue to work with them or migrate away will depend on these discussions. You also need to work with your procurement and other internal teams to prevent similar failures in future. 

We also believe that with the increasing risk of non-compliant service providers, there should be more explicit highlighting of the risk and what is expected from the PCI Council and/or the Card Brands. 

More clarification is also desirable about how far this needs to be applied as not all types of service providers have equal risk. Some types of organizations with well defined offerings have their own mature industry regulations that could be more effective to rely upon (e.g. TLS certificate providers are subject to regulations under the CA/Browser Forum) than fitting their operations to PCI DSS. This will be a complex and nuanced discussion that industry needs to have.  

Learn More

We don't expect that you will always take our word for it, so as usual we have provided references and links to other articles and official PCI documents. 

Control Gap Articles

Control Gap articles include a mix of analysis and humorous articles designed to drive understanding of key PCI concepts. Our non-compliance lesson series are cautionary tales on how to make your assessments more exciting and unpredictable:

• Entities and responsibility for compliance (a humorous look at PCI due diligence and supply-chains through the lens of a Halloween story) https://www.controlgap.com/blog/the-entity-a-scary-pci-monster
• Our Non-Compliance lessons series (a humorous look at roads not to take on your way to compliance):
  
  
  • Scope Ignorance https://www.controlgap.com/blog/non-compliance-lesson-no-1
  • Fine Print https://www.controlgap.com/blog/non-compliance-lesson-no-2
  • Cloudy thinking https://www.controlgap.com/blog/non-compliance-lesson-no-4 
• Guidance, insight, and interpretation (where we look at commonly misunderstood areas and ways to simplify):
  
  
  • Compliance "footprints" i.e. which requirements apply to your environment https://www.controlgap.com/blog/pci-compliance-footprints
  • Scope and "Connected-to" https://www.controlgap.com/blog/connected-to-pci
  • Loosing control of scope https://www.controlgap.com/blog/why-did-my-pci-dss-scope-explode
  • Getting on top of PCI DSS https://www.controlgap.com/blog/6-ways-to-deal-with-the-magnitude-of-pci-dss

PCI SSC Guidance 

The PCI Council provides a number of useful FAQ's, Information Supplements, and Guidance documents:

• Third-Party Assurance https://docs-prv.pcisecuritystandards.org/Guidance%20Document/PCI%20DSS%20General/ThirdPartySecurityAssurance_March2016_FINAL.pdf and https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Third-Party%20Relationships/PCI-SSC-Connected-to-Service-Providers-Guidance.pdf
• Compliance certificates are worthless, FAQ #1220 https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/Are-compliance-certificates-recognized-for-PCI-DSS-validation/
• Simplification by aligning your compliance footprint with an SAQ, FAQ #1331  https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/Can-SAQ-eligibility-criteria-be-used-for-determining-applicability-of-PCI-DSS-requirements-for-onsite-assessments
• Redacted AoC's, FAQ #1354 https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/Can-a-service-provider-redact-information-in-the-PCI-DSS-Attestation-of-Compliance-before-providing-it-to-customers
• Third-party service provider FAQs:
  
  
  • #1312 https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/If-an-entity-uses-a-service-provider-that-is-not-PCI-DSS-compliant-how-does-this-impact-the-entity-s-compliance/ 
  • #1282 https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/Can-an-entity-be-PCI-DSS-compliant-if-they-use-a-third-party-service-provider-TPSP-that-is-validated-to-a-previous-version-of-PCI-DSS/ 
  • #1065 https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/Should-service-providers-demonstrate-PCI-DSS-compliance-as-part-of-their-client-s-assessment-or-in-their-own-separate-assessment/ 
• The special role of Acquirers: 
  
  
  • #1284 https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/Are-acquirers-considered-service-providers-for-the-purpose-of-PCI-DSS-Requirements-12-8-and-12-9 
  • #1473 https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/What-is-the-role-of-compliance-accepting-entities-and-assessors-in-determining-the-applicability-of-PCI-DSS-requirements-for-merchant-and-service-provider-PCI-DSS-assessments/ 

PCI Solution Listings

The PCI Council maintains lists of variety of validated solutions, applications, devices.  The purpose of these lists is to provide reliable information on compliant solutions that can help reduce risks and ease your compliance burden:

• P2PE solutions https://listings.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_solutions
• Payment Applications/Software
  
  
  • Secure Software (new standard) https://listings.pcisecuritystandards.org/assessors_and_solutions/payment_software
  • PA-DSS (original standard) https://listings.pcisecuritystandards.org/assessors_and_solutions/payment_applications

• PTS devices (e.g. HSMs, POIs/terminals) https://listings.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices
• SPoC (Software PIN on COTS) https://listings.pcisecuritystandards.org/assessors_and_solutions/spoc_solutions

Compliant Service Provider Lists

Brands maintaining lists of compliant service providers:

• Master Card (search for 'Service Provider List') https://www.mastercard.com/globalrisk/en/resources/pci360.html
• Visa https://usa.visa.com/splisting/splistingindex.html