ISO 42001 Navigator BETA

Clause 1 tells you what the Standard is for and who it applies to. It specifies that ISO/IEC 42001:2023 sets out the requirements for establishing, implementing, maintaining, and continually improving an AI Management System (AIMS) within an organisation. It applies to any organisation — regardless of size, type, or sector — that provides or uses products or services that utilise AI systems. The clause makes clear that the Standard is designed to help organisations develop and use AI responsibly in pursuit of their objectives, and to meet obligations from interested parties such as customers, regulators, and the public.

What this means in practice

Clause 1 carries no requirements you must implement — it is descriptive, not normative. Its function is to fix the boundary of the Standard: AIMS, not AI systems themselves.

The Standard governs the management system around AI, not the technical performance of any individual model. This distinction matters because it determines what an auditor checks (your governance, processes, and controls) versus what they do not check (the accuracy or safety of any specific AI system in isolation).

Why it matters

Scope clauses are routinely skipped, but Clause 1 settles three questions that affect everything downstream: (1) ISO 42001 applies whether you build, deploy, or merely use AI; (2) sector and size are not gating criteria; (3) certification is to the management system, not to a product. Misreading any of these leads to mis-scoped implementations.

Clause 2 lists the external documents that are formally referenced within ISO/IEC 42001:2023 and that are indispensable for its application. In the published Standard, this clause states that there are no normative references — meaning ISO 42001 does not require you to read or apply any other standard in order to conform to it.

What this means in practice

Clause 2 is a placeholder. ISO management system standards conventionally include it in the same position to maintain a consistent ten-clause structure (the Annex SL high-level structure shared with ISO 27001, ISO 9001, and others). Because ISO 42001 stands alone in normative terms, the clause is effectively empty — but the placeholder is retained so the numbering aligns with every other ISO management system standard.

Why it matters

Two practical points. First, ISO 42001 is self-contained: you do not need to purchase or implement ISO 27001, ISO 9001, or any other standard to certify against it.

Second, although there are no normative references, the Standard’s bibliography points to related documents (ISO/IEC 22989 on AI concepts and terminology, ISO/IEC 23894 on AI risk management, ISO/IEC 38507 on governance) that are useful for implementation but not required. Treat those as supporting reading, not obligations.

Clause 3 establishes the vocabulary used throughout ISO/IEC 42001:2023. It defines the terms an organisation must understand to apply the Standard consistently — covering AI-specific concepts (AI system, AI system lifecycle, machine learning, training data, intended use, foreseeable misuse), management system concepts (organisation, interested party, top management, policy, objective, process), and audit and conformity concepts (audit, nonconformity, corrective action, continual improvement).

The clause itself does not write out every definition. Many terms are imported by reference from ISO/IEC 22989:2022 (Artificial intelligence — Concepts and terminology), which serves as the foundational vocabulary standard for the ISO/IEC AI standards family. ISO 42001 then adds or adapts terms specific to managing AI within an organisational system.

What this means in practice

Clause 3 carries no requirements you must implement — like Clause 2, it is descriptive. But it is the most consequential of the three opening clauses, because the definitions here govern how every later requirement is interpreted.

When Clause 6 talks about “AI risk,” Clause 8 talks about “AI system impact assessment,” or Annex A refers to “intended use,” the meaning is fixed by Clause 3 and its referenced sources — not by colloquial usage or by your internal vocabulary.

Two definitions deserve particular attention:

AI system — the boundary of what the Standard governs. If something does not meet the definition of an AI system, it falls outside AIMS scope. The ISO definition is broader than many internal definitions teams use, so misalignment here causes scope errors downstream.

AI system lifecycle — the stages your controls must cover (inception, design, development, verification, validation, deployment, operation, monitoring, retirement). Annex A controls map to lifecycle stages, so this definition determines what evidence auditors expect at each phase.

Terminology drift is the single most common source of nonconformity in early AIMS implementations. Teams adopt the Standard but continue using their own definitions — “model” instead of “AI system,” “release” instead of “deployment,” “incident” instead of “nonconformity” — and the resulting documentation cannot be cleanly audited against the Standard.

Clause 3 is short, but treating it as boilerplate is a structural error: the vocabulary it fixes is the vocabulary your policies, risk register, Statement of Applicability, and audit evidence must use.

Clause 4 is where the normative requirements begin. It asks the organisation to define the environment in which its AIMS will operate before designing the system itself. Four sub-clauses set out what this means:

4.1 Understanding the organisation and its context — identify the internal and external issues that affect the organisation’s ability to achieve the intended outcomes of its AIMS. This includes the organisation’s role in relation to AI systems (provider, developer, deployer, user, or a combination), the nature of the AI systems involved, and the regulatory, market, technological, and ethical environment in which it operates.

4.2 Understanding the needs and expectations of interested parties — identify the parties relevant to the AIMS (customers, users, regulators, employees, affected individuals, suppliers, the public) and determine which of their needs and expectations will be addressed through the management system.

4.3 Determining the scope of the AI management system — establish the boundaries of the AIMS: which AI systems, business units, geographies, and lifecycle stages it covers, and what is excluded. The scope must be documented and available as documented information.

4.4 AI management system — establish, implement, maintain, and continually improve the AIMS itself, including the processes needed and their interactions, in accordance with the Standard.

What this means in practice

Clause 4 forces an organisation to answer three questions before doing anything else:

• What role do we play in relation to AI?
• Who cares about how we do it?
• What are we actually certifying?

The role question (4.1) determines which Annex A controls apply most heavily. A provider developing foundation models faces a different control surface than a deployer integrating a third-party system or a user procuring AI-enabled software.

The Standard expects the role to be stated explicitly, not assumed.

The interested parties exercise (4.2) is more substantive than it appears. It is the input to risk assessment, impact assessment, and the AI policy that follows in Clause 5. Skipping it — or treating it as a stakeholder list — leaves later clauses without an anchor.

The scope statement (4.3) is the document an auditor checks first. It defines what is on the table for certification and what is out.

Scope errors here propagate:

• Under-scoping creates audit gaps;
• Over-scoping creates implementation burden without business justification.

Why it matters

Clause 4 is the foundation the rest of the Standard rests on. Every subsequent requirement — leadership commitment in Clause 5, risk and impact assessment in Clause 6, operational controls in Clause 8 — refers back to the context, interested parties, and scope established here.

Implementations that treat Clause 4 as preamble and rush to Annex A produce AIMS documentation that auditors describe as “controls without a system”: the controls exist but cannot be traced to the organisational context that should justify them.
Two specific failure modes recur:

Role ambiguity. Organisations that develop AI for internal use, license third-party AI, and resell AI-enabled services often try to claim a single role. The Standard accommodates multiple roles, but each must be declared and its implications worked through. Hiding role complexity in Clause 4 surfaces it as nonconformity in Clause 8.

Scope drift. AIMS scope is sometimes written to mirror the organisation’s full AI footprint when the certification target is narrower. The scope statement should match what the AIMS actually governs at the time of audit — not aspiration.

Clause 5 sets out what top management must do for the AIMS to function. It establishes that responsible AI is a governance responsibility, not a technical one, and assigns specific obligations to the leadership of the organisation. Three sub-clauses divide the requirements:

5.1 Leadership and commitment — top management must demonstrate active commitment to the AIMS. This includes ensuring the AI policy and objectives are established and compatible with the strategic direction of the organisation, integrating AIMS requirements into business processes, making resources available, communicating the importance of effective AI management, ensuring the AIMS achieves its intended outcomes, directing and supporting personnel, promoting continual improvement, and supporting other relevant management roles.

5.2 AI policy — top management must establish a documented AI policy that is appropriate to the purpose of the organisation, provides a framework for setting AI objectives, includes a commitment to satisfy applicable requirements, and includes a commitment to continual improvement of the AIMS. The policy must be communicated within the organisation and made available to interested parties as appropriate.

5.3 Roles, responsibilities and authorities — top management must assign and communicate responsibility and authority for ensuring the AIMS conforms to the Standard and for reporting on its performance.

What this means in practice

Clause 5 is where AIMS implementations most often go wrong on paper and even more often go wrong in practice. The Standard does not allow leadership to delegate the AIMS to a compliance officer, a CISO, or an AI ethics committee and walk away.

Top management is named as the accountable party — and “top management” is defined in Clause 3 as the person or group of persons who directs and controls the organisation at the highest level.

Three concrete deliverables emerge from Clause 5:

• A signed, dated AI policy that meets the criteria in 5.2 and is genuinely owned by leadership — not a marketing statement and not an inherited code of ethics.
• Evidence of leadership engagement: minuted management reviews, resource allocation decisions, communications to staff, and the integration of AIMS objectives into business planning. Auditors look for these as proof that 5.1 is operative, not declarative.
• A documented assignment of roles — who owns the AIMS, who owns the AI policy, who owns risk assessment, who owns impact assessment, who reports performance to top management — with the authority to perform each role.

Why it matters

The most common nonconformity at certification audit is leadership commitment that exists on paper but cannot be evidenced in operation.

The Standard is structured so that 5.1 deficiencies cascade: weak leadership commitment produces a thin policy (5.2), unclear roles (5.3), under-resourced risk processes (Clause 6), and operational controls (Clause 8) that no one has authority to enforce.

Auditors trace from Annex A controls back to Clause 5 to test whether the control owner has the authority the Standard requires.

Two specific failure modes recur:

The borrowed policy. Organisations adapt an existing information security or ethics policy and call it the AI policy. The Standard requires the policy to address AI specifically and to provide a framework for AI objectives — not a generic statement that AI will be used responsibly.

Borrowed policies fail 5.2 on the framework requirement even when they pass on commitment language.

Diffuse accountability. Responsibility for the AIMS is sometimes spread across a steering committee with no single named owner. The Standard allows committee structures, but 5.3 still requires identifiable assignment of authority. “The committee is responsible” is not a sufficient answer when an auditor asks who is accountable for AIMS performance.

Clause 6 is where the AIMS moves from governance scaffolding to substantive work. It requires the organisation to identify risks and opportunities, conduct AI-specific risk and impact assessments, set objectives, and plan changes. Four sub-clauses structure the requirements:

6.1 Actions to address risks and opportunities — the organisation must determine the risks and opportunities that need to be addressed to give assurance the AIMS can achieve its intended outcomes, prevent or reduce undesired effects, and achieve continual improvement. This sub-clause is further divided:

• 6.1.1 General — establishes the obligation to plan actions to address risks and opportunities, integrate those actions into AIMS processes, and evaluate their effectiveness.
• 6.1.2 AI risk assessment — establish and maintain an AI risk assessment process that defines and applies risk criteria, identifies AI risks, analyses them, and evaluates them against the criteria. Results must be documented.
• 6.1.3 AI risk treatment — establish and maintain a risk treatment process that selects appropriate treatment options, determines the controls necessary to implement them, compares those controls against Annex A, produces a Statement of Applicability, formulates a risk treatment plan, and obtains risk owners’ approval of the plan and acceptance of residual risks.
• 6.1.4 AI system impact assessment — establish a process to assess the potential consequences for individuals, groups of individuals, and societies that can result from the development, provision, or use of AI systems. The process must be applied throughout the AI system lifecycle and documented.

6.2 AI objectives and planning to achieve them — establish measurable AI objectives at relevant functions and levels, consistent with the AI policy. For each objective, the organisation must determine what will be done, what resources are required, who is responsible, when it will be completed, and how results will be evaluated.

6.3 Planning of changes — when the organisation determines the need for changes to the AIMS, those changes must be carried out in a planned manner.

What this means in practice

Clause 6 is the operational heart of the Standard. It produces the four documents an auditor will spend the most time examining:

The AI risk assessment — methodology, criteria, identified risks, analysis, evaluation. The Standard does not mandate a specific methodology. ISO/IEC 23894 is the conventional reference but not required.

The Statement of Applicability (SoA) — the document that lists each Annex A control, states whether it is applicable, justifies inclusion or exclusion, and records implementation status. The SoA is the document certification bodies use as the working surface of the audit.

The AI risk treatment plan — what will be done about each identified risk, by whom, by when, with what residual risk accepted by which risk owner.

The AI system impact assessment — the assessment of consequences for individuals, groups, and societies. This is the requirement that distinguishes ISO 42001 most sharply from ISO 27001 and other management system standards. It is not a risk assessment from the organisation’s perspective; it is an assessment of effects on those outside the organisation.

The impact assessment requirement (6.1.4) is where most implementations under-deliver. Teams familiar with ISO 27001 default to organisational risk thinking and produce an impact assessment that catalogues risks to the business rather than effects on affected parties.

The Standard is explicit that impact assessment addresses consequences for individuals and societies — fairness, safety, autonomy, rights, environmental and social effects — and must be applied across the AI system lifecycle, not as a one-off exercise at deployment.

The 6.2 objectives requirement is more demanding than it reads. Objectives must be measurable, time-bound, resourced, and assigned. “Implement responsible AI” is not an objective. “Reduce false positive rate in deployed classification systems below 5% by Q4, owned by Head of ML, reviewed monthly” is.

Why it matters

Clause 6 is the clause that determines whether the AIMS is real. Clauses 4 and 5 establish context and commitment; Clause 6 produces the artefacts that prove the system operates.

The Statement of Applicability alone consumes most of the documentation effort in a typical implementation and is the single most scrutinised document in certification.

Three specific failure modes recur:

Risk assessment without impact assessment. Organisations conflate 6.1.2 and 6.1.4, producing a single risk register that addresses business risk but not effects on individuals and society. These two assessments serve different purposes and require different methodologies; merging them is a structural nonconformity, not a documentation oversight.

The Statement of Applicability as inventory rather than justification. The SoA must justify each inclusion or exclusion against the risk treatment plan, not merely tick a box for each Annex A control. SoAs that list controls without traceability to identified risks fail audit.

Objectives that cannot be measured. Aspirational language in 6.2 — “improve AI governance,” “enhance transparency” — is not auditable. Objectives must specify the measurement method at the point they are set, not retrofitted before audit.

Clause 7 covers the resources and infrastructure that make the AIMS workable in practice. Once context is set (Clause 4), leadership is committed (Clause 5), and risks and objectives are planned (Clause 6), the organisation must equip the system to operate. Five sub-clauses set out what is required:

7.1 Resources — determine and provide the resources needed for the establishment, implementation, maintenance, and continual improvement of the AIMS. Resources include people, infrastructure, tooling, data, computational capacity, and budget.

7.2 Competence — determine the competence necessary for persons doing work under the organisation’s control that affects AIMS performance, ensure those persons are competent on the basis of appropriate education, training, or experience, take action where competence gaps exist, and retain documented information as evidence of competence.

7.3 Awareness — ensure persons doing work under the organisation’s control are aware of the AI policy, their contribution to the effectiveness of the AIMS (including the benefits of improved performance), and the implications of not conforming to AIMS requirements.

7.4 Communication — determine the internal and external communications relevant to the AIMS, including what to communicate, when, with whom, how, and who communicates. The clause covers both routine communication and communication about AI system characteristics, intended use, and known limitations to interested parties.

7.5 Documented information — establish, maintain, and control the documented information required by the Standard and determined by the organisation as necessary for AIMS effectiveness. The clause is subdivided:

• 7.5.1 General — sets the obligation to maintain documented information.
• 7.5.2 Creating and updating — requires appropriate identification, description, format, review, and approval of documents.
• 7.5.3 Control of documented information — requires controls for availability, distribution, access, storage, version control, retention, and disposition.

What this means in practice

Clause 7 produces the infrastructure auditors test against the requirements of every other clause. A risk assessment under Clause 6 only conforms if the people performing it are competent under 7.2. An operational control under Clause 8 only conforms if the documented procedure under 7.5 exists and is current; a management review under Clause 9 only conforms if the communication channels under 7.4 are operative.

Four deliverables emerge in practice:

A competence framework specific to AI roles. Generic role descriptions are insufficient. The Standard expects the organisation to identify the competencies needed across the AI system lifecycle — data engineering, model development, deployment, monitoring, risk assessment, impact assessment — and to evidence that named individuals hold them. ISO 42001 is the first management system standard to require AI-specific competence; borrowed ISO 27001 frameworks under-cover this.

An awareness programme. Training records must demonstrate that staff understand the AI policy, their role in AIMS effectiveness, and the consequences of nonconformity. The bar is higher than security awareness training because AI competence is uneven across organisations and the population that needs awareness extends beyond technical teams.

A communications matrix. Internal communication about AIMS objectives, risks, and performance; external communication to users, affected parties, and regulators about AI system characteristics, intended use, and limitations. The external limb of 7.4 is the requirement most often missed — particularly the obligation to communicate known limitations of AI systems to interested parties.

A documented information control system. Version control, access control, retention, and approval workflows for all AIMS documents. Where the organisation already runs an ISO 27001 or ISO 9001 documented information regime, ISO 42001 can be folded in; where it does not, this is substantial new infrastructure.

Why it matters

Clause 7 is where AIMS implementations either become operational or remain documentary. The clauses before it produce policy, scope, and plans, but Clause 7 produces the conditions under which those plans can actually be executed.

Auditors test Clause 7 by sampling: pick a control from Annex A, find the person responsible, check their competence record, find the procedure, verify it is current, ask the person to perform the task. Gaps in any link produce nonconformities that trace back to Clause 7.
Three specific failure modes recur:

• Competence asserted, not evidenced. Organisations list “AI/ML expertise” against named individuals without documentation. The Standard requires evidence — qualifications, training records, demonstrated experience — not assertion. CVs alone are not sufficient where the competence claim is current.
• Awareness collapsed into training. Awareness under 7.3 is not the same as competence training under 7.2. Awareness is about the policy, the system, and the consequences of nonconformity, and it extends to everyone whose work affects the AIMS — including non-technical staff. Treating 7.3 as a subset of 7.2 leaves a documentary gap.
• External communication of AI system limitations omitted. The 7.4 requirement to communicate known limitations to interested parties is frequently overlooked because it bridges into product documentation, user-facing notices, and customer communications that sit outside the compliance function. The requirement is nonetheless explicit, and it is the most direct point of overlap with EU AI Act transparency obligations.

Clause 8 is where the AIMS does its work. Everything established in Clauses 4 to 7 — context, policy, roles, risks, objectives, resources, competence, documented information — converges here into operational processes that govern AI systems across their lifecycle.

Three sub-clauses structure the requirements:

8.1 Operational planning and control — plan, implement, and control the processes needed to meet AIMS requirements and to implement the actions determined in Clause 6.

The organisation must:

• Establish criteria for the processes,
• Implement control of the processes in accordance with the criteria,
• Maintain documented information to demonstrate the processes have been carried out as planned,
• Control planned changes and review unintended changes,
• Take action to mitigate adverse effects, and
• Ensure externally provided processes, products, or services relevant to the AIMS are controlled.

8.2 AI risk assessment — perform AI risk assessments at planned intervals, when significant changes are proposed or occur, and when significant nonconformities or incidents arise. Retain documented information of the results.

8.3 AI risk treatment — implement the AI risk treatment plan established under 6.1.3, and retain documented information of the results.

8.4 AI system impact assessment — perform AI system impact assessments at planned intervals and when triggered by changes to AI systems, their context, or their use. Retain documented information of the results.

What this means in practice

Clause 8 is short on the page but contains the largest operational obligation in the Standard. It is the clause Annex A controls attach to the 38 controls across nine objectives are the means by which Clause 8 is implemented in practice.

When an auditor asks how the organisation controls AI system development, data management, third-party AI components, or post-deployment monitoring, the answer is a Clause 8 process implementing one or more Annex A controls.

Four operational deliverables emerge:

AI system lifecycle processes. Documented procedures covering inception, design, development, verification, validation, deployment, operation, monitoring, and retirement — each with criteria, controls, evidence, and accountability. The lifecycle is the spine on which Annex A controls hang; without it, controls float without context.

A repeatable risk assessment cadence (8.2). Risk assessments are not one-off artefacts produced for certification. They must be performed at planned intervals and triggered by change. Organisations need a defined frequency, defined triggers, and a defined methodology — the same methodology used at 6.1.2, applied repeatedly.

Operational evidence that the risk treatment plan is executing (8.3). The plan produced under 6.1.3 must demonstrably translate into action: controls implemented, residual risks tracked, owners reviewing, exceptions documented. Auditors compare the plan to operational reality and look for drift.

A repeatable impact assessment cadence (8.4). Impact assessments are likewise lifecycle artefacts, not deployment-gate checkboxes. Material changes to the AI system, its data, its context of use, or affected populations trigger reassessment. The cadence and triggers must be defined.

Externally provided processes under 8.1 — third-party models, foundation model APIs, training data providers, MLOps platforms, AI-enabled SaaS — receive specific attention. The organisation cannot outsource AIMS conformity. Controls over third-party AI components must demonstrate that risks introduced through procurement are assessed, treated, and monitored to the same standard as internally developed systems. Annex A’s controls on third-party relationships and AI system use make this concrete.

Why it matters

Clause 8 is where the AIMS is judged. Clauses 4 through 7 can be implemented competently and still produce nothing of operational value if Clause 8 is thin. The clause is also where the largest delta between ISO 27001 and ISO 42001 lives: the lifecycle, the impact assessment cadence, and the third-party AI control surface have no clean equivalents in information security management and cannot be ported across.

Three specific failure modes recur:

Lifecycle without stages. Organisations describe AI development “from concept to deployment” without defining the stages, gates, criteria, and evidence at each transition. Annex A controls reference lifecycle stages explicitly; an undifferentiated lifecycle cannot evidence stage-specific controls.

Risk and impact assessments as snapshots. Assessments performed once at design time and never repeated violate the 8.2 and 8.4 cadence requirements. The Standard requires repetition at planned intervals and on change — operational rhythm, not one-off documents.
Third-party AI treated as procurement, not AIMS scope.

Foundation models, AI-enabled platforms, and AI components from suppliers are inside AIMS scope when the organisation provides or uses them. Treating them as ordinary vendor management — handled outside the AIMS — leaves the third-party AI control surface uncovered.

Clause 9 requires the organisation to measure whether the AIMS is working. It establishes the obligation to monitor, measure, analyse, and evaluate the system, to audit it independently, and to subject it to formal management review. Three sub-clauses set out what is required:

9.1 Monitoring, measurement, analysis and evaluation — determine what needs to be monitored and measured, the methods used to ensure valid results, when monitoring and measurement are performed, when results are analysed and evaluated, and who is responsible. The organisation must evaluate the performance of the AIMS and the effectiveness of the AIMS itself, and retain documented information as evidence.

9.2 Internal audit — conduct internal audits at planned intervals to provide information on whether the AIMS conforms to the organisation’s own requirements and to the requirements of ISO/IEC 42001, and whether it is effectively implemented and maintained. The clause is subdivided:

• 9.2.1 General — establishes the obligation to conduct internal audits.
• 9.2.2 Internal audit programme — plan, establish, implement, and maintain an audit programme;
  1. Define audit criteria and scope for each audit;
  2. Select auditors and conduct audits in a way that ensures objectivity and impartiality;
  3. Report results to relevant management;
  4. Take appropriate correction and corrective action without undue delay;
  5. Retain documented information as evidence.

9.3 Management review — top management must review the AIMS at planned intervals to ensure its continuing suitability, adequacy, and effectiveness. The clause is subdivided:

• 9.3.1 General — sets the obligation to conduct management reviews.
• 9.3.2 Management review inputs — defines what must be considered: status of actions from previous reviews, changes in external and internal issues, changes in needs and expectations of interested parties, information on AIMS performance (nonconformities, monitoring results, audit results, fulfilment of objectives), feedback from interested parties, results of risk assessment and risk treatment, opportunities for continual improvement.
• 9.3.3 Management review results — outputs must include decisions related to continual improvement opportunities and any need for changes to the AIMS. Documented information of the results must be retained.

What this means in practice

Clause 9 is the clause that distinguishes a maintained AIMS from a documented one. It produces four deliverables an auditor expects to find current at the time of certification and at every surveillance audit:

A monitoring and measurement programme. Defined metrics for AIMS performance (objectives from 6.2, control effectiveness from Annex A, risk treatment progress, incident rates, training completion) and for AI system performance where it informs AIMS effectiveness.

The Standard does not prescribe metrics — it requires the organisation to determine them and to justify their adequacy. Vague metrics fail 9.1 on the “valid results” requirement.

An internal audit programme. A schedule of audits across the AIMS, with criteria, scope, independent auditors, reports, and corrective actions. The independence requirement is structural: internal auditors must not audit their own work.

In small organisations this often requires bringing in external consultants to perform the internal audit function — internal here refers to the audit being internal to the AIMS, not to the staff performing it.

Management review minutes. Documented evidence that top management has reviewed the AIMS at planned intervals, considered each of the required inputs under 9.3.2, and produced decisions on the required outputs under 9.3.3.

The minutes are the single most concrete evidence of leadership engagement required by the Standard and are checked against Clause 5 commitments.

Traceability from monitoring to action. Monitoring results that identify problems must be visible in management review inputs; management review decisions must produce changes traceable into Clause 10 corrective actions and Clause 6 planning updates. Auditors test this trace and treat its absence as a structural weakness.

The interval question — “planned intervals” appears in 9.1, 9.2, and 9.3 — is not defined by the Standard. The organisation determines the frequency and must justify it.

Annual management review and annual internal audit are common but not mandated. hHigh-risk or rapidly changing AI portfolios may require more frequent cycles.

Why it matters

Clause 9 is the clause that proves the AIMS is alive. Certification audits routinely find documentation that exists, controls that are implemented, and risk assessments that have been performed — and Clause 9 evidence that is thin, late, or missing.

When that happens, the AIMS is judged as a static artefact rather than a managed system, and the entire certification is at risk regardless of how well the other clauses are documented.

Three specific failure modes recur:

Monitoring without analysis. Organisations collect metrics but do not analyse or evaluate them. The Standard requires both — collection alone does not satisfy 9.1. Analysis must produce conclusions about AIMS performance and effectiveness, and those conclusions must feed management review.

Internal audit performed by the implementer. The person who built the AIMS frequently also audits it. This violates the objectivity and impartiality requirement of 9.2.2 even when the individual is competent and well-intentioned. Independence is a structural requirement, not a judgement about the auditor.

Management review as standing meeting. Management review is conflated with regular leadership meetings where AI is discussed. The Standard requires a review with the specific inputs in 9.3.2 and specific outputs in 9.3.3, documented as such. A general leadership meeting that touches on AI does not meet the requirement, even if all participants are present.

Clause 10 closes the management system cycle. Where Clause 9 measures performance, Clause 10 requires the organisation to act on what the measurements reveal — correcting nonconformities when they occur and continually improving the AIMS over time. Two sub-clauses set out what is required:

10.1 Continual improvement — the organisation must continually improve the suitability, adequacy, and effectiveness of the AIMS.

10.2 Nonconformity and corrective action — when a nonconformity occurs, the organisation must react to it, evaluate the need for action to eliminate its causes so it does not recur or occur elsewhere, implement any action needed, review the effectiveness of corrective action taken, make changes to the AIMS if necessary, and retain documented information as evidence of the nature of nonconformities, actions taken, and results. Corrective actions must be appropriate to the effects of the nonconformities encountered.

What this means in practice

Clause 10 produces two operational deliverables that auditors examine closely:

A nonconformity and corrective action register. A documented record of every nonconformity identified — through monitoring (9.1), internal audit (9.2), management review (9.3), incidents, complaints from interested parties, or external audit findings — together with root cause analysis, corrective actions, owners, deadlines, verification of effectiveness, and any consequential changes to the AIMS.

Auditors sample this register and trace individual entries from identification through to verified closure.

Evidence of continual improvement. Demonstrable changes to the AIMS over time that improve its suitability, adequacy, or effectiveness. The Standard does not prescribe what improvement looks like; it requires that improvement happens and is evidenced.

Common forms include policy revisions following lessons learned, expanded control coverage as the AI system portfolio grows, tightened risk criteria as the organisation matures, and refined impact assessment methodology as affected populations change.

The distinction between correction and corrective action in 10.2 matters and is routinely missed. Correction is the immediate fix — the model is retrained, the data source is replaced, the affected output is rolled back.

Corrective action addresses the cause so the nonconformity does not recur and does not occur elsewhere. A register that records corrections without corrective actions fails 10.2 on the recurrence-prevention requirement, regardless of how diligently each individual incident was resolved.

Root cause analysis is the connective tissue. The Standard requires evaluation of the need for action to eliminate causes — meaning the organisation must look beyond the symptom to the underlying weakness in process, control, competence, or design. Five-whys, fishbone, and structured causal analysis methods are conventional; the Standard does not mandate a method but expects the analysis to be visible in the register.

The effectiveness review requirement is the loop closure. After corrective action is implemented, the organisation must verify that it actually worked — that the nonconformity has not recurred and that the cause has been eliminated.

Closed register entries that lack effectiveness verification are open nonconformities in audit terms.

Why it matters

Clause 10 is short, but it is the clause that turns the AIMS from a maintained system into an improving one.

Together with Clause 9, it forms the Plan-Do-Check-Act cycle that defines management system standards across the ISO family. An AIMS that monitors itself (Clause 9) without acting on what it learns (Clause 10) is structurally incomplete.

Three specific failure modes recur:

Corrections logged as corrective actions. Registers that record the immediate fix and close the entry, without root cause analysis or recurrence prevention, fail 10.2 on its central requirement. This is the single most common nonconformity raised against Clause 10 at certification.

No effectiveness review. Corrective actions are implemented and closed without verification that they worked. The register shows resolution, but the AIMS cannot show that the underlying weakness has been eliminated.

Continual improvement asserted, not evidenced. Organisations claim continual improvement in policy language but cannot produce a record of changes made to the AIMS in response to measurement, audit, or review findings. The Standard requires evidence of improvement, not commitment to it.

Annex A is the normative annex of ISO/IEC 42001:2023. It lists 38 reference controls organised under nine control objectives (A.2 through A.10).

The controls are the operational means by which Clause 8 is implemented and the Annex against which the Statement of Applicability (SoA) under 6.1.3 is built.

Every Annex A control must be considered for inclusion in the AIMS; controls that are excluded must be justified in the SoA.

The ten control objectives are:

A.2 — Policies related to AI.

Establish management direction and support for AI in accordance with business requirements and relevant laws and regulations.

A.3 — Internal organisation.

Establish accountability within the organisation for the responsible implementation and operation of AI systems.

A.4 — Resources for AI systems.

Ensure the organisation accounts for the resources (including AI system components, data, tooling, system and computing resources, and human resources) required for the AI system lifecycle activities.

A.5 — Assessing impacts of AI systems.

Assess the impacts on individuals, groups of individuals, and societies that can arise from the development, provision, or use of AI systems.

A.6 — AI system lifecycle.

Ensure that the organisation identifies objectives and implements processes for the responsible design, development, deployment, operation, monitoring, and decommissioning of AI systems.

A.7 — Data for AI systems.

Ensure that the organisation understands the role and impacts of data in AI systems throughout their lifecycle.

A.8 — Information for interested parties of AI systems.

Ensure that relevant interested parties have the necessary information to understand and appropriately use AI systems.

A.9 — Use of AI systems.

Ensure that the organisation uses AI systems responsibly and according to organisational policies.

A.10 — Third-party and customer relationships.

Ensure that the organisation understands its responsibilities and remains accountable when third parties are involved at any stage of the AI system lifecycle, and that risks arising from the use of AI systems by customers are appropriately managed.

What this means in practice

Annex A is the working surface of the AIMS. Where Clauses 4 through 10 establish the management system, Annex A specifies what the system must control. Three documents anchor the Annex A workflow:

The Statement of Applicability (SoA)

The document that lists each of the 38 Annex A controls, declares whether each is applicable, justifies inclusion or exclusion against the risk treatment plan, and records implementation status.

The SoA is the single most scrutinised document in certification and is built under 6.1.3 but operates against Annex A.

The risk treatment plan

Links identified risks (from 6.1.2) to the controls selected to treat them. Annex A controls are the conventional source, but the Standard permits additional controls beyond Annex A where the risk treatment requires them.

Operational evidence per control

Procedures, records, logs, and outputs demonstrating that each applicable control is implemented and operating. Annex A controls are stated at a level of generality; the organisation must produce the operational artefacts that evidence each one.

Three Annex A objectives carry disproportionate weight and warrant specific attention:

A.5 (Impact assessment) is the operational home of the 6.1.4 impact assessment requirement. It is where ISO 42001 most clearly departs from ISO 27001 logic. The controls under A.5 require an impact assessment process, documented assessments, and consideration of impacts on individuals, groups, and societies — not on the organisation itself.

Auditors treat A.5 as a test of whether the organisation has internalised the ISO 42001 worldview or has ported information security thinking.

A.6 (AI system lifecycle) is the largest control set and the spine of the operational AIMS. It covers objectives for responsible development, processes for responsible design and development, requirements specification, design and development documentation, verification and validation, deployment, operation and monitoring, technical documentation, and event logging. Almost every other Annex A objective references back to lifecycle stages defined here.

A.7 (Data for AI systems) addresses data quality, data provenance, data preparation, and data management across the lifecycle. The controls under A.7 are where most data governance work surfaces in the AIMS and where overlap with GDPR is most concrete — though ISO 42001 addresses data for AI system performance and trustworthiness, not data protection per se.

A.10 (third-party and customer relationships) is where the third-party AI control surface flagged in Clause 8 becomes specific. Controls cover supplier responsibilities, customer responsibilities, and shared accountability when AI systems cross organisational boundaries. For organisations that procure foundation models, use AI-enabled SaaS, or provide AI to downstream customers, A.10 is operationally heavy.

Why it matters

Annex A is the part of the Standard that determines what the AIMS actually does day to day. Clauses establish the management system but the Annex A specifies the controls that make AI governance concrete. Three structural points are worth flagging:

• Annex A is normative, not informative. It is part of the Standard’s requirements. Controls cannot be ignored — they must be considered, and exclusions must be justified. This distinguishes Annex A from Annexes B, C, and D, which are informative and provide guidance without requirements.
• The 38 controls are reference controls, not a closed list. The Standard permits and sometimes requires additional controls beyond Annex A where the organisation’s risk treatment plan calls for them.Treating Annex A as exhaustive is a structural error. the SoA may legitimately include controls drawn from other frameworks (NIST AI RMF, sector-specific guidance) where they address risks Annex A does not.
• Control selection is risk-driven, not menu-driven. The Standard requires controls to be selected on the basis of the risk treatment plan, then compared against Annex A to ensure no necessary control has been omitted. SoAs built by working through Annex A in order without reference to identified risks fail this requirement, even when every control is addressed.

Three specific failure modes recur:

SoA as control inventory. The Statement of Applicability lists controls and ticks boxes without traceability to the risk treatment plan, the identified risks, or the operational evidence. This is the most common Annex A nonconformity at certification.

Annex A treated as exhaustive. Organisations limit their AIMS to the 38 reference controls and exclude additional controls their risk profile requires. The Standard is explicit that Annex A is a reference, not a ceiling.

Impact assessment controls (A.5) ported from privacy or security frameworks. Organisations reuse DPIA templates or security risk assessment templates for A.5 and miss the breadth of impact ISO 42001 requires — individuals, groups, and societies, across the lifecycle. The result conforms on paper and fails on substance.

Annex B provides implementation guidance for the 38 controls listed in Annex A. Where Annex A states each control at a level of generality — what the control is intended to achieve — Annex B explains how to implement it.

For each Annex A control, Annex B sets out the control’s purpose, guidance on what implementation involves, and considerations the organisation should take into account.

Annex B follows the structure of Annex A exactly: the same nine objectives (A.2 through A.10) and the same 38 controls, each expanded with implementation detail.

The guidance covers what activities the control requires, what artefacts typically evidence it, what factors influence how it should be applied, and how it interacts with other controls.

What this means in practice

Annex B is informative, not normative. The Standard distinguishes the two clearly: Annex A controls are requirements (subject to inclusion or justified exclusion in the SoA), while Annex B guidance is advice on how to implement those requirements.

An organisation can implement an Annex A control in a way that differs from Annex B guidance and remain conformant, provided the implementation meets the control objective.

In practice, Annex B serves four functions:

The default implementation reference. For organisations without existing AI governance practice, Annex B is the starting point for designing each control’s operational form. Audit-ready implementations rarely deviate from Annex B without a documented reason.

The auditor’s interpretation aid. Certification auditors use Annex B to test whether implementations meet the spirit of each Annex A control.

Implementations that diverge significantly from Annex B guidance attract scrutiny — not automatic nonconformity, but a higher evidential burden.

The bridge between Standard and operations. Annex A states “the organisation shall”; Annex B explains what that obligation looks like in concrete activities, documents, and decisions.

Implementation teams use Annex B to translate requirements into work.
The reference for sector adaptation. Where Annex B guidance does not fit the organisation’s context — sector, scale, AI system type — the organisation is expected to adapt rather than abandon the control. Annex B is the baseline against which adaptation is measured.

The relationship between Annex A and Annex B is asymmetric. Annex A is binding; Annex B is guidance. An organisation cannot be cited for nonconformity against Annex B directly — only against the Annex A control it elaborates.

But auditors test conformity to Annex A controls in light of Annex B guidance, and unexplained departures from that guidance attract findings even where the underlying control objective is technically met.

Why it matters

Annex B is the longest of the four annexes and the one implementers spend most time inside. Three structural points are worth flagging:

Informative does not mean optional in practice. Annex B is not a requirement, but treating it as such — implementing controls without reference to it — produces implementations that struggle in audit and miss obvious operational design choices the Standard’s authors intended. The “informative” designation is a legal category, not a recommendation to ignore it.

Annex B is where ISO/IEC 42001’s worldview is most explicit. Annex A controls are stated abstractly; Annex B is where the Standard’s expectations about lifecycle stages, affected parties, data provenance, and accountability across the value chain are spelled out.

Reading Annex A without Annex B produces controls without their intended meaning.

Annex B complements but does not replace external references. ISO/IEC 23894 (AI risk management), ISO/IEC 22989 (concepts and terminology), and sector-specific guidance remain relevant to implementation. Annex B does not exhaust what good implementation looks like; it specifies what the Standard’s authors consider the baseline.

Two specific failure modes recur:

Annex A implemented from the title alone. Teams read the one-line Annex A control statement and design implementation without consulting Annex B. The result typically meets the literal control text and misses the substantive expectations the Standard captures only in B.

Annex B treated as binding text. The opposite error: teams treat every line of Annex B as a requirement and over-engineer implementations to match guidance that was offered as a default.

Annex B should inform design choices, not constrain them where context justifies a different approach.

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 6.1.2 and impact assessment under 6.1.4 — the catalogue from which an organisation draws when identifying what it is trying to achieve through responsible AI and what can go wrong in pursuit of those objectives.

Annex C is structured in two parts:

Potential AI-related organisational objectives.

A list of objectives the organisation may pursue through its AIMS, including (among others) accountability, AI expertise, availability and quality of training and test data, environmental impact, fairness, maintainability, privacy, robustness, safety, security, transparency and explainability, and adherence to AI ethical principles. Each objective is named and briefly characterised.

Potential AI-related risk sources.

A list of sources of risk that AI systems can introduce, including (among others) complexity of environment, lack of transparency and explainability, level of automation, risk sources related to machine learning, system hardware issues, system lifecycle issues, technology readiness, and unclear responsibility for AI risks. Each risk source is named and briefly characterised.

What this means in practice

Annex C is informative, not normative. The Standard does not require organisations to adopt these specific objectives or to enumerate these specific risk sources.

What it does is supply a shared vocabulary that risk and impact assessments can draw on — and against which auditors can sense-check whether an organisation has considered the conventional territory.

Three operational uses follow:

Input to risk assessment (6.1.2)

When defining risk criteria, identifying AI risks, and analysing them, Annex C’s risk source list functions as a prompt. An organisation that performs risk assessment without considering whether its AI systems exhibit any of the Annex C risk sources is likely to produce an under-scoped risk register.

Conversely, an organisation that traces each identified risk back to one or more Annex C sources produces a risk assessment auditors can navigate.

Input to impact assessment (6.1.4).

Annex C’s objectives list — particularly fairness, privacy, transparency, safety, and the ethical principles cluster — maps closely to the categories of impact on individuals and societies that an impact assessment must address.

The objectives list is where the link between organisational intent and impact methodology is most clearly drawn.

Input to objectives setting (6.2)

When establishing AI objectives, Annex C provides the conventional menu. Organisations are not obliged to adopt these objectives, but where they decline to address one — fairness, environmental impact, robustness — the absence is conspicuous and likely to attract audit scrutiny.

Why it matters

Annex C is the shortest and most overlooked of the four annexes, but it has outsized influence on the substantive quality of risk and impact assessments.

Three structural points are worth flagging:

Annex C supplies the 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.

Implementations that import these terms from external frameworks (NIST AI RMF, OECD principles, sector codes) and reconcile them only loosely with Annex C produce inconsistent internal vocabulary.

The risk source list is the implicit audit checklist. Certification auditors do not formally require Annex C coverage, but they sample risk assessments against the conventional risk landscape — and

Annex C is the conventional landscape the Standard sets out. Risk assessments that omit categories listed in Annex C without explanation invite questions.

Annex C connects to ISO/IEC 23894. The risk source list aligns with ISO/IEC 23894 (AI risk management), the more detailed companion standard for risk methodology. Organisations using 23894 for methodology and 42001 for the management system find that Annex C is the connective tissue between them.

One specific failure mode recurs:

Annex C ignored entirely. Because Annex C is informative, teams often skip it and build risk and impact assessment methodology from external sources. The result is methodology that may be defensible in its own terms but does not align with the Standard’s vocabulary.

Auditors then have to reconcile the organisation’s internal categories with Annex C’s, and gaps surface as nonconformities against 6.1.2 and 6.1.4 rather than against Annex C itself.

Annex D addresses how the AIMS established under ISO/IEC 42001 applies across different domains and sectors, and how it relates to other management system standards. It is the shortest of the four annexes and the most contextual: it does not add controls or vocabulary but situates the Standard within the broader ISO management system landscape and across the sectoral environments in which AI systems are deployed.

Annex D covers two themes:

Integration with other management system standards

AIMS implementations rarely exist in isolation. Organisations frequently operate ISO/IEC 27001 (information security), ISO 9001 (quality), ISO 14001 (environmental), ISO/IEC 27701 (privacy information management), and ISO 31000 (risk management) alongside ISO 42001.

Annex D acknowledges this and notes the Annex SL high-level structure shared across ISO management system standards, which allows ISO 42001 to be integrated with existing management systems rather than implemented as a parallel regime.

Sector and domain applicability

AI systems are deployed across health, financial services, public sector, transportation, defence, education, and other domains, each with its own regulatory, ethical, and operational context.

Annex D recognises that the AIMS must be adapted to the sector in which it operates, and that sector-specific guidance — emerging from ISO/IEC subcommittees, sectoral regulators, and industry bodies — sits alongside the Standard rather than being absorbed into it.

What this means in practice

Annex D is informative and does not impose requirements. It functions as orientation: a reminder that ISO 42001 is part of a system of standards, not a stand-alone instrument, and that sector context shapes implementation.

Three operational implications follow:

Integrated management systems are explicitly supported. Organisations with mature ISO 27001 or ISO 9001 implementations can integrate AIMS into the existing structure rather than building parallel processes. Shared elements — leadership commitment, documented information control, internal audit, management review, corrective action — can be evidenced once across multiple certifications, provided the AI-specific obligations in Clauses 6, 8, and Annex A are addressed substantively.

Sector context shapes risk, impact, and control selection. Annex D signals that the same Annex A controls will be implemented differently in healthcare, finance, and public administration. Risk thresholds, impact categories, regulatory overlay, and operational tempo all vary.

The Standard does not prescribe sector adaptation. Instead, Annex D acknowledges that it must happen and points implementers towards sector-specific guidance.

External references remain relevant. Sectoral codes of practice, regulatory guidance (EU AI Act, sectoral AI guidance from financial regulators and health authorities), and emerging sector-specific ISO standards complement Annex D rather than being replaced by it. Annex D is a pointer outward, not a closed framework.

Why it matters

Annex D is short and easy to dismiss, but it carries two structural messages that affect how the AIMS is designed:

ISO 42001 is built for integration. The Annex SL structure is not incidental — it is the mechanism by which ISO 42001 plugs into existing management systems.

Implementations that treat ISO 42001 as a standalone regime, separate from ISO 27001 or ISO 9001 already in place, duplicate effort without strengthening governance and produce documentation auditors find harder to navigate.

The Standard does not pretend to be sector-complete. ISO 42001 is deliberately sector-neutral. Sectoral applicability is left to sector bodies, regulators, and implementers. Annex D makes this explicit and signals that an AIMS implementation in a regulated sector must look outward for the additional layer the Standard does not provide.

One specific failure mode recurs:

AIMS implemented in isolation from existing management systems. Organisations with operational ISO 27001 build a parallel AIMS rather than integrating, producing duplicated leadership commitments, duplicated documented information regimes, and duplicated audit programmes.

Annex D’s integration message is the explicit corrective, and integrated implementations are both more efficient to maintain and more credible at audit.