AOC or ROC: Which PCI Document Does Your Customer Actually Want?

When a customer asks for your PCI paperwork, send the Attestation of Compliance. There are three documents in play, and only one of them is built to travel: the PCI Security Standards Council states plainly that "The PCI DSS Attestation of Compliance is intended to be shared externally to requesting entities, according to applicable Participating Payment Brand rules and as noted in the Qualified Security Assessor Program Guide" (PCI SSC FAQ 1568, last updated April 2023). The AOC itself "is the document used to indicate that the appropriate Report on Compliance or Self-assessment Questionnaire has been performed, and to attest to your organization's compliance status with PCI DSS" (PCI SSC FAQ 1132). Here is the part that surprises people in a blocked deal: whether you produce a Report on Compliance at all is not your decision, and it is not your assessor's either.

Bias note on the source: the Council is the standards body founded by the payment brands. It writes these documents and it says so itself that it does not run the compliance programs that consume them, which is exactly why its FAQs are useful for what a document *is* and useless for what your bank will accept. The rest of this piece is the document map, who decides which one you owe, what you may safely redact before sending it, and the sequencing mistake that costs a quarter.

Key takeaways

• The AOC is the shareable summary. The ROC and the SAQ are the working papers behind it, and there is no obligation to hand either to a customer.
• The entity that decides whether you validate by ROC or by SAQ is your acquirer or the payment brand, described by the Council as the "compliance-accepting entity". Not you, not your customer, not your QSA.
• You may redact an AOC before sharing it, but only the parts that are not relevant to why you are sharing it.
• An AOC cannot exist before the ROC behind it is final, so "send us the AOC now, the report can follow" is not a thing you can agree to.
• The Council does not manage compliance programs and imposes no consequences for non-compliance. Every enforcement question routes to the brands and your acquirer.

The three documents, in the order they get confused

The Report on Compliance (ROC) is the full assessment record produced when a Qualified Security Assessor, or an Internal Security Assessor, tests your environment against PCI DSS v4.0.1 and documents the result requirement by requirement. It is long, it names systems, and it is the evidentiary basis for everything else.

The Self-Assessment Questionnaire (SAQ) is the alternative reporting vehicle for eligible entities. The Council publishes several, each with its own eligibility criteria, and picking the right one is its own decision that we cover in which PCI SAQ do you need. One detail that resolves a lot of confusion for software companies: "SAQ D for Service Providers is the ONLY SAQ for SAQ-eligible service providers. All other SAQs are for merchant use only" (PCI SSC FAQ 1133, last updated April 2024).

The Attestation of Compliance (AOC) sits on top of whichever of the two you produced. It is the signed declaration of the outcome. It is the artifact your customer's vendor risk team is actually equipped to read, and it is the one the Council designed to be handed over.

A useful way to hold the relationship: the ROC or SAQ is the work, and the AOC is the result. The two are not alternatives to each other, and a customer asking for "your ROC or your AOC, either is fine" is telling you they have not read either.

Who decides whether you owe a ROC or an SAQ

This is the question that ends most arguments, and the Council answers it directly. "Compliance-accepting entities (typically, payment brands and acquirers) are responsible for determining the PCI DSS validation and reporting methods of their merchants and service providers, including how compliance is to be evidenced" (PCI SSC FAQ 1473, last updated March 2023). The FAQ's own example of what "evidenced" means is the choice between a Report on Compliance and a Self-Assessment Questionnaire.

The same FAQ goes further, and this is the part that changes scoping conversations: compliance-accepting entities "may also provide direction to their customers about which PCI DSS requirements to include in the assessment", and it gives as an example a requirement "that only a specific subset of PCI DSS requirements, such as those included in an SAQ, be tested and the results documented in a ROC." A ROC scoped to an SAQ-sized set of requirements is a real, sanctioned outcome. Nobody discovers that by reading a vendor blog.

The Council routes the practical version of the question to the same address. Asked how a business determines whether it needs an independent assessment or a self-assessment, it answers: "Merchants should contact the acquiring financial institutions with whom they have merchant agreements (for example, their merchant bank) to determine whether they must validate compliance and the specific requirements for performing and reporting their compliance validation. Service providers should contact the individual payment brands for further information" (PCI SSC FAQ 1126).

And on enforcement, the Council disclaims the role entirely: "The PCI Security Standards Council does not manage compliance programs and does not impose any consequences for non-compliance. Individual payment brands, however, may have their own compliance initiatives, including financial or operational consequences to certain businesses that are not compliant" (PCI SSC FAQ 1015). If you are trying to work out what happens if you slip, the Council is not the party to ask. Whether you need a QSA at all is the adjacent decision, and we work through it in do you need a QSA.

What to send when procurement asks for "your PCI certificate"

There is no PCI certificate. What exists is the AOC, and it is meant to be shared. So the answer to the request is almost always: the current AOC, plus whatever scope detail the requester genuinely needs.

The Council permits redaction, with a limit that is worth quoting because it is the line people get wrong in both directions: "an entity may redact sensitive information from their PCI DSS Attestation of Compliance (AOC), providing that the resulting document contains, unredacted, all information relevant to the purpose for which the AOC is being shared" (PCI SSC FAQ 1354, last updated April 2023). The same FAQ gives the shape of the judgment: it may not be necessary for a customer to know the city where a data center sits, or the specific technologies inside your cardholder data environment, while "details about the scope and services covered by the PCI DSS assessment, the requirements assessed, and the findings of the assessment, are relevant to the service provider's customers and should be included."

It also states the preference we spend a surprising amount of time defending on customers' behalf: "Sharing the AOC may be preferred to sharing the full Report on Compliance (ROC) or Self-Assessment Questionnaire." A customer who insists on the ROC is asking for your internal architecture documentation. Sometimes that is negotiable under an NDA and sometimes the honest answer is no. Either way, the AOC is the document the ecosystem built for this exchange, and saying so with the citation attached ends most of those threads.

One more practical point for service providers: the AOC has to identify what it covers. If your assessment covered one product and the customer is buying a different one, an unredacted AOC does not help you, it just documents the gap more clearly.

The sequencing trap that costs a quarter

Here is a request that arrives in almost every enterprise deal running against a quarter end: can we get the AOC now, with the report to follow?

No. "An Attestation of Compliance (AOC) cannot be provided to an assessed entity before the Report on Compliance (ROC) is finalized. The AOC must be completed as a declaration of the results of the assessment" (PCI SSC FAQ 1375). The Council's reasoning is structural: Section 2 of the AOC states that it "reflects the results of an onsite assessment, which is documented in an accompanying Report on Compliance (ROC)", and the assessor has to give the date of the assessment in both.

Which raises the date question, and there is a definite answer. "For PCI DSS assessments documented in a Report on Compliance (ROC), the Date of Report is considered the completion date for the PCI DSS assessment. This denotes the date when the QSA Company and assessed entity agree on the final version of the ROC" (PCI SSC FAQ 1583, last updated August 2024). Executive and QSA signature dates are expected to fall on the same date or within a reasonable timeframe after it, and those signatures acknowledge accuracy rather than marking completion. For an SAQ, the equivalent is the Self-Assessment completion date at the start of Section 2 (PCI SSC FAQ 1582).

The operational consequence: work backward from the date your customer needs a document in hand, not from the date you want fieldwork to end. The gap between "testing is done" and "the ROC is agreed" is real, and the AOC is downstream of the second one.

When a ROC is right even though an SAQ is allowed

Eligibility is a floor, not an instruction. Two situations regularly justify a ROC that nobody required.

The first is customer concentration. If one enterprise buyer represents a large share of revenue and their vendor risk process treats self-assessment as a weaker signal, an assessor-signed AOC can be worth more than the assessment costs, even though your acquirer would have accepted the SAQ. That is a commercial decision, not a compliance one, and it should be made with the revenue number in front of you.

The second is scope honesty. The Council warns against reasoning in the other direction: "SAQs should not be used as a 'guide' for determining the applicability of PCI DSS requirements unless explicitly reviewed, discussed and agreed upon with the merchant's compliance accepting entity" (PCI SSC FAQ 1331, last updated August 2026). If your environment has drifted past the eligibility criteria of the SAQ you have been filing, the SAQ is not a lighter version of the truth. It is the wrong document.

What this article cannot tell you

Three limits, stated plainly.

We cannot tell you your merchant level or your validation type. Those come from your acquirer or the brands, they are set independently by each brand, and they can be escalated after an incident. Any number you read on a blog, including this one, is not the number that binds you. Get it in writing.

We cannot tell you what your customer's security team will accept. Vendor risk questionnaires vary wildly, and some enterprises have internal policies that name the ROC by mistake. The fix there is a conversation with a citation, not a document you did not owe.

And we are not a QSA firm. Top Floor cannot sign your Report on Compliance and cannot issue your AOC. If a firm offers to do your readiness work and sign your attestation, that combination should raise a question rather than close a sale.

Where Top Floor fits

The part worth paying for is not the paperwork, it is making the paperwork small. Our PCI DSS work concentrates on scope: where card data actually flows, which systems have unrestricted connectivity to the ones that do, and what an integration change would remove from the assessment before an assessor ever quotes you. That is the same reasoning as reducing your SAQ burden, applied one layer up.

Where a program spans PCI plus SOC 2 plus a customer questionnaire backlog, compliance as a service is the model that keeps one evidence set feeding all of them. And when the assessment is the thing you need managed rather than the controls, our audit and readiness practice runs the evidence and the assessor relationship without ever being the party that signs.

How to decide this week

Send one email to your acquirer, and one to the customer who is blocking.

To the acquirer: here is how we accept payments, here is our approximate annual card volume, here is whether we handle card data for anyone else. Which validation type do you require from us, and by when? Ask for it in writing, because that answer is the only one that decides between a ROC and an SAQ.

To the customer: offer the current AOC, redacted to the parts relevant to their assessment of you, and ask specifically what their control requires. If they insist on the ROC, ask which requirement in their policy names it. In our experience the request usually dissolves at that question, because the person asking inherited the word rather than the requirement.

Then check your own dates. If your AOC covers a period that ended more than a year ago, or covers a product line you no longer sell the same way, the document is going to fail review no matter how promptly you send it.

Frequently asked questions

Is an AOC the same as a PCI certificate?

No, and there is no such thing as a PCI certificate. The AOC is a signed declaration of the results of an assessment documented in either a Report on Compliance or a Self-Assessment Questionnaire, described by the PCI Security Standards Council as the document used to indicate that the appropriate ROC or SAQ has been performed and to attest to your compliance status. Anyone offering you a PCI certificate is selling something the standard does not define.

Can we refuse to send a customer our full Report on Compliance?

Generally yes, and the Council's own guidance supports it. It states that sharing the AOC may be preferred to sharing the full ROC or SAQ, and that an AOC may be redacted provided everything relevant to the purpose of sharing stays unredacted. The ROC contains detail about your internal environment that most customers have no need for. Offer a properly scoped AOC first, and ask which specific requirement in their policy calls for the full report.

Who decides whether we need a QSA-signed ROC instead of a self-assessment?

Your compliance-accepting entity, which is typically your acquirer for merchants and the individual payment brands for service providers. The PCI SSC is explicit that these entities determine the validation and reporting methods, including how compliance is to be evidenced, and it directs merchants to contact their acquiring bank and service providers to contact the brands. Get the answer in writing before you buy an assessment.

Can our assessor give us the AOC before the report is finished?

No. The Council states directly that an AOC cannot be provided to an assessed entity before the ROC is finalized, because the AOC is a declaration of results that references the accompanying report and its date. If a deal is waiting on paperwork, plan backward from the date the ROC is agreed between you and the QSA company, which is the date treated as the assessment completion date.