What is a PCI DSS Attestation of Compliance, and when do customers ask for it?
A customer, acquirer or contract that asks for PCI DSS evidence usually wants the Attestation of Compliance (AOC), the PCI Security Standards Council form that declares the result of a completed Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ). The AOC is only as strong as the assessment behind it: a ROC completed by an independent Qualified Security Assessor (QSA), or a completed SAQ, supports it. A certificate, badge or letter from a vendor or consultant does not replace it, because only the official PCI SSC templates count as validation evidence. The AOC does not describe the controls itself. It states the outcome and points to the assessment that holds the detail.
The AOC's content depends on three things: the report type (ROC or the specific SAQ), the entity's role (merchant, service provider or other), and the scope the assessment covered. A service provider's AOC carries scope and third-party information that a merchant's SAQ AOC may not. Before you send anything, confirm with your acquirer and the relevant payment brands which report type, validation level and AOC version they accept, and whether they want the full AOC or a different form. Ask them to name the contact who will receive the document and the date by which they need it. Those answers decide which AOC you prepare, and a mismatch is a common reason a request gets sent back.
Ask your QSA or assessor to confirm the assessment date and signatures before the AOC is issued, since the AOC cannot precede a final ROC. Keep the signed AOC and the matching report together in your evidence file so you can answer follow-up questions on scope and status without reconstructing them. If a customer asks for more than the AOC, such as relevant ROC sections, confirm the request is permitted under your payment brand rules and whether a confidentiality agreement should cover the description of services.
Who signs the AOC for a ROC and for an SAQ?
A Report on Compliance ends with an Attestation of Compliance that two parties sign. The first is an executive officer of the assessed entity, who attests to the organization's compliance status. The second is a duly authorized officer of the Qualified Security Assessor company, who stands behind the assessor's findings. Both signatures appear on the same AOC, and the two signers answer for different things.
- Entity executive officer: Signs for the organization and confirms its PCI DSS status as described in the ROC.
- QSA company officer: Signs for the assessing firm, confirming the QSA performed the assessment under its own accountability.
- Assessment date: The assessor enters the date in both the ROC and the AOC, so the signatures must follow a finalized report.
- Matching content: The AOC must reflect the results in the accompanying ROC, so the signers should review the final ROC before signing.
- Authority: Confirm that each signer has the internal or firm authority to sign on behalf of the company.
Before signing, check that the executive officer has actually read the final ROC and that the QSA company's signer is named in the AOC exactly as the firm's authorization requires.
A Self-Assessment Questionnaire ends with an Attestation of Compliance signed only by an executive officer of the assessed entity. No QSA company signs the SAQ AOC, because no QSA issues the questionnaire. The entity accepts responsibility for the answers it gave, and the signature is its declaration of its own compliance status.
- Single signatory: An executive officer of the entity signs, not a manager of the security or compliance team unless they hold that role.
- Self-declared answers: The signer is attesting to answers the organization completed, so the signer should understand the basis for each answer.
- No assessor signature: A consultant who helped complete the SAQ does not sign it, and a consultant's involvement does not change the signature requirement.
- Correct SAQ version: The signer should confirm the AOC matches the SAQ type and the PCI DSS version in use.
- Assessment date: The date should reflect when the SAQ was completed and reviewed, with the completed answers in hand.
Before signing, confirm that the answers and the AOC are final and that the signer has reviewed both.
Ownership of the attestation and ownership of the report are separate. The organization owns the AOC it issues to customers and acquirers, and it is answerable for the compliance status that the AOC declares. The assessor owns the ROC, which records the testing performed and the findings reached. Neither party can transfer that ownership to a third party.
- Organization: Owns the compliance status, the decision to sign, and the distribution of the AOC under payment brand rules.
- Assessor: Owns the ROC content, the testing conclusions, and its own signature on the ROC AOC.
- Implementation partner: Prepares systems, controls and evidence, but signs neither the ROC AOC nor the SAQ AOC.
- Consultant preparing an SAQ: Can help complete answers, but the organization's executive officer still makes the attestation.
- Independence: Work by a consultant does not replace the assessor's independent judgment, so the roles should stay documented and separate.
When you engage outside help, ask in writing who signs each document and confirm that no consultant or implementation partner is named as a signatory.
Signature errors are a common reason an AOC cannot be relied on, so a short pre-signing review helps. The checks below cover the sequence and the people involved. They apply to both report types, with the QSA company signature added for a ROC.
- Sequence: For a ROC, finalize the report before any AOC is signed or given to the entity.
- Name and title: Confirm each signatory's legal name, title and authority, as they will appear on the form.
- Version and template: Use the current official PCI SSC template for the report or questionnaire type.
- Record keeping: Keep the signed AOC with the supporting ROC or SAQ and the review record.
- Questions to confirm: Ask your QSA or acquirer which signatures they require and whether they accept electronic signatures.
Before sharing any AOC externally, check that the signatures match the report type and that the signatories have reviewed the content they are attesting to.
Why an AOC cannot be issued before the ROC is final
An Attestation of Compliance for a Report on Compliance cannot be handed over until the ROC is final, because the AOC does not stand on its own. It declares the results documented in the accompanying ROC, so the two documents must agree. The assessor enters the assessment date on both the ROC and the AOC, which ties the attestation to a specific, completed report. Under PCI SSC FAQ 1375, an AOC issued ahead of the finished ROC would declare results the report does not yet contain. Treat the AOC as the last step of the assessment, not a document that can be drafted in parallel with it.
The practical risk appears when a deadline arrives before the assessment is finished. A customer, acquirer or payment brand may ask for a current AOC, and the temptation is to request a signed attestation early, or to ask the QSA to date it to match the requirement. Either move puts the organization in the position of sharing a document that describes compliance the assessor has not finished confirming. If the ROC later changes, the AOC already in a customer's hands is wrong, and the organization carries the consequences. Ask the QSA early, in writing, when the ROC will be finalized, and confirm what the customer will accept in the interim, such as an assessment in progress letter, rather than assuming an AOC can bridge the gap.
Build the ROC completion date into the contract timeline from the start. Work backward from the date a customer, acquirer or payment brand needs the AOC, then allow time for the QSA's quality review, any remediation of findings, and the assessor's final sign-off. Confirm with the QSA how many review cycles they expect and whether remediation of open findings will reopen testing. The organization should also confirm which PCI SSC template version the assessment will use, since the ROC and AOC must match the current template. Put these dates in the statement of work or project plan so that the AOC is an expected output of a finished assessment, not a pressure point at the end.
How service provider AOCs serve as customer evidence
A service provider that holds a current Attestation of Compliance is expected to give it to customers when they ask for it. The AOC tells the customer that an assessment was completed, what the provider's compliance status is, and which services fell inside the assessed scope. Customers may also request relevant sections of the Report on Compliance or, where the provider validated through an SAQ D for Service Providers, the matching sections of that questionnaire. Because the AOC is the document meant for external sharing, it is usually the first thing a customer's procurement or security team asks for.
Customers use the AOC to map the provider's scope against their own payment flows. The scope and responsibility sections show which requirements the provider has validated on its side, and the third-party service provider listing shows which of the provider's own vendors were covered. A customer should check that the services it actually buys appear in the scope described, and that the attestation date is recent enough for its contract. Any requirement the provider leaves to the customer, such as account management or log review on the customer's side, needs an owner on the customer's team. Ask for a responsibility matrix alongside the AOC if the document does not make the split clear.
The AOC does not transfer compliance. The customer still owns its own PCI DSS obligations for the cardholder data it sends, stores or transmits, and its acquirer or the relevant payment brand decides what evidence it must hold. A clean provider AOC does not cover the customer's own configurations, access reviews or assessment. Before signing, confirm with the provider whether any redactions were made, check that the AOC is signed by an executive officer, and record which customer-side requirements the assessor will need to see from your own environment.
Why a PCI DSS certificate is not a substitute for an AOC
A certificate can look like proof of compliance, but PCI DSS recognizes only the official PCI SSC templates as validation evidence. The four cards below cover what that rule means for the documents you hand customers, what to ask your consultant for instead, and who decides whether a document is accepted.
Only official templates count
PCI DSS validation is documented on official PCI SSC templates: the Report on Compliance (ROC), the Self-Assessment Questionnaire (SAQ), the Attestation of Compliance (AOC) and the ASV scan attestation. Certificates issued by vendors or consultants are not recognized as validation. A logo, a seal or a letter saying a platform is "PCI compliant" does not replace any of these templates, and the standard does not treat a platform as compliant on its own.
The risk of rejection
A customer that asks for your AOC and receives a certificate has no way to verify your scope, the assessment date or the results behind it. Procurement and third-party risk teams will usually treat the request as unanswered, which can delay a contract or trigger a new questionnaire. Confirm early which document each customer and each payment brand expects, so the certificate never becomes the only artifact you produce.
What to ask your consultant for
Ask your consultant for the work products that feed a real assessment: a scoping summary, a gap analysis mapped to each requirement, remediation evidence and a readiness report. Ask which of these will be prepared for the assessor and who signs them. Where a qualified assessor is needed, the consultant can prepare the file but cannot issue the ROC or AOC, so confirm the assessor's role in writing before work starts.
Acceptance belongs to the requester
Whether a particular document satisfies a customer depends on the requesting entity and the payment brand rules that apply to the relationship. The organization that owns the controls decides what it shares, and the requesting entity decides whether it accepts an SAQ AOC, a ROC AOC or a service provider AOC. Confirm the acceptance criteria in writing with each requester, and keep the AOC and its supporting sections in a single, current set.
How to prepare your organization before an AOC request arrives
This sequence gets the validation type, assessor relationship, evidence and sharing rules settled before a customer or acquirer asks for an Attestation of Compliance. The output is a signed-off plan and a ready-to-share AOC that reflects a finalized assessment.
Confirm the required validation type
Ask your acquirer or the relevant payment brand which validation they expect: a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire with its own AOC, and which SAQ type applies. Brand rules decide who must validate and how, so get the answer in writing. Your compliance lead owns this step, and it is done when the requirement is recorded with the date, the contact and the form name.
Define the scope of the assessment
Document the cardholder data environment, its boundaries, connected systems and any third-party service providers whose services affect it. Assessors will test this scope, and it also determines which AOC sections need accurate service and third-party details. Your team owns the inventory and data-flow diagrams, and an implementation partner can help prepare them. The step is complete when the scope is approved internally and matches what the assessor or SAQ path will cover.
Agree the assessment path with the QSA or SAQ owner
If a ROC is required, agree with your Qualified Security Assessor the evidence expectations, sampling approach, onsite or remote method and the schedule for finalizing the report. If an SAQ applies, confirm internally who completes it and who will sign. Ask the assessor for a written engagement that separates advisory work from assessment work, consistent with QSA independence rules. The output is a signed engagement letter and a shared evidence request list.
Prepare evidence and any compensating control records
Assemble the artifacts the assessor will request, such as policies, configuration records, logs, scan results and access reviews. Where a requirement is met through a compensating control or the customized approach, document the rationale and the supporting analysis in advance. Assessors judge sufficiency, so confirm the approach with them before relying on it. Done when every requirement in scope has a named evidence owner and a storage location.
Confirm the AOC is issued only after the ROC is final
Establish an internal rule that no AOC is shared externally until the ROC is finalized and the assessor has entered the assessment date. Advance drafts or unsigned forms are not a substitute. Ask the QSA which signatures are required from your executive officer and from the QSA company's authorized officer, and schedule those approvals. The check is complete when the sign-off path is documented and a finalized AOC exists in your records.
Set the AOC redaction rules
Decide in advance what you will redact before sharing, such as a data center location or specific technologies in the CDE. Contact information, service provider scope verification, third-party service provider details, the summary of assessment and the validation and attestation sections should stay unredacted. Have legal or compliance review the redaction standard so each request is handled the same way. Done when a written redaction checklist is approved.
Create the sharing procedure and confidentiality terms
Write a procedure that names who receives AOC requests, who approves release, how the document is transmitted and how the request is logged. Where the description of services is sensitive, prepare a confidentiality agreement to accompany the AOC, since sharing the AOC is generally preferred over sharing the full ROC or SAQ. Keep a register of recipients and versions. The step is complete when the procedure is published to the teams that handle customer and acquirer requests.
Test the request process with a dry run
Run one internal scenario in which a customer asks for the AOC and, if relevant, relevant ROC or SAQ D sections. Walk through identification of the form, redaction, approval, sharing and logging, and note where the process stalls. Assign owners for each fix and confirm that a certificate or vendor letter is never offered as validation. The output is a short after-action record and an updated procedure.
Frequently asked questions about the PCI DSS AOC
Who issues the PCI DSS Attestation of Compliance?
The entity being assessed owns the AOC, and an executive officer of that entity signs it. For a Report on Compliance, a duly authorized officer of the Qualified Security Assessor company also signs. Neither your implementation partner nor any consultant issues or signs the AOC. The AOC accompanies either a ROC completed by a QSA or a Self-Assessment Questionnaire, and it can only be finalized after the underlying assessment is complete. Confirm the signatories and the required form version with your acquirer or payment brand before the assessment starts, because their reporting rules determine which AOC you must produce.
Can we send a draft AOC to a customer while the ROC is in progress?
No. The AOC declares the results documented in the ROC, and the assessor enters the assessment date in both documents, so an AOC cannot be given to the assessed entity before the ROC is final. A draft or unsigned AOC is not validation evidence. If a customer asks for status while the assessment runs, you can share a written statement of the planned timeline and the scope under review, but present it as progress information, not as an attestation. Ask your QSA when the ROC will be finalized so your sales and procurement teams do not promise dates the assessment cannot meet.
What may we redact from an AOC before sharing it?
You may redact some sensitive details, such as the city of a data center or the technologies used in the cardholder data environment. Contact information, scope verification for service providers, third-party service providers, the summary of assessment, and the validation and attestation sections should stay unredacted. Redaction is a judgment about what your payment brand and the requesting customer accept, so confirm the approach with your QSA and your acquirer before you send a redacted copy. Where the description of services is sensitive, agree a confidentiality agreement with the requester before you share the document.
Who pays for the ROC, and what drives its cost?
Your organization pays the QSA company for the ROC assessment, because the entity being assessed contracts for it. The fee depends on the size and complexity of the cardholder data environment, the number of locations and systems in scope, how much evidence is available in advance, and whether the assessment is onsite, remote or a mix. This page does not supply a figure. When requesting quotes, ask each QSA company to state the scope it assumed, the number of assessor days, the sampling approach, and any travel or reporting charges. Ask whether the quote covers one assessment or a recurring annual cycle.
Can a consultant sign our AOC or prepare the ROC for us?
A consultant cannot sign the AOC on the assessed entity's behalf unless the consultant is an executive officer of that entity, and a consultant cannot be the QSA who signs a ROC for an engagement it helped to design. Keep consulting and assessment work separate. Implementation partners can prepare systems, configuration evidence, policies and documentation, and they can help you organize the evidence the assessor requests. The QSA then tests that evidence and makes the determinations. Confirm the independence boundaries with your QSA before the engagement starts, since assessor independence rules constrain which services they can provide to the same client.
What happens if a customer rejects our certificate instead of the AOC?
The customer may reject it because a certificate is not recognized as validation under PCI DSS. Only official PCI SSC templates, including the ROC, the AOC, the SAQ and the ASV scan attestation, count as validation evidence, and certificates issued by vendors or consultants do not. Respond by sending the signed AOC that corresponds to your ROC or SAQ, and offer the sections of the report the customer is entitled to review under its contract and payment brand rules. If the AOC is not yet available, explain the status honestly and give the customer the expected completion steps rather than a substitute document.
Can we obtain a service provider AOC from our own vendors to support our assessment?
Yes, a service provider with an AOC is expected to provide it to customers on request, and customers may also ask for relevant ROC or SAQ D sections. Request the vendor's current AOC and check its date, its scope, and the services it covers, since a vendor AOC describes that vendor's own assessment and not yours. Record which requirements the vendor covers in your responsibility matrix so your assessor can see where your evidence ends and the vendor's begins. Ask the vendor to confirm whether the AOC remains current for the services you use.
How DeployOpen works on this
DeployOpen prepares the systems, controls and evidence that a QSA reviews before an Attestation of Compliance can be issued. The independent QSA writes the ROC and the AOC, while your organization owns its controls and decides how the AOC is shared.
How we scope
- Agree the written scope for the AOC work before any engagement begins, including which systems and services it covers.
- Confirm with your QSA or acquirer which AOC form and assessment type applies, such as a ROC or a specific SAQ.
- Identify which sections of the AOC will need redaction review and who in your organization approves any redacted copy.
How we build
- Implement or harden the self-hosted open-source platforms in your own infrastructure so the controls they provide are in place before the assessor arrives.
- Configure logging, access and monitoring so the assessor can trace each claimed control to a repeatable, dated record.
- Document any compensating controls or customized approach designs as your organization's decisions, with the supporting evidence attached.
How we hand over
- Deliver the evidence register, configuration records and control documentation that the QSA requests during fieldwork.
- Hand over a list of the open items and their owners, so your team can answer assessor questions without delay.
- Keep the handover clear that only the QSA issues the ROC and AOC, and that certificates or readiness letters are not validation.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the assessment, if your organization wants it.
- Help your team respond to customer requests for the AOC, including confirming which sections are safe to share under payment brand rules.
- Prepare updated evidence when the annual cycle or a change to the cardholder data environment requires the AOC to be refreshed.
