A Report on Compliance is a deeper audit artifact, usually produced after a QSA reviews documentation and tests controls. An Attestation of Compliance is the declaration that the organisation meets PCI DSS requirements, often after a self assessment or audit. In practice, the RoC demonstrates the evidence base, while the AoC confirms the compliance outcome for the relevant scope.
How the Two PCI Artefacts Differ in Practice
The Report on Compliance and the attestation of compliance serve different purposes in PCI DSS governance. The RoC is the deeper assessment record, built from control review and testing, while the AoC is the formal declaration that the assessed scope meets the requirement set. That distinction matters because one is evidence-heavy and the other is outcome-heavy.
The RoC is typically associated with a Qualified Security Assessor-led review, so it carries detail about what was examined, how controls behaved, and where scope was determined. The AoC is much shorter and is designed to communicate compliance status in a standardised form that can be shared with acquirers, partners, and other stakeholders who need confirmation rather than the full audit trail. For the PCI DSS baseline itself, see PCI DSS v4.0 — PCI Security Standards Council.
For teams mapping compliance obligations into broader security governance, the difference is not just document length. The RoC helps answer, “What was tested and what evidence supports the conclusion?” while the AoC answers, “What is the organisation asserting about compliance for this scope?” If you need defensible assurance, the RoC is the more informative artefact; if you need a standard compliance declaration, the AoC is the one that usually travels externally. NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives is a useful adjacent reference for how audit evidence, governance obligations, and access review expectations are typically framed in practice.
When Each Document Is Used
The RoC is usually the artefact that matters when the organisation has undergone a formal assessment and needs a detailed record of control testing. It is the more authoritative source for internal remediation work, assessor follow-up, and explaining exactly why the assessor reached the conclusion they did.
The AoC is more commonly used as the concise proof-point that the organisation has completed the PCI DSS process for the relevant scope. In many programmes, it is the document people ask for first because it is easier to distribute and interpret. Where the compliance journey includes self-assessment rather than a full assessor review, the AoC often becomes the principal external-facing record.
The difference is especially important when scope is disputed. A valid AoC without the underlying evidence may be enough for a checkbox request, but it is not a substitute for understanding how the controls were evaluated. Conversely, a RoC without a clean outcome declaration can leave partners uncertain about the final compliance status. The two documents complement each other rather than compete.
For organisations aligning cardholder-data controls to a broader security management system, ISO/IEC 27001:2022 Information Security Management and ISO/IEC 27002:2022 Information Security Controls provide a helpful way to distinguish control design from control evidence, even though PCI documents are not the same as ISO certification artefacts.
Risk and Threat Considerations
The main risk is treating the AoC as if it proves control effectiveness on its own. A compliant-looking declaration can hide scope gaps, weak evidence, or untested controls if the underlying assessment was shallow or if the organisation relies on stale assumptions about what was actually reviewed.
Failure mechanism: Control evidence is incomplete, scope is misdefined, or the assessed environment changed after the review, so the RoC and AoC no longer describe the same operating reality.
Impact: The organisation may overstate compliance, miss remediation work, or fail to detect that sensitive card-data systems drifted out of alignment with the assessed scope.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 7 — Restrict Access by Business Need to Know | PCI compliance evidence depends on scoped access controls being assessed and justified. |
| 8.6 — System and Application Accounts and Management | RoC evidence often examines non-human accounts and related control testing in PCI scope. | |
| Recommendation — Document and verify least-privilege access for the assessed PCI scope. Track and review system and application accounts within the cardholder-data environment. | ||
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | The RoC versus AoC distinction reflects how evidence and declared compliance support governance decisions. |
| Recommendation — Use governance processes to separate assessment evidence from compliance declarations. | ||
Practitioner Guidance
What to verify: Confirm whether the request is asking for evidence of assessment depth or simply proof of compliance status. If the stakeholder wants to understand how the conclusion was reached, the RoC is the right document; if they only need a formal declaration, the AoC is usually sufficient.
Common mistake: Teams often circulate the AoC as though it settles all audit questions. It does not answer control-by-control questions, and it should not be used as a substitute for the assessor’s evidence trail when there is a dispute, exception, or remediation discussion.
Practitioner takeaway: Use the RoC to defend the assessment, and use the AoC to communicate the outcome; when those two documents diverge in timing, scope, or evidence quality, treat that as a governance issue, not a paperwork issue.
Related resources from NHI Mgmt Group
- What is the difference between storing PCI data in Box and maintaining PCI compliance on Box?
- What is the difference between detective PCI DSS controls and shift-left compliance controls?
- What is the difference between PCI DSS responsibility for third-party service providers and the customer’s own compliance obligations?
- What is the difference between RBAC and secrets management in PCI DSS 4.0 compliance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
