Documented AI safety incidents rose 56% in a single year, from 149 in 2023 to 233 in 2024, according to the Stanford AI Index 2025. For US organisations deploying AI in regulated environments, that trajectory has a direct compliance implication: governance frameworks built on informal policies and spreadsheets are no longer adequate, and regulators, board members, and enterprise customers increasingly know it.
ISO/IEC 42001:2023 provides the structure that fills this gap. Published in December 2023 as the world’s first certifiable AI management system (AIMS) standard, it specifies exactly what an organisation must establish, document, and maintain to govern AI responsibly. Understanding what the standard requires is useful. Knowing which specific action each requirement maps to is what actually gets teams to certification.
This guide maps every major ISO 42001 clause and Annex A control domain to the concrete steps your GRC team, AI governance function, or C-suite sponsor needs to take. By the end, you will know what to build, in what order, and why each piece matters to an auditor.
What ISO 42001 Actually Requires: The Clause-by-Clause Map
ISO 42001 is structured around 10 clauses. Clauses 1 through 3 cover scope, definitions, and normative references. Clauses 4 through 10 contain the actual requirements that auditors assess. The standard also includes Annex A, a normative catalogue of 39 AI-specific controls that organisations select and implement based on their risk profile.
The clause-level requirements can be grouped into four functional areas:
| Functional Area | Clauses | What It Governs |
|---|---|---|
| Organisational Context | Clause 4 | Stakeholders, scope, AI policy context |
| Leadership & Governance | Clause 5 | Top management roles, AI policy, responsibilities |
| Planning | Clause 6 | Risk assessment, AI objectives, Statement of Applicability |
| Support & Resources | Clause 7 | Competence, awareness, documentation, communication |
| Operations | Clause 8 | AI lifecycle controls, risk treatment, impact assessment |
| Performance & Audit | Clause 9 | Monitoring, internal audit, management review |
| Continual Improvement | Clause 10 | Nonconformity handling, corrective action, PDCA cycle |
Each of these is not just a documentation exercise. Auditors assess whether your policies describe what the organisation actually does. That distinction matters: a Clause 5 AI policy that reads as a board aspiration but has no operational mechanism behind it will draw a nonconformity, regardless of how well it is written.
Clause 4: Understanding Your Context
Clause 4 requires you to determine the external and internal factors relevant to your AI activities, identify interested parties (regulators, customers, employees, affected communities), and define the scope of your AIMS. In practice this means four deliverables:
- A context analysis document identifying regulatory obligations (federal AI executive orders, sector-specific rules, state AI laws) and business drivers for AI governance
- A documented list of interested parties and their requirements, including data subjects, procurement counterparties, and oversight bodies
- A formal AIMS scope statement defining which AI systems, business units, and geographies fall within the management system
- An understanding of how the AIMS integrates with existing management systems such as ISO 27001 or SOC 2
Organisations already operating under ISO 27001 can map their existing context documentation to Clause 4, which significantly reduces the drafting burden. The AI-specific additions centre on AI system use cases, intended uses, and the populations affected by automated decisions.
Clause 5: Leadership and AI Policy
Clause 5 is where AI governance moves from concept to accountability. It requires top management to demonstrate commitment to the AIMS, assign roles and responsibilities, and establish an organisational AI policy.
The AI policy is the most visible Clause 5 output. It must commit the organisation to the requirements of ISO 42001, set the framework for AI objectives, and be communicated to relevant parties. What auditors look for is not length or language, but whether the policy is operationally connected: does it name a responsible person, does it link to risk assessment processes, does it describe how AI activities are governed at the system level?
AI governance responsibility typically sits across three functions: a senior accountable owner (often the CISO, CDO, or a dedicated Chief AI Officer), a cross-functional governance committee, and embedded controls owners within AI development and deployment teams. Clause 5 requires all three levels to have documented roles.
Clause 6: Planning and Risk Assessment
Clause 6 is the technical core of the standard. Clause 6.1 requires a formal AI risk assessment that identifies risks associated with each AI system in scope, evaluates their likelihood and impact, and selects risk treatment options. Clause 6.1.3 specifically requires the organisation to compare its selected controls against Annex A to confirm no necessary control has been omitted. This comparison feeds the Statement of Applicability (SoA), which documents which of the 39 Annex A controls are applicable, how they are implemented, and why excluded controls are not relevant to the organisation’s AI activities.
Clause 6.2 requires the organisation to establish measurable AI objectives aligned to the AI policy, with defined owners, timelines, and mechanisms for tracking progress.
| Auditor focus areaClause 6.1.3 and the Statement of Applicability are among the most scrutinised documents in an ISO 42001 audit. An SoA that simply lists controls as ‘applicable’ without explaining how they are implemented or justifying exclusions will generate a nonconformity. Each entry needs a brief implementation note and, for excluded controls, a risk-based rationale. |
Clauses 7, 8, 9, and 10: From Policy to Operations
Clause 7 addresses the resources and infrastructure needed to run the AIMS: people with documented AI competence, awareness training for all relevant staff, controlled documentation, and defined communication channels for AI governance matters.
Clause 8 covers operations. This is where AI system lifecycle management lives: the processes for designing, developing, testing, deploying, monitoring, and decommissioning AI systems. Clause 8.4 requires an AI system impact assessment for systems that affect individuals or groups, addressing societal and ethical impacts alongside technical risk. Clause 8.5 requires a formal AI risk treatment plan.
Clause 9 covers performance evaluation: monitoring and measurement of AIMS effectiveness, periodic internal audits, and formal management reviews. Clause 10 closes the PDCA cycle with nonconformity management and corrective action processes.
Annex A Controls: 39 Requirements, Nine Domains
The 39 Annex A controls are organised across nine domains, labelled A.2 through A.10. These are normative requirements: during Clause 6.1.3 planning, the organisation must review each control, determine applicability, and document the reasoning in the SoA. Controls that are applicable but not yet implemented will generate audit findings.
| Domain | Control Ref. | Primary Focus | Key Actions Required |
|---|---|---|---|
| AI Policies | A.2 | Governance foundation | Document AI policy; align with data, security, ethics policies |
| Internal Organisation | A.3 | Roles and accountability | Establish AI governance committee; define responsible roles |
| Resources for AI | A.4 | Competence and infrastructure | Inventory AI tools and infrastructure; document human oversight mechanisms |
| AI System Impact | A.5 | Impact assessment | Conduct AI system impact assessments; document societal and individual effects |
| AI System Lifecycle | A.6 | Development and operations | Define responsible design, development, testing, and monitoring processes |
| Data for AI | A.6 / A.7 | Data governance | Document training data provenance, quality controls, and data bias assessments |
| System Information | A.7 | Transparency and documentation | Maintain AI system documentation accessible to stakeholders and auditors |
| Use of AI Systems | A.8 | Operational controls | Define permitted uses, human oversight requirements, and misuse prevention |
| Third-Party AI | A.9 / A.10 | Supply chain and relationships | Assess AI vendors; include AI governance obligations in contracts |
The AI System Lifecycle Controls (A.6) in Practice
Domain A.6 is the most operationally complex section for most organisations. It requires documented processes across the full AI system lifecycle: from responsible design objectives through development, testing, deployment, and ongoing monitoring. A.6.1.2 requires documented responsible AI objectives for each system in development. A.6.1.3 requires defined processes for responsible design and development.
What this looks like in practice: each AI system in scope should have a system card or model card that documents its intended use, training data summary, evaluation methodology, known limitations, and the controls applied at each lifecycle stage. This document becomes the primary evidence artefact for Annex A controls during certification and ongoing surveillance audits.
Teams that begin building system-level documentation after initiating an ISO 42001 programme typically find this is the most time-consuming part of the process. Organisations with existing MLOps documentation have a significant head start, but most need to add governance layers: bias assessment records, human oversight configurations, and post-deployment monitoring reports.
Third-Party and Supply Chain Controls (A.9/A.10)
A third-party AI control requirement that catches many organisations off guard: ISO 42001 extends governance obligations to external AI providers. If your organisation uses a third-party AI model or platform within an in-scope AI system, you need documented evidence that the provider meets appropriate standards, and your contracts need to include AI governance obligations.
This does not mean every AI vendor must be ISO 42001 certified. It means your organisation has assessed their governance posture, documented the result, and included contractual requirements proportionate to the risk. For high-risk AI systems with external model components, this may require a supplier questionnaire, a review of the vendor’s AI governance documentation, and contractual provisions covering incident notification and model change management.
The 19 Mandatory Documents: What You Must Produce
ISO 42001 requires 19 mandatory documents: 14 at the clause level and up to 5 additional documents from Annex A controls, depending on the scope and risk profile of the organisation’s AI activities. Missing any of the 14 clause-level documents will generate a major nonconformity.
The standard specifies no mandatory format. Documents may be structured text, spreadsheets, databases, or workflow tool records, provided they meet the content requirements, are appropriately identified and version-controlled, and are accessible to those who need them during an audit.
| Document | Clause / Annex | Purpose |
|---|---|---|
| AIMS Scope Statement | Clause 4.3 | Defines what is covered by the management system |
| AI Policy | Clause 5.2 | Top-level organisational commitment and framework |
| AI Risk Assessment Report | Clause 6.1.2 | Documents identified risks, evaluation criteria, and results |
| Statement of Applicability (SoA) | Clause 6.1.3 | Maps selected and excluded Annex A controls with justifications |
| AI Risk Treatment Plan | Clause 6.1.4 | Specifies how identified risks are treated |
| AI Objectives and Plans | Clause 6.2 | Measurable objectives with owners and timelines |
| Competence Records | Clause 7.2 | Evidence of staff qualifications relevant to AI governance |
| Documented Information Procedure | Clause 7.5 | Governs how AIMS documentation is controlled and managed |
| Operational Planning Evidence | Clause 8.1 | Records of processes for controlling AI operations |
| AI System Impact Assessment | Clause 8.4 | Assesses impacts of AI systems on individuals and groups |
| Internal Audit Programme and Results | Clause 9.2 | Planned audits and their findings |
| Management Review Records | Clause 9.3 | Evidence of senior leadership review of AIMS performance |
| Nonconformity and Corrective Action Log | Clause 10.1 | Tracks issues and corrective actions |
| Continual Improvement Records | Clause 10.2 | Documents improvements to the AIMS |
| AI System Documentation (Annex A) | A.7 controls | Technical documentation for each AI system in scope |
The Statement of Applicability deserves particular attention. It is the document that connects the clause-level risk assessment to the Annex A controls framework. Auditors frequently start their review here because it reveals whether the organisation has understood the standard or simply ticked boxes. An SoA with vague implementation descriptions and no exclusion rationale signals a surface-level implementation.
Implementation Roadmap: Six Phases from Gap to Certification
Most enterprise implementations follow a six-phase sequence. The timeline varies significantly based on how much existing governance infrastructure the organisation can leverage. Organisations already operating under ISO 27001 or NIST CSF typically move faster through Phases 1 and 2, since context, risk methodology, and documentation infrastructure are already in place.
- Scope and context definition (Clause 4) Identify which AI systems are in scope, map relevant regulations and stakeholder requirements, and document the AIMS boundary.
- Gap analysis against clauses 4-10 and Annex A Conduct a clause-by-clause assessment of existing governance controls. Map existing ISO 27001 or NIST AI RMF processes to ISO 42001 requirements to identify what already satisfies requirements and what is missing.
- Policy and governance framework (Clause 5 and A.2/A.3) Draft the AI policy, establish the AI governance committee, assign accountable roles, and define escalation paths.
- Risk assessment and SoA (Clause 6) Conduct AI risk assessments for each in-scope system, select risk treatment options, and produce the Statement of Applicability. This phase generates the AI risk register.
- Control implementation (Clauses 7, 8 and Annex A) Build the operational infrastructure: AI system documentation, lifecycle controls, competence records, data governance processes, and third-party assessment mechanisms.
- Internal audit, management review, and certification Conduct a full internal audit against the standard, address nonconformities, complete a formal management review, and engage an accredited certification body for Stage 1 (document review) and Stage 2 (on-site audit) assessment.
| Integration advantageOrganisations already operating under ISO 27001 can leverage a significant portion of their existing documentation, risk methodology, and internal audit infrastructure. ISO 42001’s clause structure deliberately mirrors ISO 27001, ISO 9001, and other ISO management system standards to reduce implementation friction for multi-framework environments. Mapping existing controls before starting builds a realistic picture of the gap and avoids duplicating effort. |
How ISO 42001 Maps to the EU AI Act and NIST AI RMF
One of the practical advantages of building an ISO 42001-compliant AIMS is that it creates substantial overlap with the two other major AI governance frameworks US enterprises are navigating: the EU AI Act and the NIST AI Risk Management Framework. Understanding where the frameworks align reduces implementation effort and avoids building parallel governance structures for each.
ISO 42001 and the EU AI Act
The EU AI Act, which entered into force in August 2024, imposes risk-based obligations on AI providers and deployers. High-risk AI systems, defined across sectors including employment, credit, education, and critical infrastructure, require conformity assessments, technical documentation, human oversight mechanisms, and incident reporting. For US organisations selling AI-enabled products or services into EU markets, these obligations apply regardless of where the organisation is headquartered.
ISO 42001 addresses the operational infrastructure behind most EU AI Act Article 9 risk management requirements. The standard’s Clause 6.1 risk assessment methodology, Annex A.5 impact assessment controls, and Annex A.6 lifecycle controls collectively cover the technical documentation, risk management system, and quality management requirements the Act imposes on high-risk AI providers. Organisations that achieve ISO 42001 certification do not automatically satisfy the EU AI Act, but they have built the governance infrastructure on which Act compliance can be demonstrated more efficiently.
ISO 42001 and NIST AI RMF
The NIST AI Risk Management Framework, published in January 2023, organises AI governance around four core functions: Govern, Map, Measure, and Manage. These map naturally onto ISO 42001’s clause structure. The NIST Govern function covers organisational culture, policies, and accountability structures, corresponding closely to ISO 42001 Clauses 4, 5, and the A.2 and A.3 control domains. The NIST Map function, which involves contextualising AI risks within the organisation’s operations, maps to Clause 4 context analysis and Clause 6.1 risk identification. NIST Measure and Manage functions align with ISO 42001’s Clause 8 operational controls and Clause 9 performance monitoring requirements.
For US organisations, the NIST AI RMF is the more familiar framework, having been widely adopted since its release and referenced in federal procurement requirements. Building from NIST AI RMF documentation and extending it to meet ISO 42001’s clause and Annex A requirements is a practical path to certification for organisations that have already invested in NIST alignment.
| Governance Area | ISO 42001 Clause/Control | EU AI Act Alignment | NIST AI RMF Alignment |
|---|---|---|---|
| Risk assessment | Clause 6.1, A.5 | Article 9 risk management | Map + Measure functions |
| AI policy and governance | Clause 5, A.2, A.3 | Article 9(2) quality management | Govern function |
| Technical documentation | Clause 7.5, A.7 | Article 11 technical docs | Govern + Map functions |
| Human oversight | Clause 8, A.8 | Article 14 human oversight | Manage function |
| Incident reporting | Clause 10.1 | Article 73 incident reporting | Manage function |
| Lifecycle controls | A.6 | Articles 9, 17 quality management | Map + Manage functions |
| Third-party assessment | A.9, A.10 | Article 25 deployer obligations | Govern + Manage functions |
The AI Model Registry: Your AIMS Central Nervous System
Most governance failures in AI are not failures of policy. They are failures of inventory. Organisations cannot govern AI systems they do not know they have, and in enterprise environments with active model deployments across business units, the list of in-scope AI systems grows faster than governance teams can track it.
A structured AI model registry is the practical solution. It functions as the living inventory of every AI system within the AIMS scope, and it directly satisfies several ISO 42001 requirements at once: the Clause 4 scope documentation, the Clause 6.1 risk assessment basis, the Annex A.5 impact assessment trigger, and the Annex A.7 system information requirements all depend on having an accurate, maintained inventory of AI systems.
An effective AI model registry captures, at minimum, the following for each system:
- System identifier and descriptive name
- Intended use and business function
- Development or procurement status (in-house, third-party, open-source)
- Deployment environment and geographic scope
- Data inputs and training data summary
- Risk classification and impact assessment results
- Applicable Annex A controls and their implementation status
- Human oversight configuration and escalation path
- Responsible owner and review schedule
Govern365.ai’s AI model registry automates this inventory layer, mapping each registered system to its applicable ISO 42001 clauses and Annex A controls. For GRC teams managing multiple in-scope systems, this replaces a fragmented spreadsheet environment with a version-controlled, audit-ready record that updates as systems change.
What Most Implementation Guides Leave Out: Audit Evidence Strategy
An ISO 42001 audit is an evidence-gathering exercise. The auditor’s job is to determine whether your AIMS actually functions as documented. That means the difference between passing your Stage 2 audit and receiving a nonconformity is almost always a question of evidence quality, not policy quality.
Most implementation guides focus on what documents to produce. Fewer address how to structure those documents so that evidence retrieval during an audit is efficient and complete. Three practices consistently separate organisations that pass their first certification audit from those that require additional corrective action:
1. Map Evidence to Clause Requirements Before the Audit
For each clause and Annex A control that applies to your organisation, document in advance: what evidence exists, where it is stored, and who is responsible for retrieving it. This is not an audit-week activity. It should be maintained as a living document and tested during the internal audit process. When an auditor requests evidence for Clause 8.4 impact assessments, the answer should be immediate, not a three-day search through shared drives.
2. Use the Internal Audit as a Full Evidence Rehearsal
The Clause 9.2 internal audit requirement is often treated as a formality. It should be treated as a dress rehearsal. Run it against the same evidence structure you expect the external auditor to use, and identify gaps while you still have time to close them. Internal audits conducted two to three months before the Stage 2 assessment allow time for corrective action without jeopardising the certification timeline.
3. Version-Control Everything
ISO 42001’s Clause 7.5 documentation control requirements mean that every mandatory document must be version-controlled, with approval records and change history. Auditors verify not just that documents exist but that they are current, approved, and properly maintained. A risk assessment that was completed nine months ago and has not been reviewed since a material change to an in-scope AI system will raise questions about whether the AIMS is actually operating as described.
Common Nonconformities and How to Avoid Them
Across ISO 42001 certification audits, a consistent set of gaps appears across organisations that begin implementation without a structured approach. Understanding the most common nonconformity categories before starting implementation is the most efficient form of risk treatment.
| Nonconformity Type | Typical Cause | Prevention |
|---|---|---|
| Incomplete Statement of Applicability | Controls listed without implementation descriptions or exclusion rationale | Use a structured SoA template with mandatory fields for each control; review in internal audit |
| Risk assessment not linked to AI systems | Generic risk assessment disconnected from actual systems in scope | Conduct risk assessment at the system level, using AI model registry as the basis |
| AI policy lacks operational connection | Policy exists but has no mechanism linking it to governance processes | Include specific references to risk assessment, roles, and review cycles in the policy itself |
| Third-party AI controls absent | Organisations focus only on in-house AI; external models not assessed | Include all third-party AI components in scope definition; add supplier questionnaire process |
| Competence records incomplete | Training completed but not formally documented | Maintain a competence matrix linking roles to required skills with evidence of completion |
| Impact assessments missing for high-risk systems | A.5 controls understood but not operationalised | Trigger impact assessment at system registration; make it a required step before deployment |
Frequently Asked Questions
How long does ISO 42001 implementation typically take?
Timeline depends on your starting point. Organisations with mature ISO 27001 or NIST frameworks in place can typically complete gap analysis, policy work, and control implementation in four to six months. Organisations starting from a lower baseline typically require eight to fourteen months before a Stage 1 audit. The largest variables are AI system inventory complexity and the maturity of existing documentation controls.
Does ISO 42001 certification replace EU AI Act compliance?
No. ISO 42001 certification demonstrates that your organisation operates a functioning AI management system, but it does not satisfy specific EU AI Act legal obligations. What it does is build the governance infrastructure, technical documentation, and risk management processes that EU AI Act compliance requires. For US organisations with EU market exposure, ISO 42001 and EU AI Act obligations are complementary, not substitutable.
How does ISO 42001 relate to ISO 27001 for information security?
ISO 42001 is designed to be implemented alongside ISO 27001, not instead of it. Both standards share the same high-level structure (Annex SL), which means clause numbering, document requirements, and management system concepts are directly compatible. An organisation already certified to ISO 27001 can extend its management system to cover ISO 42001 requirements with significantly reduced duplication. The AI policy and AIMS scope become additions to, not replacements for, the existing ISMS framework.
What is a Statement of Applicability and why does it matter so much?
The Statement of Applicability is the document that maps your organisation’s risk assessment results to the Annex A controls framework. It lists all 39 controls, states which are applicable to your AI activities, describes how each applicable control is implemented, and justifies why any excluded controls are not relevant. Auditors use it as a navigation document for the Stage 2 assessment. An incomplete SoA signals a surface-level implementation and frequently generates nonconformities.
Can we use ISO 42001 to cover AI systems from third-party vendors?
Yes, but with important caveats. Your AIMS covers how your organisation governs its use of AI systems, including third-party ones. Annex A.9 and A.10 controls require you to assess your AI vendors’ governance posture and include AI governance obligations in contracts. You cannot certify a vendor’s practices under your AIMS, but you must demonstrate that your organisation has assessed and managed the AI governance risk those systems introduce.
How does Govern365.ai support ISO 42001 implementation?
Govern365.ai provides the platform infrastructure behind an ISO 42001-aligned AIMS. The AI model registry maintains the system inventory that drives risk assessment and control mapping. The compliance dashboard tracks SoA completion, document version status, and audit evidence across all in-scope systems. Audit evidence management organises artefacts by clause and Annex A control, so retrieval during a certification audit is immediate rather than manual. Govern365.ai is built by the Global AI Certification Council, which means the framework logic embedded in the platform reflects how auditors actually assess conformance.
Conclusion
ISO 42001 is not a compliance checkbox. It is the operational architecture that makes AI governance repeatable, auditable, and continuously improving. Every clause requirement and Annex A control maps to a specific governance function that protects the organisation from AI-related risk, demonstrates responsible AI to regulators and customers, and creates the documentation infrastructure that supports multi-framework compliance.
The practical starting point is always the same: define your scope, inventory your AI systems, and run a clause-by-clause gap analysis. Everything else, from risk assessment to SoA to certification, builds from that foundation. Organisations that build the governance infrastructure properly the first time avoid the rework cycles that most certification programmes require.Start your 14-day free trial of Govern365.ai, by the Global AI Certification Council, and build your ISO 42001-aligned AI management system on the platform built by the people who defined the standard.
