From Framework to Workflow: Why ISO 42001 Implementation Fails (and How to Fix It)

Most organizations treat ISO 42001 as a document exercise. That’s the mistake and it’s the same mistake that made ISO 27001 implementations brittle for a decade before anyone admitted it.

Give an organization a certifiable standard and it will build a binder. Auditors ask for evidence. Evidence lives in documents. Documents get written to satisfy the audit, not to run the business. Eighteen months later, the binder is accurate as of the day it was written and increasingly disconnected from what the organization actually does.

ISO 42001 is at real risk of following this same path, and the timeline is compressed compared to ISO 27001’s ten-year descent into checkbox territory. Organizations are adopting it fast, often as a competitive requirement rather than a chosen practice, and the temptation to treat it as a paperwork sprint is strong.

This series argues for a different starting point: treat ISO 42001 as a workflow you run continuously, not a framework you document once. The clause structure of the standard actually supports this if you read it that way.

The clause structure already implies a workflow

Strip away the ISO numbering and Annex A cross-references, and 42001 describes five things an organization has to do, in a loop, forever:

• Know what AI systems you have and what they’re for (Register)

• Understand the risks each one carries (Assess)

• Put controls in place that address those risks (Mitigate)

• Make a deliberate, accountable decision to proceed (Approve)

• Keep checking that the controls still work as circumstances change (Monitor)

Every one of those five things reappears in the standard’s structure: once as a requirement in the main clauses (4 through 10) and again as a control expectation in Annex A. That repetition is not redundancy. It’s the standard telling you this is a cycle, not a phase gate you pass through once and file away.

This series uses that five-stage shape deliberately. We’re borrowing the Register → Assess → Mitigate → Approve → Monitor structure that we use operationally at Airia because it happens to match how the standard actually wants you to work. If anything, the causality runs the other way: we built the workflow because organizations that treated AI governance as a discrete lifecycle event kept failing their own audits.

Where the failure mode comes from

The specific failure pattern looks like this. An organization builds a risk assessment for its AI systems as a standalone project, usually to satisfy Clause 6.1.2 ahead of a certification audit. The assessment is thorough, thoughtful, and complete on the day it’s finished. It identifies real risks and maps them to real controls.

Then a new AI use case gets deployed six weeks later, outside the process that produced the original assessment, because nobody built a mechanism for new systems to enter the same pipeline. Or a model gets updated, and the risk profile shifts, but nothing in the governance process notices because monitoring was scoped as “check the document quarterly,” not “track the system continuously.”

By the time the surveillance audit comes around, the documentation is stale, the auditor asks pointed questions about systems that aren’t in the original assessment, and the response is a scramble to retrofit evidence. This is compliance theater because the underlying process was never built to keep up with itself.

What this series covers

Each of the next five posts takes one stage of the cycle and treats it as an implementation problem, not a documentation problem. We’ll cover:

• Register — defining scope and governance context correctly the first time, because scope mistakes compound

• Assess — running a risk assessment that actually holds up against Clause 6.1.2, not just against the audit checklist

• Mitigate — selecting and sequencing Annex A controls so implementation matches actual risk, not standard order

• Approve — building a governance decision framework with real accountability, not a rubber stamp

• Monitor— the stage almost everyone under-invests in, and the one that determines whether your certification survives its first surveillance audit

This mirrors the structure we used for our NIST AI RMF series, and deliberately so: Govern, Map, Measure, and Manage are NIST’s language for nearly the same lifecycle. If you found that series useful, this one will feel familiar in shape and different in specificity. NIST is a risk management vocabulary. ISO 42001 is a certifiable management system with auditable clauses and a defined Annex A control set. The lifecycle logic transfers; the implementation mechanics don’t.

The thread running through this series

A management system is only as good as its weakest transition which is the handoff between stages. Most organizations invest heavily in one stage (usually Assess, because it’s visible and required for certification) and treat the others as administrative follow-through. The posts ahead spend the most time on the transitions: how assessment output becomes control selection, how control implementation becomes an approval decision, how approval becomes something worth monitoring.

If you’re building this from scratch, or rebuilding it because your first attempt didn’t survive contact with a real audit, the next five posts are meant to be used in order. Each one assumes you’ve done the work of the one before it.