ISO 42001 Implementation Guide: From Gap Analysis to Certification Audit
A stage-by-stage account of what implementing an AI management system actually involves — what you write, what you have to run long enough to produce evidence, and where organizations underestimate the work.
What is ISO/IEC 42001?
ISO/IEC 42001 is the international management system standard for artificial intelligence. It specifies requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS), so an organization can govern how AI is developed, procured, deployed and monitored in a way that is accountable, risk-based and auditable.
The distinction that matters most: this is a governance standard, not a technical standard. It does not tell you how to build a model, what accuracy to reach, or which architecture to use. It asks who decided, on what basis, with what oversight, and what record exists to prove it.
Structurally it follows the same harmonized clause set as ISO 27001 and ISO 9001 — context, leadership, planning, support, operation, performance evaluation, improvement — with an Annex A control set specific to AI, plus guidance annexes covering AI-specific risks and impacts.
Who needs ISO 42001?
Three groups, for three different reasons:
| Who | Why the pressure arrives |
|---|---|
| AI providers | Enterprise buyers increasingly add AI governance clauses to procurement. Certification shortens the security and compliance review from months to weeks. |
| AI deployers | You did not build the model, but you are accountable for the decisions it influences in your organization. The standard gives that accountability a documented structure. |
| Regulated sectors | Finance, health, HR, insurance and public bodies face regulators who expect demonstrable oversight — not a statement that oversight exists. |
There is a fourth, quieter driver. Boards are starting to ask who is accountable when an AI system makes a consequential decision. Most organizations cannot answer that question with a document. An AIMS is how you get to one.
The implementation stages
Eight stages, roughly sequential, though scope and risk work always loop.
| Stage | What it produces |
|---|---|
| 1 · Scope & context | Which AI systems, units, sites and lifecycle stages are covered; interested parties and their requirements |
| 2 · Gap analysis | Clause-by-clause and control-by-control status: evidenced, partial or missing |
| 3 · AI inventory | Every AI system with owner, purpose, data, model, and risk classification |
| 4 · Risk & impact management | Risk criteria, assessments, treatment decisions, residual risk acceptance |
| 5 · Policies & controls | AI policy, roles and responsibilities, Statement of Applicability |
| 6 · Operate | Real records: decision logs, oversight actions, supplier assessments, training, incidents |
| 7 · Internal audit & management review | Audit findings, corrective actions, documented management review |
| 8 · Certification audit | Stage 1 documentation review, Stage 2 implementation audit, certificate |
How a gap analysis is conducted
Walk every clause and every applicable Annex A control, and mark each one as evidenced, partial or missing — recording the actual artefact, not an opinion. “We do this” is not a finding. “We do this and here is the record” is.
Most organizations discover their gap is not policy. It is evidence. The practice exists, but nothing records that it happened, who approved it, or what the outcome was.
That pattern is worth naming early, because it changes the plan. If the gap were policy, you would write documents for six weeks and be done. Because the gap is evidence, you have to change how work is recorded — and then run it long enough for records to accumulate.
Which policies and controls are required
The mandatory documented information includes the scope, the AI policy, risk assessment and treatment processes and their results, the Statement of Applicability, objectives, competence records, operational records, monitoring and measurement results, internal audit programme and results, and management review results.
The Statement of Applicability deserves particular attention. It lists every Annex A control, whether it applies, and the justification for each inclusion or exclusion. Auditors read it closely, because it is where an organization reveals whether it actually thought about its own context or copied a template.
Beyond the mandatory set, most implementations produce an AI acceptable-use policy, a human oversight design per high-impact system, supplier and third-party model assessment criteria, a data governance procedure covering training and inference data, and an AI incident response procedure.
The role of AI risk management
This is where ISO/IEC 42001 diverges most from the management system standards people already know. Classical risk management asks what could harm the organization. AI risk management under this standard also asks what the AI system could do to people — individuals and society, not only the business.
- Risk assessment — likelihood and consequence across security, safety, fairness, privacy, transparency and reliability
- Impact assessment — effects on individuals and groups affected by the system's outputs, including those who never interact with it directly
- Treatment — what is mitigated, what is accepted, who accepted it, and on what date
- Monitoring — how the risk picture is refreshed as models, data and usage drift
The impact assessment is the part organizations most often underestimate. It requires naming affected parties who have no commercial relationship with you — and defending the conclusion that the impact on them is acceptable.
What evidence the audit requires
Auditors are not evaluating your intentions. They are checking whether the system ran. The evidence pack typically includes:
| Evidence | What it demonstrates |
|---|---|
| AI inventory | You know what AI you have, including embedded features and shadow AI |
| Risk & impact assessments | Risk was assessed with a defined method, not asserted |
| Statement of Applicability | Control selection was reasoned against your context |
| Human oversight records | Oversight is real: someone reviewed, and sometimes overrode |
| Supplier & model assessments | Third-party AI was evaluated before it entered production |
| Competence & training records | The people operating the system were equipped to do so |
| Monitoring output | Performance and drift were watched over time |
| Incident records | Something went wrong and the process handled it |
| Internal audit & management review | The organization checks itself and leadership engages |
An audit finding is rarely “you have no policy.” It is far more often “your policy says X and your records show Y.”
How long certification takes
For a mid-sized organization that already runs a management system, typically six to twelve months from gap analysis to certificate. Organizations starting without any management system discipline should plan longer.
The binding constraint is rarely documentation. It is the operating period. Auditors need records produced by the system running under real conditions, and there is no way to compress the time it takes to generate them. Writing the policy set is weeks of work; accumulating three to six months of oversight logs, monitoring output and at least one internal audit cycle is not.
Certification itself follows the standard two-stage pattern: a Stage 1 review of documentation and readiness, then a Stage 2 audit of implementation. The certificate is maintained through surveillance audits, with recertification on a three-year cycle.
How ISO 42001 relates to the EU AI Act
They are complementary rather than interchangeable, and conflating them causes real problems in planning.
| EU AI Act | ISO/IEC 42001 | |
|---|---|---|
| Nature | Law | Voluntary management system standard |
| Structure | Obligations by risk class and by role (provider, deployer) | Requirements for how the organization governs AI |
| Question asked | Is this system permitted, and under what conditions? | Can this organization govern AI systematically? |
| Outcome | Legal compliance | Certificate from an accredited body |
Certification does not by itself establish legal compliance. But the artefacts an AIMS produces — risk management, technical documentation, logging, human oversight design, post-market monitoring — are much of what the Act expects a provider or deployer to be able to show. Building the management system first makes the regulatory work considerably lighter.
If your immediate driver is the Act rather than certification, our EU AI Act readiness workshop starts from risk classification and the 90-day plan instead.
What an implementation roadmap should contain
- Scope decision — with an explicit rationale for what is excluded and why
- Accountable owner — a named person, not a committee
- Gap analysis output — the evidenced/partial/missing table, prioritized by risk
- Evidence design — for each gap, which system or process will generate the record, and starting when
- Operating window — the deliberate period during which records accumulate before internal audit
- Internal audit and management review dates — scheduled, not aspirational
- Certification body engagement point — booked early; lead times are real
Item 4 is the one most roadmaps omit, and the one that determines whether the timeline holds. Deciding what to record is a workshop. Deciding which system produces the record automatically is the actual engineering work.
Frequently asked questions
Do we need a separate management system if we already have ISO 27001?
No. ISO/IEC 42001 follows the same harmonized structure, so scope, leadership, planning, support, operation, evaluation and improvement can be integrated rather than duplicated. What is genuinely new is AI-specific: impact assessment on individuals and society, data and model lifecycle controls, human oversight design and transparency obligations.
Can we certify only part of the organization?
Yes — scope is a deliberate choice and a narrow first scope is often the right one. But the scope statement must be defensible: excluding a business unit because its AI is inconvenient to govern is visible to an auditor and undermines the certificate's credibility with customers.
Does buying AI rather than building it reduce the obligations?
It changes them rather than reducing them. You inherit responsibility for supplier assessment, contractual controls, monitoring of a system you cannot inspect internally, and human oversight of its outputs. Deployers frequently find the supplier-assessment control harder than providers find the development controls.
What is the most common reason implementations stall?
Treating it as a documentation project. The policy set can be written quickly; the evidence cannot be back-dated. Implementations that start by changing how decisions are recorded finish roughly on schedule. Implementations that start by writing policies discover at internal audit that they have nothing to show.
Indigonix runs ISO/IEC 42001 gap analyses, designs AI management systems and prepares organizations for certification audit. If you would rather build the capability internally, the governance workshop covers the same material as a two-day applied lab.
Talk to us Governance workshop Clause-by-clause guide← Indigonix System Intelligence