ISO 42001 vs the EU AI Act: what to say when an auditor asks

A customer's security questionnaire lands in your inbox. Buried in the AI section, between questions about model providers and data retention, is one line: "Are you ISO/IEC 42001 certified?" Someone on the team assumes that's just the EU AI Act by another name and moves on. It isn't, and treating the two as interchangeable is exactly how a QA or compliance lead ends up answering a follow-up question they weren't ready for.

ISO/IEC 42001 and the EU AI Act both showed up in the same two-year window, both talk about "AI risk," and both get cited in the same procurement emails. Past that, they don't do the same job. One is a certifiable management-system standard you can choose to adopt. The other is binding law with fines attached. This is about where each one actually applies, where the two actually line up, and what to say the next time someone asks if you "have 42001."

What ISO/IEC 42001 actually is

ISO/IEC 42001:2023 is a management system standard, in the same family as ISO 27001 (information security) and ISO 9001 (quality). It's the first international standard for what it calls an AI management system, or AIMS: the policies, roles, risk processes, and continuous-improvement loop an organization runs around how it builds or uses AI. It follows the same Plan-Do-Check-Act structure as its ISO siblings. You define objectives and risk criteria, run the processes, check whether they're working, and adjust.

Two things about it matter more than the acronym. First, it's voluntary. No government requires it. Second, it's certifiable: an accredited third-party auditor can review your AIMS against the standard's clauses and issue a certificate, the same way a SOC 2 or ISO 27001 audit works. That certificate says something specific: your organization runs a documented, repeatable process for governing AI. It doesn't evaluate any particular AI system against any particular legal requirement. It evaluates whether you have a functioning management system wrapped around AI generally.

That's also its real value. Most engineering orgs building AI features don't have a documented risk process for it at all. ISO 42001 gives you a template: define AI-specific risks, assign owners, log decisions, review on a cadence. Getting that structure in place is useful independent of any regulation, the same way ISO 27001 is worth having even for a company with no legal security mandate.

What the EU AI Act actually is

Regulation (EU) 2024/1689, the AI Act, is a different kind of object entirely. It's binding EU law, not a standard you opt into. It doesn't certify your management practices. It classifies individual AI systems into risk tiers, from banned outright down to unregulated, and attaches specific legal obligations to each tier: risk management, data governance, technical documentation, logging, human oversight, and a conformity assessment before a high-risk system goes to market. We cover the tiers and how to place a feature in them in our classification guide.

And it has teeth. Article 99 sets fines up to €35 million or 7% of global annual turnover for the banned practices, and up to €15 million or 3% for most other high-risk violations, whichever is higher. ISO 42001 has no penalty regime at all. The worst outcome for failing an ISO audit is that you don't get the certificate. The worst outcome for shipping a high-risk AI system in the EU without the Act's required documentation is a fine that scales with your revenue.

Side by side

Where they genuinely overlap

This isn't a case of two unrelated frameworks that happen to share a topic. ISO 42001's risk-management clauses map fairly closely onto what Article 9 of the AI Act requires: a risk management system that runs across the AI system's lifecycle, with defined criteria, documented decisions, and periodic review. An organization that's already running an AIMS has done most of the process work the Act expects. It has a place to log AI risks, an owner for each one, and a review cadence, instead of scrambling to invent all three under deadline pressure.

There's also a formal path where ISO-style standards could matter directly. Article 40 of the Act lets the European Commission request harmonised standards, and once a standard is published in the Official Journal, a system built to it gets a legal presumption of conformity with the corresponding Act requirements. CEN-CENELEC's Joint Technical Committee 21 is the body drafting those standards now, including a dedicated quality-management standard for AI Act purposes. ISO 42001 isn't that harmonised standard. It's a separate, earlier document that the European standards bodies are drawing on, not a stand-in for it.

Where ISO 42001 stops covering you

Here's the gap that catches teams out. Certification under ISO 42001 doesn't classify your systems into the Act's risk tiers. It doesn't tell you whether your CV-screening feature lands on the Annex III list, or whether it qualifies for the Article 6(3) exemption. That classification work is legal analysis specific to what your system does, and no management-system audit substitutes for it. We wrote a full walkthrough of that classification process in this guide, and it's work you still have to do with or without a 42001 certificate on the wall.

It also doesn't satisfy the Act's system-level requirements on its own: the conformity assessment for a specific high-risk system, the technical documentation tied to that system, the automatic logging built into it, the human-oversight mechanism that actually works for that use case. ISO 42001 audits your governance process. The Act cares about the individual product. You can have an excellent AIMS wrapped around a system that still hasn't done its Article 9 risk assessment or its Annex IV technical file.

And it doesn't resolve the legal questions the Act asks that have nothing to do with governance maturity: are you a provider or a deployer, does your use case fall under Annex III, did you accidentally inherit provider obligations by fine-tuning a foundation model. Those are determinations for whoever owns compliance at your company to make, not something an ISO auditor rules on. Our piece on who owns EU AI Act compliance goes into how that work typically gets split across legal, engineering, and QA.

So what do you say when someone asks "do you have 42001?"

If you have the certificate, say so and mean it: it's a real signal that your AI governance isn't improvised. But don't let it answer a question it wasn't built to answer. A customer or auditor asking about 42001 is usually really asking "can I trust how you handle AI risk," and the certificate is genuine evidence toward that. It isn't evidence that a specific high-risk feature has been classified, documented, and conformity- assessed under the Act. Those are two separate asks, and a sharp auditor will eventually ask both.

If you don't have the certificate, that's not automatically a compliance gap either. Plenty of companies are fully on top of their EU AI Act obligations without ever pursuing ISO 42001. The certificate is a governance signal, not a legal gate. What matters legally is whether each in-scope AI system has been classified, documented, and tested to the standard its risk tier demands, which is a system-by-system exercise regardless of what certifications sit above it.

The practical order of operations for a QA or engineering team: classify your AI features against the Act first, because that determines what's legally required and by when. Treat ISO 42001 as an optional governance layer on top, useful for procurement conversations and for giving your risk process a proven shape, but not a substitute for the classification and testing work underneath. Dividing that work across legal, engineering, and QA is a reasonable next stop either way.

Whichever framework you're answering to, the thing an auditor or a customer ultimately wants is evidence: that a given AI feature was tested against defined criteria, that the results were recorded, and that the record didn't quietly disappear after thirty days. That's the layer qtrl sits on. Test plans, execution history, and results stay linked and auditable, so whether the question is "show me your 42001 process" or "show me how you validated this high-risk system," the record is already there instead of reconstructed the night before.

If your team is trying to get its AI testing evidence into shape for either conversation, see how it works.