An AI Management System Is Not a Policy Binder. It's the Machine ISO 42001 Actually Audits.

Listen to this article

An AI Management System Is Not a Policy Binder. It's the Machine ISO 42001 Actually Audits.

0:00

What an AIMS is, and how to make it audit-ready, ten slides

Save it, share it, or send it to whoever thinks the AI policy document is the finish line.

Swipe to preview · 10 slidesDownload the PDF

ISO 42001 certifies a management system

The standard’s own definition is precise about this. A management system is “a set of interrelated or interacting elements of an organization to establish policies and objectives, as well as processes to achieve those objectives.” An AI management system takes that same structure and points it at AI: the organisation has to “establish, implement, maintain, continually improve and document an AI management system, including the processes needed and their interactions.” A policy is a single artefact inside that system. The system is the whole loop, planning, doing, checking, and improving, that the policy is supposed to sit on top of.

That loop is the seven clauses that make up the certifiable core of ISO/IEC 42001: context of the organization, leadership, planning, support, operation, performance evaluation, and improvement. Sitting alongside them is Annex A, a normative set of control objectives across nine areas, from AI policies and internal organisation through resources, impact assessment, the AI system life cycle, data, information for interested parties, responsible use, and third-party relationships. The document that ties the two together is the statement of applicability: a record of every Annex A control the organisation includes or excludes, with a justification for each decision. That’s the artefact an auditor typically asks to see first, because it’s the map of everything else they’re about to go check.

None of this is a document a policy team can write in an afternoon. It’s a system that has to keep producing evidence, month after month, that it’s running.

Most organisations have AI policies without an AI management system behind them

The gap between having an AI policy and having a functioning AIMS shows up clearly in the data. Cisco’s 2026 Data and Privacy Benchmark Study, surveying over 5,200 privacy and security professionals across 12 markets, found three in four organisations already have a dedicated AI governance body in place. Only 12% describe that structure as mature. A governance committee is easy to stand up. A management system that produces repeatable risk assessments, documented impact assessments, and closed-loop corrective actions is a different order of investment, and most organisations haven’t made it yet.

Thoropass’s 2026 State of Audit and Compliance Report, based on a survey of more than 500 security and compliance professionals, puts a number on the same gap from the other direction: 69% say AI adoption inside their organisation is outpacing their compliance controls, and only 6% say their AI governance is more advanced than their AI adoption. Certification volume tells the same story. As of April 2026, Doppel’s ISO 42001 certification announcement noted it was among the first 350 organisations worldwide to achieve it, a small number set against how many enterprises are already running AI in production.

The regulatory pressure behind this is not going away, even after 2026’s delays. The EU AI Act’s Digital Omnibus pushed the compliance deadline for stand-alone high-risk AI systems (Annex III) from August 2026 to 2 December 2027, and for AI embedded in regulated products (Annex I) to 2 August 2028. Article 9 of the Act requires a continuous, systematic risk management process across the AI system’s life cycle, identification, analysis, evaluation, control, and post-market monitoring, which is close to a description of ISO 42001’s own clause 6 and clause 8 requirements. An AIMS built properly to the ISO standard is the most direct path most organisations have to demonstrating that obligation when the deadline arrives.

Seven clauses run from understanding context to closing the loop on nonconformities

The clause structure is the same “harmonised” shape used across ISO management-system standards, which is deliberate, it’s built to sit alongside an existing ISO 27001 or quality system. What’s specific to AI is what each clause requires you to produce.

Every row in this table is a documented-information requirement, not a discretionary one. An auditor working through Clause 9.2 is explicitly checking whether Clause 6 through 8 happened, not whether they were planned to happen.

Documented information is what an auditor asks to see

Clause 7.5 defines documented information broadly: the management system and its processes, information created so the organisation can operate, and evidence of results achieved. In practice that third category, the records, is where audits succeed or fail, and it’s also where most organisations underinvest relative to the policy document itself.

Glocert International’s review of common ISO 42001 nonconformities lays out where the gaps appear in practice. AI system impact assessments aren’t conducted for every system in scope, or don’t address impacts on the people affected by them. Personnel responsible for AI governance lack documented evidence of AI-specific competence. The statement of applicability doesn’t address every Annex A control, or excludes controls without adequate justification. Management reviews either don’t happen on schedule or skip required inputs. Internal audits get run, but not against the ISO 42001 clauses themselves, or the auditors aren’t independent, or findings never get tracked to closure. And AI services brought in from third parties, an API, a SaaS tool with an embedded model, never make it into the risk assessment or supplier management process at all.

None of these are exotic failures. They’re the predictable result of treating the AIMS as a policy-writing exercise.

Evidence generated from day one is cheaper than evidence reconstructed before an audit

The practical difference between an easy audit and a hard one is almost never the standard’s requirements. It’s whether the organisation was generating the required evidence continuously or trying to manufacture a year of it in the six weeks before the certification body arrives.

Start with resource documentation. Annex A.4 requires the organisation to document the data, tooling, computing, and human resources behind each AI system. That’s a five-minute exercise at the point a use case is scoped and a difficult one to reconstruct eighteen months later, once the original team has moved on and the data sourcing has been forgotten. Build it into the intake step for every new AI use case instead of into a pre-audit scramble.

Design the AI risk assessment process for repeatability from the start. Clause 6.1.2 explicitly requires the process to be “designed such that repeated AI risk assessments can produce consistent, valid and comparable results.” An ad hoc workshop that reaches a good answer once but can’t be re-run the same way a year later technically satisfies nothing, because the standard is testing the process, not the individual answer. The same applies to the AI system impact assessment under 6.1.4 and A.5: run it when a system is scoped, not after it’s already deployed, document the result, and retain it for a defined period.

Start the internal audit programme early, and run it against the ISO 42001 clauses themselves. Clause 9.2 requires evidence that internal audits happened at planned intervals and were reported to relevant managers, and a certification body will expect to see at least one completed internal audit cycle before a stage 2 audit. Auditing against your own internal AI policy instead of against the standard’s actual clauses is one of the most common findings Glocert flags, and it’s entirely avoidable by scoping the audit criteria correctly from the first cycle.

And treat the statement of applicability as a living document, not a kickoff deliverable. Every time a risk assessment identifies something new, every time a new AI system enters scope, the SoA needs to be revisited. A document signed once at project kickoff and never touched again is the single most common gap an ISO 42001 auditor finds, because it’s the fastest way to check whether the rest of the system is current.

A practical starting checklist

None of this requires a compliance department. It requires treating the AIMS as something that produces evidence continuously, not a certificate to earn once and file away.

The management system has to be run

Every clause in ISO 42001 exists because a policy document, on its own, tells an auditor nothing about whether the organisation manages AI risk. A management system does, because it’s built to keep generating the evidence that proves it. Context, leadership, planning, support, operation, performance evaluation, improvement: none of it is optional, and none of it is a one-time project with a finish line, because clause 10.1 requires continual improvement for as long as the AIMS exists.

The organisations that clear a certification audit without a scramble won’t be the ones who wrote the sharpest AI policy. They’ll be the ones who treated every risk assessment, every impact assessment, and every internal audit as a record worth keeping from the first day it was performed.

The AI Governance & ROI Executive Programme builds an AIMS your own organisation can run, clause by clause, evidence by evidence, before a certification body tests it. Details are on the workshops page.