What ISO 42001 certification actually requires of you

ISO/IEC 42001:2023 is the first management system standard for artificial intelligence that a certification body can audit you against. Published in December 2023, it is being written into procurement requirements faster than ISO 27001 was at the equivalent point in its life — largely because the EU AI Act gave organisations a deadline that certification helps them evidence against.

This is what implementing it actually involves.

The structure will be familiar#

42001 follows the harmonised high-level structure shared by ISO 27001, ISO 9001 and the rest: context, leadership, planning, support, operation, performance evaluation, improvement.

For organisations already running an ISO 27001 management system, roughly 40% of the clause requirements are satisfiable by extending existing artefacts rather than creating new ones:

Clause 8 is where the real work is, and it does not have an ISMS equivalent.

Annex A: the controls that are genuinely new#

Annex A contains the AI-specific controls. Four groups cause most of the implementation effort.

AI system impact assessment

The requirement is to assess potential consequences for individuals, groups and society — a broader lens than a data protection impact assessment, which is concerned with risks to data subjects arising from processing.

An AI impact assessment has to consider fairness across affected groups, safety, transparency, contestability of decisions, environmental impact, and effects on people who are not users of the system but are subject to its output.

The implementation trap is weight. An assessment that takes three weeks will be avoided, and teams will find ways not to trigger it. Ours runs as a threshold test of twelve questions taking ten minutes, followed by a full assessment only for systems that clear the threshold — which is typically 15–20% of the inventory.

Data for AI systems

Controls covering provenance, quality, preparation and representativeness of data used across training, tuning and evaluation.

This is where organisations using third-party foundation models hit a wall, because the provenance of the base model's training data is genuinely unknown to them and often unknowable. The standard does not require you to know the unknowable; it requires you to identify the limitation, assess its consequence and document your position.

The defensible position looks like: base model provenance is not disclosed by the provider; we have assessed the consequence for our use case as [X]; we mitigate through [evaluation / output filtering / human review]; we have requested disclosure and recorded the response.

Silence on the point is what produces a finding.

AI system lifecycle

Controls across objectives definition, design, data acquisition, development, verification and validation, deployment, operation and retirement.

Organisations with mature MLOps practices satisfy much of this already but rarely with the documented decision records the standard expects. The gap is usually not the activity — it is the absence of a record showing that a validation gate was passed and by whose authority.

Third-party relationships

Controls allocating responsibilities across the AI supply chain — foundation model providers, AI-enabled SaaS, data suppliers and labelling vendors.

For most organisations this is now the largest part of the AI estate, and traditional vendor assessments do not ask the right questions. What is needed is a supplementary AI module covering training-data use, prompt and output retention, sub-processors, evaluation evidence, model version notification and exit.

Where it sits relative to the EU AI Act#

Worth being precise, because vendors are imprecise about it.

ISO 42001 certification does not confer EU AI Act compliance. The Act imposes legal obligations; the standard is a voluntary management system. No certification body can certify legal compliance and none will claim to.

What a well-implemented AIMS does is generate most of the evidence the Act requires a provider or deployer to hold: risk management, data governance, technical documentation, human oversight design, post-market monitoring, incident reporting. Harmonised standards under the Act are expected to align closely with 42001.

The practical approach is to build the AIMS and maintain an explicit cross-map to the Act's obligations, so that when a customer's procurement team asks how your certificate relates to their conformity requirements, you have an answer rather than an assertion.

Timeline and integration decision#

For an organisation with an existing ISO 27001 management system, expect 12–16 weeks to certification readiness. Without one, 16–24 weeks, because you will be building management system machinery from scratch alongside the AI-specific content.

The integration decision matters more than the timeline. Two options:

Integrated management system. One set of management system clauses serving both the ISMS and the AIMS, with separate Annex A control sets. One internal audit programme, one management review, one risk methodology extended to cover AI risk. This is what we recommend in almost every case.

Parallel systems. Separate policies, separate audits, separate reviews. Faster to stand up if the AI governance function is organisationally distinct, and consistently more expensive to operate from year two onward.

Is it worth doing now?#

For organisations selling AI-enabled products to enterprise or public-sector buyers: increasingly yes. It is appearing in tender requirements, and it removes a tranche of bespoke due diligence from every deal.

For organisations using AI only internally: the management system is worth building even where the certificate is not urgent, because the underlying obligations — inventory, impact assessment, oversight, monitoring — arrive through other routes regardless. DPDPA purpose limitation, sectoral model risk expectations and customer contractual terms all converge on the same capability.

Who should own the AIMS#

This decision shapes whether the system works, and the obvious answers are usually wrong.

Not the data science team. They build the systems the AIMS governs. Asking them to own it recreates the conflict that makes a CISO an unsuitable DPO — and it puts governance overhead on the group whose velocity you most want to preserve.

Not Legal alone. Legal can interpret the obligation but cannot assess whether an evaluation protocol is adequate or whether a monitoring threshold is meaningful. An AIMS owned entirely by Legal produces documentation that describes a system nobody has tested.

Not the CISO by default, although this is where it often lands. Security governance experience transfers well, but AI risk includes fairness, contestability and societal impact — dimensions outside a standard security remit. Where a CISO does own it, the impact assessment function needs someone with a different background attached.

The arrangement that works most often is a named AI governance lead with a technical understanding of how models are built and evaluated, reporting into whichever function already owns the risk taxonomy, with a cross-functional review board that includes Legal, Security, Data Science and the business owner of the highest-tier systems.

At smaller scale that lead is a part-time role held by someone with genuine model literacy. What matters is that it is a named person with allocated time, because an AIMS without an owner decays faster than an ISMS — the underlying systems change weekly rather than quarterly.

What it costs to run, not just to build#

Certification is the visible cost. The operating cost is the one that surprises boards in year two.

An AIMS carries three recurring obligations that an ISMS does not: re-evaluation of models as they drift or are retrained, impact reassessment when a system's purpose or population changes, and monitoring of a supply chain where the underlying foundation model may change without notice.

Budget for the review cadence rather than the certificate. For an organisation with five tier-one systems, that has typically meant quarterly evaluation cycles on those five, an annual impact reassessment across the estate, and a standing process to catch vendor model changes — perhaps fifteen to twenty days of specialist effort a year, plus whatever evaluation tooling costs.

That is affordable. What is not affordable is discovering it at the surveillance audit, having budgeted only for the implementation.

Our AI Governance & Assurance practice delivers these implementations, and the ISO 42001 framework page sets out the obligations and control domains in full.