ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system, is the first international management system standard dedicated to artificial intelligence. Published by ISO and IEC in December 2023, it specifies the requirements for establishing, implementing, maintaining, and continually improving an AI Management System (AIMS) within an organisation. The Standard is certifiable: an organisation can be audited against it by an accredited certification body and issued a certificate valid for three years, subject to annual surveillance.
“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)
What an AI Management System actually is
An AI Management System is not software. It is not a model registry, a governance tool, or a compliance dashboard. It is the set of organisational structures, policies, processes, and records by which an organisation manages AI — analogous to the way an information security management system (ISMS) under ISO 27001 manages information security, or a quality management system (QMS) under ISO 9001 manages quality.
The AIMS sits around AI systems, not inside them. It governs:
| Element | What the AIMS does |
|---|---|
| Policy | Sets the organisation’s direction on AI |
| Roles | Assigns accountability for AI activities |
| Risk | Identifies and treats AI-related risks |
| Impact | Assesses effects of AI systems on individuals, groups, and societies |
| Lifecycle | Governs AI system development, deployment, operation, and retirement |
| Data | Manages data used by AI systems |
| Third parties | Controls AI components, models, and services sourced externally |
| Monitoring | Measures whether the system is working |
| Improvement | Acts on what monitoring and audit reveal |
The Standard does not tell the organisation which AI systems to build, how they should perform, or what risk appetite to adopt. It specifies the management system that produces those decisions and records them in a form that can be audited.
Key definitions
| Term | Meaning |
|---|---|
| AI system | An engineered system that generates outputs — content, forecasts, recommendations, or decisions — for a given set of human-defined objectives. The boundary of what the AIMS governs. |
| AI Management System (AIMS) | The set of interrelated or interacting elements of an organisation to establish policies, objectives, and processes to achieve those objectives in relation to AI. |
| Top management | The person or group of persons who directs and controls the organisation at the highest level. Named as the accountable party for the AIMS. |
| AI system lifecycle | The stages of an AI system from inception through design, development, verification, validation, deployment, operation, monitoring, and retirement. |
| Interested party | A person or organisation that can affect, be affected by, or perceive itself to be affected by a decision or activity of the organisation. |
What “establishing an AIMS” means in practice
The phrase appears throughout the Standard. In practical terms, establishing an AIMS means producing and operating eight things:
| Element | What it is | Source |
|---|---|---|
| Scope statement | What the AIMS covers — which AI systems, business units, lifecycle stages | Clause 4.3 |
| AI policy | Top-management statement of direction on AI | Clause 5.2 |
| Assigned roles | Named owners for the AIMS and the controls within it | Clause 5.3 |
| Risk assessment | Methodology and ongoing assessment of AI-related risks | Clause 6.1.2 |
| Risk treatment plan and Statement of Applicability | Controls selected to treat identified risks, documented in the SoA | Clause 6.1.3 |
| Impact assessment | Assessment of effects on individuals, groups, and societies | Clause 6.1.4 |
| Operational processes | The day-to-day procedures implementing the controls, organised across the AI system lifecycle | Clause 8, Annex A |
| Performance evaluation and improvement | Monitoring, internal audit, management review, corrective action | Clauses 9 and 10 |
These eight elements together are the AIMS. Producing them once is not enough — the Standard requires them to be maintained, reviewed, and improved over time. An AIMS that exists as documentation but is not operated is non-conformant regardless of how complete the paperwork is.
How ISO 42001 compares to ISO 27001 and ISO 9001
ISO 42001 follows the Annex SL high-level structure shared across ISO management system standards. This is what allows it to be integrated with ISO 27001 (information security) and ISO 9001 (quality) where those already exist. The clause numbers, sequence, and concepts are deliberately aligned.
| Element | ISO 9001 (Quality) | ISO 27001 (Security) | ISO 42001 (AI) |
|---|---|---|---|
| Object of management | Product and service quality | Information security | AI systems |
| Risk concept | Risk-based thinking | Information security risk | AI risk |
| Impact concept | — | — | Impact on individuals, groups, societies |
| Annex SL structure | Yes | Yes | Yes |
| Annex of controls | — | Annex A (93 controls) | Annex A (38 controls) |
| Certifiable | Yes | Yes | Yes |
| Published | 1987 (first edition) | 2005 (first edition) | 2023 |
The most consequential difference between ISO 42001 and its predecessors is the impact assessment requirement. ISO 27001 manages risk to the organisation from information security threats. ISO 9001 manages risk to product and service quality.
ISO 42001 manages both organisational risk and impact on those outside the organisation — individuals affected by AI decisions, groups exposed to AI systems, societies in which AI operates.
Organisations porting ISO 27001 thinking into an AIMS routinely under-implement this requirement because the concept does not exist in the information security standard.
The shared structure has practical consequences. Organisations with mature ISO 27001 or ISO 9001 implementations can integrate ISO 42001 efficiently — leadership commitment, documented information control, internal audit, management review, and corrective action are shared infrastructure that can be evidenced once across multiple certifications. Implementations that build the AIMS in isolation duplicate effort without strengthening governance.
The role of policy
The AI policy under Clause 5.2 is the document the AIMS is built around. It is the top-management statement of direction, the framework against which AI objectives are set, and the document leadership commitment is evidenced against.
The Standard specifies what the policy must do:
| Requirement | What it means |
|---|---|
| Appropriate to the organisation’s purpose | Specific to what the organisation does with AI — not generic |
| Framework for objectives | Provides the structure against which AI objectives under Clause 6.2 are set |
| Commitment to satisfy applicable requirements | Includes regulatory, contractual, and self-imposed requirements |
| Commitment to continual improvement | Recognises that the AIMS is improved, not static |
| Communicated within the organisation | Known to staff whose work affects the AIMS |
| Available to interested parties as appropriate | Available to customers, regulators, affected parties where relevant |
A common failure mode is the borrowed policy: an existing ethics statement or information security policy adapted with AI language. These typically fail the framework-for-objectives requirement and the appropriate-to-purpose requirement, even when the commitment language is technically present.
The role of risk treatment
Risk treatment is the bridge between risk assessment (what could go wrong) and operational controls (what we do about it). Under Clause 6.1.3, the organisation must select treatment options for identified risks, determine the controls necessary to implement them, compare those controls against Annex A, and produce a Statement of Applicability (SoA).
The SoA is the document certification audits centre on. For each of the 38 Annex A controls, it records:
- Whether the control is applicable
- Justification for inclusion or exclusion
- Implementation status
The SoA is risk-driven, not menu-driven. Controls are selected because they treat identified risks — not because they appear in Annex A. SoAs built by working through Annex A in order without reference to risk fail this requirement even when every control is addressed.
The Standard is explicit that Annex A is a reference list, not exhaustive. Where the risk treatment plan calls for controls beyond Annex A — drawn from NIST AI RMF, sector-specific guidance, or internal requirements — those controls are added. Treating Annex A as a closed list is a structural error.
The role of ISO 42001 objectives
AI objectives under Clause 6.2 translate the AI policy into measurable targets. The Standard requires objectives to be:
| Requirement | What it means |
|---|---|
| Consistent with the AI policy | Aligned with the direction the policy sets |
| Measurable | Defined so that achievement can be verified |
| Monitored | Tracked over time |
| Communicated | Known to those who must achieve them |
| Updated as appropriate | Revised when the policy, context, or risk profile changes |
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.
Aspirational language fails this requirement. “Improve AI governance” is not an objective; “Reduce model approval cycle time to under 14 days by Q4, owned by the AI Management Committee, reviewed monthly” is. Objectives that cannot be measured at the point they are set cannot be audited against Clause 6.2.
The role of internal audit in ISO 42001
Internal audit under Clause 9.2 is the mechanism by which the organisation tests its own AIMS against the Standard and against its own requirements. The audit programme must be planned, scoped, conducted by independent and impartial auditors, reported to relevant management, and followed by correction and corrective action.
Independence is structural. Internal auditors must not audit their own work — the person who built a control cannot audit it. In small organisations this often requires external consultants performing the internal audit function. “Internal” here refers to the audit being internal to the AIMS, not to the staff performing it.
The audit programme is risk-based. High-risk areas — typically Annex A controls covering impact assessment, lifecycle, data, and third-party AI — are audited more frequently and in more depth than lower-risk areas. Programmes that audit every control with equal weight produce evidence the certification body can navigate but do not reflect the Standard’s expectation of risk-driven planning.
The role of management review in ISO 42001
Management review under Clause 9.3 is the standing forum at which top management examines the AIMS for continuing suitability, adequacy, and effectiveness. It is the single most concrete evidence of leadership engagement required by the Standard.
The Standard specifies what management review must consider as inputs:
| Input | What it covers |
|---|---|
| Status of actions from previous reviews | Closure of prior decisions |
| Changes in external and internal issues | Updates to the context established under Clause 4 |
| Changes in needs and expectations of interested parties | Shifts in stakeholder requirements |
| AIMS performance | Nonconformities, monitoring results, audit results, objective fulfilment |
| Feedback from interested parties | Customer, regulator, public input |
| Results of risk assessment and treatment | What the AIMS has identified and acted on |
| Opportunities for continual improvement | What could be better |
And what it must produce as outputs:
| Output | What it covers |
|---|---|
| Decisions on continual improvement opportunities | What will be improved |
| Decisions on changes to the AIMS | What will change in policy, scope, controls, or processes |
Management review is not a standing leadership meeting that happens to touch on AI. The Standard requires the specific inputs and outputs above, documented as such. Minutes that show general AI discussion without traceability to the prescribed inputs and outputs fail the requirement.
What the AIMS produces over time
A functioning AIMS produces a defined set of artefacts on a defined cadence. The cycle below is illustrative of how most implementations settle once past the first year of operation:
| Cadence | Artefact |
|---|---|
| Continuous | Control operation, evidence capture, incident response |
| Per AI system lifecycle stage | Risk assessment, impact assessment, technical documentation, gate decisions |
| Quarterly | Objective review, AI Management Committee oversight |
| Annual | Internal audit cycle, management review, AI policy review |
| Triennial | Recertification, full AIMS reassessment |
The cadence is not prescribed by the Standard — “planned intervals” appears throughout Clause 9 without specifying frequency. The organisation determines the cadence and must justify it. High-risk or rapidly changing AI portfolios may require more frequent cycles than the illustrative pattern above.
Who the AIMS is for
ISO 42001 applies to any organisation that provides or uses AI systems, regardless of size, type, or sector. The Standard recognises multiple roles, and an organisation may hold more than one:
| Role | Definition |
|---|---|
| Provider | An organisation that develops an AI system and places it on the market or puts it into service. |
| Developer | An organisation involved in the design and development of AI systems. |
| Deployer | An organisation that uses an AI system under its own authority. |
| User | An entity that interacts with an AI system. |
The role declaration under Clause 4.1 determines which Annex A controls bear most heavily. A provider building foundation models faces a different control surface than a deployer integrating a third-party system or a user procuring AI-enabled software. Organisations with multiple roles must declare each.
What ISO 42001 does not do
Three points are worth stating explicitly because they shape expectations.
ISO 42001 does not certify AI systems. Certification is to the management system, not to any individual model. A certified organisation has demonstrated that it has a governance system that addresses AI responsibly — not that any specific model is safe, fair, or accurate in isolation.
ISO 42001 does not satisfy the EU AI Act. The Act is binding regulation with specific obligations — risk classification, conformity assessment routes, CE marking for high-risk systems, post-market monitoring, transparency to deployers and users — that ISO 42001 does not directly impose. Certification supports conformity assessment but does not substitute for it.
ISO 42001 does not prescribe technical methods. The Standard is technology-neutral and methodology-neutral. It does not specify how to assess model bias, how to test robustness, what metrics constitute fairness, or which architectures to prefer. It specifies that the organisation must have processes that address these questions — and leaves the substantive answers to the organisation, its sector, and emerging technical standards.
Why the ISO 42001 Standard exists
AI governance was, until ISO 42001, fragmented. Sectoral regulators issued sectoral guidance. National authorities produced national frameworks. Voluntary principles — OECD, UNESCO, industry codes — proliferated. The EU AI Act introduced binding regulation in one jurisdiction. None of these provided organisations with a single, international, certifiable governance framework they could implement, audit, and demonstrate to customers and regulators.
ISO 42001 fills that gap. It does not replace sectoral regulation, national frameworks, or the EU AI Act. It provides the management system layer that sits beneath them — the structure within which sectoral, national, and regulatory requirements are operationalised, and the certificate that demonstrates the structure exists and works.
For most organisations, the practical question is not whether to adopt ISO 42001. It is when, in what scope, and integrated with which existing management systems. That decision is the subject of the implementation framework guide.
