ISO 42001 Explained: Requirements, Certification and What Your Engineering Team Must Build 

ISO 42001 is the international standard that demonstrates your organisation governs AI properly, and enterprise customers are starting to ask for it. 

An AI policy can be signed off in a fortnight. The controls it promises, such as model monitoring, data lineage, and release approvals, must already be running in production before an auditor accepts them. That work falls to infrastructure teams who are already committed to the roadmap. 

This guide sets out the requirements engineers will own, how ISO 42001 sits alongside ISO 27001 and the EU AI Act, and a four-phase route to certification. 

What Is ISO 42001, and Does It Apply to Your Company?

ISO 42001 is a certifiable standard for running an AI management system (AIMS). The auditor does not grade your models. They check whether your organisation has the policies, owners, risk processes and technical controls to manage AI from design to retirement.

Your AI is in scope if your teams:

• Train or fine-tune models
• Ship product features built on AI
• Call an external model through an API
• Use AI tools to make decisions about customers or staff

ISO 27001 teams start ahead. Both standards use the ISO Harmonised Structure, with the same clauses 4 to 10. Document control, internal audit and management review carry straight over. The new work is in risks that ISO 27001 never asked about: bias, transparency, explainability, human oversight and the impact of AI decisions on people.

Since March 2026, the standard has also existed as EN ISO/IEC 42001:2026, the European adoption. UK suppliers can now point to one standard in both domestic and EU tenders.

Why Your Next Enterprise Deal May Depend on ISO 42001 Certification

ISO 42001 is moving from governance teams into procurement checklists. Three forces are driving that shift.

The commercial risk is easy to underestimate. If a security review stalls on AI governance, the deal stalls with it.

ISO 42001 Requirements: The Four Areas Auditors Will Test

The clauses define how the management system runs. Annex A lists the reference controls. Auditors test both across four areas.

AI Policy and Leadership Accountability

What the auditor checks: A signed AI policy, defined roles and a budget behind the work.

Where to start: Name one accountable executive for AI governance and one owner for each AI system in your inventory.

AI Risk Assessment and AI Impact Assessment

What the auditor checks: Two separate assessments. The risk assessment covers threats to the organisation. The impact assessment covers effects on individuals, groups and society.

Where to start: Reuse your ISO 27001 risk method for the first assessment. The impact assessment needs a new template, because security teams rarely assess harm to people outside the company.

AI System Lifecycle Controls

What the auditor checks: Controls at every stage, from requirements and design through data preparation, testing, deployment, monitoring and retirement.

Where to start: Pick your highest-risk production model and document its lifecycle end to end. Gaps found there will repeat across other systems.

Third-Party and Supplier AI Management

What the auditor checks: How you assess AI risk in suppliers and how you split responsibilities with customers.

Where to start: Add AI-specific questions to your supplier review. Ask how the vendor trains, updates and monitors the models you depend on, and whether your data is used to train them.

The ISO 42001 Controls Your Compliance Dashboard Cannot Build

Legal and GRC teams can write the AI policy, the risk method and the supplier questionnaire. Much of Annex A, however, only passes an audit once it runs in your infrastructure.

What Drata and Vanta do well:

• Collect evidence from connected systems
• Track control status and flag gaps
• Keep policies, owners and review dates in one place

What your engineers still have to build:

• A model registry with versioned, reproducible training runs
• Pipeline gates that block unapproved models and prompts from production
• Logging that records what each AI system did and when
• Monitoring rules that detect when model behaviour changes
• A tested response route for AI failures

The platform reports on controls, but it cannot create them. When nobody owns the engineering list, the dashboard turns green on policy evidence while production runs unchanged.

A practical test: For each Annex A control, name the system that produces its evidence automatically. Any control without an answer is a manual task that is likely to fail during the audit.

Autonomous agents raise the bar further, because they act on systems rather than only answer questions. This guide to agentic AI governance covers the oversight controls agents need before they reach production. 

ISO 42001 vs ISO 27001 vs SOC 2: Which Do You Need?

Each framework answers a different buyer question. ISO 27001 shows you protect information. SOC 2 shows your security controls have been independently tested against US criteria. ISO 42001 shows how you govern your AI’s behaviour.

Choose based on who is asking:

1. UK or EU enterprise buyers asking about security → ISO 27001
2. North American customers asking for an audit report → SOC 2
3. Any buyer asking how you control your AI → ISO 42001, ideally built on top of ISO 27001
4. A mix of all three → one integrated control set, mapped to each framework

The fourth option saves the most effort. Access control, logging, change management and supplier reviews can serve all three frameworks when they are designed once and mapped three ways. Separate programmes mean separate evidence, separate owners and duplicated audit preparation.

Holding SOC 2 or ISO 27001 already? Neither will answer an AI governance questionnaire on its own. Treat ISO 42001 as an extension of the controls you have.

Regulated sectors carry the heaviest overlap. See how ISO 27001 applies to AI in finance for a sector example.

Does ISO 42001 Make You EU AI Act Compliant? (Not Quite)

No. ISO 42001 certifies a management system. The EU AI Act places legal duties on specific providers, deployers and AI systems. The standard has not been harmonised under the Act, so a certificate gives no legal presumption of conformity.

It still covers much of the groundwork. Risk assessments, system records, human oversight and post-deployment monitoring built for ISO 42001 feed directly into the technical documentation the Act expects.

Three rules for UK companies selling AI into the EU:

1. Classify before you certify. Identify which of your systems fall into the Act’s high-risk categories. That classification decides how much work sits outside ISO 42001.
2. Plan the gaps separately. The standard does not cover conformity assessment, CE marking or EU database registration for high-risk systems. Give each one its own owner and deadline.
3. Watch your wording. Present the certificate as evidence of AI governance. Never present it as proof of legal compliance in sales decks, tenders or website copy.

On timing: the Digital Omnibus on AI entered into force on 27 July 2026 as Regulation (EU) 2026/1744. Obligations for standalone high-risk systems under Annex III now apply from 2 December 2027. That is a workable window for organisations already building an AIMS, and a tight one for those starting from zero. 

ISO 42001 Implementation: A Four-Phase Roadmap That Protects Your Product Team

Phase 1: Inventory and Scope

List every AI system you build, deploy or buy. Include tools that individual teams adopted without formal approval. Then decide which systems the AIMS will cover first.

Done when: An AI register with an owner for every system.

Phase 2: Gap Analysis

Compare current practice with each clause and the relevant Annex A controls. Sort every gap into one of two lists: policy gaps for GRC and engineering gaps for your platform team. An independent AI consulting review can speed up both phases.

Done when: Two prioritised backlogs with named owners.

Phase 3: Build the Controls

Work through the engineering backlog, starting with your highest-risk systems. Define controls as code wherever possible, so each deployment produces its own audit evidence.

Done when: Controls are running in production and evidence is collected automatically.

Phase 4: Audit and Certify

Run an internal audit and a management review, then close the findings. Book the Stage 1 documentation review and the Stage 2 certification audit with an accredited body.

Done when: A certificate and a surveillance plan for the years that follow.

Where product teams get hurt: Phase 3. It usually lands on the infrastructure team that already ships your features. Compliance tickets slip behind release work, audit dates move, and the gap between documented and working controls grows with every sprint. Ring-fence Phase 3 with a dedicated team or an external partner, and the product roadmap stays on track.

Short on Engineering Capacity? When an ISO 42001 Partner Pays Off

Bring in outside help when:

• A customer deal or tender has a certification date attached
• Policies are signed off, but no engineer owns the controls behind them
• You already hold ISO 27001 or SOC 2 and want ISO 42001 to extend those controls and not duplicate them

Deployflow supports ISO 42001 implementation through a fixed-rate engagement of three to four months. The focus is the engineering work your infrastructure team would otherwise fit around feature delivery. Certification itself always comes from an independent, accredited body.

Your auditor will ask for proof. Bring your AI policy to the AI engineering team and leave with a three-to-four-month plan to make every line of it true in production.

ISO 42001 Frequently Asked Questions