ISO 42001 and the Emerging Shape of AI Management Systems
ISO/IEC 42001 was published in December 2023 as the first international standard for an artificial intelligence management system. Two and a half years on it has moved from a document most people had not read to something that appears in vendor questionnaires, and the reason is worth understanding, because it says something about where AI governance is heading.
What kind of standard this is
ISO/IEC 42001 is a management system standard. That places it in the same family as ISO/IEC 27001 for information security and ISO 9001 for quality, and it shares their structure: context and scope, leadership and policy, planning around risks and objectives, support and resourcing, operational controls, performance evaluation, and improvement.
This matters more than it sounds. A management system standard does not primarily tell you which technical controls to implement. It tells you to run a governing process: to decide what is in scope, identify what could go wrong, decide what you are going to do about it, assign someone to do it, check whether it worked, and act on what you find. The controls in the annex support that process rather than replacing it.
For anyone who has been through ISO 27001, the shape will be immediately familiar, and that familiarity is the point. Organizations with a functioning ISMS have most of the machinery already: the risk methodology, the internal audit function, the management review cadence, the document control. Extending it to cover AI systems is a smaller undertaking than building it from nothing.
What it asks for that is genuinely new
The AI-specific content is where 42001 earns its existence. Several requirements have no real analogue in security management.
- An AI policy that states the organization’s position on how AI is developed and used, aligned with its objectives and its obligations.
- AI system impact assessment: a structured consideration of consequences for individuals and groups affected by an AI system, which is a different exercise from assessing risk to the organization.
- Life cycle controls covering how AI systems are designed, developed, verified, deployed, operated, and retired, with documentation at each stage.
- Data governance specific to AI, covering provenance, quality, and the appropriateness of data for the purpose the system is put to.
- Roles and responsibilities across the AI supply chain, including what you require of suppliers and what you commit to for downstream users.
The impact assessment requirement deserves particular attention. Most organizations arrive with a risk process oriented entirely around risk to themselves. Assessing effects on the people subject to a system is an unfamiliar discipline for a lot of security and compliance functions, and it is where we most often see first attempts fall short.
Where the certification market has got to
The standard is certifiable, meaning an accredited certification body audits you and issues a certificate, in the same manner as ISO 27001. Certification bodies have operationalised their audit programmes, and a number of large technology vendors now hold certificates.
The practical significance is that ISO/IEC 42001 has become the artifact buyers point at when they want assurance about AI governance and do not have a better instrument. Security questionnaires have started asking for it. Procurement teams that would struggle to evaluate a bespoke AI governance narrative can evaluate a certificate from an accredited body.
It is worth being clear-eyed about what a certificate does and does not tell you. It says an auditor was satisfied that a management system exists and functions. It does not say a particular model is safe, accurate, or fair. Buyers who treat it as a warranty of model behaviour are misreading it, and vendors who market it that way are inviting a problem.
How it sits alongside the EU AI Act and the NIST AI RMF
These three are frequently mentioned together and are three different kinds of thing.
The EU AI Act is law. It applies to systems within its scope whether or not you have adopted any standard, and compliance is not optional for those in scope.
The NIST AI Risk Management Framework is a voluntary framework, organised around the functions of govern, map, measure, and manage. It is not certifiable. There is no auditor and no certificate. It is a well-constructed way to think about AI risk and a common reference point in the United States, and organizations use it to structure a programme rather than to prove one.
ISO/IEC 42001 is a certifiable management system standard. It is the one of the three that produces an independently issued artifact you can hand to a counterparty.
The relationship between 42001 and the AI Act is the question we are asked most often, and it needs care. Running a conforming management system builds a great deal of the governance and documentation discipline that the Act’s high-risk obligations require, and organizations doing both find substantial reuse. But a 42001 certificate is not a conformity assessment under the Act and does not by itself demonstrate compliance with it. Harmonised standards under the Act are still being developed, and anyone telling you today that a certificate closes out your AI Act obligations is overstating it.
Whether you should pursue it
The honest answer is that it depends almost entirely on whether anyone is asking, and on what you build.
The case is strongest for organizations that develop or deploy AI systems as a material part of what they sell, particularly into enterprise, regulated, or public sector buyers, and most of all where those buyers are in or selling into Europe. In that position the certificate answers a question you are going to be asked repeatedly, and answering it once is cheaper than answering it per deal.
The case is weaker for organizations that use AI features incidentally, in tooling they did not build, with no customer asking. There, the useful work is inventory and classification, knowing what you have and what obligations attach to it, rather than a certification programme.
A middle path that serves a lot of organizations: build the management system, run it properly, and defer the certification decision until a buyer makes it for you. The governance value is in the system. The certificate is in the audit, and the audit can wait until it has a commercial purpose.
What the audit actually looks at
Certification follows the pattern established by other management system standards, and knowing the shape in advance removes most of the anxiety around it.
A stage one audit reviews whether the management system exists on paper and is ready to be tested: scope definition, AI policy, risk and impact assessment methodology, the register of AI systems in scope, and evidence that you have planned internal audit and management review. Auditors commonly stop here and tell an organization to come back, and the usual reason is a scope that does not match reality or a risk methodology that was written but never applied.
A stage two audit tests whether the system operates. The auditor samples AI systems from your register and follows them through: was an impact assessment performed, was it reviewed, did identified risks get treated, is there evidence the treatment happened, and did anyone check afterward. They will interview people outside the compliance function, and answers that contradict the documentation are the most damaging thing that can happen in the room.
Surveillance audits follow annually, with recertification on a three-year cycle. The practical implication is that the internal audit and management review obligations are not one-time gates. An organization that certifies and then stops running the cycle will fail its first surveillance audit.
The register is the thing to get right first
If there is one artifact that determines whether a 42001 programme goes smoothly, it is the inventory of AI systems in scope.
Most organizations do not have one, and building it surfaces uncomfortable facts: features shipped by product teams without governance review, vendor products whose AI functionality arrived in a release note, models running in analytics that nobody classified as AI. A management system scoped around a register that omits half of what you actually run is a system that will fail when an auditor samples outside it.
This is also the artifact with the most reuse. The same register drives EU AI Act classification, answers customer questionnaires, and tells you where impact assessments are owed. Building it well is the highest-leverage work in AI governance, and it is worth doing before any decision about certification.
Our ISO/IEC 42001 overview covers what we operate for clients running an AI management system, and our NIST AI RMF page covers the framework alongside it.
Related frameworks
The Verdict Forum publishes educational guidance, not legal or compliance advice. Confirm requirements against the authoritative sources and your assessor before acting.
Read next
What the EU AI Act Requires of Companies Outside the EU
The Act reaches organizations with no European entity. Which roles and risk tiers apply, what the 2026 amendments moved, and what the deferral did not cover.
HIPAA Security Rule Obligations for Technology Vendors
Business associates carry direct statutory obligations, not contractual ones. What the Security Rule requires, what "addressable" really means, and where the 2025 proposed update stands.