Documented AI safety incidents rose 56% year on year in 2024—from 149 to 233 reported cases, according to the Stanford AI Index 2025. For compliance teams, that number is less a data point than a signal: regulators, procurement departments, and boards are all asking the same question at the same time can you prove your AI systems are governed?
ISO/IEC 42001:2023 is the answer the market has converged on. Published in December 2023, it is the first certifiable international standard for AI management systems (AIMS), and its Annex A is where governance commitments become operational controls. This walkthrough covers every Annex A control group—what the standard requires, what auditors examine, and where most US organisations fall short before they walk into a Stage 2 audit.
What Annex A Is and What It Isn’t
Annex A of ISO/IEC 42001 contains 38 controls organised into nine control objectives, running from A.2 (AI policy) through A.10 (third-party and supplier relationships). Think of the main clauses (4 through 10) as the operating system of your AIMS—they define what the management system must do. Annex A is the feature set you run day to day.
That distinction matters because Annex A controls are informative reference controls, not a mandatory checklist. Clause 6.1.3 of the standard is explicit: the organisation selects controls based on its AI risk assessment, documents those selections in a Statement of Applicability (SoA), and provides written justification for any exclusions. An auditor who finds a control excluded without documented justification will raise a nonconformity not because the control was excluded, but because the reasoning was absent.
This also means the nine control domains are not equally weighted across organisations. A company that develops foundation models faces materially different Annex A obligations than one that deploys a procurement-automation tool licensed from a third party. The SoA is where that difference gets made explicit.
ISO 42001 Annex A: Control Objectives at a Glance
| Control Objective | Domain | No. of Controls |
|---|---|---|
| A.2 | AI Policy | 3 |
| A.3 | Internal Organisation | 2 |
| A.4 | Resources for AI Systems | 2 |
| A.5 | AI System Impact Assessment | 3 |
| A.6 | AI System Life Cycle | 10 |
| A.7 | Data for AI Systems | 5 |
| A.8 | Information for Interested Parties | 4 |
| A.9 | Use of AI Systems | 5 |
| A.10 | Third-Party and Supplier Relationships | 4 |
A.2 – A.4: Policy, Organisation, and Resources
Start with the foundations. These three control objectives AI policy (A.2), internal organisation (A.3) and resources (A.4) are where most certification programmes either establish credibility or expose structural gaps.
A.2: AI Policy (3 controls)
The standard requires a documented AI policy endorsed by top management, aligned with the organisation’s objectives and ethical commitments (A.2.2), consistent with other organisational policies such as the information security policy (A.2.3), and subject to periodic review (A.2.4). That last control catches more organisations than expected: a policy signed in 2024 that has not been formally reviewed is technically a gap against A.2.4, even if the content remains accurate.
Auditors look for evidence of the review meeting minutes, a version-controlled document with revision history, or a formal policy governance schedule. A policy that exists as a PDF with no version control and no review date is almost always flagged.
A.3: Internal Organisation (2 controls)
A.3 requires clear definition and assignment of roles and responsibilities for AI governance (A.3.2), and designation of accountability for AI system oversight (A.3.3). In practice, this means the organisation must be able to show who owns each AI system from a governance perspective not the product manager or the engineer, but the accountable governance role.
The most common finding here: organisations have built AI governance committees without mapping individual accountability to specific systems. Collective accountability is functionally no accountability. Auditors will ask, for each AI system in scope, “Who is responsible for this system’s governance, and how do you know?”
A.4: Resources for AI Systems (2 controls)
A.4 covers identification and documentation of the resources required to develop, deploy, and maintain AI systems including data, tooling, computing infrastructure, and human expertise (A.4.2), plus a specific control on ensuring appropriate competency and training (A.4.3). The competency control is harder than it looks. Demonstrating that staff responsible for AI system oversight understand what they are overseeing requires more than a training completion certificate. Auditors want to see evidence of competency assessment, not just attendance.
A.5: AI System Impact Assessment
Of all the control objectives in Annex A, A.5 is the one that generates the most confusion during first-time implementations. That confusion usually comes from conflating the AI system impact assessment with the AI risk assessment required under Clauses 6.1 and 8.2. They are related but distinct processes.
The AI risk assessment (Clause 6.1) analyses risks to the organisation and its stakeholders from AI failures, bias, misuse, or system misbehaviour. The AI system impact assessment (A.5, Clause 8.4) goes further it evaluates the potential consequences of deploying a specific AI system on individuals, groups, and society, including intended use, foreseeable misuse, and contextual effects that may not register as internal organisational risks.
A.5 contains three controls:
A.5.2: Establish and implement a process for conducting AI system impact assessments
A.5.3: Document the AI system impact assessment, including scope, methodology, findings, and actions taken
A.5.4: Use assessment results to inform system design decisions, deployment conditions, and ongoing monitoring requirements
The practical implication: you need documented impact assessments for each AI system in scope, updated when the system changes materially or when deployment context shifts. Auditors will test whether impact assessment findings actually influenced system design or deployment decisions not whether a document was produced.
One pattern that consistently separates organisations that pass their first audit from those that don’t: the impact assessment is treated as a one-time pre-deployment exercise rather than a living document. When an AI system’s use case expands or its user population changes, a new or updated impact assessment is warranted. Organisations that treat A.5 as a checkbox rather than a process invariably have this surfaced as a major nonconformity.
A.6: AI System Life Cycle: The Heart of Operational Governance
A.6 is the largest control objective in Annex A, with ten controls spanning the full AI system lifecycle from requirements definition through decommissioning. If Annex A has a centre of gravity, it is here.
The ten controls in A.6 cover:
1. A.6.2: Documenting AI system specifications and intended use before development or procurement begins
2. A.6.3: Establishing data requirements and quality criteria for training and validation datasets
3. A.6.4: Implementing processes for AI model development that address bias, fairness, and performance evaluation
4. A.6.5: Conducting verification and validation activities before deployment
5. A.6.6: Managing AI system deployment, including rollout controls and user communication
6. A.6.7: Establishing operational monitoring processes post-deployment
7. A.6.8: Managing changes to AI systems through a formal change control process
8. A.6.9: Establishing incident management processes specific to AI failures or unexpected outputs
9. A.6.10: Decommissioning AI systems in a controlled manner, including data handling
10. A.6.11: Maintaining appropriate documentation throughout the lifecycle
The controls that generate the most audit findings in practice are A.6.7 (operational monitoring) and A.6.8 (change control). On monitoring: organisations frequently deploy models and then rely on downstream business outcomes as the only signal of model drift or degradation. A.6.7 requires formal monitoring processes defined metrics, review cadences, alert thresholds, and documented responses to anomalies. On change control: AI systems are often updated retrained, fine-tuned, or reconfigured without the same change governance applied to other enterprise software. A.6.8 requires that AI system changes go through a documented assessment of whether the change affects the system’s risk profile, its impact assessment conclusions, or its compliance with Annex A controls.
The AI model registry is the practical mechanism most organisations use to satisfy several A.6 controls simultaneously. A registry that captures system specifications, training data provenance, performance benchmarks, deployment conditions, and change history provides auditors with a coherent evidence trail across the lifecycle. Govern365.ai’s AI model registry is designed precisely for this purpose mapping each registered system to its applicable Annex A controls and surfacing gaps in lifecycle documentation before an auditor does.
A.7: Data for AI Systems
Data governance is where AI compliance intersects most directly with information security and privacy obligations and where organisations that have already invested in ISO 27001 or ISO 27701 find the most reusable infrastructure.
A.7 contains five controls:
A.7.2: Establishing criteria for data suitability for use in AI system development and operation
A.7.3: Implementing processes for data acquisition, collection, and preparation that maintain quality and lineage
A.7.4: Ensuring data used for AI training and validation is representative and free from inappropriate bias
A.7.5: Documenting data provenance and maintaining records sufficient to reproduce or audit data decisions
A.7.6: Managing data throughout the AI system lifecycle, including data used for retraining
The controls in A.7 are deliberately principle-based rather than prescriptive. “Representative and free from inappropriate bias” (A.7.4) does not specify a statistical methodology the organisation must define and document its approach. This is intentional: appropriate bias detection methods vary significantly by application domain, data type, and risk profile. What the standard demands is that the approach exists, is documented, and is applied consistently.
Auditors ask three questions in A.7 reviews: Do you know where your training data came from? Can you demonstrate that it meets your own documented quality criteria? And when the model is retrained or updated, can you show the same quality controls were applied to the new data? Organisations that can answer all three with documented evidence are rarely tripped up by A.7.
The one area where US organisations frequently underestimate the control requirement: data lineage. Many teams know what datasets they used but have not documented the chain of custody, transformation steps, or quality validation applied at each stage. That documentation gap is straightforward to close before certification and much harder to reconstruct during an audit.
A.8: Information for Interested Parties: Transparency Controls
A.8 covers what the organisation communicates about its AI systems to users, affected individuals, and other stakeholders. It is the transparency chapter of Annex A, and it directly maps to the explainability and disclosure requirements emerging in US federal AI guidance, the EU AI Act’s Article 13 transparency obligations, and NIST AI RMF’s GOVERN and MANAGE functions.
The four controls in A.8 are:
A.8.2: Providing users and affected parties with appropriate information about AI system capabilities, limitations, and intended use
A.8.3: Communicating how AI systems make or support decisions, to the extent technically feasible and appropriate to the context
A.8.4: Ensuring that information provided to interested parties is accurate, complete, and not misleading
A.8.5: Maintaining records of what information was communicated, to whom, and when
The phrase “to the extent technically feasible” in A.8.3 acknowledges that full algorithmic transparency is not always possible particularly for large language models or ensemble systems where decision pathways are not fully interpretable. What the standard requires is a good-faith effort to communicate meaningfully about how systems function, not a complete technical disclosure that may be impractical or competitively sensitive.
For US organisations deploying AI in regulated contexts healthcare (where FDA AI/ML guidance applies), financial services (where CFPB and OCC have issued AI-related supervisory guidance), or federal contracting (where EO 13960 and its successors set AI disclosure expectations) A.8 controls provide a structured way to demonstrate compliance with disclosure obligations that exist independently of ISO 42001.
The practical implementation question is audience segmentation: the information appropriate for a technical user differs from what an individual affected by an AI decision needs. A.8.2 requires that communication be tailored to the audience. Organisations that publish a single technical whitepaper and call A.8 complete are regularly corrected by auditors.
A.9: Responsible Use of AI Systems
A.9 is where the ethical commitments embedded throughout Annex A become operational requirements. Its five controls address human oversight, accountability, and responsible deployment practices.
A.9.2: Implementing human oversight mechanisms appropriate to the AI system’s risk level and application context
A.9.3: Defining thresholds for AI system outputs that require human review before action is taken
A.9.4: Establishing accountability for AI-driven decisions, including clear escalation paths for disputed or erroneous outputs
A.9.5: Implementing controls to prevent misuse of AI systems
A.9.6: Monitoring AI systems for behaviours inconsistent with their intended use
A.9.2 and A.9.3 together represent what most organisations call their “human-in-the-loop” requirements. The standard does not mandate human review of every AI output that would make most AI deployments operationally unviable. What it requires is a documented, risk-calibrated determination of which outputs carry enough consequence to warrant human validation before acting on them.
In practice: an AI system recommending product content for a marketing email might operate autonomously. An AI system recommending treatment dosages, credit decisions or hiring outcomes should have defined human review thresholds with documented override authority and audit trails.
The control that receives the least attention during implementation but the most attention during audits is A.9.6 monitoring for behaviours inconsistent with intended use. This requires more than output monitoring. It requires that the organisation has defined what “intended use” means in operational terms, documented the boundaries, and established a process for detecting when the system is being used outside those boundaries either by users or by downstream integrations.
A.10: Third-Party and Supplier Relationships
For most US enterprises, a significant portion of AI risk lives in the supply chain. Third-party AI components, foundation model APIs, data providers, and AI-enabled SaaS platforms all introduce governance obligations that extend beyond the organisation’s own controls. A.10 is where that supply chain risk is addressed.
The four controls in A.10 cover:
A.10.2: Establishing requirements for AI-related products and services provided by third parties
A.10.3: Assessing third parties’ AI governance practices before procurement and at defined intervals
A.10.4: Ensuring contractual arrangements address AI-specific obligations including transparency, data use, and incident notification
A.10.5: Monitoring third-party AI systems and components for performance, drift, and governance conformance on an ongoing basis
The conceptual model underlying A.10 is similar to the shared responsibility model familiar from cloud security. When an organisation deploys an AI capability built on a third-party foundation model, governance responsibilities are distributed the provider is accountable for certain infrastructure and model-level controls, while the deploying organisation retains accountability for use-case definition, impact assessment, transparency to end users, and oversight of outputs.
A.10 requires that this distribution of responsibility is explicit and documented not assumed. Contracts with AI vendors should specify: what governance documentation the vendor provides; how incidents are reported and by whom; what the vendor’s obligations are around model updates that affect the organisation’s use case; and how the vendor’s AI governance practices are assessed over time.
This is where ISO 42001 certification by AI vendors becomes commercially relevant. An AI vendor that holds ISO 42001 certification can provide documented evidence of their AIMS controls to enterprise customers reducing the audit burden under A.10.3 and strengthening the contractual governance case under A.10.4. The growing procurement requirement for vendor ISO 42001 certification is not coincidental: it is a direct response to A.10’s supply chain governance obligations.
The Statement of Applicability: Where Annex A Becomes Your Governance Record
The Statement of Applicability (SoA) is defined in Clause 3.26 of ISO/IEC 42001 as the document that records all controls selected during risk treatment whether each is applicable, the justification for inclusion or exclusion, a brief description of implementation, references to relevant documented information, and the responsible party.
It is both a governance document and an audit artefact. Typically, it is the first document an auditor requests at Stage 1.
Building the SoA requires three inputs to be in place: a completed AI risk assessment covering all AI systems in scope, an AI system impact assessment for each system, and a review of each of the 38 Annex A controls against the identified risks. Controls that address identified risks are included. Controls that are not applicable to the organisation’s AI activities because the risk they address is not present may be excluded with documented justification.
A few practical points that matter for US organisations going through certification:
First, “not applicable” requires genuine reasoning, not convenience. An organisation that excludes A.6.9 (AI incident management) because it finds incident management burdensome will not survive audit scrutiny. Exclusions need to be risk-grounded.
Second, the SoA is a living document. When new AI systems are added to scope, when risk assessments are updated, or when the organisation’s AI activities change materially, the SoA should be reviewed and updated. Auditors check version history.
Third, organisations with existing ISO 27001 implementations can map existing controls risk management methodology, incident response processes, access controls, supplier management to their ISO 42001 SoA where they address overlapping risks. This disciplined reuse is one reason ISO 27001-certified organisations can achieve ISO 42001 compliance up to 40% faster than those starting without a management system foundation.
What Auditors Actually Examine: Common Nonconformities in US Certifications
Based on published certification body guidance and practitioner accounts from early ISO 42001 adopters, the following represent the most frequently cited gaps in US certification audits.
Lifecycle controls without operational evidence. Organisations document A.6 controls at policy level but cannot produce evidence that they were applied to specific systems. A model monitoring policy exists; records of monitoring outputs for individual systems do not.
Impact assessments treated as one-time events. A.5 assessments completed at deployment time but not revisited when system scope expands, user population changes, or new use cases emerge. The standard requires impact assessments to reflect the system’s current context, not its original deployment.
Role assignments without accountability trails. A.3 responsibility matrices exist but cannot be linked to specific decisions. When an auditor asks “who approved this AI system’s deployment and what was the governance review process?” the answer should be retrievable from documented records, not reconstructed from memory.
Data quality criteria defined but not applied. A.7 requires not just criteria for data suitability but evidence that those criteria were evaluated for the actual training data used. Defining standards without applying them systematically is a standard source of major nonconformities.
Third-party governance that lives in contracts but not operations. A.10.4 compliance is often achieved on paper through contract clauses. A.10.5 ongoing monitoring of third-party AI systems is where operational evidence is expected and frequently absent.
The pattern across these findings: the gap is between documented policy and operational practice. ISO 42001 is not a documentation audit. It is a management system audit. The standard expects to see evidence that controls are operating, not just evidence that they were designed.
Mapping Annex A to NIST AI RMF and EU AI Act
US organisations rarely operate in a single-framework environment. The NIST AI RMF (published in January 2023 and updated with the Generative AI Profile in 2024), the EU AI Act for organisations with EU operations or EU-facing AI systems, and sector-specific regulatory guidance all create compliance obligations that overlap with ISO 42001.
The good news: the overlap is substantial and purposeful.
The NIST AI RMF’s four core functions Govern, Map, Measure, Manage map closely to ISO 42001’s management system structure. GOVERN maps to Clauses 4–6 and A.2–A.3. MAP maps to A.5 (impact assessment) and A.6 (lifecycle). MEASURE maps to A.6.7 (monitoring) and A.7 (data quality). MANAGE maps to A.6.8–A.6.9 (change control and incident management) and A.9–A.10. Organisations that have implemented the NIST AI RMF find that ISO 42001 provides the auditable management system structure around existing RMF practices adding certification rigour without requiring a full rebuild.
For EU AI Act compliance, the intersection is even more direct. The Act’s requirements for high-risk AI systems risk management (Article 9), data governance (Article 10), transparency (Article 13), human oversight (Article 14), and accuracy and robustness (Article 15) map to Annex A control objectives A.5, A.7, A.8, A.9, and A.6 respectively. Organisations that implement Annex A controls comprehensively will find the EU AI Act’s high-risk requirements substantially addressed, though the Act’s specific technical documentation (Article 11) and conformity assessment obligations require additional work.
This multi-framework alignment is not accidental. ISO 42001 was designed to function as a governance layer that can accommodate jurisdiction-specific regulatory requirements without requiring separate compliance architectures. For US enterprises managing compliance across multiple jurisdictions, a single AIMS anchored in ISO 42001 with an SoA that maps controls to applicable regulatory requirements is significantly more efficient than parallel compliance programmes.
Framework Alignment: ISO 42001 Annex A vs. NIST AI RMF vs. EU AI Act
| Annex A Domain | NIST AI RMF Function | EU AI Act Article (High-Risk) |
|---|---|---|
| A.2 – A.3 (Policy & Organisation) | GOVERN | Art. 9 (Risk Management System) |
| A.5 (Impact Assessment) | MAP | Art. 9 (Risk Assessment) |
| A.6 (Lifecycle) | MAP / MANAGE | Art. 11 (Technical Documentation) |
| A.7 (Data) | MEASURE | Art. 10 (Data Governance) |
| A.8 (Transparency) | GOVERN | Art. 13 (Transparency) |
| A.9 (Responsible Use) | MANAGE | Art. 14 (Human Oversight) |
| A.10 (Third-Party) | GOVERN / MANAGE | Art. 9 (Supply Chain) |
Frequently Asked Questions
1. Are all 38 ISO 42001 Annex A controls mandatory?
No. Annex A controls are informative reference controls, not mandatory requirements. Clause 6.1.3 requires organisations to select controls based on their AI risk assessment and document selections in a Statement of Applicability. Controls that address risks not present in your AI activities may be excluded with documented justification. Auditors examine exclusions carefully; an exclusion without sound justification becomes a nonconformity.
2. How is the AI system impact assessment (A.5) different from the AI risk assessment?
The AI risk assessment (Clause 6.1) analyses organisational and stakeholder risks from AI system failures. The AI system impact assessment (A.5, Clause 8.4) evaluates the broader consequences of deployment on individuals, groups, and society including foreseeable misuse and societal effects. Both are required; both feed the SoA; and both need to be updated when the system or its deployment context changes materially.
3. Can we reuse our ISO 27001 controls for ISO 42001?
Yes, where they address overlapping risks. ISO 27001 controls covering risk management methodology, incident response, access control, and supplier management all have ISO 42001 equivalents. Documenting this reuse in your SoA is both permitted and efficient it is one reason ISO 27001-certified organisations typically implement ISO 42001 significantly faster than those starting without a management system foundation.
4. What does an ISO 42001 Stage 2 audit actually examine?
Stage 2 auditors test whether your AIMS is operating effectively, not just documented. They will request evidence that lifecycle controls (A.6) were applied to specific AI systems, that impact assessments (A.5) are current, that monitoring processes (A.6.7, A.9.6) produce records, and that role accountabilities (A.3) are traceable to decisions. Documented policies without operational evidence are the primary source of major nonconformities.
5. How often does the Statement of Applicability need to be updated?
The SoA is a living governance document. It should be reviewed whenever new AI systems are added to AIMS scope, when the risk assessment is updated, when AI activities change materially, or as part of the annual management review. Surveillance audits at 12-month intervals will check whether the SoA reflects the organisation’s current AI governance posture. Auditors examine version history.
6. Does ISO 42001 certification help with EU AI Act compliance?
Substantially, yes particularly for high-risk AI system requirements. The EU AI Act’s obligations on risk management (Article 9), data governance (Article 10), transparency (Article 13), and human oversight (Article 14) map directly to Annex A control objectives A.5, A.7, A.8, and A.9. ISO 42001 certification does not substitute for EU AI Act conformity assessment, but it significantly reduces the gap for organisations subject to both.
7. How long does it take to implement ISO 42001 Annex A controls?
Timelines vary significantly by organisation size and existing governance maturity. Most practical estimates range from six to twelve months for organisations starting without a management system foundation. Organisations with mature ISO 27001 programmes typically compress this to four to six months by reusing existing risk management infrastructure, documentation processes, and supplier governance practices.
Conclusion
ISO 42001’s Annex A is not a compliance hurdle it is a governance architecture. The 38 controls across nine domains, selected through risk assessment and documented in a Statement of Applicability, give organisations a structured way to demonstrate that AI governance is operational, auditable, and improving. The organisations that pass their first certification audit are not the ones that built the most documentation. They are the ones that embedded controls into real processes and built the evidence trails to prove it.
The practical next step: map your current AI systems against the nine Annex A control objectives and identify where operational evidence is thin. That gap analysis is the foundation of both your SoA and your audit readiness.
Start your 14-day free trial of Govern365.ai by the Global AI Certification Council and begin building your AIMS with Annex A controls, impact assessments, and audit evidence management in one platform.
