Why Evidence Management Is the Real Audit Challenge
ISO/IEC 42001 certification is often approached as a policy-writing exercise: draft an AI risk management policy, document a data governance procedure, write an AI system lifecycle process, and assemble a management manual. This gets an organization through much of Stage 1. It does not get an organization through Stage 2.
ISO/IEC 42001 follows the same Annex SL high-level structure used across ISO management system standards, with clauses covering context of the organization, leadership, planning, support, operation, performance evaluation, and improvement. Certification audits under this structure follow the standard two-stage model: Stage 1 assesses whether the management system is documented and ready for assessment, and Stage 2 evaluates whether that system is operating effectively in practice.
The distinction matters because the evidence required at each stage is fundamentally different. Stage 1 auditors are largely reviewing whether required documents exist and whether the AIMS scope, risk assessments, and policies are complete and internally consistent. Stage 2 auditors are looking for proof that those documented controls are actually being enforced, monitored, and acted upon in an operating AI environment. An organization that treats Stage 2 preparation the same way it treated Stage 1, by producing more documents, will struggle to satisfy auditors who are now asking for logs, records, and traceable operational history.
What Stage 1 Auditors Typically Review
Stage 1 review centers on documentation completeness and internal coherence rather than operational proof. Auditors examine whether the AIMS scope statement correctly identifies which AI systems, business units, and processes are in scope. They review whether risk assessments have been conducted and whether a risk treatment plan exists that maps identified risks to specific mitigating controls. They check whether Annex A controls that apply to the organization's context have been addressed, either through implementation or documented justification for exclusion.
Because ISO/IEC 42001 requires organizations to maintain documented information as evidence of conformity, Stage 1 also involves confirming that this documented information exists in a retrievable, version-controlled form. Gaps found at Stage 1 are typically documentation gaps: a missing risk treatment plan, an incomplete Annex A applicability statement, or a scope definition that does not clearly account for third-party AI components.
What Stage 2 Auditors Typically Request
Stage 2 is where operational evidence becomes the primary currency. Auditors sample specific Annex A controls and ask for records showing the control functioning over a period of time, not just a policy describing how it should function. This is a meaningful shift for teams that spent most of their preparation time on documentation.
For Annex A areas addressing AI system lifecycle management, auditors look for records covering design, development, verification, deployment, operation, and monitoring activities, since the standard requires documented processes across the full lifecycle rather than at a single checkpoint. For risk assessment and treatment, auditors expect to see evidence of a recurring cycle, such as periodic reassessments and corrective action records, rather than a single point-in-time risk assessment produced ahead of the audit. For data governance controls, auditors look for traceability linking data quality and provenance claims to actual system records, which is difficult to demonstrate convincingly through narrative documentation alone.
Governance evidence is also tested directly. Because the standard requires top management involvement and accountability, auditors will ask for management review meeting records and decisions, not only technical logs.
Where Operational AI Records Fit Into the Evidence Set
ISO/IEC 42001 does not prescribe specific technical logging formats. It leaves the definition of adequate operational evidence to the organization, which creates both flexibility and risk. Annex A controls tied to AI system operation and monitoring imply a need for records demonstrating ongoing enforcement, such as access controls and monitoring logs, rather than documentation asserting that enforcement occurs.
For AI systems that include autonomous agents or tool-calling architectures, this gap is more pronounced. The standard is technology-agnostic and does not include dedicated provisions for agentic AI, which means evidence requirements for these systems must be interpreted using existing clause language rather than purpose-built guidance. In practice, this means an organization operating AI agents needs to determine, on its own, what constitutes sufficient evidence of controlled access, permission enforcement, and monitored tool use for those Annex A controls to be satisfied.
This is where runtime governance records become directly relevant as audit evidence rather than as a separate security concern. Records of agent identity, agent permissions enforced at runtime, tool approval decisions, and policy enforcement actions provide the kind of system-generated, time-stamped evidence that Stage 2 auditors are looking for under lifecycle management and operational monitoring controls. Audit logging that captures what an agent was permitted to do, what it attempted, and what was enforced or blocked gives an organization a traceable record that maps directly to Annex A expectations for ongoing control operation, rather than a static description of intended controls.
Practical distinction
Policy documents answer "what should happen." Operational records answer "what did happen." Stage 2 audits are built around the second question.
Distinguishing Static Documentation From Dynamic Records
Internal audits conducted before certification should explicitly test for both categories of evidence, since auditors assess them differently. Static documentation, such as policies and procedures, is evaluated for completeness and consistency. Dynamic operational records, such as monitoring logs, incident records, and access records, are evaluated for continuity and whether they demonstrate the control actually operating over time.
A practical way to prepare is to walk through each applicable Annex A control and ask two separate questions: does a policy document exist for this control, and does an operational record exist showing this control being enforced during normal system operation. Version control and change-management records for AI systems should also be retained, since they support evidence of controlled lifecycle management rather than ad hoc changes. Organizations that only answer the first question going into Stage 2 typically find themselves generating operational records under time pressure rather than presenting an existing evidence trail.
Certification Body Considerations
Because ISO/IEC 42001 certification programs are still maturing, accreditation processes for certification bodies are being established rather than fully settled. Organizations should confirm that a prospective certification body holds accreditation specifically for ISO/IEC 42001, rather than relying on accreditation for a related standard such as ISO/IEC 27001. This is a governance decision as much as a procurement one, since certification issued by a body without confirmed ISO/IEC 42001 accreditation may carry less weight for regulatory or contractual purposes.