ISO/IEC 42001 is the first international, certifiable standard for an artificial-intelligence management system — AIMS. Published in 2023, it occupies the same place for AI that ISO 27001 occupies for information security and ISO 9001 for quality: it does not tell you what to build, it tells you how to govern.
That tends to disappoint people who arrive looking for technical model requirements. That is not what the standard is about. It is about who decides, on the basis of which assessment, with what evidence and on what review cycle. Which is why a company that merely uses third-party AI — most companies — is also an addressee of it.
This guide is a practical introduction and does not replace reading the standard, which is a paid, copyrighted document. What follows is the map of the terrain and the order of work, not the normative text.
The structure of the standard
ISO/IEC 42001 follows the harmonised structure common to management-system standards — good news for anyone already holding ISO 27001 or 9001, because clauses 4 to 10 are recognisable and integrable:
| Clause | What it covers | What it asks for in practice |
|---|---|---|
| 4. Context | Scope of the management system and interested parties. | Define where AI is used, by whom, and who is affected — including people who are not customers. |
| 5. Leadership | AI policy, roles and responsibilities. | A published policy and someone in top management with named responsibility. |
| 6. Planning | Risks, opportunities, impact assessment and objectives. | An AI risk assessment and an assessment of the systems' impact on people and society. |
| 7. Support | Resources, competence, awareness and documentation. | Training with records, and version control over documents. |
| 8. Operation | Executing the planned controls and assessments. | This is where the inventory and the system life cycle become routine. |
| 9. Performance evaluation | Monitoring, internal audit and management review. | Indicators, an internal audit, and a recorded management review meeting. |
| 10. Improvement | Nonconformity, corrective action and continual improvement. | A record of deviations with the action taken — and evidence that they were treated. |
Annex A holds the controls, organised in groups from A.2 to A.10: policies related to AI, internal organisation, resources for AI systems, assessing impacts of AI systems, AI system life cycle, data for AI systems, information for interested parties, use of AI systems, and third-party and customer relationships. As in ISO 27001, controls are justifiable by applicability — which requires a statement of applicability with an item-by-item rationale.
What is genuinely new relative to ISO 27001
Organisations already running a certified management system tend to overestimate the effort of the structure and underestimate that of the AI-specific controls. In practice the new work concentrates in four areas:
Impact assessment on people and society
ISO 27001 assesses risk to the organisation. ISO 42001 adds a dimension that did not exist: the impact of the AI system on individuals and on groups — bias, discrimination, effects on rights, unintended consequences. It is the deepest conceptual change in the standard, and the one that generates the most rework when it is treated as just another column in the existing risk matrix.
AI system life cycle
Conception, development or acquisition, verification, deployment, operation, monitoring and retirement. For organisations that only consume third-party AI, the cycle concentrates on acquisition, operation and retirement — but it has to exist and be documented.
Data governance for AI
Provenance, quality, representativeness and preparation of the data used. Companies that only use third-party tools tend to assume this block does not apply; it applies in the form of what data the company feeds into those tools — which is exactly the point of contact with data protection law.
Information for interested parties
Transparency about AI use towards those affected by it: customers, candidates, employees. It speaks directly to the right to review of automated decisions and to the transparency duties of the EU AI Act.
Where to start
The sequence below generates the least rework. Note that the policy, which nearly every project puts first, appears third:
- 1. Scope. Decide what falls inside the management system. Too broad a scope on a first certification is the number-one cause of projects that never finish.
- 2. Inventory. Map the AI systems in use and in development. Without it, clause 6 and clause 8 have no object. See how to build an AI-BOM.
- 3. Policy and roles. Now — written over the real environment rather than the imagined one. See the annotated template.
- 4. Risk and impact assessment. Two distinct assessments, and it is common to see them mistakenly merged into one.
- 5. Annex A controls and statement of applicability. With a rationale per control, including the ones deemed not applicable.
- 6. Operate, producing evidence. Run it for a few months generating records. This is the stage with no shortcut.
- 7. Internal audit and management review. A formal prerequisite before certification.
- 8. Certification audit. In two stages: document review and implementation audit.
What fails an audit is almost never a missing document — it is missing evidence of operation. A published policy with no acknowledgement records, a risk assessment untouched since it was created, and an inventory with no last-verified date are the three most predictable findings.
Certify, or just align?
These are different decisions and both are legitimate. Aligning to the standard without certifying delivers most of the governance benefit at a fraction of the cost. Certifying delivers one thing alignment does not: proof a third party accepts without every customer having to audit you.
The practical criterion is commercial, not technical: if your sales process already runs into vendor questionnaires asking about AI governance, certification pays for itself in sales cycle. If it does not yet, alignment is enough — and leaves you a few months away from certification when it is demanded.
Relationship with the other frameworks
| Framework | Relationship to ISO/IEC 42001 |
|---|---|
| ISO/IEC 27001 | Complementary. Same management structure, different scopes: information security vs AI management. Integrable into a single system. |
| LGPD / GDPR | Complementary. ISO 42001 provides the management system; data protection law provides the legal obligation over personal data. Much of the evidence serves both. |
| EU AI Act | Convergent. A management system conforming to ISO 42001 is a natural route to demonstrating much of the regulation's governance obligations. |
| NIST AI RMF | Voluntary and non-certifiable, organised in functions (Govern, Map, Measure, Manage). Useful as a method; ISO 42001 is what gets certified. |
Frequently asked questions
What is ISO/IEC 42001?
It is the first international, certifiable standard for an artificial-intelligence management system (AIMS), published in 2023. It does not define how to build models: it defines how an organisation governs the use and development of AI — policy, roles, risk and impact assessment, life cycle, data, suppliers and continual improvement.
Is ISO/IEC 42001 mandatory?
No. It is a voluntary standard. In practice, though, it is increasingly required by contract: large corporate customers, public tenders and vendor due diligence have started asking for it, much the way ISO 27001 stopped being a differentiator and became an entry requirement in many sectors.
How much of ISO 42001 carries over if we already hold ISO 27001?
Much of the management structure — context, leadership, planning, competence, documentation, internal audit and management review follow the same harmonised structure and can be integrated into the existing system. What is new are the AI-specific controls: impact assessment on people and society, AI system life cycle, data governance for AI, and information for interested parties.
How long does ISO/IEC 42001 certification take?
For an organisation already running a certified management system, typically six to twelve months. Starting from zero, twelve to eighteen. The critical path is rarely the documentation: it is accumulating enough operational evidence to demonstrate the system has been working long enough to be audited.