An Attestation of Compliance is the formal statement that an organisation has completed its PCI DSS validation and believes its controls meet the required standard. It is a declaration of accountability, not a technical control, and it carries weight because it links the assessment result to the organisation’s operating environment.
Expanded Definition
An Attestation of Compliance, often abbreviated AOC, is the formal statement used in PCI DSS validation to record that an organisation has completed assessment activities and asserts its controls meet the standard. It is an accountability artifact, not a technical safeguard, and it is typically paired with evidence such as a Report on Compliance or self-assessment results.
In NHI and broader IAM governance, an AOC matters because it reflects the state of the environment at a point in time, including how service accounts, API keys, certificates, and other secrets are governed. That makes it relevant to operational identity risk even though it is not itself an identity control. The most precise reading is that the AOC confirms compliance posture, while the underlying control set must be continuously maintained across systems and teams.
Usage varies across organisations and assessors, so definitions vary across vendors when people treat the AOC as proof that risk has been eliminated. Guidance from NIST Cybersecurity Framework 2.0 and ISO/IEC 27001:2022 Information Security Management reinforces that assurance statements must be backed by ongoing operational discipline. The most common misapplication is treating an AOC as continuous evidence of compliance, which occurs when organisations stop validating access, secrets hygiene, and compensating controls after the document is issued.
Examples and Use Cases
Implementing AOC rigorously often introduces evidence-collection overhead, requiring organisations to weigh audit certainty against the cost of maintaining current control records and traceable ownership.
- A merchant completes a PCI DSS assessment and issues an AOC to show that cardholder-data controls were validated for the current operating environment.
- A SaaS provider uses the AOC during customer due diligence to demonstrate that compliance scope, including managed secrets and privileged service accounts, has been assessed.
- An internal risk team cross-checks the AOC against the Ultimate Guide to NHIs — Regulatory and Audit Perspectives to confirm that identity governance evidence is current and defensible.
- An assessor references NIST SP 800-53 Rev 5 Security and Privacy Controls to map validation evidence to access control, audit, and configuration management practices.
- A security program ties the AOC to the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs so that attestation reflects real lifecycle discipline for non-human identities.
Why It Matters in NHI Security
An AOC is important in NHI security because compromised service accounts, leaked API keys, and weak secret governance can undermine the assurance a compliance statement is meant to convey. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a strong reminder that attestation without operational identity control can create false confidence. In practice, the AOC is only as credible as the evidence behind it.
This is where governance, audit readiness, and technical hygiene intersect. If secrets are stored outside controlled vaults, rotated inconsistently, or left with excessive privilege, the organisation may still sign an attestation while carrying unresolved exposure. That gap is especially visible when external trust depends on the document, including partner onboarding, card data flows, and third-party risk reviews. The Top 10 NHI Issues is a useful reminder that the operational failures behind compliance gaps are usually recurring, not isolated.
Organisations typically encounter the limits of an AOC only after an incident, failed audit, or customer challenge, at which point the attestation becomes operationally unavoidable to validate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | AOC is the formal compliance statement used in PCI DSS validation. | |
| NIST CSF 2.0 | GV.RM, ID.IM | Attestation depends on governance, risk, and continuous improvement practices. |
| NIST SP 800-63 | IAL, AAL | Identity assurance concepts inform how strong validation evidence should be. |
| OWASP Non-Human Identity Top 10 | NHI-01 | NHI governance failures often invalidate the operational truth behind attestations. |
| NIST Zero Trust (SP 800-207) | PA, PDP/PEP | Zero trust requires continuous verification beyond static compliance statements. |
Use assurance concepts to verify that identities and authenticators match the claimed environment.
