Guide
What is ISO 42001?
The certifiable standard for an AI management system. What it covers, how it differs from ISO 27001, and the one requirement people get wrong.
ISO/IEC 42001 is the international standard for an AI management system, published in December 2023. It does for artificial intelligence roughly what ISO 27001 does for information security: a governance framework covering how an organisation develops, provides or uses AI, certifiable by an accredited body. If you already hold ISO 27001 a good deal transfers, and the part that does not is the part that matters most.
Last reviewed:
What it is, and what it is for
Published in December 2023, ISO/IEC 42001 is the first certifiable management system standard for artificial intelligence. It applies whether you build AI, supply it, or simply use somebody else's, and that last case is the one most organisations fall into without having noticed.
What an AI management system has to do
- InventoryKnow what AI you have
- AssessmentAssess impact on people
- ControlsControl and account
- CycleOperate and improve
The word management is doing real work in that phrase. The standard does not tell you which AI systems are acceptable, what accuracy is good enough, or where to draw a line on automated decisions. It requires that you have a process for reaching those answers, that somebody owns it, that the reasoning is recorded, and that the whole thing is reviewed rather than written once. An auditor is not assessing your models. They are assessing whether you can demonstrate control over them.
That distinction is why the certificate is worth something to a buyer. Anybody can assert that their AI is responsible. A certificate says an accredited third party examined the machinery and found it running.
- 1The inventory What you develop or use, who owns it, what it decides
- 2Nine control objectives Annex A, A.2 to A.10. Published counts of the individual controls vary
- 3The impact runs outward On individuals and society, not on the organisation
- 4Not a relabelled DPIA Fairness, contestability, and what happens when it is wrong
What is actually inside it
The body of the standard follows the harmonised structure common to every modern ISO management system: context, leadership, planning, support, operation, performance evaluation and improvement, at clauses 4 to 10. If you have been through ISO 27001 this will be entirely familiar territory.
The AI-specific material sits in Annex A, organised into nine control objectives.
ISO/IEC 42001:2023, Annex A control objectives
| Ref | Objective | What it is really asking |
|---|---|---|
| A.2 | Policies related to AI | Is there a stated position, approved by someone with authority to state it |
| A.3 | Internal organisation | Who is accountable, and does the reporting line survive a disagreement |
| A.4 | Resources for AI systems | People, compute, tooling and data, identified rather than assumed |
| A.5 | Assessing impacts of AI systems | The requirement that has no equivalent in an ISMS. See below |
| A.6 | AI system life cycle | Objectives, design, verification, deployment and monitoring as a managed sequence |
| A.7 | Data for AI systems | Provenance, quality and preparation. Where did this data come from, and on what basis |
| A.8 | Information for interested parties | What you tell users, subjects and customers about the system |
| A.9 | Use of AI systems | Responsible use by your own people, including systems you did not build |
| A.10 | Third-party and customer relationships | The suppliers whose models you have embedded, and what you promised your customers |
Two of those repay a second look. A.7 on data provenance is where a great many programmes stall, because the honest answer for a bought-in model is often that nobody knows. And A.10 is the one that catches organisations who believed they were out of scope because they do not develop anything: if you have embedded a supplier's model in a product, you have an AI management problem whether or not you have an AI development team.
Where it overlaps with ISO 27001, and where it does not
Transfers from ISO 27001
- Clauses 4 to 10: the harmonised management system structure.
- Internal audit programme.
- Management review.
- Document and record control.
- Corrective action and continual improvement.
Does not transfer
- The AI system inventory: what you have, who owns it, what it decides.
- The impact assessment on individuals and society.
- Data provenance: where training and input data came from, and on what basis.
- Transparency and explainability expectations.
- Human oversight arrangements that are real rather than nominal.
The management machinery transfers. The subject matter does not. That is why holding ISO 27001 saves months rather than most of the work, and why the estimate offered by a consultancy that has priced this as an ISO 27001 extension is usually optimistic.
There is a deeper difference underneath the clause mapping. An information security management system protects the organisation from the world. An AI management system is substantially concerned with protecting the world from the organisation. Risk registers built on the first assumption tend to record only risks to the business, and an assessor will notice within an hour.
The requirement people get wrong
Until recently the fair objection to all of this was that the standard asked for an impact assessment without saying much about what one should contain. That gap has now been filled. ISO/IEC 42005 was published in 2025 as guidance on AI system impact assessment: what to consider, how to structure it, and how it fits into the life cycle.
It is guidance rather than a certifiable standard, so nobody audits you against it directly. Its practical value is that it removes the argument. An assessment built along its lines is recognisably the thing clause A.5 is asking for, and it is considerably harder for an internal stakeholder to insist that the existing DPIA will do.
The law moved. The standard did not.
Anyone building an AI governance programme in the last two years has been working towards 2 August 2026, the date the EU AI Act's high-risk obligations were due to apply. That date has changed.
The Commission tabled the Digital Omnibus on AI on 19 November 2025. Following political agreement in May 2026 and formal adoption in June, the high-risk obligations were deferred: standalone systems under Annex III to 2 December 2027, and AI embedded in regulated products under Annex I to 2 August 2028.
What was not deferred matters just as much, and is being widely overlooked.
What moved, and what did not
Prohibited practices have applied since 2 February 2025. General-purpose AI model obligations have applied since 2 August 2025. And the Article 50 transparency duties, which include telling people when they are interacting with an AI system and labelling synthetic content, apply from 2 August 2026 exactly as originally scheduled.
So the position for an organisation using AI today is that some of the law is already live, some of it arrives in 2027 and 2028, and the reason for the delay was that the harmonised standards and national supervisory machinery were not ready in time.
The lesson to draw from this is not that AI governance can wait. It is that a programme organised around a compliance date is fragile in a way that a management system is not. The date moved; the inventory, the impact assessments, the ownership and the oversight arrangements did not become less necessary. Organisations that had built the management system spent the deferral improving it. Organisations that had built a deadline project stopped, and will restart from a colder position in 2027.
Check who is certifying you
One more piece of the family matters commercially, and it is new enough that it is worth checking rather than assuming.
ISO/IEC 42006 was published in 2025. It sets the requirements for the bodies that audit and certify AI management systems, supplementing the general rules in ISO/IEC 17021-1 with AI-specific competence and process requirements. It is the mechanism by which an ISO 42001 certificate comes to mean the same thing from one certification body to the next.
The practical consequence is a question to ask any body quoting for the work: under what accreditation are they issuing this certificate. A certificate from a body that is not accredited for AI management systems is not worthless, but it is a different product from the one a procurement team believes it is receiving, and the difference tends to surface at exactly the wrong moment.
Why organisations are pursuing it
Three reasons, in roughly this order of honesty.
Procurement is starting to ask. Certification is becoming a line in supplier questionnaires, particularly where the buyer has their own regulatory exposure and is passing it down the chain.
It makes regulatory work tractable. The EU AI Act, the NIST AI Risk Management Framework and ISO 42001 overlap substantially in what they want you to be able to demonstrate. Running one managed programme rather than three disconnected workstreams is the practical argument, and it is a stronger one now that the legal timetable has proved changeable.
It forces the inventory. Most organisations cannot currently list the AI systems they use. The standard makes that unavoidable, and the inventory is where the surprises live. A great deal of AI arrives switched on inside software that was licensed for something else, and nobody records it as an AI decision because nobody made one.
What the audit actually looks like
Certification follows the same two-stage pattern as every other accredited management system audit, and knowing the shape of it removes most of the anxiety.
Stage 1 is a readiness review. The auditor reads your documentation and checks that the management system exists, that its scope is coherent, and that you have done the things that cannot be done quickly. It is normal to come out of stage 1 with findings. It is not normal, and not recoverable in a fortnight, to come out of it having never run an internal audit.
Stage 2 is the substantive audit. Here the question changes from whether the system is documented to whether it is operating, and the evidence is drawn from what actually happened rather than from what the policy says should happen. Expect the auditor to pick systems from your inventory and follow them through: who approved this, what did the impact assessment conclude, what happened when it was reviewed, who was told.
The failure mode is almost never a missing document. It is an inventory that turns out to be incomplete when the auditor names a system the organisation uses and cannot find it on the list, or an impact assessment that was written once and never revisited after the system changed.
What a realistic programme looks like
Build the AI system inventory
What AI the organisation develops or uses, who owns each system, what it decides, and what data it touches. This almost always takes longer than expected, because a great deal of AI arrives switched on inside software already licensed.
You should see: A list somebody outside the team would recognise as complete.
Assess impact, properly
For each system that materially affects people: fairness, contestability, and the consequences of being wrong. Not the DPIA with a new cover page. ISO/IEC 42005 is the reference to build it against.
You should see: An assessment that would still make sense to someone affected by the system.
Put accountability on it
Ownership, oversight arrangements, and a route for someone to challenge an outcome. Human oversight that exists on paper and nowhere else is a finding waiting to happen.
You should see: Every system has a named owner who knows they own it.
Run it long enough to evidence it
The same constraint as every other ISO management system. Nine to fifteen months from a standing start is realistic, and most of that is operating time rather than writing time.
You should see: An internal audit that found something, and a management review that decided something.
Where to go next
The free readiness assessment on this site scores your position clause by clause, with what an assessor expects to see and where organisations usually fall short, and orders the gaps by what to fix first rather than by clause number. Nothing you enter leaves your browser.
Common questions
›What is ISO 42001 in simple terms?
A management system for AI. You establish what AI your organisation develops or uses, assess how those systems affect people, put controls and accountability around them, and run the cycle that keeps that current. It is certifiable, so an accredited body audits it and issues a certificate, which is increasingly what customers and procurement teams ask for.
›How is ISO 42001 different from ISO 27001?
They share the harmonised structure that every ISO management system standard uses, so clauses 4 to 10 will look familiar and your existing internal audit programme, management review and document control largely transfer. The difference is what they protect. ISO 27001 protects the organisation's information. ISO 42001 is concerned with the effect of AI systems on individuals and on society, which is a fundamentally different question and cannot be answered with a security control set.
›We have ISO 27001. How much of a head start is that?
Real but partial. Expect the reused portion to save months rather than to be most of the job. What transfers is the management machinery. What does not is the AI-specific work: the AI system inventory, the impact assessment on individuals and society, and data provenance. Those three are where the effort actually goes.
›What is an AI system impact assessment?
An assessment of how an AI system affects individuals and society, as distinct from how it affects your organisation. It is the clearest difference between ISO 42001 and an information security management system, and it is the requirement most often satisfied incorrectly by relabelling a data protection impact assessment. A DPIA examines privacy. This examines fairness, contestability, and the consequences of the system being wrong.
›How long does ISO 42001 certification take?
For an organisation starting from nothing, realistically nine to fifteen months. As with ISO 27001, the binding constraint is not documentation but operating history: an internal audit and a management review both need to have genuinely happened before a stage 2 audit is worth booking.
›Does ISO 42001 satisfy the EU AI Act?
No, and treat anyone who says otherwise carefully. The Act imposes legal obligations; the standard is a voluntary management system. Holding the certificate demonstrates you run AI governance as a managed process, which makes meeting those obligations considerably easier and gives you much of the evidence, but the two are not equivalent and a certificate is not a defence.
Where to go next