ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system, was published by ISO and IEC in December 2023. It runs to roughly 40 pages of normative text and annexes. The Standard is structured in two parts: the main body, which contains ten clauses, and four annexes that follow.
“This document specifies the requirements and provides guidance for establishing, implementing, maintaining and continually improving an AI management system within the context of an organization.” — ISO/IEC 42001:2023, Clause 1 (Scope)
The Standard follows the Annex SL high-level structure shared across ISO management system standards. This is the structural convention that gives ISO 27001, ISO 9001, ISO 14001, and ISO 42001 the same ten-clause shape. The convention is not cosmetic: it is the mechanism by which the Standard integrates with management systems an organisation already operates.
Normative versus informative
Two terms determine how each part of the ISO 42001 is read. The distinction is structural and affects what an auditor checks.
| Term | Meaning | What it imposes |
|---|---|---|
| Normative | Carries requirements. The organisation must conform. | Auditable obligations |
| Informative | Provides guidance, examples, or context. Conformity is not tested against it directly. | No direct obligations; informs interpretation |
The distinction matters because the same Standard contains both. Clauses 4 through 10 are normative — they impose requirements. Annex A is normative — its controls must be considered. Annexes B, C, and D are informative — they guide implementation without imposing requirements. Reading the Standard without keeping the distinction in mind produces either over-implementation (treating informative annexes as binding) or under-implementation (treating normative requirements as optional).
ISO/IEC 42001:2023 structure at a glance
| Section | Content | Status |
|---|---|---|
| Clause 1 | Scope | Descriptive |
| Clause 2 | Normative references | Descriptive (no references listed) |
| Clause 3 | Terms and definitions | Descriptive |
| Clauses 4–10 | Requirements for the AI Management System | Normative |
| Annex A | Reference controls and control objectives | Normative |
| Annex B | Implementation guidance for Annex A controls | Informative |
| Annex C | Potential AI-related organisational objectives and risk sources | Informative |
| Annex D | Use of the AIMS across domains and sectors | Informative |
| Bibliography | Related standards and references | Informative |
The opening ISO/IEC 42001:2023 clauses (1–3): vocabulary and boundary
The first three clauses are descriptive rather than normative. They impose no requirements but fix the vocabulary and boundary the rest of the Standard depends on.
| Clause | Title | What it does |
|---|---|---|
| 1 | Scope | Defines what the Standard governs (the AIMS) and to whom it applies (any organisation providing or using AI systems, regardless of size, type, or sector) |
| 2 | Normative references | Placeholder retained for Annex SL alignment; the Standard lists no normative references and is self-contained |
| 3 | Terms and definitions | Establishes the vocabulary, drawing many terms from ISO/IEC 22989 (AI concepts and terminology) |
Clauses 1 and 2 are short and rarely revisited. Clause 3 is short on the page but consequential: the definitions it fixes — “AI system,” “AI system lifecycle,” “intended use,” “foreseeable misuse” — govern how every subsequent requirement is interpreted. Terminology drift between the organisation’s internal vocabulary and Clause 3 is the single most common source of nonconformity in early implementations.
ISO/IEC 42001:2023 requirement clauses (4–10): the AI Management System
Clauses 4 through 10 are the normative core of the Standard. They follow the Plan-Do-Check-Act cycle that defines management system standards across the ISO family. Each clause depends on the ones before it; weaknesses cascade forward.
| Clause | Title | What it requires | What it produces |
|---|---|---|---|
| 4 | Context of the organisation | Define the context, interested parties, AIMS scope, and the AIMS itself | Role declaration, scope statement, interested parties register |
| 5 | Leadership | Demonstrate top-management commitment, establish the AI policy, assign roles and authorities | AI policy, leadership commitment evidence, role assignments |
| 6 | Planning | Address risks and opportunities, perform AI risk and impact assessment, set objectives, plan changes | Risk assessment, risk treatment plan, Statement of Applicability, impact assessment, AI objectives |
| 7 | Support | Provide resources, ensure competence and awareness, manage communication, control documented information | Competence framework, awareness programme, communications matrix, documented information control |
| 8 | Operation | Plan and control operational processes, perform recurring risk and impact assessments, implement controls | Lifecycle processes, operational risk and impact assessment records, Annex A control implementation |
| 9 | Performance evaluation | Monitor, measure, analyse, evaluate, perform internal audit, conduct management review | Monitoring results, internal audit programme and reports, management review minutes |
| 10 | Improvement | Identify nonconformities, take corrective action, continually improve the AIMS | Nonconformity and corrective action register, evidence of improvement |
The structure is sequential by design. Clauses 4 and 5 establish context and governance. Clause 6 plans the substantive work. Clause 7 equips the system to operate. Clause 8 runs it. Clause 9 measures it. Clause 10 improves it. An AIMS implementation that treats the clauses as a checklist of independent requirements typically produces documentation that conforms in isolation and fails when audited as a system.
Where the heaviest ISO 42001 obligations sit
Not all clauses carry equal implementation weight. Three concentrate the substantive obligations of the Standard:
| Clause | Why it carries weight |
|---|---|
| 6.1 | Risk assessment (6.1.2), risk treatment (6.1.3), and impact assessment (6.1.4) produce the Statement of Applicability and the methodologies the rest of the AIMS operates on. The impact assessment requirement is the requirement that most distinguishes ISO 42001 from ISO 27001. |
| 8 | Operation is where Annex A controls attach. The 38 controls are implemented through Clause 8 processes, and the operational lifecycle defined here is the spine on which the rest of the AIMS hangs. |
| 9.2 and 9.3 | Internal audit and management review are the clauses that determine whether the AIMS is alive or documentary. Certification bodies expect at least one cycle of each before Stage 2. |
Clauses 4, 5, 7, and 10 carry real requirements but are typically lighter implementation loads — particularly for organisations integrating with mature ISO 27001 or ISO 9001 systems, where leadership, support, and improvement infrastructure can be shared.
ISO/IEC 42001:2023 annexes: controls, guidance, vocabulary, sector
Four annexes follow the main body. Only Annex A is normative. The other three are informative — guidance that shapes implementation without imposing requirements.
Annex A — Reference controls (normative)
Annex A lists 38 reference controls organised under nine control objectives. The controls are the operational means by which Clause 8 is implemented and the Annex against which the Statement of Applicability under Clause 6.1.3 is built.
| Code | Objective | Number of controls |
|---|---|---|
| A.2 | Policies related to AI | 4 |
| A.3 | Internal organisation | 3 |
| A.4 | Resources for AI systems | 6 |
| A.5 | Assessing impacts of AI systems | 5 |
| A.6 | AI system lifecycle | 10 |
| A.7 | Data for AI systems | 5 |
| A.8 | Information for interested parties of AI systems | 4 |
| A.9 | Use of AI systems | 2 |
| A.10 | Third-party and customer relationships | 3 |
“The organization shall produce a Statement of Applicability that contains the necessary controls and justification for inclusions, whether they are implemented or not, and the justification for exclusions of controls from Annex A.” — ISO/IEC 42001:2023, Clause 6.1.3
Three structural points about Annex A determine how it should be read:
- Every control must be considered. Exclusions must be justified in the SoA against the risk treatment plan.
- The 38 controls are reference controls, not a closed list. Additional controls may be added where the risk treatment plan requires them.
- Control selection is risk-driven, not menu-driven. SoAs built by working through Annex A in order without reference to identified risks fail this requirement.
A.6 (lifecycle) is the largest control set and the spine of the operational AIMS. A.5 (impact assessment) is where ISO 42001 departs most clearly from ISO 27001 logic. A.10 (third-party) carries disproportionate weight for organisations procuring foundation models or AI-enabled SaaS.
Annex B — Implementation guidance (informative)
Annex B provides implementation guidance for each of the 38 Annex A controls. For each control, Annex B explains the control’s purpose, what implementation involves, and considerations the organisation should take into account.
The asymmetry between Annex A and Annex B matters. Annex A is binding; Annex B is guidance. An organisation can implement an Annex A control in a way that differs from Annex B guidance and remain conformant, provided the control objective is met. But auditors test conformity to Annex A controls in light of Annex B, and unexplained departures from that guidance attract scrutiny.
Annex B is the longest of the four annexes and the one implementation teams spend most time inside. Treating it as optional — implementing controls without reference to it — produces implementations that meet the literal control text and miss the substantive expectations the Standard’s authors intended.
Annex C — Objectives and risk sources (informative)
Annex C provides a reference list of organisational objectives and risk sources relevant to AI systems. It is the vocabulary annex for risk assessment under Clause 6.1.2 and impact assessment under Clause 6.1.4.
| Part | Content |
|---|---|
| Potential AI-related organisational objectives | Accountability, AI expertise, data quality, environmental impact, fairness, maintainability, privacy, robustness, safety, security, transparency and explainability, adherence to AI ethical principles |
| Potential AI-related risk sources | Complexity of environment, lack of transparency and explainability, level of automation, machine learning-related risks, system hardware issues, system lifecycle issues, technology readiness, unclear responsibility for AI risks |
The annex is informative — the organisation is not required to adopt these specific objectives or risk sources. What it supplies is the shared vocabulary the rest of the Standard assumes. Terms like “fairness,” “transparency,” “robustness,” and “explainability” appear throughout Annex A and Annex B without further definition; Annex C is where they are characterised.
Annex C aligns with ISO/IEC 23894 (AI risk management), the more detailed companion standard for risk methodology. Organisations using ISO/IEC 23894 for methodology and ISO 42001 for the management system find that Annex C is the connective tissue between them.
ISO 42001 Annex D — Domains and sectors (informative)
Annex D addresses how the AIMS applies across different domains and sectors, and how it relates to other management system standards. It is the shortest of the four annexes.
Annex D covers two themes:
- Integration with other management system standards. ISO 42001 shares the Annex SL high-level structure with ISO/IEC 27001, ISO 9001, ISO 14001, ISO/IEC 27701, and others. The annex confirms that AIMS implementations can be integrated with these systems rather than implemented as a parallel regime.
- Sector and domain applicability. AI systems are deployed across healthcare, financial services, public sector, transportation, defence, education, and other domains. Annex D acknowledges that the AIMS must be adapted to sector context and that sector-specific guidance sits alongside the Standard rather than being absorbed into it.
Annex D imposes no requirements. Its function is orientation: a reminder that ISO 42001 is part of a system of standards, not a standalone instrument, and that sector context shapes implementation.
Where each ISO/IEC 42001 obligation sits
For an organisation reading the Standard for the first time, the most useful question is where in the document each obligation lives. The table below traces the key obligations to their source clauses.
| Obligation | Source | Status |
|---|---|---|
| Declare role (provider, developer, deployer, user) | 4.1 | Normative |
| Define AIMS scope | 4.3 | Normative |
| Establish AI policy | 5.2 | Normative |
| Assign AIMS roles and authorities | 5.3 | Normative |
| Perform AI risk assessment | 6.1.2 | Normative |
| Produce Statement of Applicability | 6.1.3 | Normative |
| Perform AI system impact assessment | 6.1.4 | Normative |
| Set measurable AI objectives | 6.2 | Normative |
| Ensure competence | 7.2 | Normative |
| Ensure awareness | 7.3 | Normative |
| Manage external communication of AI system limitations | 7.4 | Normative |
| Implement Annex A controls (or justify exclusion) | 6.1.3, 8.1, Annex A | Normative |
| Operate AI system lifecycle processes | 8.1, Annex A.6 | Normative |
| Repeat risk assessment at intervals and on change | 8.2 | Normative |
| Repeat impact assessment at intervals and on change | 8.4 | Normative |
| Monitor, measure, analyse, evaluate | 9.1 | Normative |
| Conduct internal audit | 9.2 | Normative |
| Conduct management review | 9.3 | Normative |
| Maintain nonconformity and corrective action register | 10.2 | Normative |
| Demonstrate continual improvement | 10.1 | Normative |
| Apply Annex B implementation guidance | Annex B | Informative |
| Use Annex C vocabulary | Annex C | Informative |
| Integrate with other management systems | Annex D | Informative |
How ISO/IEC 42001:2023 Standard reads in practice
For an organisation working through ISO/IEC 42001:2023 for the first time, three reading strategies are common and each has different consequences.
Reading front to back produces the most complete understanding but is the slowest path to implementation. Most teams read Clauses 1 through 10 in order and then work through the annexes, which produces a coherent mental model but defers operational planning.
Reading Annex A first — the controls — produces faster operational planning but risks treating the Standard as a control catalogue rather than a management system. Implementations built this way tend to produce SoAs that list controls without traceability to risk.
Reading the requirement clauses (4–10) alongside Annex A is the implementation-oriented approach most consultants and certification bodies recommend. It treats Clauses 6 and 8 and Annex A as a connected system — risk and impact assessment producing the SoA, the SoA driving Clause 8 operations, Annex A providing the reference controls — and produces an AIMS that holds together at audit.
The bibliography at the end of the Standard points outward to ISO/IEC 22989 (concepts and terminology), ISO/IEC 23894 (AI risk management), ISO/IEC 38507 (governance implications of AI), and other related documents. These are not required reading for conformity but are widely treated as the conventional supporting literature for substantive implementation.
FAQ
Where do the requirements of the Standard actually live?
In Clauses 4 through 10 and in Annex A. Everything else — Clauses 1 to 3, Annexes B, C, and D, and the bibliography — is either descriptive or informative. When an auditor checks conformity, they check it against the normative sections; the informative sections inform how the normative requirements are interpreted but do not themselves carry obligations.
Why does the Standard have ten clauses when only seven contain requirements?
The ten-clause structure is the Annex SL high-level structure shared across all ISO management system standards. Clauses 1 to 3 (Scope, Normative References, Terms and Definitions) are kept in the same position across ISO 9001, ISO 27001, ISO 42001, and others so that organisations running integrated management systems can align them cleanly. The structural consistency is the integration mechanism — it is not redundancy.
Why is Clause 2 empty?
ISO 42001 is self-contained — it does not depend on any other standard to be applied. Clause 2 (Normative References) is retained as a placeholder to preserve the Annex SL structure, but the Standard lists no normative references. This means an organisation does not need to purchase or implement ISO 27001, ISO 9001, or any other standard to conform to ISO 42001.
What is the difference between Annex A and Annex B?
Annex A is normative — it lists the 38 reference controls that must be considered for inclusion in the AIMS. Annex B is informative — it provides implementation guidance for each Annex A control. An organisation conforms to Annex A; Annex B helps it implement Annex A but does not itself impose requirements. Auditors test conformity to Annex A in light of Annex B, so unexplained departures from B attract scrutiny even though B is not directly binding.
Are the 38 Annex A controls a closed list?
No. Annex A is described as a reference. Additional controls — drawn from NIST AI RMF, sector-specific guidance, internal frameworks — may be added where the risk treatment plan calls for them. The Standard requires every Annex A control to be considered, but it does not limit the AIMS to the 38 controls Annex A lists.
Which clauses carry the most implementation weight?
Clause 6 (Planning), Clause 8 (Operation), and the audit and review clauses (9.2 and 9.3). Clause 6 produces the Statement of Applicability, the risk and impact assessment methodologies, and the AI objectives. Clause 8 is where Annex A controls are implemented. Clauses 9.2 and 9.3 produce the evidence that the AIMS is operating, not merely documented. Clauses 4, 5, 7, and 10 carry real requirements but are typically lighter implementation loads, particularly where existing management systems can be extended.
What is the relationship between ISO 42001 and ISO/IEC 22989, 23894, and 38507?
ISO/IEC 22989 supplies AI concepts and terminology — much of the Clause 3 vocabulary is drawn from it. ISO/IEC 23894 provides AI risk management methodology — it is the conventional reference for Clause 6.1.2 risk methodology. ISO/IEC 38507 addresses governance implications of AI for governing bodies — it complements ISO 42001 at the board level. None of these is a normative reference for ISO 42001, but all are listed in the bibliography and are widely used as supporting literature.
Is Annex D enough to handle sector-specific requirements?
No. Annex D is orientation, not content. It acknowledges that sector context matters and that ISO 42001 must be applied in light of sectoral regulation, guidance, and emerging sector-specific standards. The Standard does not supply the sector layer itself; the organisation must look outward to sectoral regulators, industry bodies, and sector-specific ISO/IEC subcommittee work for that material.
How long is the Standard, and how should I read it?
ISO/IEC 42001:2023 runs to roughly 40 pages including annexes. Implementation-oriented teams typically read Clauses 4 through 10 alongside Annex A first — treating risk and impact assessment, the Statement of Applicability, Clause 8 operations, and the Annex A controls as a connected system — then return to Annex B for implementation detail. Reading front to back produces a more complete understanding but defers operational planning; reading Annex A alone produces faster planning but risks treating the Standard as a control catalogue rather than a management system.
Where does the EU AI Act sit relative to this structure?
The EU AI Act is not referenced in ISO/IEC 42001. The two instruments operate at different levels — ISO 42001 is a voluntary international management system standard; the AI Act is binding EU regulation with specific obligations the Standard does not enumerate. Certification to ISO 42001 supports conformity assessment under the Act but does not substitute for it. Many AIMS controls evidence Act obligations, but the mapping is not one-to-one, and the Act applies regardless of whether the organisation is certified.
