ISO 42001 compliance: a practical guide

ISO/IEC 42001:2023 is the first international standard for an AI management system (an AIMS). If you've met ISO 27001 for information security, the shape is familiar: it isn't a checklist of technical controls so much as a way to run the part of your organization that builds and operates AI — with clear ownership, risk thinking, documented decisions, and evidence that the system does what you say it does. Certification is a third party confirming you actually run it that way.

This guide is the practical version: what the standard asks for, the path to certification, the part everyone underestimates (evidence), and how to make that evidence a by-product of running your AI rather than a binder you assemble the week before an audit.

Why it matters now

Three forces are converging. Buyers in regulated sectors increasingly put AI governance questions in their procurement and vendor-risk reviews — and "we're careful" doesn't survive a security questionnaire. Regulators are formalizing expectations; the EU AI Act, in particular, asks high-risk systems for risk management, data governance, logging, human oversight, and transparency — the same muscles ISO 42001 builds. And boards want assurance that the AI their teams are shipping won't become tomorrow's incident. ISO 42001 gives all three a recognizable answer: an auditable management system instead of good intentions.

For an organization without an in-house AI team, that's the trap — the expectation arrives before the capability does. The standard is achievable, but only if governance is built into how the AI runs, not bolted on after.

How the standard is organized

ISO 42001 follows the same high-level structure as other ISO management standards. Clauses 4 through 10 are the management system; Annex A is a catalog of AI-specific controls you select from based on your risk.

• Clause 4 — Context. Define what your AIMS covers: which systems, which teams, which obligations (legal, contractual, ethical). Scope is where most programs quietly succeed or fail.
• Clause 5 — Leadership. Named accountability, an AI policy, and resources. Governance without an owner is a slogan.
• Clause 6 — Planning. Risk assessment and AI impact assessment — how a system could affect individuals and groups — plus objectives you'll actually measure.
• Clause 7 — Support. Competence, awareness, and documented information. The standard cares that decisions are written down and current.
• Clause 8 — Operation. Run the controls: the AI lifecycle, data management, third-party/supplier risk, and change control.
• Clause 9 — Performance evaluation. Monitoring, internal audit, and management review. You check yourself before a certifier does.
• Clause 10 — Improvement. Nonconformities get corrected, and the system gets better over time.

Annex A spans the lifecycle: impact assessment, data quality and provenance, roles and responsibilities, transparency to affected people, human oversight, security, and supplier governance. You don't implement all of it blindly — you justify which controls apply to your risk in a Statement of Applicability, the document a certifier reads first.

The path to compliance

A realistic program looks like this. It is iterative, not linear — but the order matters.

1. Scope the AIMS. Decide which AI systems and processes are in. Start narrow and real (one or two production systems) rather than boiling the ocean.
2. Assign ownership and write the policy. A named accountable owner and a short, honest AI policy beat a long one nobody follows.
3. Run risk and impact assessments. For each in-scope system, assess both organizational risk and impact on people. Document the reasoning — that reasoning is the deliverable.
4. Select controls and write the Statement of Applicability. Map Annex A to your risks; include what you do and, where you exclude a control, why.
5. Implement and operate the controls. Data governance, human-in-the-loop approvals, logging, access control, supplier review — running, not aspirational.
6. Generate evidence as you go. Logs, approvals, model and data records, change history. If you can't show it, to an auditor it didn't happen.
7. Internal audit and management review. Find your own gaps, fix them, and have leadership formally review the system.
8. Certification audit. A Stage 1 documentation review, then a Stage 2 audit of the system in operation, then surveillance audits to keep it.

The hard part: evidence

Almost every program underestimates the same thing. The policies are the easy 20%. The other 80% is proving — months later, for systems that have changed since — that the controls actually ran: that PII was handled the way the policy says, that a human approved the action the policy says needs approval, that you can reconstruct who did what and why.

When evidence is collected by hand, two things happen. It's incomplete (nobody logs the boring path), and it's a tax on every project. Teams quietly route around the controls to ship, and the binder drifts from reality — which is exactly the gap an auditor is trained to find.

Make compliance a by-product, not a project

The fix is structural: put the controls in the path the AI already takes, so the evidence is produced automatically. That's the idea behind a governed gateway — every AI request and action runs through one place that:

• strips PII at the boundary and enforces data-handling policy (Annex A data controls);
• parks external actions for human approval by policy (human oversight);
• authenticates and authorizes every call (access control);
• logs everything — prompt, decision, action, approver, model — into an immutable trail (your audit evidence);
• captures the impact assessment and model/data records alongside the systems they govern.

When the gateway is the only way the AI reaches your systems, the Stage 2 audit stops being a scramble. The evidence is the operational record. That's the difference between a compliance project you survive once and a management system you can actually run.

ISO 42001 alongside NIST and the EU AI Act

You don't pick one. NIST AI RMF gives you the best structure for doing the risk thinking (Govern, Map, Measure, Manage); ISO 42001 gives you the management system that makes it auditable; the EU AI Act sets the legal floor for high-risk systems. The work compounds: one impact assessment, structured with NIST and recorded for ISO, also answers the Act's risk-management and logging expectations. Build the governed substrate once and you're feeding all three. (We go deeper on this in NIST AI RMF and ISO 42001: two frameworks, one program.)

Common pitfalls

• Scoping too wide. An AIMS that covers "all AI everywhere" never reaches evidence. Start with what's in production.
• Policy without operation. A beautiful policy and no logs is the fastest way to fail Stage 2.
• Treating it as a one-time project. Surveillance audits are annual; a management system has to keep running.
• Manual evidence. If staying compliant taxes every project, teams route around it — and the binder drifts from reality.
• No named owner. Shared accountability is no accountability.

Where to start

Pick one production AI system. Define a tight scope around it, name an owner, run a real impact assessment, and route that system's AI traffic through a governed path so the evidence starts accumulating from day one. Get one system certifiable and the pattern — and most of the evidence machinery — extends to the next.

That's the model we run for organizations without an AI team: we stand up the governed substrate, do the risk and impact work with you, and operate it as a managed service so the AIMS stays real between audits, not just during them.