ISO/IEC 42001: The AI Management System Standard, Explained

Your AI systems stopped being demos. They read customer records, file tickets, move money, and call tools you did not write. And somewhere in a procurement thread, a customer just asked whether you are certified to ISO/IEC 42001.

ISO/IEC 42001 is the international standard for an artificial intelligence management system. It is the first AI standard an organization can actually be certified against, which is why it moved from a standards-committee curiosity to a line item in enterprise security reviews within a couple of years of publication. It is also widely misunderstood. Most guides treat it as a certificate you acquire. It is closer to an operating system you run, and this page treats it that way.

If you are earlier in the journey, start with the broader discipline of AI governance and come back. If you already know why you need governance and are choosing a framework, keep reading.

What is ISO/IEC 42001?

ISO/IEC 42001 is the international standard that specifies requirements for establishing, implementing, maintaining, and continually improving an artificial intelligence management system, or AIMS. Published in 2023 by ISO and IEC, it applies to any organization that provides, develops, or uses AI systems, regardless of size or sector. It is the first AI standard that supports accredited third-party certification.

Its position as the reference AI management system standard is recognized well outside ISO. NIST maintains a published crosswalk mapping its AI Risk Management Framework onto ISO/IEC 42001, which is a useful signal of how the two are expected to be used together.

The standard was written by ISO/IEC JTC 1/SC 42, the joint subcommittee responsible for artificial intelligence standards. That lineage explains the shape of the document. ISO/IEC 42001 follows the same Harmonized Structure that ISO 27001, ISO 9001, and every other modern management-system standard uses. If you have lived through an ISO 27001 program, the skeleton will feel familiar within about ten minutes.

What is not familiar is what the standard asks you to control. ISO 27001 protects information. ISO/IEC 42001 asks you to take responsibility for the effects of systems that make decisions, including effects on people who never agreed to be part of your product. That is a different kind of obligation, and it is the reason the standard cannot be satisfied by copying your existing security controls into a new binder.

What is an AI management system (AIMS)?

An AI management system is the set of policies, roles, processes, and records an organization uses to govern how it develops, provides, and uses AI. It is organizational machinery, not software. The AIMS is how you decide which AI systems you will build, who is accountable for each one, what risks you accept, and how you prove any of that later.

This is the distinction almost every guide skips, and it causes real confusion in kickoff meetings:

• An AI system is a thing you build or buy - a model, a pipeline, an agent, a feature.
• An AI management system is how your organization governs all of those things - one AIMS, many AI systems.

You do not certify a model. You certify the management system that governs your models, and the auditor tests that claim by sampling the AI systems inside its scope. Which makes scope the most consequential decision in the whole program, and we will come back to it.

Why ISO/IEC 42001 matters now

Three forces turned a 2023 standard into a 2026 procurement requirement.

Regulation created a demand for defensible process. Providers of high-risk AI systems are required to put a quality management system in place, with documented risk management, data governance, and post-market monitoring, under the EU Artificial Intelligence Act. Our guide to EU AI Act compliance obligations walks through who those duties land on. ISO/IEC 42001 is not itself a harmonised standard that grants presumption of conformity, and any page telling you otherwise is overselling: the harmonised standards for the AI Act are being developed separately by CEN-CENELEC JTC 21. But an AIMS produces most of the artifacts those obligations demand, which is why regulated organizations start here.

Procurement caught up. Security questionnaires now ask about AI the way they asked about SOC 2 a decade ago. Certification is the shortest credible answer to "how do you govern your AI," and unlike a self-attestation, it survives a skeptical reviewer.

Agents changed the object being governed. A model that returns a prediction is a contained risk. An agent that selects its own tool calls, chains them, and acts on the result is a different problem, and it is the one the standard handles least gracefully. That gap gets its own section below, because it is where most implementations quietly break.

How ISO/IEC 42001 is structured: clauses 4 to 10

The standard opens with three administrative clauses (scope, normative references, terms) and then delivers its requirements in clauses 4 through 10. These are the mandatory core. You do not get to skip one because it is inconvenient.

Here is what each clause demands, and the question an auditor will ask to test it. That third column is where most readiness assessments fall apart.

Clause	What it requires	What an auditor asks you to show
4. Context of the organization	Identify internal and external issues, interested parties and their requirements, and define the AIMS scope.	Your written scope statement, and the reasoning behind everything you left out of it.
5. Leadership	Demonstrated top-management commitment, a documented AI policy, and assigned roles and authorities.	An approved AI policy with named owners, plus evidence that leadership reviewed it rather than signed it.
6. Planning	AI risk assessment and treatment, AI system impact assessment, measurable AI objectives, and the Statement of Applicability.	The risk register, completed impact assessments, and an SoA where every inclusion and exclusion is justified.
7. Support	Resources, competence, awareness, communication, and controlled documented information.	Competence records for the people who actually operate your AI systems, not a generic training completion report.
8. Operation	Operational planning and control, executing the risk treatment and impact assessments, controlling changes and outsourced processes.	Change records tied to real releases, and evidence that supplier controls were in force during the audit period.
9. Performance evaluation	Monitoring, measurement, analysis, internal audit, and management review.	Internal audit reports that contain findings, and minuted management reviews that acted on them.
10. Improvement	Handling nonconformity, corrective action, and continual improvement.	A nonconformity log with closed actions and evidence that the correction actually worked.

Two clauses carry more weight here than in a generic management-system standard. Clause 6 and clause 8 are expanded to account for how AI affects individuals, groups, and society, which is why an impact assessment sits alongside the familiar risk assessment. If you are building that risk practice from scratch, ISO/IEC 23894, the companion AI risk management standard, gives you the method the clause assumes you already have. It is guidance rather than a certifiable standard, and it pairs with 42001 rather than competing with it. Our broader guide to running an AI risk management program covers the operating side.

Annex A: 38 controls across 9 objectives

Annex A contains 38 controls grouped under 9 control objectives, numbered A.2 through A.10. Annex B gives implementation guidance for each control, Annex C lists potential AI-related objectives and risk sources, and Annex D covers applying the AIMS across domains and sectors.

The ISO 42001 Annex A controls are where the standard stops being generic. Each objective, and the artifact that most reliably satisfies it:

Objective	Theme	The artifact that satisfies it
A.2	Policies related to AI	A published, versioned AI policy with a review date and subordinate policies it actually governs.
A.3	Internal organization	A responsibility map naming an owner per AI system, plus a working route for raising concerns.
A.4	Resources for AI systems	A documented inventory of the data, tooling, compute, and people each AI system depends on.
A.5	Assessing impacts of AI systems	Completed impact assessments per system, covering individuals, groups, and society.
A.6	AI system life cycle	Lifecycle gates with recorded sign-offs from design through verification, deployment, and operation.
A.7	Data for AI systems	Provenance records and stated quality criteria for the data each system was trained on and uses.
A.8	Information for interested parties	System documentation written for the people affected, and a channel for reporting problems.
A.9	Responsible use of AI systems	A stated intended use, documented foreseeable misuse, and monitoring records that show use stayed inside it.
A.10	Third-party and customer relationships	Agreements that allocate AI responsibilities across the value chain, in both directions.

The Statement of Applicability

The Statement of Applicability, or SoA, is the document that records which Annex A controls apply to your AIMS, which you excluded, and why. Unlike clauses 4 to 10, Annex A controls are applied selectively, driven by your risk assessment and impact assessments.

This is the standard's honesty test. An SoA that excludes A.6, A.9, and A.10 because they are hard produces a certificate that is technically valid and commercially worthless, because the first sophisticated customer who reads your SoA will notice that you certified the parts that were already done. Write exclusions you would be comfortable defending in a customer security review, not just to an auditor.

The AI system impact assessment

If you take one thing from this page that ISO 27001 did not prepare you for, take this. A security risk assessment asks what could happen to the organization. An AI system impact assessment asks what could happen to people: the individuals your system decides about, the groups it might treat unevenly, and the wider society it operates in.

The direction of the analysis is inverted, and so is the evidence. You are not documenting an asset and its threats. You are documenting a decision, who it lands on, what it does to them when it is wrong, and what you built to catch that. Teams with mature security programs consistently underestimate this piece, because none of their existing artifacts answer the question.

Scoping your AIMS: the decision that determines everything else

Scope decides your audit duration, your evidence volume, your cost, and whether the certificate means anything to the person reading it. Nobody selling audits will frame it as a tradeoff. It is one.

A narrow scope, say one product's recommendation model, certifies cleanly. It is fast, cheap, defensible, and it tells a customer almost nothing, because the AI system they are worried about is probably not in it. A broad scope, say every AI system capable of taking an action in production, is slower, costs more, and is the certificate that ends the security review.

Three questions to settle before you contact a certification body:

1. Which AI systems can take an action rather than produce an output? Anything that writes, sends, pays, provisions, or deletes belongs inside the boundary. If you exclude those, you have certified the safe half.
2. Where does your responsibility stop? You are a provider for what you build and a user for what you buy, and Annex A.10 expects you to say which is which for every system. Vague answers here produce findings.
3. Can you produce a current inventory of the systems inside the boundary? Not a spreadsheet someone updated for the kickoff. A current one. If the answer is no, your scoping problem is actually an inventory problem, and no auditor can help you with that.

Where ISO/IEC 42001 strains against autonomous agents

The standard is deliberately technology-neutral, which is a strength for durability and a genuine problem for anyone certifying an agent fleet. Read Annex A closely and you will find an implicit model of what an AI system is: an artifact that gets designed, verified, released, and then monitored. Agents violate that model in three specific places.

A.6 assumes a life cycle with releases. Lifecycle controls want design records, verification results, and deployment sign-offs. An agent's behavior surface is defined less by its code than by the tools it can reach and the instructions it receives. Grant it a new tool on a Tuesday and it can do something on Wednesday that no lifecycle gate ever reviewed, with no release and no diff. The lifecycle evidence an auditor samples describes a system that has since changed.

A.9 assumes a documented intended use. You are expected to state intended use and foreseeable misuse. An agent composes tool calls at runtime to satisfy a goal, and the specific composition is frequently something nobody enumerated. Intended use for an agent is not a paragraph, it is a boundary that has to be enforced while the agent runs. The practical form of that boundary is identity and authorization: agents have to be treated as first-class identities with their entitlements enforced at runtime rather than governed by a policy document. Our guide to governing AI agents at runtime covers how those controls are built, and non-human identities explains the identity model underneath them.

A.10 assumes a stable supplier boundary. Third-party controls expect you to know who your providers are and what you delegated to them. An agent that discovers tools at runtime, through a connector protocol or a registry, crosses that boundary continuously and without a purchase order. If your agents reach external tool servers, the tool layer is part of your AIMS scope whether you scoped it or not, and MCP compliance becomes part of the same conversation.

None of this makes ISO/IEC 42001 unsuitable for agents. It makes the evidence harder, which is the next section.

The evidence problem: what a Stage 2 auditor actually samples

Stage 1 reads your documents. Stage 2 samples your reality. Organizations rarely fail Stage 2 because their policies are bad. They fail because they cannot demonstrate that the policy was enforced on a specific system, on a specific day, inside the audit period.

For a model with a quarterly release cadence, that gap is closeable with diligence. For an agent fleet it is not, because the relevant facts are generated at runtime and disappear unless something records them. This is the matrix worth bookmarking:

Control theme	Stage 1 evidence (documents)	Stage 2 evidence (reality)	What produces it for an agent fleet
AI policy (A.2)	Approved, versioned policy	Proof the policy was enforced on real systems	Runtime policy decisions, logged with their outcome
Life cycle (A.6)	Lifecycle procedure and gates	Sign-off records for what is deployed today	Release and configuration history per agent, including every tool grant and revocation
Data (A.7)	Data governance procedure	Provenance for data a system actually used	Retrieval and data-access logs tied to specific runs
Responsible use (A.9)	Intended-use statement	Monitoring showing use stayed inside intent	Per-invocation records of what the agent did and which limits it hit
Third party (A.10)	Supplier register and agreements	Evidence the supplier boundary held	A record of which external tools and servers each agent called
Improvement (Clause 10)	Nonconformity procedure	Closed corrective actions with effectiveness evidence	Incident records traceable to the specific agent run that caused them

Read the right-hand column and the point becomes obvious. None of it is a document you write. All of it is a record your runtime either emitted or did not, and you cannot reconstruct it the week before the audit. That is the difference between a compliance project and a compliance capability, and it is why AI observability and agent audit logs stop being a nice-to-have the moment agents enter your AIMS scope. Our guide to how AI systems and agents get audited goes deeper on sampling and audit trails.

How ISO/IEC 42001 certification works

ISO 42001 certification follows the same two-stage pattern as every accredited management-system audit.

1. Gap analysis. Assess your current practice against clauses 4 to 10 and the Annex A controls you expect to apply.
2. Build and operate. Close the gaps, then run the AIMS long enough to generate records. You cannot audit a management system that has never run.
3. Internal audit and management review. Both are clause 9 requirements and both are audited. Skipping them is the most common self-inflicted Stage 1 finding.
4. Stage 1 audit. The certification body reviews your documentation, scope, SoA, and readiness, and tells you what will fail in Stage 2.
5. Stage 2 audit. The auditor tests effectiveness by sampling real systems and real records against the controls you claimed.
6. Certification. The certificate is issued for a three-year cycle.
7. Surveillance audits. Annual, narrower than Stage 2, aimed at whether the system is still running.
8. Recertification. A full audit at the end of the three-year cycle.

Choosing an accredited certification body

Not every certificate is equal, and this is the detail most guides omit. A certification body should be accredited by a recognized national accreditation body, and since 2025 there is a dedicated standard governing exactly that. ISO/IEC 42006:2025 sets the requirements for bodies providing audit and certification of AI management systems, adding AI-specific requirements on top of ISO/IEC 17021-1: auditor competence, how audit time is calculated, and what a certification document must say. Accreditation bodies are now transitioning their certification bodies onto it.

Practically: ask a prospective certification body who accredits them for ISO/IEC 42001 specifically, and whether their auditors' competence is assessed against 42006. An unaccredited certificate is a PDF. An accredited one is a claim someone else is standing behind.

Cost and timeline, honestly

Publicly cited figures cluster around four to nine months from a serious start to certificate, and roughly twenty to sixty thousand dollars in audit fees, with the lower end common for organizations already running ISO 27001. Treat that as an industry range rather than a quote, because no neutral body publishes audit pricing. Three variables move it more than anything else:

• Scope size - the number of AI systems inside the boundary drives audit days directly.
• Existing management-system maturity - an organization with a working ISO 27001 program already has clause 7, 9, and 10 muscle.
• Evidence readiness - whether your systems already emit the records Stage 2 samples, or whether someone has to go find them.

The internal effort almost always exceeds the audit fee. Budget accordingly.

ISO 42001 vs ISO 27001, ISO/IEC 23894, and the NIST AI RMF

These four get compared constantly and confused almost as often. They are not alternatives; they occupy different slots.

	ISO/IEC 42001	ISO/IEC 27001	ISO/IEC 23894	NIST AI RMF
Certifiable	Yes, accredited third-party certification	Yes	No, it is guidance	No, it is voluntary
What it governs	An AI management system	An information security management system	The process of managing AI risk	AI risk across an organization
What it demands	Clauses 4 to 10, selected Annex A controls, and AI system impact assessments	Clauses 4 to 10 and selected security controls	Guidance on applying risk management principles to AI	Four functions: govern, map, measure, and manage
Reach for it when	Customers or regulators need proof you govern AI responsibly	You handle information that must stay confidential and intact	You need a defensible method for the risk work 42001 assumes	You want a shared vocabulary for AI risk, especially US-facing

The ISO 42001 vs ISO 27001 question deserves a direct answer, because the reassuring version circulating on vendor blogs is misleading. An existing ISO 27001 program genuinely accelerates you: the clause structure is shared, your internal audit and management review processes transfer, and your document control already works. What does not transfer is the substance. The AI system impact assessment, the lifecycle controls in A.6, the data provenance requirements in A.7, and the responsible-use requirements in A.9 are new work with no ISO 27001 equivalent. Expect the management-system scaffolding to carry over and the AI-specific controls to be built from nothing.

For the two non-certifiable frameworks, go deeper on the NIST AI Risk Management Framework, published by NIST as a voluntary framework whose govern, map, measure, and manage functions map cleanly onto clause 6. AI RMF 1.0 is worth reading in full if you are building the risk practice. And ISO/IEC 23894 supplies the AI risk management method itself.

Should you certify?

Every page on this topic assumes the answer is yes, which is what you would expect from pages written by people who sell audits. Here is the honest version.

Certify when at least two of these are true:

• Customers ask about AI governance in security reviews, and deals slow down while you improvise an answer.
• You are a provider or deployer facing the EU AI Act and need a management system you can defend.
• You already run ISO 27001 successfully, so the marginal cost is the AI-specific work rather than the whole apparatus.
• Your AI systems take consequential actions that affect people, which means the impact assessment is work you should be doing regardless.

Wait when any of these are true:

• Your AI is a vendor feature you configure but do not control. Your scope would be nearly empty and the certificate would say almost nothing. Push the question to your vendor instead.
• You cannot produce a current inventory of your AI systems. Certifying a boundary you cannot enumerate fails at Stage 2, reliably. Fix the inventory first; it is a prerequisite, not a deliverable.
• Nobody owns it. A management system without a named, resourced owner passes its first audit and decays before the first surveillance visit. That is worse than not certifying, because you have now made a claim you are not maintaining.

An ISO/IEC 42001 implementation checklist

Ordered, because the order matters. Steps 1 and 2 are where programs are won.

1. Inventory every AI system, including the agents, the vendor features, and the internal tools nobody registered. Record who owns each one and what it can do.
2. Draw the AIMS scope using the three scoping questions above, and write down what you excluded and why.
3. Name an accountable owner for the AIMS with real authority, and owners for each AI system inside scope.
4. Write the AI policy, and make it specific enough that someone could violate it. A policy nobody can breach cannot be enforced.
5. Run the AI risk assessment using a documented method, then the AI system impact assessments for every system in scope.
6. Produce the Statement of Applicability with a justification for every included and excluded Annex A control.
7. Close the control gaps, prioritizing A.6, A.9, and A.10 if your scope contains agents, because that is where the evidence is thinnest.
8. Wire up evidence generation so the runtime records in the Stage 2 column of the matrix above exist by default. Retrofitting this is the single most expensive mistake in the program, and it is where an AI compliance platform earns its keep.
9. Run an internal audit and a management review, and let them produce real findings. An internal audit with no findings tells a Stage 1 auditor that your internal audit does not work.
10. Engage an accredited certification body, confirm their accreditation covers ISO/IEC 42001, and schedule Stage 1 only once the AIMS has been running long enough to have a record.

Frequently asked questions

What is ISO/IEC 42001?

ISO/IEC 42001 is the international standard specifying requirements for an artificial intelligence management system (AIMS). Published in 2023 by ISO and IEC, it applies to organizations that develop, provide, or use AI, and it is the first AI standard supporting accredited third-party certification. It covers clauses 4 to 10 plus 38 Annex A controls.

Is ISO 42001 mandatory?

No. ISO/IEC 42001 is a voluntary standard, not a law. In practice it is becoming commercially mandatory in some markets, because enterprise customers increasingly ask for it in security reviews and regulated organizations use it to demonstrate the governed process that regulations such as the EU AI Act expect.

How many controls are in ISO 42001?

Annex A of ISO/IEC 42001 contains 38 controls grouped into 9 control objectives, numbered A.2 through A.10. Unlike clauses 4 to 10, which are mandatory, Annex A controls are applied selectively based on your risk and impact assessments, with your Statement of Applicability recording every inclusion and exclusion.

What is the difference between ISO 42001 and ISO 27001?

ISO 27001 governs information security; ISO/IEC 42001 governs artificial intelligence. They share the same clause structure, so an existing ISO 27001 program transfers the scaffolding. The substance is new: AI system impact assessments, lifecycle controls, data provenance, and responsible-use requirements have no ISO 27001 equivalent.

How long does ISO 42001 certification take?

Publicly reported timelines commonly run four to nine months from a serious start to certificate, shorter for organizations with a working ISO 27001 program. The two variables that move it most are the number of AI systems inside your scope and whether your systems already produce the evidence a Stage 2 auditor samples.

Does ISO 42001 make you compliant with the EU AI Act?

No. ISO/IEC 42001 is not a harmonised standard granting presumption of conformity under the EU's regulatory framework for AI; those are being developed separately by CEN-CENELEC JTC 21. An AIMS does produce many of the artifacts the Act's quality-management and risk-management obligations require, so it supports compliance without satisfying it.

What is ISO/IEC 42006?

ISO/IEC 42006:2025 sets requirements for the bodies that audit and certify AI management systems, extending ISO/IEC 17021-1 with AI-specific rules on auditor competence, audit time, and certification documents. It is why an accredited ISO 42001 certificate is now meaningfully comparable between organizations.

Keep going

• AI governance - the parent discipline: what governing AI and autonomous agents involves beyond any single standard.
• ISO/IEC 23894 - the companion AI risk management standard that supplies the method clause 6 assumes you have.
• NIST AI Risk Management Framework - the voluntary US framework whose govern, map, measure, and manage functions map onto 42001's planning clauses.
• EU AI Act compliance - the regulation driving most 42001 programs, and where the two genuinely connect.
• AI audit - how AI systems and autonomous agents are actually audited, including sampling and audit trails.
• AI agent governance - the runtime controls that make Annex A's responsible-use requirements enforceable rather than aspirational.
• AI observability - how agent audit logs get generated, which is where your Stage 2 evidence comes from.

ISO/IEC 42001 rewards organizations that can prove what their AI systems did, not the ones with the thickest policy binder. For models on a release cadence, that proof is assembled. For agents that decide their own next action, it has to be emitted while they run, and the record has to be complete enough that an auditor can sample it a year later. If your AIMS scope includes agents, see how agen.co produces accountability and audit trails for agent actions continuously, so Stage 2 becomes a query rather than a scramble.