PCI DSS Attestation of Compliance (AoC) : Who Issues It, and How to Get One

"PCI DSS certification" is not a thing. There is no certificate, no badge, no plaque from the PCI Security Standards Council. When acquiring banks, enterprise customers, and card networks ask for proof of PCI DSS compliance, what they want is the Attestation of Compliance (AoC) a signed legal document that summarises your validation results and formally attests that your organisation meets the standard. Without a current AoC, card processing privileges can be revoked, B2B contracts stall, and your own customers' compliance programmes have a gap they cannot close.

The AoC is the endpoint of the entire PCI DSS journey and it is also the most consistently misunderstood document in payments security. It is routinely confused with the Report on Compliance (ROC) and the Self-Assessment Questionnaire (SAQ). Vendors describe themselves as "PCI certified" without producing one. Compliance leads submit the wrong document to banks and lose weeks resolving the friction. Service providers issue AoCs to customers without the shared responsibilities matrix those customers actually need.

For Level 1 merchants and most service providers, the AoC must be signed by a Qualified Security Assessor (QSA) a firm formally listed by the PCI Security Standards Council as authorised to conduct PCI DSS assessments and issue attestations. SecurityWall is QSA-listed entity, which means we conduct your Report on Compliance and sign your AoC directly, end to end, without handing off to a third-party assessor mid-engagement.

This guide explains what an AoC is, how it differs from a ROC and SAQ, who issues and signs it, what your bank and enterprise customers do with it, and what it takes to get one written for the compliance lead, CISO, or CFO making the call on which validation pathway to commission, and how soon the AoC has to be in hand.

1. What a PCI DSS AoC Actually Is — and Why "PCI DSS Certification" Is a Misnomer
2. AoC vs ROC vs SAQ: The Three Documents and Which One You Actually Need
3. Merchant AoC vs Service Provider AoC — Why the Difference Matters
4. What's Inside an AoC — and What Happens When a Section Is Wrong
5. Who Signs Your AoC and Why It Matters Legally
6. How Long an AoC Is Valid — and the Vendor AoC Trap
7. What Your Bank, Enterprise Customers, and Card Brands Do With It
8. How SecurityWall Supports the Attestation Process

What a PCI DSS AoC Actually Is — and Why "PCI DSS Certification" Is a Misnomer

A PCI DSS Attestation of Compliance is a formal, signed document that summarises the results of your PCI DSS assessment and attests that your organisation meets the requirements of PCI DSS v4.0.1. It is the external-facing artefact of the compliance process the document your acquiring bank receives, the document your enterprise customers ask for during vendor due diligence, and the document the card networks rely on to confirm your compliance status.

What the AoC is not: a certificate. PCI DSS does not issue certifications. There is no "PCI DSS certified" stamp, no badge from the PCI Security Standards Council, no expiry-dated wall plaque. When vendors describe themselves as "PCI DSS certified," what they actually mean or should mean is "we have completed PCI DSS validation and hold a current Attestation of Compliance." This distinction matters more than it sounds. Compliance-literate buyers know the difference, and a vendor who claims "PCI certification" without producing an AoC raises immediate concern.

The AoC is produced at the end of the validation process, after either:

• A Self-Assessment Questionnaire (SAQ) completed by the organisation itself eligible Levels 2–4 merchants and some service providers
• A Report on Compliance (ROC) completed by a Qualified Security Assessor mandatory for Level 1 merchants and most service providers

Both pathways produce an AoC. The ROC and SAQ are the underlying assessment artefacts; the AoC is the signed attestation that summarises them. Banks, card brands, and enterprise customers do not typically receive the ROC or SAQ they receive the AoC.

When your enterprise customer asks for "your PCI DSS documentation," what they want is the AoC, not the underlying ROC. The ROC is a confidential, technical document containing evidence detail your organisation reasonably treats as sensitive. The AoC is the sanitised, externally-shareable summary specifically designed for this purpose. Confusing the two either over-sharing the ROC or under-providing by sending only the SAQ is a routine source of friction in B2B compliance conversations.

AoC vs ROC vs SAQ: The Three Documents and Which One You Actually Need

The three documents that anchor PCI DSS validation are routinely confused and the consequences range from minor B2B friction to full validation failure. Here is what each one is and which one your bank or customer actually wants.

Self-Assessment Questionnaire (SAQ). Your organisation's own validation questionnaire, completed against PCI DSS requirements. Nine SAQ types exist, each scoped to a specific payment channel architecture. Eligible for Levels 2–4 merchants and some service providers. The SAQ stays internal it is not externally shared.

Report on Compliance (ROC). The detailed assessment report produced by a Qualified Security Assessor after a formal audit. Mandatory for Level 1 merchants and most service providers. Hundreds of pages of evidence, held confidentially by the QSA, your organisation, and your acquiring bank. Not shared with enterprise customers.

Attestation of Compliance (AoC). The signed summary that gets submitted to acquiring banks and shared with enterprise customers during vendor due diligence. The only one of the three that routinely leaves the organisation.

Merchant AoC vs Service Provider AoC — Why the Difference Matters

There are two distinct AoC forms, and which one applies to your organisation determines what your AoC must contain and what your enterprise customers can rely on it for.

The Merchant AoC applies to organisations that accept payment cards as a form of payment for their own goods or services. It attests that the merchant's payment environment meets PCI DSS requirements for the SAQ type or ROC scope assessed.

The Service Provider AoC applies to organisations that store, process, or transmit cardholder data on behalf of other organisations payment gateways, processors, hosting providers, managed service providers, SaaS platforms with subscription billing, fraud detection services, and any vendor whose service touches cardholder data for its customers.

The Service Provider AoC contains a section the Merchant AoC does not: a shared responsibilities matrix that breaks down which PCI DSS requirements the service provider handles versus which remain with the customer.

This matrix is the most important document in your compliance relationship with any cloud or SaaS provider that handles cardholder data. It tells you, requirement by requirement:

• What the service provider has already validated on your behalf you can rely on this in your own assessment
• What remains your responsibility within their environment you must validate this yourself
• What is shared between you both parties have specific obligations

Where This Matters Most: Cloud and SaaS

If you are running PCI workloads in AWS, Azure, GCP, or any IaaS environment, your provider's Service Provider AoC covers their infrastructure layer physical security, hypervisor, hardware, and the controls they manage on your behalf. It does not cover your applications, your operating system configurations, your IAM, your data, or anything you build on top.

The shared responsibilities matrix tells you exactly where the line falls. The same applies to payment gateways, hosting providers, and SaaS platforms that handle cardholder data.

The Trap

Organisations routinely assume their cloud or SaaS provider's compliance covers more than it actually does. Reading the shared responsibilities matrix carefully before relying on a vendor's AoC for your own compliance is the difference between a clean validation and an unexpected gap finding.

If you are a service provider yourself, the inverse is true: your shared responsibilities matrix is what your customers will rely on during their assessments. A well-drafted matrix makes you a procurement-friendly vendor. A vague or missing one creates friction that costs you deals.

What's Inside an AoC — and What Happens When a Section Is Wrong

The AoC is structured into four parts. Each part is scrutinised by acquiring banks and enterprise customers and errors in any section trigger rework that delays compliance acceptance.

Part 1: Contact Information and Scope of Assessment

Identifies the assessed organisation, the QSA or signing officer, and the scope including merchant level (or service provider designation), the SAQ type completed (if applicable), assessment dates, in-scope locations, and a description of the cardholder data environment.

The most common Part 1 error is a scope statement that does not match the organisation's actual operations. If your AoC says "e-commerce only" and you also process card-present transactions, the AoC is invalid for the card-present channel and your acquiring bank will catch it.

Part 2: Executive Summary of Assessment Findings

Summarises the assessment results and overall compliance status. The status is one of three states:

• Compliant all applicable requirements met
• Compliant with Compensating Controls requirements met through documented alternative controls
• Non-Compliant with Action Plan one or more requirements unmet, with remediation timeline

A Non-Compliant AoC is still a valid attestation if it carries a Part 4 Action Plan. Banks and enterprise customers do not typically reject Non-Compliant AoCs outright but they do increase scrutiny and impose deadlines for remediation.

Part 3: Validation and Attestation (Signatures)

The signed declarations from your senior officer (CEO, CFO, CISO, or equivalent) and, for ROC-derived AoCs, from the QSA. Without valid signatures from authorised parties, the AoC is not enforceable.

The most common signature error: an executive signs without legal authority to attest on behalf of the organisation. Acquiring banks have rejected AoCs signed by IT directors, security managers, or external consultants who lacked the authority to legally bind the organisation.

Part 4: Action Plan for Non-Compliant Requirements

Required only if any requirement is marked Non-Compliant in Part 2. The action plan must include:

• The specific requirement
• The current status and gap description
• The remediation activity planned
• The responsible party
• The target completion date

Acquiring banks track Action Plan deadlines closely. Missed self-imposed deadlines trigger follow-up requests, escalating in severity to non-compliance fines and processing privilege reviews.

The pattern across all four parts: the AoC is a legal attestation, signed under organisational authority. Errors in scope, signature, or action plan execution have downstream consequences that materially exceed the time it would have taken to get the document right the first time.

Who Signs Your AoC and Why It Matters Legally

Two distinct signature requirements apply depending on the validation pathway.

For SAQ-derived AoCs (Levels 2–4):

• A senior company officer with authority to attest on behalf of the organisation typically the CEO, CFO, CISO, or a designated executive signed by a Qualified Security Assessor (QSA), SecurityWall is a QSA firm.
• Optionally, an Internal Security Assessor (ISA) or external advisor may co-sign for additional credibility

For ROC-derived AoCs (Level 1 and most service providers):

• A senior company officer with the same authority requirement
• The Qualified Security Assessor who conducted the ROC

The QSA signature is what distinguishes a Level 1 AoC from a self-attested AoC in the eyes of acquiring banks and card networks. The QSA signature carries independent attestation weight it is the QSA confirming, professionally and on the record, that the organisation meets PCI DSS requirements as evidenced in the underlying ROC.

Why the Signing Officer Matters Legally

The senior officer signature is a legal attestation. The signer declares, under their organisation's authority, that the contents of the AoC are accurate. False attestations carry real legal exposure particularly under regulatory frameworks where misrepresentation of security posture is independently actionable.

This is why many organisations route AoC signature through general counsel before the executive signs. It is also why acquiring banks reject AoCs signed by IT directors, security managers, or external consultants who lack the formal authority to bind the organisation. Confirm internally before the AoC is drafted who has signing authority and what internal review process the document needs to clear.

How Long an AoC Is Valid — and the Vendor AoC Trap

A PCI DSS Attestation of Compliance is valid for one year from the date of assessment completion. Annual renewal is mandatory there is no PCI DSS programme where an AoC issued more than 12 months ago remains valid.

Renewal is triggered by any of three conditions:

• Annual expiry the AoC must be renewed every 12 months regardless of any other factor
• Significant infrastructure or application change major architecture changes, new payment channels, cloud migrations, platform replacements
• Confirmed payment data breach typically triggers re-validation, often at an elevated merchant level

The Vendor AoC Trap

Service provider AoCs expire on the same annual cycle. If your organisation relies on a service provider's AoC as part of your own compliance which most cloud and SaaS-dependent organisations do that AoC must be current.

PCI DSS Requirement 12.8 obligates you to maintain a list of your service providers and verify their compliance status. An expired vendor AoC is your problem, not theirs, in your next assessment.

The practical implication: vendor AoC tracking is not a one-time onboarding task. It is an annual recurring obligation. Organisations that treat vendor compliance as set-and-forget routinely discover at their own assessment that one or more critical vendors have lapsed AoCs and that gap becomes a finding against the assessed organisation.

What Your Bank, Enterprise Customers, and Card Brands Do With It

Understanding what happens to your AoC once you submit it explains why getting it right the first time matters so much. Three different recipient groups use it for three different purposes.

Acquiring Banks

Your acquiring bank uses the AoC to confirm your compliance status for card processing privileges. Specifically they:

• Verify the AoC is current within 12 months of submission
• Check the merchant level matches their records
• Review the compliance status Compliant, Compliant with Compensating Controls, or Non-Compliant with Action Plan
• Track Action Plan deadlines for Non-Compliant AoCs and escalate if remediation slips
• Forward summary information to the relevant card networks

A current, accurate AoC keeps card processing privileges active. A late AoC, an inaccurate scope, or a stale Action Plan triggers escalation non-compliance fines, increased transaction reserves, or in severe cases, suspension of processing.

Enterprise Customers (B2B Vendor Due Diligence)

If you are a service provider, your enterprise customers use your AoC as part of their own compliance programme. PCI DSS Requirement 12.8 obligates them to maintain a list of service providers and verify the compliance status of each.

Enterprise customers will:

• Verify your AoC is current and matches their procurement records
• Review your shared responsibilities matrix to confirm what your compliance covers
• Identify any requirements they must validate themselves within your environment
• Track your AoC expiry against their own assessment cycles

A late AoC from a service provider creates a compliance gap in every customer's own assessment. This is why enterprise customers ask repeatedly and increasingly aggressively for current AoCs from their vendors.

Card Brands

Visa, Mastercard, American Express, Discover, and JCB receive compliance summary data from acquiring banks and use it to monitor merchant and service provider compliance across their networks. Card brands maintain registries of compliant service providers Visa's Global Registry of Service Providers, Mastercard's Compliant Service Provider list and inclusion or removal from these registries directly affects business development opportunities.

How SecurityWall Supports the Attestation Process

SecurityWall provides end-to-end PCI DSS support from initial gap assessment through to signed Attestation of Compliance for merchants and service providers across all validation levels. The model is built around the reality that the AoC is the endpoint, not a milestone, and every step in the journey should be structured to produce a document that holds up under acquiring bank, enterprise customer, and card brand scrutiny.

From Gap Assessment to Signed AoC, in One Coordinated Programme

Every step in the validation journey produces evidence the next step depends on:

• Gap assessment identifies what needs remediation against PCI DSS v4.0.1
• Remediation advisory closes the gaps with documentation aligned to the validation pathway
• Pre-assessment confirms readiness before formal validation begins
• SAQ completion or ROC coordination depending on merchant level and pathway
• AoC drafting and signature support ensures the final document holds up under scrutiny

Where SecurityWall has conducted the earlier steps, materials transfer directly into the AoC eliminating the rework that comes from coordinating multiple vendors across the journey.

SAQ-Level Validation: Direct Path to AoC

For Levels 2–4 merchants and eligible service providers, we deliver SAQ completion as a unified service:

• Confirm the applicable SAQ type against your payment channel architecture
• Complete the SAQ accurately based on gap assessment and remediation evidence
• Draft the AoC with correct scope, signature blocks, and Action Plan if applicable
• Coordinate executive signature, including legal review where governance requires it
• Deliver the signed AoC in the format your acquiring bank and enterprise customers will accept

Level 1 ROC Coordination with Independent QSA Partners

For Level 1 merchants and ROC-required service providers, we coordinate with our independent QSA partners:

• SecurityWall conducts gap assessment, remediation, and pre-assessment
• The independent QSA conducts the formal ROC and signs the AoC
• Advisory-assessment separation is preserved where governance frameworks require it
• The QSA receives gap assessment and remediation evidence in the format they expect reducing the formal validation timeline

Service Provider AoC: Shared Responsibilities Done Right

For service providers, we draft the shared responsibilities matrix that defines what your AoC covers and what your customers must validate themselves:

• Map every applicable PCI DSS requirement to either you, your customer, or shared
• Document the controls implemented for each requirement you own
• Provide your customers with the clarity they need to rely on your AoC during their own assessments
• Position your AoC as a procurement-grade document, not a generic attestation

AoC Renewal and Vendor AoC Tracking

PCI DSS compliance does not end at first AoC signature. We provide:

• Annual renewal cycles aligned to your assessment date
• Vendor AoC tracking maintaining the list of your service providers' AoCs as required by Requirement 12.8
• Alerts before vendor or your own AoC expiry, with timeline planning for renewal
• Post-significant-change reassessment when major infrastructure or application changes occur

Bundled with Penetration Testing and ASV Scanning

SecurityWall is an Approved Scanning Vendor and delivers the technical testing requirements PCI DSS demands as a coordinated programme:

• Annual penetration testing under Requirement 11.4 internal, external, and segmentation testing
• Quarterly external vulnerability scanning under Requirement 11.3.2
• Gap assessment, SAQ/ROC support, and AoC delivery as a single engagement

Single point of contact across every PCI DSS requirement that produces evidence for your AoC.

Related reading:

• What Is PCI DSS Compliance? A Plain-Language Guide for 2026
• PCI DSS Penetration Testing Requirements: What Assessors Check
• PCI DSS v4.0 Compliance Checklist for E-Commerce Merchants (coming soon)
• PCI DSS v4.0 & v4.0.1: Everything That Changed and What You Must Do by 2026
• PCI DSS Gap Assessment: What It Covers and How to Prepare in 2026
• PCI DSS for Cloud and SaaS: What's Different in AWS, Azure, and GCP (coming soon)

Frequently Asked Questions

Is "PCI DSS certification" the same as a PCI DSS AoC?

No. PCI DSS does not issue certifications there is no certificate. The Attestation of Compliance is the closest equivalent and the only document that formally evidences your compliance status. When vendors say they are "PCI certified," they should mean they hold a current AoC.

How do we get a PCI DSS Attestation of Compliance?

Complete a validation pathway either an SAQ (eligible Levels 2–4) or a QSA-led ROC (Level 1 and most service providers) and produce a signed AoC at the end. The AoC is the deliverable; the SAQ or ROC is the underlying assessment. SecurityWall delivers both pathways end-to-end.

Can SecurityWall sign our AoC?

For SAQ-derived AoCs, signature authority sits with your senior officer SecurityWall drafts the AoC and supports the signature process, including legal review where required. For ROC-derived AoCs, the QSA who conducted the ROC signs alongside your senior officer. SecurityWall coordinates with independent QSA partners for ROC-required engagements.

How long does it take to get an AoC?

From gap assessment to signed AoC: 2–6 months for SAQ-eligible environments with current documentation, 6–12 months for first-time Level 1 ROC engagements. Timelines depend on the size of any remediation gap identified at gap assessment. Renewals on already-compliant environments typically complete in 4–8 weeks.

Our cloud provider's AoC is current — does that mean we are compliant?

No. Your cloud provider's Service Provider AoC covers their infrastructure layer and the controls they manage on your behalf. The shared responsibilities matrix in their AoC tells you what remains your obligation applications, OS configurations, IAM, and your data. You must validate your portion of the responsibilities yourself.

Our AoC is expiring next month and we have not started renewal — what now?

Contact us today. AoC renewal under audit-deadline pressure is achievable but requires immediate scoping. The first action is confirming whether your environment has changed materially since the last assessment significant changes trigger a fresh gap assessment rather than a streamlined renewal.

What does the engagement actually cost?

Cost depends on validation pathway, environment size, and starting compliance posture. We provide scoped pricing within 24 hours of an initial scoping conversation. There is no standard rate card because no two PCI environments or AoC scopes are alike.