When an acquiring bank, a payment brand, or an enterprise customer’s procurement team asks for “your PCI compliance paperwork,” they rarely specify which of two very different documents they mean. Handing over the wrong one either overshares infrastructure detail you never meant to disclose, or fails to satisfy the request entirely. The Report on Compliance (ROC) and the Attestation of Compliance (AOC) are both real PCI DSS deliverables, but they serve different audiences, carry different levels of detail, and get requested by different parties for different reasons. Mixing them up is one of the more common friction points between security teams and the partners auditing their supply chain.
What the Report on Compliance contains and who writes it
The ROC is the full assessment record. For most Level 1 merchants (generally over six million card transactions a year, thresholds vary by brand) and for service providers designated Level 1 by a payment brand, it is produced by a Qualified Security Assessor (QSA) after testing the entity against every applicable PCI DSS requirement. The PCI Security Standards Council publishes a standardized ROC template, and a completed one typically runs anywhere from 80 to well over 300 pages depending on how large and segmented the cardholder data environment (CDE) is.
Inside, you find the assessment scope definition, network diagrams, cardholder data flow diagrams, the sampling rationale used when testing multiple similar systems, and, requirement by requirement, a narrative of exactly how the QSA validated it: which firewall rule sets were observed, which administrators were interviewed, which change tickets were reviewed, which configuration files were pulled and on what date. This is evidence-grade documentation, and that is precisely why it is sensitive. A ROC appendix can effectively be a map of your segmentation boundaries, in-scope system names, and sometimes IP ranges. Only the assessed entity, its QSA, and, on specific request, its acquiring bank or a card brand (for example during breach forensics) would ever see the complete document. It is not something you send to a customer running vendor due diligence, and it is not something a vendor should be asking you for either.
The Attestation of Compliance as the shareable summary, and SAQ-based AOCs
The AOC is the document actually designed to travel between organizations. It is a short, standardized PCI SSC form, with separate templates for merchants and service providers, and separate versions depending on whether the underlying assessment was a full ROC or a Self-Assessment Questionnaire (SAQ). Where a ROC can be hundreds of pages, an AOC is typically four to six pages regardless of how large the underlying assessment was.
Structurally it has four parts: Part 1 covers entity and contact information, Part 2 is an executive summary stating the PCI DSS version assessed against, the assessment date, and the QSA company name if one was used, Part 2a confirms the scope of the assessment, and Part 3 carries the validation statement and signatures. For entities that qualify for a Self-Assessment Questionnaire instead of a full QSA-led ROC, such as SAQ A, A-EP, B, B-IP, C, C-VT, or the merchant and service-provider variants of SAQ D, the AOC still exists in the same short form, just referencing the relevant SAQ instead of a ROC.
Who is entitled to request which document, and what you should never share
Your acquiring bank and the card brands are entitled to the AOC as a matter of course, and can request the full ROC directly, or through your QSA, in specific circumstances such as post-incident follow-up. A business partner or customer running a vendor risk assessment on you is entitled to the AOC, and reasonably to supporting items like your most recent passing ASV scan attestation, but not the ROC itself.
If a partner insists on seeing the full ROC as a condition of doing business, that request is worth pushing back on. Standard practice routes deeper assurance through the acquirer relationship or a mutual NDA covering specific, narrow items, not wholesale disclosure of testing evidence and network diagrams. Two practical rules follow from this:
- Never attach a ROC, or ROC excerpts, to a public trust page or a general sales data room. The AOC is built for that purpose; the ROC is not.
- Never forward a vendor’s ROC (if one was mistakenly sent to you) to anyone else in your organization who does not need it for the specific compliance decision at hand. Treat it as you would any document containing your own infrastructure layout.
Validity period, annual renewal and changes between assessments
An AOC and its underlying ROC or SAQ are valid for twelve months from the assessment date, which is tied to when your QSA (or your own team, for SAQ) actually completed testing, not the calendar year. PCI DSS validation is a point-in-time exercise, but the standard assumes continuous control operation between assessments: quarterly external vulnerability scans by an Approved Scanning Vendor under Requirement 11.3.2, periodic internal scans, and annual penetration testing all have to keep running on their own cadence regardless of where you are in the twelve-month AOC cycle.
Material changes to the cardholder data environment, such as adding a new payment channel, onboarding a new outsourced processor, or absorbing systems through a merger, can trigger the need for a scope re-evaluation before the twelve months are up. When you review a partner’s AOC that is, say, eleven months old, it is still technically valid, but check separately whether the quarter-by-quarter evidence they are citing (most recent passing ASV scan, most recent penetration test) is actually current. Quarterly evidence expires on a much shorter clock than the annual attestation does, and a stale scan behind a fresh-looking AOC is a common gap.
Reviewing a supplier’s AOC: scope lines, dates and red flags
When a vendor sends you their AOC as part of onboarding or renewal, work through it the same way each time rather than just filing it:
- PCI DSS version. Confirm it references a version still within its migration window (v4.0.1 requirements became mandatory for most organizations after the v3.2.1 retirement); an AOC still citing 3.2.1 well past the cutover is a lapse, not a formatting quirk.
- Assessment date. Confirm it falls within the trailing twelve months from today, not from when the vendor relationship started.
- Part 2a scope. Read the included and excluded services lines carefully. A payment gateway’s AOC might cover its transaction API but explicitly exclude a separate hosting or analytics product from the same vendor. The AOC covering one product does not extend to another.
- Assessment type matches transaction volume. A vendor processing at Level 1 volumes should show a QSA-signed, ROC-based AOC, not a self-attested SAQ D. If the volume and the assessment type do not match, ask why.
- Integration method matches SAQ type. If a vendor claims the lightest SAQ A but your integration actually loads their payment fields inside an iframe served from your own page rather than a full redirect, that method typically requires SAQ A-EP, which carries meaningfully more control obligations. This mismatch is one of the most common errors in vendor AOCs.
- Named scope, not just a company name. An AOC that lists only the corporate entity, with no specific product or service named in Part 2a, tells you nothing about what is actually covered.
Keeping this checklist current across dozens of vendors is tedious by hand, which is why platforms that maintain a live compliance map, such as SITEY, attach each PCI DSS requirement to the control, scan result, or remediation ticket that satisfies it. When a vendor’s next AOC narrows what they cover, the change shows up as a reopened requirement against your own environment instead of a note buried in a spreadsheet nobody revisits until the next audit.
How service provider AOCs affect your own assessment scope
Requirement 12.8 of PCI DSS obligates you to maintain a list of service providers with access to cardholder data or that could otherwise affect its security, to document a written agreement acknowledging their PCI DSS responsibilities, and to obtain confirmation, in practice their AOC, at least annually that they remain compliant. The part teams frequently skip is 12.8.5: maintaining a matrix of which specific PCI DSS requirements the service provider manages versus which ones you still own.
That matrix is where the AOC’s exclusion language becomes operationally important. If a tokenizing payment provider’s AOC states that TLS certificate management or delivery security for an embedded checkout field is the customer’s responsibility, that requirement sits back in your own scope no matter what your architecture diagram assumed. This is the difference between qualifying for the minimal-scope SAQ A and needing to complete SAQ A-EP: SAQ A is only available when the provider’s own AOC confirms they manage all of the security-impacting elements of that payment page, including the TLS delivery. If their AOC carves any of that out, your assessment has to cover it directly.
Practically, before each renewal cycle pull the current AOC for every relevant vendor, extract the “requirements not covered” language from Part 2a, and reconcile it against your own control ownership before your QSA or SAQ session starts, not during it. Because the underlying evidence for that reconciliation, quarterly ASV scans, internal scan results, penetration test findings, and confirmation that a prior finding was actually fixed rather than just marked closed, tends to live across separate tools, the reconciliation itself is often the slow part. Tools that automate the retest step, such as SITEY, re-scan the specific finding after a patch ships instead of trusting the patch command’s exit code, which is the difference between a quarterly scan that genuinely clears a requirement and one that quietly reopens next cycle. And when an acquirer or partner asks for evidence beyond the AOC itself, reporting tooling built around that same requirement-to-evidence trail, such as SITEY, can export the specific history a reviewer is asking about instead of someone assembling it manually from scan exports the week the request lands.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.