ISO 42001 in practice: what most companies get wrong about AI governance.

Somewhere in your pipeline right now there is an enterprise buyer with a new row in their security questionnaire: "Describe your AI governance framework. Are you ISO 42001 certified or aligned?" A year ago that row didn't exist. Today the honest answer at most startups is "we have a responsible AI page on the website," and procurement teams have learned that this means nothing.

ISO/IEC 42001 is the standard that row is pointing at. It's worth understanding what it actually asks for, because most of the AI governance work I see companies do wouldn't pass a first internal audit against it, and not because the standard is hard.

What ISO 42001 actually is

ISO/IEC 42001:2023 is a management system standard for AI, published in December 2023. If you've been through ISO 27001, the shape is familiar: the same high-level structure of clauses 4 through 10 (context, leadership, planning, support, operation, performance evaluation, improvement), plus an Annex A of controls, 38 of them across nine objectives, from AI policies and internal organisation through impact assessment, the AI system life cycle, data, transparency to interested parties, use of AI systems, and third-party relationships.

The word that matters is system. It's not a checklist of AI principles. It's a way of running AI in your organisation such that someone owns each system, its risks and impacts are assessed, its life cycle is controlled, and you can prove all of that to an outsider. That's the bar. Everything below is about companies aiming lower than it.

Mistake 1: treating it as an ethics document

The first thing most companies produce is a "Responsible AI Principles" page: fairness, transparency, accountability, human oversight. Good words. Not a management system.

A principles page has no scope, so nobody knows which systems it covers. It has no owner, so nobody is accountable when a principle is violated. It has no evidence, so nobody can show it was ever applied. When the enterprise buyer's security team asks "how do you assess the impact of a new AI feature before launch," the principles page has no answer, and the deal sits.

The fix is to write the boring documents the standard actually wants: an AI policy that says what you will and won't build and deploy, defined roles (who approves a new AI system, who owns it in production, who reviews incidents), an impact-assessment procedure, and a place where the results live. Principles can be the preamble. They can't be the whole thing.

Mistake 2: no inventory, so no scope

You cannot govern what you haven't listed. Ask most engineering leaders "how many AI systems are in production?" and the answer is the one or two customer-facing features they built. The real number is higher, and the gap is where the risk lives.

The inventory needs, at minimum, every one of these:

• Customer-facing AI features you built: the support assistant, the summariser, the recommendation engine.
• Internal agents and automations: the sales-research agent, the ticket triager, the thing someone wired to Slack last quarter. I build these for business teams and I can tell you they multiply quietly.
• AI inside your vendors' products: the CRM's AI notes, the meeting recorder's transcripts and summaries, the design tool's generation features. Your customers' data flows through these whether you "use AI" or not.
• Model and provider dependencies: which foundation models, from which providers, under which data-use terms, with what retention.

For each: an owner, the data it touches, the provider, whether a DPA and data-use terms are on file, and a risk tier. This inventory is the scope statement of your AI management system. It's also the single most useful artefact in enterprise due diligence. When a buyer asks "do you send our data to third-party AI providers," you want to answer from a table, not from memory.

Mistake 3: governance in one room, security in another

The third pattern: a governance working group writes policy while the engineers shipping LLM features never hear about it, and the security team treats the AI features like any other web app. Meanwhile the actual failures happen at the seams.

Prompt injection through a support ticket body. An agent with a refund tool and no spend limit. Customer PII sitting in model traces because nobody thought of the observability platform as a data store. A vendor LLM with a default that trains on your inputs. These are AI-system life-cycle controls in ISO 42001 terms, and they're security findings in anyone's terms. The two conversations have to be the same conversation.

Practically, that means three things. First, use NIST AI RMF's four functions, Govern, Map, Measure, Manage, as the assessment structure for each system in the inventory; it maps cleanly onto 42001's impact assessment and life-cycle controls and your engineers will find it more concrete than the ISO text. Second, add an LLM application security review to the impact assessment: direct and indirect injection, data leakage into logs and traces, tool-call boundaries, agent permissions, output handling. Third, run it inside your existing ISMS if you have one. One risk register, one internal audit, one management review. ISO 42001 was designed to be integrated with 27001; running them as separate programs doubles the work and halves the credibility.

What an honest implementation looks like in 90 days

You do not need certification to answer the buyer's question well. You need a working system and evidence. Ninety days is enough for a first version.

1. Weeks 1–2: inventory. Every AI system, internal and external, with owner, data, provider and tier. Interview engineering, sales ops, support and marketing; the shadow inventory lives there.
2. Weeks 3–4: policy and roles. One AI policy people will actually follow. Approval path for new AI systems. Named roles. Acceptable-use rules for staff using external AI tools with company data.
3. Weeks 5–8: impact assessments on the top three systems. Highest tier first, using the NIST AI RMF structure. Include the security review. Each assessment ends with findings, owners and dates.
4. Weeks 5–8, in parallel: vendor terms. DPAs and data-use terms for every AI provider. Turn off training-on-inputs where it's on. Document retention.
5. Weeks 9–10: fix the findings that matter. Scope the refund tool. Redact PII from traces. Add the injection tests to CI. Ship it with the engineers, not around them.
6. Weeks 11–12: management review and the due-diligence pack. Leadership reviews the inventory, the assessments and the open risks. Write the two-page summary that answers the questionnaire row and attach the evidence.

At the end of that you have an AI management system in the sense the standard means, at the size your company actually is. Certification, if you want it, is a gap review and an external audit away, not a rebuild.

When to actually certify

Certify when it changes a commercial outcome. Three situations where it does: enterprise or public-sector buyers are asking for the certificate rather than the alignment; you sell into the EU and your systems land in a category where a recognised management system materially helps your conformity story; or you already hold ISO 27001 and your registrar can run an integrated audit, which makes 42001 an increment rather than a project.

Otherwise, build the system, gather the evidence, and say plainly that you're aligned and not yet certified. Buyers' security teams respect that far more than a certificate bought over a management system nobody runs.

The bottom line

ISO 42001 is not asking you to have opinions about AI. It's asking you to know what AI you run, to have someone own each piece, to assess what could go wrong before it ships, and to be able to prove all of that. Inventory, owners, evidence. Companies that start there have a governance program in a quarter. Companies that start with a principles page have a principles page.

You cannot govern what you haven't listed, and you cannot prove what nobody owns.