How to Get ISO 42001: A Step-by-Step Guide

ISO 42001 is the first international management system standard built specifically for artificial intelligence. If your organization builds, deploys, or relies heavily on AI systems, and customers or regulators are starting to ask how you govern that AI, ISO 42001 is quickly becoming the answer they want to see. It is new, it is growing fast, and the path to certification is more structured than most teams expect once you break it into stages.

This guide walks through what ISO 42001 actually requires, the realistic timeline from a standing start to a certificate, and where a compliance partner shortens the road.

What ISO 42001 Actually Covers

ISO 42001 is an AI management system (AIMS) standard, published in December 2023 by the International Organization for Standardization. It works like ISO 27001 for information security, but the subject is AI governance instead: how you develop, procure, deploy, and monitor AI systems responsibly across their lifecycle.

The standard sits alongside a growing set of AI regulations and frameworks rather than replacing them. The EU AI Act imposes legal obligations for AI systems used in or affecting the EU market, with risk-based requirements that scale from minimal to high risk. The NIST AI Risk Management Framework offers a voluntary, US-originated structure for identifying and managing AI risk. ISO 42001 is the certifiable management system that ties these efforts together: an auditor can assess your AIMS and issue a certificate, which is something neither the EU AI Act nor the NIST framework does on their own. Organizations selling into regulated markets increasingly use ISO 42001 as evidence of AI governance maturity when the EU AI Act or client due diligence questionnaires ask for it.

Step 1: Scope the AI Management System

Start by defining which AI systems, business units, and use cases fall inside your AIMS. Most organizations scope this around the AI products or features that customers or regulators actually care about, rather than every internal automation script. A clear scope statement keeps the project bounded and keeps the eventual audit focused on what matters.

Timeline: one to two weeks, mostly workshops with leadership and whoever owns your AI product roadmap.

Step 2: Run an AI Risk Assessment

ISO 42001 requires a documented process for identifying and evaluating AI-specific risks: bias, model drift, data quality, explainability gaps, misuse, and the impact of AI decisions on people. This is different from a generic security risk assessment. It has to address how your AI systems behave, not just how your infrastructure is secured.

Timeline: two to four weeks, depending on how many distinct AI systems are in scope.

Step 3: Build the Policy and Control Set

ISO 42001's Annex A lists controls covering AI policy, roles and responsibilities, resources for AI systems, lifecycle management, data governance, third-party and supplier management, and incident response for AI-related events. You will document policies for each applicable control and map them to how your organization actually operates. Copying a template without tailoring it to your real AI stack is the fastest way to fail an audit later.

Timeline: four to eight weeks for a mid-size organization, longer if AI development spans multiple teams or products.

Step 4: Operate the AIMS and Collect Evidence

A management system standard is not just paperwork, it requires operating the controls for a period before certification. Auditors want evidence: risk assessments actually performed, model monitoring logs, change management records for AI systems, training records, and incident response drills if applicable. Most certification bodies expect at least a few months of operating evidence, though this varies by auditor.

Timeline: typically two to three months of live operation before the certification audit.

Step 5: Internal Audit and Management Review

Before the external audit, run an internal audit against the standard and hold a formal management review. This step catches gaps while they are still cheap to fix. Skipping it is the single most common reason organizations get hit with major nonconformities during the real audit.

Timeline: two to three weeks.

Step 6: Certification Audit

An accredited certification body performs the audit in two stages: a documentation review (Stage 1) followed by an on-site or remote implementation audit (Stage 2). Minor nonconformities are common and correctable within a set window. Major nonconformities can delay certification until they are resolved and re-audited.

Timeline: four to eight weeks including scheduling, the two audit stages, and any corrective action period.

Realistic Total Timeline

For an organization starting from zero, with no existing AI governance documentation, a realistic timeline from kickoff to certificate is six to nine months. Organizations that already hold ISO 27001 or a SOC 2 report move faster, since the management system muscle memory (risk registers, document control, internal audit cadence) already exists and mostly needs extending to cover AI-specific requirements.

Where a Partner Helps

The technical work of ISO 42001 is not the hard part. The hard part is knowing what an auditor will actually push back on, tailoring Annex A controls to a real AI stack instead of a generic template, and avoiding rework because a control was documented in a way that does not hold up at Stage 2. A readiness assessment before you commit to a certification timeline tells you exactly where the gaps are, what evidence you are missing, and how long closing those gaps will realistically take, before you have booked an auditor and set a deadline you cannot hit.

traztech runs ISO 42001 readiness assessments for organizations that need to know where they stand before starting the certification clock. If ISO 42001 is one piece of a broader compliance picture that includes SOC 2, ISO 27001, or other frameworks, our compliance advisory services cover the full picture rather than treating each standard in isolation.

Getting Started

If customers or regulators are already asking about your AI governance, or you can see that question coming, the smart move is a readiness assessment before you pick a certification date. It tells you what you actually need to build, in what order, and how long it will realistically take, so you are not guessing at a launch date for the sales team.

Contact traztech to talk through where your AI systems stand today and what an ISO 42001 readiness assessment would look like for your organization.

Building the AI system inventory before anything else

Every ISO 42001 project we have seen stall in the first month stalled for the same reason: nobody could produce a defensible list of the AI systems in use. The scope statement says "our AI features", and then someone in support mentions that the customer success team has been running a summarisation tool on ticket transcripts for eight months, and the scope statement is now wrong. Before you write a single policy, build an inventory with one row per AI system and, at minimum, these fields: what the system does, who owns it, which model or vendor sits behind it, what data goes in, whether outputs affect a person's access to a service, and whether a human reviews the output before it lands anywhere.

The inventory is what turns the rest of the standard from abstract into tractable. Your risk assessment gets a per-system structure instead of a page of general worries about bias. Your Statement of Applicability equivalent has something to point at. Your Stage 2 auditor gets a document they can sample from, which is exactly what they want to do. And the exercise of building it almost always surfaces shadow AI, meaning tools adopted by a team without a procurement review. Two or three shadow systems is normal. Finding them during your own inventory work is cheap. Finding them because an auditor interviewed a support lead who mentioned them unprompted is not, because it calls the completeness of your whole management system into question.

What the AI impact assessment actually has to contain

ISO 42001 expects an assessment of the impact your AI systems have on individuals and groups, and this is the requirement teams most often satisfy with something too thin to survive review. A risk assessment asks what could go wrong for the organisation. An impact assessment asks what could go wrong for the person on the other end of the decision, which is a different question with different answers.

A usable one names the affected populations, states the plausible harm in concrete terms, and records what you decided to do about it. "Model may produce biased output" is not an impact assessment entry. "Candidates whose CVs are in French are scored lower because the training corpus skews English, which affects hiring outcomes in Quebec, mitigated by disabling automated ranking for non-English submissions and routing them to manual review" is one. The second version tells an auditor that a real person thought about a real population. It also gives you something to test in your internal audit, because you can go and check whether the routing rule actually exists in the product.

Where AI decisions touch personal information, this assessment overlaps heavily with the privacy impact assessment work Quebec's Law 25 already requires. Run them as one exercise with one template rather than two documents that will drift apart within a year.

Supplier management when your supplier is a foundation model provider

Annex A control expectations around third parties assume you can get evidence from your suppliers. When your supplier is a large model provider, you will discover quickly that the evidence you can obtain is limited to what they publish: a model card, a trust portal, a SOC 2 report covering their platform infrastructure, terms that describe whether your inputs are used for training. You cannot audit their training data and you should stop planning to.

The workable position, and the one auditors accept, is that your controls sit at the boundary you actually own. Document what you send to the provider and what you deliberately do not send. Record the contractual position on training use and data retention, with the clause reference, not a screenshot of a marketing page. Define what happens when the provider changes model versions underneath you, because they will, and a silent version change is the most common cause of a monitoring metric moving without any change on your side. Keep a fallback position for provider outage or deprecation, since model deprecation notices routinely run shorter than an enterprise change cycle.

The single most useful artefact here is a short supplier register entry per model provider that records the version you are pinned to, the date you last reviewed the terms, and the named person who owns that relationship. It takes an afternoon and it answers about six audit questions at once.

Setting objectives you can actually measure

Clause 6 wants AI objectives and clause 9 wants monitoring and measurement against them. This pairing is where documentation-first projects get caught. Teams write objectives like "ensure responsible AI use", which cannot be measured, so clause 9 produces nothing, so the management review has nothing to review, and the auditor writes a nonconformity that touches three clauses at once.

Pick objectives that already have a number behind them or that you can start counting next week. Rate of outputs escalated to human review. Number of AI incidents logged and time to close them. Percentage of in-scope systems with a completed impact assessment. Drift in a model quality metric your team already tracks for product reasons. Complaints or appeals received about an automated decision. You do not need many. Four or five objectives with real numbers, reviewed quarterly with a written decision each time, beat twelve aspirational ones.

Choosing a certification body, and the accreditation trap

ISO 42001 certification is young enough that the supply of genuinely accredited certification bodies is thin, and that creates a specific risk. Some bodies will happily sell you an ISO 42001 certificate without accreditation for that scheme from a recognised accreditation body. The certificate looks identical on your website. It does not look identical to a procurement team that checks, and the ones who ask for ISO 42001 are precisely the ones who check.

Ask three things before you sign the audit contract: which accreditation body has accredited them specifically for ISO 42001, whether the accreditation is live now or pending, and whether the lead auditor assigned to you has audited an AI management system before or is an ISO 27001 auditor with a conversion course. That last one matters more than people expect. An auditor without AI background tends to fall back on the clauses they know, which produces an audit that feels easy and a certificate that convinces nobody technical.

Book early regardless. Auditor availability for this scheme is the constraint on most timelines, and a body that can start next month is often a body worth asking why.

Running it alongside ISO 27001 instead of beside it

If you already hold ISO 27001, the integration decision is worth making deliberately at the start. The two standards share the harmonised management system structure, which means clauses 4 through 10 can be operated once: one context and interested parties analysis, one document control process, one internal audit programme covering both scopes, one management review agenda with AI as a standing item, one corrective action log. The AI-specific work then reduces to the AI risk and impact assessments, the Annex A control set, and the AI portions of your monitoring.

Done this way, ISO 42001 on top of a working ISMS is realistically three to five months rather than the six to nine a standing start takes, and you can often run combined audits with the same certification body, which cuts audit days and travel. Done badly, meaning two separate document sets with two risk registers, you have doubled your maintenance burden permanently and you will feel it at the first surveillance audit when the two registers disagree about the same vendor. Our compliance advisory work is built around running these as one system, and the free traztech Workspace exists partly so a single risk register and evidence set can serve several frameworks instead of being copied per audit.

What happens after the certificate

The certificate runs on a three-year cycle with surveillance audits, usually annual, and a recertification audit at the end. The realistic maintenance load for AI is heavier than for information security, because your subject matter changes faster. A new product feature that uses a model is a scope change. A provider swapping the default model version is a change that should trigger a review. A new region of operation can bring new legal requirements into your context analysis.

Build one habit and the surveillance audits become routine: route every AI change through the same intake that already exists for product changes, with two extra questions on the form, namely whether this touches an in-scope AI system and whether it changes who is affected by an output. That is a fifteen-minute build in whatever tracker you already run, and it produces a dated trail of decisions that is exactly what a surveillance auditor samples.

When you should not pursue ISO 42001

There are several situations where the honest advice is to spend the money elsewhere.

Nobody has actually asked for it. A lot of ISO 42001 interest is anticipatory. If no customer, regulator, or partner has put it in writing, and you are not bidding into markets where it is becoming a procurement floor, a documented AI use policy plus an inventory plus an alignment statement against the NIST AI Risk Management Framework will answer most current questionnaires at a fraction of the cost. Revisit when a deal is actually blocked.

Your AI surface is one vendor feature. If your AI exposure is a chatbot on your marketing site and a coding assistant used internally, a management system standard is heavy machinery for a light problem. Write the acceptable use policy, restrict what data can be pasted into which tools, and move on.

You are pre-product or pre-revenue. Certification requires operating evidence over months. Certifying a system that is going to be rebuilt twice before it has customers means auditing something that will not exist by the time the certificate arrives.

You need EU AI Act conformity specifically. ISO 42001 supports that work and gives you the governance backbone, but the certificate does not discharge the Act's obligations for a high-risk system. If a lawyer has told you that you are in a high-risk category, the legal analysis leads and the management system follows, not the other way round.

Your security baseline is not built yet. If you have no access reviews, no logging worth the name, and no incident process, an AI management system is being built on sand. Fix the base first. That is usually ISO 27001 or SOC 2, and the AI work then sits on top of a system that already runs. If you want to talk through which of those comes first for your situation, get in touch and we will give you an order of operations rather than a proposal for everything at once.