ISO 42001: The AI Management System Standard, Explained

Boards have started asking a question that most GRC teams weren't prepared for a couple of years ago: "What's our AI governance structure, and is there documentation to prove it?" The question sounds soft until a regulator or a large enterprise customer is the one asking. Then it lands differently.

ISO/IEC 42001:2023 was published by ISO in December 2023 to answer exactly that question with an auditable framework. It's the first international standard designed specifically for AI management systems, and certifications are starting to appear in enterprise RFPs and EU AI Act compliance programs. Here's how it actually works.

What the standard is — and isn't

ISO/IEC 42001 defines an AI Management System. The standard uses the acronym AIMS throughout, so that's worth knowing before you're in a room with an auditor. An AIMS is a documented system of policies, processes, and controls that governs how your organization develops, deploys, or uses AI systems responsibly over time.

The structural model will look familiar if you've been through ISO 27001. Both standards follow the Annex SL framework that ISO uses for management system standards, which means they share the same clause architecture from 4 through 10. If your team has already built an information security management system, the governance scaffolding of ISO 42001 is the same shape. What's different is the subject matter: instead of information security, you're building an AI governance system.

The standard is voluntary. No legislation currently mandates it the way GDPR mandates data protection programs. That context is shifting, which I'll cover when discussing the EU AI Act, but as of today, certification is a business decision, not a legal one.

One clarification worth getting right up front: ISO 42001 certification covers your management system, not individual AI systems. A certified AIMS means your organization has a documented, auditable governance program for AI. It does not mean each AI model or tool you deploy has been individually validated by ISO. Teams that conflate the two tend to get a nasty surprise in their first audit.

The clause structure and Annex A controls

The normative framework runs through Clauses 4 to 10 — same structure as ISO 27001 and ISO 9001:

• Clause 4 (Context): Define your organization's role in the AI value chain, map stakeholders, and set the scope of your AIMS.
• Clause 5 (Leadership): Top management must show visible, active commitment. This isn't a standard where the CISO runs a working group and the executive team gets a quarterly slide.
• Clause 6 (Planning): AI risk and impact assessments, plus measurable AI objectives aligned to organizational strategy.
• Clause 7 (Support): Resources, competence, awareness training, and documentation requirements.
• Clause 8 (Operation): The actual processes for developing, procuring, deploying, and monitoring AI systems under the AIMS.
• Clause 9 (Performance Evaluation): Internal audits and management reviews to verify the system is working.
• Clause 10 (Improvement): Nonconformities, corrective actions, and the continuous improvement cycle that keeps the AIMS from becoming a static binder on a shelf.

Annex A contains 38 reference controls across eight sections. Key areas include AI policy (A.2), AI risk and impact assessment (A.5 and A.6), AI system lifecycle management (A.7), data governance (A.8), and supplier management for third-party AI systems (A.10). Unlike ISO 27001, where Annex A is normative, ISO 42001's Annex A is formally a reference set. That said, every accredited certification audit expects a Statement of Applicability showing which controls apply, which are excluded, and the reasoning behind each exclusion.

Provider, user, or both?

One thing ISO 42001 gets right is acknowledging that organizations relate to AI in fundamentally different ways. The standard explicitly distinguishes between:

• AI providers — organizations that develop or supply AI systems, models, or AI-powered products
• AI users (deployers) — organizations that deploy or operate AI systems built by others

Many companies sit in both categories simultaneously. A SaaS company using a third-party LLM API is a user relative to the API provider and a provider relative to its own customers. The impact assessment controls in Annex A address this, requiring deployers to evaluate procured AI systems against minimum documentation standards before deployment.

The supplier controls under A.10 deserve particular attention. Contracts with AI suppliers must include notification obligations for significant changes, performance guarantees, and audit rights. If your current vendor agreements for AI services don't include this language, that's a gap the auditor will find. It's also where AI governance and vendor risk management start to overlap — the AI systems you buy are part of your risk surface, not outside it.

How it fits with the EU AI Act

ISO 42001 and the EU AI Act are appearing together in compliance discussions constantly. The relationship is complementary, but it's worth getting the distinction right.

The EU AI Act is binding legislation. Violations carry fines up to €35 million or 7% of global annual turnover for the most serious breaches. It applies to any organization that places AI systems on the EU market or whose AI outputs affect people in the EU, regardless of where the company is based. The Act's requirements for high-risk AI systems include conformity assessments, technical reliability and accuracy standards, human oversight mechanisms, and detailed documentation of training data.

ISO 42001 is a voluntary management system standard. What it provides is a structured, auditable governance framework that maps to many of the organizational and process requirements the EU AI Act expects: risk assessment, lifecycle documentation, controls on AI system behavior, supplier oversight. Organizations with a functioning AIMS have structured evidence of the governance practices the Act wants to see.

The honest framing: ISO 42001 is useful supporting infrastructure for EU AI Act compliance, not a substitute for it. The Act's technical requirements for high-risk systems go beyond what an AIMS covers. Treat certification as answering the governance and process questions, then plan separate work for the Act's technical obligations.

Who should pursue certification, and when

Certification makes practical sense when AI governance is a differentiator or a documented customer requirement. The clearest cases:

• AI vendors and API providers selling into regulated industries, where enterprise customers want demonstrable governance from their AI supply chain
• Organizations already certified to ISO 27001 that want to extend formal governance to cover AI — the shared framework structure cuts implementation time considerably, because the risk processes, audit cadence, and management review cycles already exist
• Companies building products subject to EU AI Act high-risk provisions, where an AIMS provides a structured home for the compliance evidence that needs to be maintained
• Public sector organizations where formal AI governance documentation is expected for procurement or oversight

For a startup using an off-the-shelf LLM for a non-critical internal feature with no enterprise customers asking for governance documentation, certification is premature. The operational overhead of maintaining an AIMS needs justification from actual business or regulatory demand.

For teams that already have ISO 27001, the implementation lift is shorter than it looks. The documented risk processes, management review cycles, and internal audit schedules carry over. You're adding AI-specific scope and controls to a system that already runs. Organizations without existing management system infrastructure face a steeper ramp — building governance processes from scratch adds significant time and internal effort before an audit can be scheduled. Timelines for those starting from zero tend to run considerably longer than for teams extending an existing ISO footprint.

Where to start

Before engaging a consultant or requesting quotes from certification bodies, spend an afternoon mapping your AI systems. What does your organization develop internally, what do you deploy from third parties, who is affected by each system, and what documentation currently exists for any of them?

That inventory tells you more about your AIMS readiness than any framework description. A long list of deployed AI tools with almost no documentation is also a useful result. It's not a failure — it's a gap list, and Clause 4 is where you start addressing it.

The frameworks hub has coverage of the other standards your AI governance program is likely to intersect with, including the EU AI Act and ISO 27001.

Get the templates we actually use.

One practical email a week: a new template, a teardown of a real framework requirement, and the occasional honest tool review. No fluff, unsubscribe anytime.

Send me the templates

No spam. Unsubscribe in one click.