Take the 2018 Third-Party Proof Survey

Available until the end of 2018

SEARCH POSTS:

Who needs an AOC? And why?

Who needs an AOC? And why? Many of our readers have likely heard of AOCs, but are looking for more information about this type of Third-Party Proof of Compliance (otherwise known as 3PP). One of the more frequently asked questions is, “Who needs an AOC?”, which this article will answer. The best place to begin is with the definition of an AOC. 

Here is the Council’s definition of AOC: 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 or Report on Compliance. 

From this definition, we see that Merchants and Service Providers need Attestations of Compliance. But why do they need AOCs to begin with? Looking back to the Council’s definition of AOC, we see the answer: “to attest to the results of a PCI DSS assessment.” This answer seems simple, but in truth, more details are needed to explain AOCs properly. One big factor to consider? The Council’s objectives or reasons for requiring a PCI DSS assessment (Payment Card Industry Data Security Standard assessment). Let’s begin digging deeper into AOCs by defining Merchants and Service Providers.

Who are Merchants?

The Council’s definition of Merchant: For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers.

A lot to digest, right? Let’s break it down for clarification. Merchants who accept payment cards, even just one, from - as the Council lists - American Express, Discover, JCB, MasterCard or Visa - must comply with PCI DSS. In 2016 it was reported that there were over 22 million merchants required to comply with PCI DSS - and the number seems to be growing rapidly. It is important to note that the PCI DSS does not apply to merchants who only accept cash, checks, crypto currencies, barter transactions, or payment cards that do not display a logo of any of the five members of the PCI SSC.

Why are AOCs important for Merchants?

The merchant AOC is generally produced as the result of performing an annual PCI DSS assessment, utilizing one or more of the Self-Assessment Questionnaires (SAQs). The completed SAQ and AOC are usually submitted to the merchant’s acquirer as evidence of the merchant’s PCI DSS compliance. For small transaction volume merchants (VISA Level 4), the acquirer is allowed to determine the method of merchant validation, including SAQs or simpler methods such as written, electronic, or voice interviews. Now that we have some clarification on what a Merchant is, let’s dig into the more complex definition of Service Providers.

Who are Service Providers?

The Council’s definition of Service Provider: 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 an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).

It is worth noting that the definition for Service Provider begins and ends with what is not. A Service Provider is a “Business entity that is not a payment brand,” (e.g. American Express, Discover, JCB, MasterCard or Visa). The Council’s definition also states, “...If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service…”. Therefore, we know that Card Brands and telecommunication providers are not Services Providers subject to PCI DSS compliance requirements. Companies (and their employees) that are trained, tested and certified by the PCI Security Standards Council (PCI SSC or Council) - including QSAs, PA-QSAs, P2PE-QSAs, ASVs, PFIs, and QIRs - are additional types of Service Providers that are not required to have a Service Provider AOC even though they do have active roles in the PCI ecosystem. These types of companies can be found in publically accessible listings on the Council’s website (see the Assessors & Solutions drop-down list), and these listings can be used to verify their current status. Note: Merchants may also be Service Providers. 

Companies providing services that do not control or do not impact the security of cardholder data are not required to be PCI DSS compliant, though some voluntarily choose to do so. Therefore they do not have an AOC. Examples of these types of services include, but are not limited to, Security Training and Background Screening. Companies that sell some types of equipment or software used in cardholder data processing, transmission, and storage environments, but have no access to, or do not impact, those environments, are also not required to be PCI compliant and therefore do not have AOCs. A few examples include routers, firewalls, application servers, database servers, telecommunications equipment, server operating systems, application firewalls, etc.

Service Providers are required to be PCI compliant

Who requires these Service Providers to be PCI DSS compliant? Primarily, it’s the Card Brands who strongly recommend that their merchants use PCI DSS compliant Service Providers when those merchants outsource part or all of their compliance requirements. Note: a merchant can never outsource their responsibility for being PCI compliant - merchants are always responsible for their PCI compliance -  they can, however, outsource the fulfillment of their security and compliance requirements. The recommended use of PCI DSS compliant service providers is usually specified in the merchant’s agreement (contract) with their acquirer. In these contracts, Merchants agree to use compliant service providers (generally appearing on one or more of the various Card Brands' third party provider lists) and also to report any service providers being used who do not appear on the lists. Note: you cannot use a Card Brand’s third party provider list to validate the PCI compliance of a service provider. The only acceptable evidence of a service provider’s PCI DSS compliance is a valid AOC from that service provider. Examples of PCI DSS compliant service providers include, but are not limited to:

  • Managed security services, e.g., firewalls, network administration, IDS/IPS, etc.
  • Hosting providers, e.g., shared hosting, dedicated hosting, data storage, etc.
  • Payment processing, e.g., Internet/ecommerce, mail order, call center, etc.
  • Back office, e.g., document shredding, magnetic tape degaussing, etc.

The PCI DSS does not explicitly require the use of compliant third party service providers (3PSP). However, when using a non-compliant service provider, the merchant must include the activity of the non-compliant service provider in the scope of their own PCI DSS compliance assessment, as if they were performing the activity within their own organization. Realistically, this is only feasible for very large merchants, so it’s best for most merchants to only use PCI compliant service providers. Bonus: The Council has an in-depth resource that covers a great deal more information about using service providers. See their free Information Supplement: Third-Party Security Assurance.

Why are AOCs important for Service Providers?

Very simply, the only acceptable evidence of a service provider’s PCI DSS compliance is a valid AOC from that service provider. The 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.

An AOC must:

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

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.

Note: "non-authorized documentation” means you cannot use a ‘certificate of AOC completion,’ or an ‘ASV scan certificate,’ as proof of compliance. Only a valid AOC will do.

Bottom line, if your service provider refuses to provide you with their AOC, or they are not PCI compliant and not planning to become compliant, then find another service provider! Note: some service providers have hesitated in the past to provide AOCs because they consider some of the information contained in this document to be confidential or sensitive, for example, their CIO’s email address. In these cases, it is acceptable for a service provider to redact this type of sensitive information from their AOC.

Additional resources

For information about AOCs, Responsibility Matrices, and much more about PCI compliance, we suggest the following articles:

Outsourcing your PCI? Get AOCs and Responsibility Matrices!

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

Sharing is Caring: The Case for Posting Your PCI Provider Responsibility Matrices