ISO 42001 is the management system your AI Act file will lean on

The question arrives from a buyer, and it is getting more common: "what is your AI governance framework?" The answers teams give are a policy document written last quarter, a link to the model provider's safety page, or silence.

ISO/IEC 42001 is the standard that gives you a real answer. It specifies an artificial intelligence management system, in the same family and the same shape as ISO 27001's information security management system. That framing matters more than any individual clause, because it tells you what the standard is and is not.

It is not an assessment of whether your model is accurate, fair or safe. It is an assessment of whether you have a repeatable system for deciding those things, evidencing the decisions, and improving when you get them wrong. Auditors check the system, not the model.

What you already have, if you hold ISO 27001

If you run a certified information security management system, the reusable portion is large and it is the reason the incremental cost is manageable.

The high-level structure is shared across ISO management system standards: context of the organisation, leadership, planning, support, operation, performance evaluation and improvement. So your scope definition, leadership commitment, competence and awareness process, documented information control, internal audit programme, management review and corrective action process transfer with edits rather than rewrites.

What is new is the content: the AI-specific controls, the impact assessment, and the fact that your risk register now has to consider harms to people and society rather than only harms to the organisation. That last shift is the one that takes teams longest to absorb. An information security risk assessment asks what could happen to us. An AI impact assessment asks what our system could do to someone.

The Statement of Applicability habit transfers directly, and it is the artefact that makes the whole thing auditable, exactly as described in the Statement of Applicability. One row per control, applicable or not, with the justification written down.

The parts that are genuinely new

The AI system inventory. You cannot govern what you have not listed. One row per AI system, including the ones bought rather than built, with its purpose, the data it uses, who owns it, and its risk classification. Almost every organisation discovers systems it had forgotten, usually in HR tooling, support automation and a script someone wrote.

Impact assessment. A documented assessment of consequences for individuals and groups, covering the foreseeable misuse as well as the intended use. This is the artefact that most directly serves double duty for regulation.

Data governance for AI. Provenance of training and evaluation data, known limitations and gaps, bias examination, and the lineage that lets you answer where a model's behaviour came from. If you fine-tune or train, this is substantial. If you only call a provider's model, it is smaller but not zero, because your retrieval corpus and your evaluation set are data with the same questions attached.

Lifecycle controls. Objectives set before development, verification and validation before release, documented deployment decisions, and monitoring in production with defined triggers for retraining or withdrawal. The last part is where teams are weakest: a model quietly degrading is a normal occurrence and most organisations have no defined response to it.

Supplier management for model providers. Your model vendor is a supplier with specific questions attached: what they do with your inputs, whether they train on them, what their own documentation says, and what happens when they deprecate a version.

Human oversight and transparency. Who reviews what, with what authority to override, and what users are told about the system's role and limits.

Where it meets the AI Act, and where it does not

The relationship is genuinely useful and routinely oversold, so be precise.

ISO 42001 gives you the management system, the documentation discipline and much of the evidence that the AI Act's provider obligations require: risk management across the lifecycle, data governance, technical documentation, human oversight design, and post-market monitoring all have a home in it.

What it does not give you is a presumption of conformity. Under EU product law, that comes from harmonised standards published in the Official Journal, and the standardisation work for the AI Act is being carried out by the European bodies. ISO 42001 is an international standard, not a harmonised European one, so certification is evidence of a mature system rather than a legal shortcut. Anyone telling you that ISO 42001 certification makes you AI Act compliant is selling something.

The honest framing for a buyer or a board: certification demonstrates you have a governed process, and it substantially reduces the work of assembling the regulatory file. The obligations themselves are in the regulation, and the way they translate into engineering work is in the EU AI Act, translated into engineering work.

The same mapping logic applies here as everywhere else. One control set, several frameworks, as argued in one control set across frameworks. Your access control evidence serves ISO 27001, SOC 2 and 42001 simultaneously, and maintaining three parallel programmes is how compliance becomes hated.

Is it worth certifying

Certify if you sell AI-enabled products to enterprise or public sector buyers in Europe, if procurement questionnaires are already asking and costing you deal time, or if you are a provider of a high-risk system under the AI Act and want a defensible structure for the file you will have to produce anyway.

Do not certify if AI is a small internal efficiency tool, if nobody is asking, or if you do not yet have an information security management system. In that last case, do ISO 27001 first. Building 42001 on nothing means building the whole management system machinery for the AI use case alone, which is the expensive order.

The middle path is real and underused: implement against the standard, produce the inventory, the impact assessments and the Statement of Applicability, and do not pay for certification until a buyer requires the certificate. You get the governance benefit and the evidence, and you defer the audit fee.

What people get wrong

• Treating it as a model evaluation. The auditor will ask for your process and your records, not for your benchmark scores.
• Scoping it to the whole company. Scope it to the AI systems, exactly as you scope an information security management system to a defined boundary.
• Forgetting bought AI. The ranking feature in your recruitment platform is in your inventory even though you did not build it.
• Writing the impact assessment once. It has to be revisited when the purpose, the data or the model changes, and a model provider's version bump is a change.
• No owner. An AI management system without a named accountable person is a folder of documents that ages.

What to do this week

Build the inventory: one sheet, one row per AI-touching feature including bought tools and internal scripts, with its purpose, its data, its owner and whether a person is affected by its output. That single sheet is the first artefact of the management system, the input to every impact assessment, and the thing you will need for the AI Act regardless of whether you ever certify. An hour with the engineering leads gets you most of it. We build it in the first week of an AI governance engagement.