"For small and medium businesses, there is tremendous upside to outsourcing as much of your security and PCI compliance as you can. With the increasing cyber threats to payments data, using third-party providers for security and PCI compliance is a no-brainer because your resources and security investments are smaller than those of the largest enterprises."

It’s a no-brainer to outsource 100% of your PCI compliance

So, you’ve decided to outsource. Good decision! There are two critical assets that you will need to obtain from service providers as you research, evaluate, and buy solutions: AOCs and Responsibility Matrices.

What is an AOC?

Definition: Acronym for “attestation of compliance.” The AOC is a form for merchants and service providers to attest to the results of a PCI DSS assessment, as documented in the Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC).

Glossary of Terms, Abbreviations, and Acronyms v3.2

To put it simply, an AOC is a document that offers proof a merchant or service provider has completed an SAQ or ROC and is PCI compliant. For a merchant, the service provider’s AOC can be relied upon for meeting some of your organization's PCI requirements. Because it is a document that can prove compliance, an AOC can correctly be considered a piece of "Third-Party Proof" (abbreviated 3PP).

Here is the Council’s Document Library for SAQs and AOCs.

Note that the term ‘entity’ is used by the Council when referring to both merchants and service providers. However, unless we are talking about service provider specific compliance issues like completing an SAQ D-SP, we will tend to use the term ‘merchant’ instead of ‘entity’ for ease of communication. A Responsibility Matrix

What is a Responsibility Matrix?

Definition: A PCI DSS responsibility matrix, also known as a Responsibility Matrix, clarifies how responsibilities for maintaining PCI DSS requirements are shared between a merchant and their Third Party Service Provider (TPSP), which we refer to as a PCI provider.

A Responsibility Matrix in its most basic form consists of a list of requirements (PCI DSS) and indicates which requirements are the responsibility of the PCI provider, the merchant, or will be shared between them. It should also contain notes to clarify the details of implementing or fulfilling each responsibility. Because a Responsibility Matrix can not contribute to proving PCI compliance, it does not qualify as a piece of "Third-Party Proof".

Example of a PCI DSS Responsibility Matrix

PCI DSS Responsibility Matrix

Third-Party Security Assurance, v1.1 March 2016 - Appendix B: Sample PCI DSS Responsibility Matrix p43

Whether you are constructing a Responsibility Matrix as a PCI provider, or you are relying on one as a merchant, then the information that needs to be represented for each requirement should include:

  • How does the service provider perform, manage, and maintain the required control?
  • How is the control implemented, and what are the supporting processes? e.g., a process for patch updates would include details of testing, scheduling, approvals, etc.
  • How and when will the service provider provide ongoing assurance and evidence to the merchant that controls are met? e.g., periodic reports, real-time notifications, results of testing, etc.

Can you prove your PCI provider is compliant?

Many small and medium businesses now follow the best practice of fully outsourcing their security and PCI compliance to third party service providers, i.e., PCI providers. Most PCI providers need to be PCI compliant themselves and must support their customers’ need for proper evidence of their PCI compliance.

If you are a merchant or service provider that relies on PCI providers, there are two methods of documenting your service provider’s compliance with PCI:

Method 1

Obtain your service provider’s Attestation of Compliance (AOC). Their AOC must be a result of a Report on Compliance (ROC) or Self-Assessment Questionnaire D for Service Providers, also known as SAQ D-SP.

For small merchants this method is the only realistic way of proving your PCI providers’ compliance.

An AOC must:

  • Be provided on the PCI Security Standards Council (PCI SSC or Council) official documentation.
  • Clearly identify the service(s) your service provider is supplying to you (see Part 2a. Scope Verification),
  • Clearly identify the summary of requirements tested (see Part 2g. Summary of Requirements Tested) and
  • Clearly identify the date of completion (see Section 2: The assessment documented in this attestation and in the SAQ was completed on) must be less than one year from the date of completing your merchant’s Self-Assessment Questionnaire (SAQ).

Accept nothing less than an official AOC

Today, it can be needlessly difficult to obtain an AOC from many service providers. AOCs are designed to be easily obtained public documents of proof of compliance, so take it as a red flag, and proceed with caution, when an AOC is not easily obtained from a provider you want to use. Many providers have a history of avoiding AOCs by handing out “Passing (ASV) Scan Certificates,” decorative PCI Compliance Certificates (meant for wall mounting), or self-produced “we’re not required to be PCI compliant” statements. Accept nothing less than an official AOC.

In 2015, the Council issued an FAQ directly addressing the unacceptability of other types of compliance documentation or certificates, and clarified the requirement for official (PCI SSC) documentation:

The only documentation recognized for PCI DSS validation are the official documents from the PCI SSC website.  Any other form of certificate or documentation issued for the purposes of illustrating compliance to PCI DSS or any other PCI standard are not authorized or validated, and their use is not acceptable for evidencing compliance. The use of certificates or other non-authorized documentation to validate PCI DSS Requirement 12.8 and/or Requirement 12.9 is also not acceptable.Are compliance certificates recognized for PCI DSS validation? (July 2015 Article Number 1220)

Bottom line:

  • If you are a PCI provider, make your AOC easy to obtain.
  • If you are a merchant, an AOC is a pragmatic method for proving your service providers’ PCI compliance.

Method 2

Annually audit the service provider as part of your organization's PCI compliance validation. Not practical, but allowed if you choose to use non-compliant service providers.

Service providers have a choice. They can choose to be audited by tens, hundreds, or thousands of customers every year, or they can provide an AOC. The customer audits are very expensive in time and money, and the alternative just requires employing a QSA company or performing a self-assessment, once a year, to produce an AOC for all your customers.

Why do I need a Responsibility Matrix?

Every merchant and service provider who must validate their PCI compliance is required to identify, list, evaluate and monitor the PCI compliance of the services outsourced to their service providers;  see PCI DSS Requirements 12.8.1 through 12.8.5.

Specifically, the Responsibility Matrix addresses Requirement 12.8.5 (SAQ Question) “Is information maintained about which PCI DSS requirements are managed by each service provider, and which are managed by the [merchant/]entity?”

While there is no specific format or wording defined to meet the requirement, the guidance and sample responsibility matrix provided on page 43 in the PCI SSC’s Information Supplement on Third-Party Security Assurance (suggested reading or at least skimming) is a good place to start.

Where a service provider supplies multiple services, each service should have its own Responsibility Matrix. Each Responsibility Matrix should be accompanied by an AOC extra form for Service Providers - Section 2g clearly identifying the service being supplied. Click here to download the appropriate form.


Request AOCs and Responsibility Matrices from each service provider you consider during your outsourcing project. This will substantially improve your understanding of the services you are outsourcing and the provider’s ability to meet your compliance requirements.

You may also like:

Why is it so damn hard to get an AOC from a PCI provider?!