What "PCI DSS certification" actually means, and who signs it

There is no PCI DSS certificate. The PCI Security Standards Council publishes no certificate template, no assessor issues one, and no acquirer accepts one in place of what its compliance programme actually asks for. What an assessed entity ends up holding is a pair: a Report on Compliance and an Attestation of Compliance, or a Self-Assessment Questionnaire and an Attestation of Compliance.

"Certification" persists because it describes the transaction well enough — you are assessed, you receive a document to send to somebody. It gets the document wrong, and the difference decides who signs and what that signature commits them to.

Search PCI DSS v4.0.1 for the word itself and you find cryptographic certificates, an individual's professional certifications, and certificates of attendance for training. Not once does it describe the outcome of an assessment.

Three documents, and the one that circulates

Section 9 lists the artefacts an entity may reasonably protect as sensitive, puts the reporting documents on that list, then carves out the third: the AOC "is not considered sensitive and third-party service providers (TPSPs) are expected to share their AOC with customers". It is also the one nobody drafts themselves — "Official Attestations of Compliance are only available on the PCI SSC website."

Who signs an SAQ, and who does not

Take SAQ D for Merchants, which carries the fullest attestation section of the set. Section 3 splits into four parts, and only one holds a signature that is always present.

• Part 3a — Merchant Acknowledgement. Three statements the signatory confirms, including that "PCI DSS controls will be maintained at all times".
• Part 3b — Merchant Attestation. "Signature of Merchant Executive Officer", with name, title and date.
• Part 3c — Qualified Security Assessor (QSA) Acknowledgement. Conditional, headed "If a QSA was involved or assisted with this assessment". Where it applies it takes two signatures: the Lead QSA, and a Duly Authorized Officer of the QSA Company.
• Part 3d — PCI SSC Internal Security Assessor (ISA) Involvement. A declaration of the role performed. No signature line at all.

The instruction above them ties the parts together: each signatory in any of Parts 3b–3d "assert(s) the following compliance status". A QSA who assisted may sign; an ISA's involvement is disclosed rather than signed; the merchant's own executive officer signs in every case. A self-assessment is your company's assertion about your company, and paying a QSA to help complete it does not move that assertion onto them.

Which questionnaire you are eligible for is a separate question with a table-shaped answer — see which SAQ applies to you.

Who signs a ROC

A ROC is written against the PCI SSC Report on Compliance Template by a QSA or an Internal Security Assessor. Size alone does not decide the route: an SAQ-eligible entity "may elect to have a QSA or ISA perform their assessment and document it in a ROC Template", and must if it wants the customised approach, which SAQ filers cannot use.

The QSA Agreement is unusually precise about what the assessor's signature certifies. Under section A.3.2 of the QSA Qualification Requirements, the QSA undertakes to include an AOC "signed by a duly authorized officer of QSA, in which QSA certifies without qualification that (a) … QSA followed the requirements and procedures of the applicable PCI SSC Standard(s) without deviation and (b) … did not indicate any conditions of non-compliance … other than those expressly noted in the ROC".

Read what is actually certified: the assessor's own conduct of the assessment, and the absence of any finding beyond what the report records. It is a statement about a body of work performed on a set of dates — not a warranty about the entity, and silent about next quarter.

An attestation can say "Non-Compliant"

Here the certificate framing gives out entirely. Before any signature, Part 3 settles two things. First, whether the assessment was Full or Partial: any requirement marked Not Tested makes it Partial, on the face of the form. Second, the compliance status, of which there are three:

• Compliant — every assessed requirement is In Place, In Place with Remediation, or Not Applicable.
• Non-Compliant — one or more are Not in Place. The form asks for a Target Date for Compliance, and the recipient may require a Part 4 action plan.
• Compliant but with Legal exception — a requirement is Not in Place because a legal restriction prevents it being met.

A form that can be validly completed, signed and submitted while stating that the entity "has not demonstrated compliance" is not a certificate. It is a dated, signed statement of position, which is how everyone downstream reads it.

Who decides you need one at all

Not the Council: "Whether any entity is required to comply with or validate their compliance to PCI DSS is at the discretion of those organizations that manage compliance programs (such as payment brands and acquirers)." The finished documents go to "the requesting organization", along with anything else it asks for, such as ASV scan reports.

The brand programmes then set the signature rules. American Express's Data Security Operating Policy of April 2026 requires a ROC AOC signed and dated annually by the QSA or ISA and by authorised leadership inside the assessed company, while a SAQ AOC needs only the entity's own leadership signature. Visa's service provider requirements, dated 15 July 2015, accept only "fully executed AOC forms, properly signed by the QSA and the third party agent", and list validated providers on a brand-run registry rather than issuing anything.

An Indian entity has a second half to this, because an RBI-regulated payment aggregator carries obligations sitting alongside PCI DSS rather than inside it — covered in PCI DSS and the RBI Payment Aggregator Directions.

"Send us your PCI certificate"

When that lands from a customer, the thing being asked for is the AOC. Requirement 12.8.4 obliges entities to monitor their third-party service providers' compliance status at least once every 12 months, and the guidance on 12.9.2 puts it plainly: "If a TPSP has a PCI DSS Attestation of Compliance (AOC), the expectation is that the TPSP should provide that to customers upon request to demonstrate their PCI DSS compliance status."

What to read on the one you receive, in the order that matters:

• Which form it is — merchant or service provider. They are not interchangeable.
• The assessment type: a ROC, or which SAQ.
• The assessment date and the version assessed against.
• Full or Partial — and if Partial, which requirements were Not Tested.
• The status, including any legal exception recorded.
• The services and system components in scope. A supplier can hold a genuine AOC covering none of what it does for you.
• The responsibility split under 12.9.2 for anything shared.

Nearly all of it sits in Section 1 of the form. The company name at the top is the least informative thing on the page.

What sits underneath the signature

An AOC is a page of signatures over a body of testing somebody had to perform first. For Requirement 11.4 the standard names who: internal and external penetration testing "By a qualified internal resource or qualified external third-party", with "Organizational independence of the tester exists (not required to be a QSA or ASV)". The same wording governs 11.4.5 segmentation testing and 11.4.6, which puts service providers on a six-month cycle.

Testing and attestation are different jobs, written so different parties can hold them. Penetration testing scoped to Requirement 11.4 produces the evidence; the signature block belongs elsewhere. Where the evidence falls short is where an assessment stalls — the recurring causes are in what gets a PCI penetration test report rejected.