Two-party attestation: how the PCI AoC handoff should work

A PCI DSS v4.0.1 guide for merchants and service providers. Why the single-signature Attestation of Compliance has structural weakness, what two-party attestation actually means, and how to ship the AoC to your QSA and your acquirer as two cryptographically verifiable artifacts.

Key 102 Consulting · 2026 · Veteran-owned. Practitioner-led PCI v4.0.1 readiness across SAQ-A through SAQ-D.

---

The acquirer inquiry that exposes the AoC's weak link

A card brand investigation closes a merchant account pending review. The acquirer requests the merchant's most recent Attestation of Compliance. The merchant sends the PDF their compliance vendor generated nine months earlier. The acquirer's compliance reviewer reads it, then sends a follow-up:

"We need confirmation that the language in this AoC reflects what your CFO actually attested to on the date in the signature block. The version your QSA submitted to us last quarter differs by one control. Can you reconcile?"

The merchant cannot. Their AoC was generated by their compliance platform's "export to PDF" function. The signature block carries their CFO's name. The date is correct. But the language in the PDF differs from the version their QSA holds — because the platform's template was updated between attestation and export. Neither version is cryptographically anchored to the other. The merchant cannot prove what their CFO actually saw and signed.

The Attestation of Compliance is the document Visa, Mastercard, American Express, Discover, and JCB receive (via the acquirer chain) as the merchant's compliance evidence. When the AoC can't prove itself, every downstream party has to trust the merchant's vendor — and the vendor's track record is what's now in question.

This paper covers what the AoC actually is, what's structurally weak about single-signature AoC handoffs, what two-party attestation means in practice, and how to ship the document to your QSA and your acquirer as cryptographically anchored, independently verifiable artifacts.

What the AoC actually is

The Attestation of Compliance is one of the PCI Security Standards Council's standard reporting documents. The merchant or service provider attests, at a specific point in time, that their assessed PCI DSS environment meets the standard.

There are several variants:

• AoC for SAQ — for self-assessed merchants completing one of the eligibility-specific Self-Assessment Questionnaires (SAQ-A through SAQ-D, plus SAQ-D-SP for service providers).
• AoC for ROC — for entities completing a full QSA-led Report on Compliance. The AoC is the executive-summary signature document that accompanies the ROC.

In both cases, the AoC is the document the merchant's QSA or ISA reviews and signs (when applicable), and the merchant's senior officer signs to attest organizational ownership. The document moves through three audiences: the QSA who reviewed it, the acquirer who receives it as part of merchant compliance reporting, and any card brand inquiry that requests evidence.

Each audience verifies the document differently — and each can challenge the document on independence and integrity grounds.

The single-signature AoC problem

A typical compliance-platform AoC carries one signature: the merchant's senior officer. The platform renders the PDF, the officer signs it, the document is filed.

Three structural weaknesses follow:

1. The practitioner's review isn't durable. A QSA or qualified practitioner reviewed the SAQ-D responses + supporting evidence, typically over several weeks. That review produced the language that ended up in the AoC. But when only the merchant signs, the practitioner's review becomes ephemeral — the document carries no durable indication that the language was vetted by someone with PCI expertise.

2. The merchant's attestation isn't byte-anchored. The officer signed something — but to what byte-stream? PCI's template includes specific language about scope, in-scope controls, compensating controls, and findings. If the platform regenerated the AoC after signature (silent template updates, font substitutions, layout shifts), the bytes the officer attested to are no longer the bytes the acquirer receives.

3. The QSA's submission becomes a separate document. The QSA typically retains a copy in their workpapers; the merchant retains a copy; the acquirer receives a third copy through the merchant's compliance reporting. Three copies exist. There's no canonical hash linking them. Discrepancies surface during inquiries, not during attestation.

The result is the scenario in the opening: an acquirer can't verify that the AoC they're holding matches what was attested. Neither can the merchant. Neither can the QSA. The trust model relies entirely on each party trusting their vendor's storage discipline.

What two-party attestation means

Two-party attestation requires both the qualified practitioner and the merchant senior officer to sign the same document, in sequence, before the AoC is considered final.

The mechanic, when properly implemented:

Step 1 — practitioner attestation. The QSA, ISA, or qualified practitioner who walked the SAQ-D + evidence package reviews the final AoC language, attests to the technical accuracy, and signs. The signature is recorded with: practitioner name, credential (QSA-conversant / QSA / ISA), timestamp, document hash at moment of signature.

Step 2 — document lock. The AoC's bytes are server-hashed (SHA-256, computed server-side at the moment of practitioner attestation, not in the merchant's browser). The hash is recorded immutably. Any subsequent change to the document changes its hash; the original hash is preserved.

Step 3 — merchant attestation. The merchant's senior officer reviews the locked document and performs a deliberate confirmation — typically a step-up authentication followed by typing a confirmation phrase ("SIGN AND LOCK" or equivalent). This is recorded with: officer name, title, timestamp, and document hash at moment of signature. The hash matches the practitioner's hash by construction.

Step 4 — append-only record. Both signature records live in an append-only table where UPDATE and DELETE are blocked at the database trigger level. Neither party can revise their signature record after the fact. If something needs to change, it happens as a new attestation event — never as a mutation of the prior one.

Step 5 — independent verification token. An RFC 3161 Trusted Timestamping Authority (typically SSL.com or DigiCert) receives the document hash and returns a signed timestamp token. The token proves the document existed in this exact byte form at this exact moment, verifiable by any recipient.

What you now have: a document that both parties signed, in the same byte-stream, anchored to an independent clock, and recorded in a structurally immutable log. The acquirer's inquiry from the opening has a clean answer.

The external-share variant problem

The AoC is rarely the only document in play. A typical PCI engagement produces:

• The full SAQ-D + AoC bundle (signed)
• The supporting evidence package (configuration extracts, logs, screenshots, walk-through notes)
• ASV scan reports (quarterly)
• Penetration test results (annual)
• Network diagrams and CDE scope documentation

The QSA wants the full bundle. The acquirer typically wants the AoC alone, sometimes with a high-level summary of the evidence package. The card brand inquiry (when one happens) wants whichever specific evidence the inquiry is targeting.

The single AoC that ships to all three audiences either over- shares or under-shares.

A working external-share variant solves this with two PDF renderings of the same canonical attestation:

The canonical (internal / QSA) variant. Full AoC text + evidence excerpt references inline. Practitioner signature page. Senior officer signature page. Used by the QSA for workpapers and by the merchant's internal audit + leadership.

The external-share (acquirer / card brand) variant. AoC text without internal evidence excerpts, with placeholder references to the canonical variant. Same signature pages. Same TSA timestamp. Same document hash anchor for the canonical version, plus a distinct hash for the redacted variant.

Both PDFs are produced from the same attestation event, share the same signatures, and each carries its own verify endpoint. A recipient can confirm which variant they're holding and verify it against the canonical attestation without seeing internal evidence excerpts that aren't theirs to view.

What QSAs actually do at handoff

A QSA reviewing a finalized AoC typically performs four checks:

1. Signature pair integrity. Both signature blocks present? Both signers identifiable? Practitioner credential listed and verifiable?

2. Byte-level consistency. Does the AoC the merchant submitted to the workpapers system match the AoC the QSA attested to? Independent hash check.

3. Scope language consistency. Does the AoC's stated scope match what was assessed? Did anything get "reduced" between assessment and final?

4. Date-window consistency. Were the merchant's controls in the attested posture for the full attestation window, or did significant scope or control changes happen post-attestation?

A two-party attestation with cryptographic anchoring makes checks 1 + 2 trivial — the QSA hits the verify endpoint and gets back signature pair + matching hash. Checks 3 + 4 still require human review, but the verifiable foundation lets the QSA focus on substance rather than authenticity.

What acquirers actually do at handoff

Acquirers run a simpler review: they confirm the merchant's AoC exists for the relevant attestation period, that the senior officer's signature is on file, and that the merchant's compliance reporting is current. Acquirers typically don't review evidence excerpts; that's the QSA's job.

When an inquiry happens — typically triggered by a card brand mandate, fraud event, or unusual activity — the acquirer escalates to a forensic investigator. At that point, the questions get specific: was control X actually in place on date Y? The two- party attested AoC + the linked canonical variant + the evidence references in the canonical variant are the response surface.

A merchant whose AoC verifies independently is in a defensible position by default. A merchant whose AoC can't verify is in a trust-the-vendor position by default, and the vendor's track record at that point is the question.

How Key 102 ships this for Vault customers

Key 102's Vault tier delivers PCI v4.0.1 readiness across SAQ-A through SAQ-D. The Vault Managed and Audit Co-Pilot tiers ship the Tier 2 PCI Deliverable as the canonical attestation mechanism:

• Practitioner attestation first; senior officer attestation second; both recorded in an append-only compliance_deliverable_ attestations table where UPDATE and DELETE are trigger-blocked
• SHA-256 hashed server-side at practitioner sign-time; hash becomes the canonical anchor
• RFC 3161 TSA timestamp via an independent authority on every attestation event
• Canonical (QSA-facing) PDF + external-share (acquirer-facing) PDF rendered from the same attestation event, each with its own verify URL
• QSA-direct verification page on every audit-facing PDF — your QSA hits the URL and confirms authenticity without calling Key 102 + without trusting our clock or database

The merchant's experience at attestation is deliberately ceremonial — the step-up confirmation makes the moment visible and undeniable. The acquirer's experience at submission is the opposite — they see a clean AoC with a verify endpoint, and the verification is one click.

---

Start your PCI v4.0.1 readiness with Key 102

Key 102 Consulting is veteran-owned, SAM-registered, and based in Phoenix, Arizona. Our Vault tier delivers PCI v4.0.1 readiness across all 12 requirements + the 51 future-dated controls mandatory as of 2025-03-31. SAQ-A through SAQ-D applicability, with the Tier 2 PCI Deliverable for two-party-attested AoC + SAQ bundles on Vault Managed and Audit Co-Pilot.

Every artifact — AoC, SAQ-D, ROC supporting evidence, quarterly readiness report — carries a named practitioner signature, server-side SHA-256 hash, RFC 3161 TSA timestamp, and a public verify endpoint your QSA + acquirer can hit independently of Key 102.

UEI: TXQFV5FJX797 Primary NAICS: 541519 (Other Computer Related Services) Additional NAICS: 541512 · 541690 · 611420 PSC Codes: DJ10 · DJ01 · D302 · R499 · U099

Start with a $674 Mission Brief →

The Mission Brief is a 90-minute diagnostic engagement with Tammie and a practitioner. PCI merchants walk out with a scoped readiness plan + an initial SAQ-D-aligned artifact. The $674 credit converts 1:1 into Vault Self-Service / Guided / Managed / Audit Co-Pilot within 14 days.

---