PCI DSS guide
How to verify a PCI DSS AOC and check a provider's compliance
There is no PCI DSS certificate to check. What you can check is the provider's Attestation of Compliance: who was assessed, for which services, when, on which version, by which assessor, and whether it covers the service you actually buy.
Key points
- There is no such thing as a PCI DSS certificate. When you check a vendor, the document to ask for is its Attestation of Compliance (AOC), signed by the provider and, for a Report on Compliance, by the assessor.
- A genuine AOC names the legal entity, the services assessed and excluded, the assessment dates, the PCI DSS version, the assessor and the signatures. Read every one of them against the service you actually use.
- Check the assessor independently: the QSA company on the PCI Security Standards Council's list, and the provider on a card-brand registry such as Visa's where one applies.
- An AOC only helps you if it covers the service in your contract. Map it to your responsibility matrix, and treat a "PCI certified" badge or a scan report offered as proof as a reason to look harder.
Why the AOC, not a certificate, is what you ask for
You are expected to know whether the providers that handle card data for you, or can affect its security, are compliant. Requirement 12 makes managing those providers part of your own programme, and your assessor will ask how you know.
PCI DSS compliance is validated, not certified. A provider that has been assessed by a Qualified Security Assessor holds a Report on Compliance (ROC) and a matching AOC; a provider that is allowed to self-assess holds a completed self-assessment questionnaire and its AOC. The ROC is detailed and usually confidential; the AOC is the summary designed to be shared, and your records should hold one for every relevant provider. The full sequence behind these documents is explained in PCI DSS validation step by step: ROC, SAQ and AOC; this guide is about reading someone else's.
What a genuine AOC shows, part by part
The PCI Security Standards Council publishes the AOC templates,. The service-provider AOC for a v4.0.1 ROC has four parts; read them in this order.
| AOC part | What to look for | Why it matters to you |
|---|---|---|
| Part 1: contact information (assessed entity and assessor) | The exact legal name you contract with; the assessor company and the individual assessor | An AOC for a parent, a sister company or a different country's entity may not cover your supplier |
| Part 2a: scope verification | The services named as assessed and those named as not assessed | The service you use must appear in the assessed list, not in the exclusions |
| Parts 2b to 2f: role, environment, locations, validated products and third parties | How the provider handles card data, the facilities in scope, and the providers it relies on | Shows whether the data centre, region or platform serving you was inside the assessment |
| Part 2g: summary of assessment | The result for each requirement, including anything marked not applicable | A requirement marked not applicable may be one your contract assumes the provider performs |
| Part 3: validation and attestation | The overall compliance status, the dates, and the signatures of the provider's executive officer and the QSA, with any ISA involvement stated | Unsigned, undated or status-less documents are drafts, not attestations |
| Part 4: action plan for non-compliant requirements | Present only where requirements were not met, with remediation dates | A non-compliant status is a risk decision for you, not a technicality |
The version matters as much as the content. PCI DSS v4.0 was retired at the end of 2024, so a current AOC should state v4.0.1. The compliance status in Part 3 should read "Compliant"; a "Non-Compliant" status or a legal exception needs an explanation from the provider before you rely on it. An AOC for a self-assessment questionnaire uses a different template with the same core elements.
Check the assessor and the listings yourself
A signature is only as good as the person and company behind it. For a ROC-based AOC, look up the QSA company on the Council's public list of Qualified Security Assessors. The list shows the company, the regions where it is qualified to work, and whether it is currently marked "In Remediation", which the Council applies after a quality assurance review finds the company has breached its qualification requirements. A separate lookup confirms individual assessors, and because the Council cautions that its list may lag, check it close to the date you rely on the document.
If Part 3 records an Internal Security Assessor, the ISA is an employee of the assessed organisation trained by the Council; whether an ISA-led attestation is accepted is for the provider's acquirer and the card brands, so ask how it was accepted. For a self-assessed AOC, the signature is the provider's own; you are relying on its executive's statement, and your due diligence should be correspondingly deeper.
Some card brands also publish service-provider listings. Visa's Global Registry of Service Providers lists providers that have validated and been registered through the brand's programme, with the date of validation. A listing is a useful second signal, not a replacement: it does not show which services were in scope.
Map the AOC to your responsibility matrix
A compliant AOC for the wrong service protects nobody. For each provider, keep a responsibility matrix stating what the provider does, what you do and what is shared, then test the AOC against it. If the matrix says the provider manages the firewall and the logging for your hosted environment, Requirements 1 and 10 must be assessed in its AOC for that hosting service.
Three questions settle most cases. Is the service named in Part 2a? Are the requirements you depend on marked in place rather than not applicable? Do the locations and platforms in Part 2 include those that serve you? Where the answer is unclear, ask for the provider's responsibility summary, which should agree with the attestation. How much of your scope a provider can take off your hands is a design question covered in PCI DSS scoping and segmentation: shrinking the CDE.
Warning signs, and what they usually mean
| What you are shown | What it usually means | What to ask for |
|---|---|---|
| A "PCI certified" badge or certificate | A marketing graphic or a document from a party that cannot certify PCI DSS | The signed AOC and the name of the assessor |
| An AOC dated more than a year ago | The annual validation is overdue or has lapsed | The current AOC, or a dated letter from the provider explaining the status and the planned assessment |
| An AOC on a retired version of the standard | An old assessment, or a template reused without a new one | An AOC for a v4.0.1 assessment |
| Your service missing from Part 2a, or listed as not assessed | The attestation covers a different product line | Written confirmation of how your service is covered, or a revised scope at the next assessment |
| A passing ASV scan report offered as proof | Evidence of external vulnerability scanning only, one test among many | The AOC; the scan belongs behind it, not in place of it |
| An AOC for a different legal entity | Group coverage that may not extend to your contracting party | Confirmation that your contracting entity was the assessed entity |
None of these proves bad faith on its own; what matters is whether the provider answers with evidence or with reassurance.
What to do if the document does not hold up
Start with the provider, in writing. Say what is missing and ask for the correct document by a date. If you doubt that the document is authentic, contact the QSA company named on it through the details on the Council's list, not the contact details printed on the AOC, and ask it to confirm that it issued an attestation for that entity on that date.
If the gap is real, record it as a third-party risk, tell your own assessor, and decide on the control: contractual commitments with a date, compensating measures on your side, a change in how data flows to that provider, or a different provider. Where you suspect a forged attestation, your acquirer should know. Filing a doubtful document and hoping it is not sampled is not an option: your own validation rests on it.
How Sterling reviews provider evidence
Every provider AOC read against the service you use, then kept current.
In the gap analysis, Sterling's expert and experienced PCI DSS consultants build your provider register with you, read each AOC against the contract and the responsibility matrix, and list what to request before your assessment. Under Sustain™, the register lives in Effivity, included with the engagement at no additional cost, with review dates that flag an attestation before it goes stale. Sterling does not validate compliance or verify attestations on a card brand's behalf; your QSA assesses, and your acquirer and the card brands accept the result.
Book a free discovery callVerifying a PCI DSS AOC: questions buyers ask
How often should we ask a provider for a new AOC?
Every year. Validation is annual, so an attestation more than twelve months past its assessment date should be replaced. Put the date in your provider register and ask ahead. The rest of the yearly rhythm is set out in The PCI DSS annual cycle: quarterly scans, annual validation and business as usual.
Can a provider refuse to share its Report on Compliance?
Yes, and many do, because the ROC describes their environment in detail. The AOC exists to be shared. If you need more than it offers, ask for the provider's responsibility summary or a discussion of specific requirements under a confidentiality agreement.
Is an ISO/IEC 27001 certificate or a SOC 2 report an acceptable substitute?
Not for PCI DSS. Both are useful evidence of security, but neither validates the PCI DSS requirements for the card data a provider handles for you.
Our provider says it never sees card data, so it has no AOC. Is that enough?
Ask how it can be sure. A provider that only receives tokens may genuinely be out of scope; one that hosts, supports or can change systems in your cardholder data environment usually is not. Get the reasoning in writing.
Does the provider's AOC cover its own subcontractors?
Part 2f lists the third parties the provider relies on, but their compliance is the provider's responsibility to manage.
More PCI DSS guides
Every guide in the PCI DSS series is written for one question and links back to the hub for the whole picture.
- The PCI DSS annual cycle
- PCI DSS assessor questions
- PCI DSS compliance cost: what moves the price
- Effivity for PCI DSS: the guide
- PCI DSS vs ISO/IEC 27001 and SOC 2
- PCI DSS requirements explained, requirement by requirement
- PCI DSS scoping and segmentation: shrinking the CDE
- PCI DSS training: who needs what
- PCI DSS in the UAE and GCC
- PCI DSS v4.0.1: what changed and what your next assessment tests
- PCI DSS validation step by step: ROC, SAQ and AOC
- Which SAQ applies to you: eligibility explained
Keep exploring
Explore more about PCI DSS
Watch a video on how to implement PCI DSS here.
Watch a video on PCI DSS requirements here.
PCI DSS resources
Services for PCI DSS
Talk to a consultant
Make sure every provider AOC covers the service you rely on.
Tell us your goals, locations and target date. We’ll help you define the scope, timeline and next steps.
hello@sterling-grc.com+1 201 263 4443 (global headquarters) · your nearest office and its number are at the top of this page
What would you like to achieve?
Choose a starting point. The enquiry form takes about a minute.
Book my free discovery callContinue to the enquiry form to share your details. Please do not include passwords, sensitive personal information or confidential files. A Sterling consultant replies within one working day. Privacy notice