DAY 2 — 4 Part Mini-Series: ISO Wrote the Exam. Your Organization Still Has to Sit It.
AI
NIST's AI RMF, which we covered yesterday, is voluntary — a common vocabulary for what "good" looks like, with nobody administering it and nobody failing it.
ISO/IEC 42001 is different in one specific, important way: it's the kind of document an auditor can show up and check you against. An organization can be certified to it. And that creates a very particular kind of risk — the risk of passing the exam without actually knowing the material.
Certification proves a process exists. It doesn't prove the process is any good. To see why, and what that gap actually looks like in practice, I read the standard with the same three lenses I did for NIST: governance, architecture, and executive accountability. Each one exposes the same underlying design choice from a different angle.
What ISO/IEC 42001 Actually Is
ISO/IEC 42001:2023, "Information technology — Artificial intelligence — Management system," was published in December 2023 and applies to any organization, of any size or type, that develops, provides, or uses products or services built on AI systems — which is to say, almost everyone reading this.
The detail that matters most: this is a management system standard, built on the same harmonized clause structure as ISO 9001 (quality) and ISO/IEC 27001 (information security). If your organization already holds either certification, ISO/IEC 42001 is designed to bolt on rather than start from scratch.
A management system standard doesn't hand you a list of technical fixes. It requires you to have a system — a policy, defined objectives, assigned roles, a risk process, a way of checking whether that process is working, and a commitment to keep improving it. That's a different kind of document than a technical control list, and it explains almost everything else about how the standard behaves.
How It Actually Functions
Seven core clauses, numbered 4 through 10, carry the weight: Context (what's your role — provider, user, developer, partner?), Leadership (top management sets AI policy and assigns authority — not delegable, more on that below), Planning (the engine room: risk criteria, AI risk assessments, a separate AI system impact assessment, documented objectives), Support (resources, competence, documentation), Operation (running all of the above on an ongoing basis), Performance evaluation (monitoring, internal audit, a management review top management conducts itself), and Improvement (continual improvement plus a formal nonconformity process).
Four annexes sit underneath, and the difference between them matters more than it sounds like it should. Annex A is a set of reference controls — 38 of them, grouped into categories like AI policy, resourcing, impact assessment, the AI system life cycle, data, third-party relationships, and human oversight. Annex A is normative: if a control doesn't apply to you, you have to document why in a Statement of Applicability, and that justification has to come from your own risk assessment. Annex B gives implementation guidance for each control — practical detail on how you might actually do it — but you're explicitly not required to justify skipping it. Annex C is an informative list of organizational objectives and risk sources you might consider. Annex D explains how the AI management system integrates with other standards, like ISO/IEC 27001 or ISO 9001.
Put simply: NIST gave you outcomes and a vocabulary. ISO/IEC 42001 gives you a system to run, a set of controls to weigh, and a document trail to prove you ran it. That's real progress over "voluntary framework, do what you like." It's also where the harder questions start.
Reading It as Governance: What the System Requires vs. What It Actually Tests
Put on a governance hat, and the standard's honesty about itself becomes the whole story. Several of its own definitions and clauses openly acknowledge how much discretion the organization retains.
Take data quality. The standard defines it as data that "meet the organization's data requirements for a specific context." The standard requires the organization to define that bar. It does not, on its own, establish that the bar was demanding enough — that's left entirely to whoever wrote the requirement.
Or take the Statement of Applicability. An organization can exclude an Annex A control "where the controls are not deemed necessary by the risk assessment." That's a piece of self-referential discretion worth sitting with: the same risk assessment that determines necessity is the instrument used to justify skipping the control, and nothing in the clause requires an independent check on whether that risk assessment was rigorous in the first place. Only that it exists and is written down.
Or take governing body, a term the standard defines with an explicit note that "not all organizations, particularly small organizations, will have a governing body separate from top management." Board-level oversight of AI isn't a structural requirement here — top management can, in effect, govern itself.
None of this makes the standard weak. It's a defensible design choice for a document meant to span every industry and maturity level. But it means certification proves something specific and limited: a governance process exists and operates with documented discipline. It doesn't, by itself, prove the judgments inside that process are good ones — the thread this whole piece pulls on.
Worth naming a blind spot plainly, too: the standard's technical vocabulary is noticeably more generic than the risk language organizations now use for generative and agentic AI. The closest hooks are things like "continuous learning" systems and "level of automation" as a risk source — nowhere does the language reach the specificity of prompt injection, hallucination, or an autonomous agent taking a multi-step action on its own. If your AI estate in 2026 leans generative or agentic, you'll be doing real translation work to map your actual risks onto the standard's terms.
Reading It as Architecture: The Standard Doesn't Build Anything for You
Shift to an engineering lens, and the framing sharpens: ISO/IEC 42001 is a management system framework, not an engineering blueprint. It tells you a control has to exist — impact assessments, risk management, lifecycle documentation — and gives you no engineering specification for how to build it.
Left alone, that gap becomes a bottleneck of manual paperwork. The job for platform and architecture teams is to translate governance requirements into automated platform capabilities, so the compliant path is also the easy one. Mapped against the standard's own lifecycle and data controls, that translation lands on five areas: data lineage and provenance, the AI/model development and supply chain, evaluation and safety testing, deployment and runtime control, and observability and incident response. Some of the work in each can be automated — data hashing, experiment tracking, drift monitoring, secret rotation. Some genuinely can't be — the legal review of data rights, the decision to promote a model from staging to production, the initial red-team strategy.
The difference between those two states is easy to see side by side. One organization's "approved AI system" is a PDF impact assessment sitting in a governance repository, filed after the fact, that nobody's deployment pipeline ever checks for. Another's is a deployment pipeline that will not let a model reach production until it can find that same impact assessment and a passing evaluation run attached to the model's version — automatically, every time, with no manual step to forget. Both organizations can point to the same Annex A control and say they satisfy it. Only one of them has actually built the control into how software ships.
There's also a gap worth naming honestly: much of the standard's conceptual framing maps more naturally to AI systems an organization develops and manages directly than to the reality of calling someone else's model through an API. The standard's own resource and third-party controls do apply to externally sourced AI — but only if the organization does the work of extending them there; nothing in the text tells you to route every external model call through a governed gateway rather than a hardcoded key.
Which leads to a genuinely useful test, if you're an engineer being told "we've adopted ISO/IEC 42001" and want to know whether to believe it: does a model or prompt reach production without passing through something that checks for a completed impact assessment and a passing evaluation? Are external AI API calls routed through a central point, or hardcoded into individual codebases? Does producing audit evidence require someone to manually screenshot a notebook, or does the platform generate it as a byproduct of the pipeline running? If the honest answer to any of those is "not really," that's not a certification failure — a conforming management system can run on manual controls. It's a sign the governance still lives on paper rather than in how the AI actually ships.
Reading It as an Executive: The Accountability the Standard Won't Let You Delegate
Read the standard the way a CEO or board should, and its most important structural move comes into focus immediately: Clause 5 puts AI policy, resourcing, and ultimate review of the whole system on top management, by name. Not the CISO. Not the data science team. Not the AI governance function. Top management establishes the AI policy, ensures resources exist, and personally reviews the management system's performance on a recurring basis. The standard separately defines a governing body — explicitly naming boards and board committees as examples — as accountable for the organization's overall performance and conformance. As the governance section above noted, though, that body doesn't have to be separate from top management; smaller organizations can satisfy the standard without one. Where a genuine governing body does exist, this is squarely its territory.
That framing turns several decisions into things executives cannot treat as purely technical, because the standard's own clauses only make sense if a business owns them: what risk the organization is willing to accept (6.1.1 requires criteria distinguishing acceptable from unacceptable risk — someone has to decide where that line sits); who has authority to accept residual risk after controls are applied (6.1.3 requires designated management approval); and whether the organization is willing to use AI for a given consequential decision at all. A model can be technically excellent and still be an outcome leadership shouldn't accept — that's a values judgment, not a metrics one.
The standard is genuinely strong on the machinery of accountability: assigned roles, a concerns-reporting mechanism, mandatory management review with specific required inputs, internal audit, a formal nonconformity process. What it can't guarantee is that any of it has teeth. An "AI owner" can exist without budget authority. A governance committee can exist without the power to actually stop a deployment. Residual-risk sign-off can become a rubber stamp instead of a real challenge. The standard builds the room; it doesn't decide who's willing to say no in it.
What Certification Actually Proves
Governance sees the process-versus-judgment gap in the standard's own hedging language and its self-referential exclusion mechanism. Architecture sees it in the absence of any engineering specification. The executive lens sees the sharpest version: a certified, well-documented AI management system can still make bad calls about risk appetite, because the standard was never built to make that call for you. Three angles, one design choice — not a flaw, but the honest shape of what a document meant for every industry and every maturity level can actually do.
Which means the badge on the RFP slide, "ISO/IEC 42001 certified," answers a narrower question than most people assume. It tells you a company can prove its AI governance process exists and runs with discipline. It doesn't tell you the company's judgment inside that process is any good.
So skip "are we certified" as the only question. Ask, one per lens:
Show me a Statement of Applicability exclusion, and walk me through who checked the risk assessment behind it.
Show me the actual technical chokepoint that stops an unapproved model from reaching production.
Show me who personally owns the decision to accept residual risk on your highest-stakes system — and watch how fast they answer.
ISO/IEC 42001 gave the field something NIST never could: a system you can actually be tested against. It didn't give anyone permission to stop at passing the test.
Stay tuned for Day 3 and a look at the EU AI Act