ISO/IEC 42001:2023 · JTC 1/SC 42 · Implementation guide
The AI Management
System, Assembled
The only certifiable AI standard, taken clause by clause — with all 38 Annex A controls, the Statement of Applicability, and what an auditor will actually ask to see.
- Designation
- ISO/IEC 42001:2023
- Title
- AI management system
- Edition
- First — December 2023
- Committee
- ISO/IEC JTC 1/SC 42
- Document type
- Requirements — “shall”
- Certifiable
- Yes — accredited third party
The clause structure, scope, introduction, all 26 defined terms and the bibliography below come from the publicly viewable sections of ISO/IEC 42001:2023 on the ISO Online Browsing Platform. The requirement text of clauses 4 to 10 and the implementation guidance in Annexes A to D are not public, and none of it is reproduced here. Everything under “What it requires” and “What the auditor wants” is an implementation reading, written to the clause title and the harmonized structure, and intended to be usable. Buy the standard before you certify against it.
01What it is
ISO/IEC 42001 is a management system standard for artificial intelligence. It is the one document in the SC 42 family that an accredited body can certify you against, which is why it has become the centre of gravity for AI governance programmes.
If you have lived through ISO 27001 or ISO 9001, you already know the shape. 42001 uses the harmonized structure — the common skeleton ISO now mandates for management system standards, with identical clause numbers, clause titles and core definitions across the family. Clause 4 is context, 5 is leadership, 6 is planning, 7 is support, 8 is operation, 9 is performance evaluation, 10 is improvement. Anyone who has run one management system can navigate another on day one, and an organisation running several can run them as one.
What makes it an AI management system is what sits inside that skeleton. Three things are genuinely new:
- AI system impact assessment (clauses 6.1.4 and 8.4). No other management system standard requires you to formally assess your effect on people outside the organisation. This is the requirement ISO/IEC 42005 exists to satisfy.
- Annex A — 38 reference controls spanning policy, roles, resources, impact, life cycle, data, transparency, use and third parties, selected through a Statement of Applicability.
- An explicit role split. The standard applies to organisations that develop, provide or use AI systems, and expects you to say which you are. A deployer's AIMS looks materially different from a developer's, and Annex A is built to be drawn from differently by each.
The introduction is unusually direct about the intent: organisations should focus their application on the features that are unique to AI. Continuous learning that changes behaviour in use. Decisions made without transparency or explainability. Systems designed from data rather than hand-written logic. If a control you are writing would read identically for a conventional IT system, you are probably doing generic IT governance and labelling it AI governance.
One more framing worth internalising: a management system is not a document set, it is a loop. Plan, do, check, act. The standard's real question is not “do you have a policy?” but “does anything change when the policy is not met?” Certification tests the loop.
02Scope and audience
The scope fixes three things.
| The scope fixes | Which means |
|---|---|
| Requirements and guidance | Clauses 4–10 are requirements — “shall”, and auditable. Annexes B, C and D are guidance. Annex A is normative but selectively applied through the Statement of Applicability. |
| Providers and users | Anyone providing or using products or services that utilise AI systems. Buying and deploying a model puts you squarely in scope. |
| Any organisation | Regardless of size, type or nature — and the risk-based approach is what makes that credible. A ten-person firm applies the same clauses at a proportionate depth. |
The single most consequential early decision is clause 4.3 — the scope of the management system itself. Too broad and you are certifying a body of AI activity you cannot actually govern yet. Too narrow and the certificate says something so limited that customers reading it learn nothing, or worse, feel misled when they discover which systems it excludes. The scope statement appears on the certificate. Write it as though a prospective customer will read it as a claim — because they will.
03The vocabulary
Twenty-six terms in clause 3, most inherited from the harmonized structure. Five carry AI-specific weight, and the rest are worth knowing precisely because auditors use them precisely.
Clause 3 imports the whole of ISO/IEC 22989 (AI concepts and terminology) as its single normative reference, so “AI system”, “machine learning”, “training data” and the rest already have agreed meanings. Definitions below are paraphrased.
| Ref | Term | In plain terms |
|---|---|---|
| 3.24 | AI system impact assessment | A formal, documented process in which impacts on individuals, groups of individuals, or both, and on societies, are identified, evaluated and addressed. Note the three verbs — 42001's version of the definition is more demanding than a bare “considered”: you must act on what you find. |
| 3.26 | Statement of applicability | Documentation of all necessary controls plus justification for each inclusion and exclusion. The notes make clear you may use fewer than Annex A lists, or more — Annex A is a floor to reason from, not a ceiling. |
| 3.22 | Governing body | Those accountable for the organisation's performance and conformance — board, trustees, supervisory board. Explicitly distinguished from top management, though the standard concedes small organisations may not have both. |
| 3.3 | Top management | Those who direct and control at the highest level, with power to delegate authority and allocate resources. Clause 5 attaches personally to these people. |
| 3.21 | Control | In the risk sense: a measure that maintains or modifies risk. The second note is the honest one — controls do not always have the effect assumed of them, which is the whole justification for clause 9. |
| 3.25 | Data quality | The characteristic that data meets the organisation's requirements for a specific context. Quality is not absolute; the same dataset can be fit for one use and unfit for the next. |
| 3.7 | Risk | Effect of uncertainty — positive or negative. The standard means both directions, and clause 6.1 is titled “risks and opportunities” for that reason. |
| 3.10 | Documented information | Information the organisation is required to control and maintain, plus its medium. Covers the system's own documentation, operating information, and records of results. |
| 3.18 | Audit | A systematic and independent process for obtaining evidence and evaluating it objectively against audit criteria. The note points at ISO 19011 for “audit evidence” and “audit criteria” — the two standards are designed to be used together. |
| 3.16 / 3.17 | Nonconformity, corrective action | Non-fulfilment of a requirement; and action to eliminate its cause and prevent recurrence. Note what corrective action is not: fixing the instance. Fixing the instance is correction. |
04Document map
Ten clauses and four annexes. Clauses 4 to 10 are what you are certified against. Annex A is the control catalogue. Annex B is where the practical detail actually lives.
| Part | Title | Status | What it gives you |
|---|---|---|---|
| 1–3 | Scope, normative references, terms | — | Boundaries and 26 definitions |
| 4 | Context of the organization | Shall | Issues, interested parties, AIMS scope, the system itself |
| 5 | Leadership | Shall | Commitment, AI policy, roles and authorities |
| 6 | Planning | Shall | Risk assessment and treatment, impact assessment, objectives, change |
| 7 | Support | Shall | Resources, competence, awareness, communication, documented information |
| 8 | Operation | Shall | Doing it — operational control, risk assessment, treatment, impact assessment |
| 9 | Performance evaluation | Shall | Monitoring, internal audit, management review |
| 10 | Improvement | Shall | Continual improvement, nonconformity and corrective action |
| A | Reference control objectives and controls | Normative | 38 controls in 9 objective areas |
| B | Implementation guidance for AI controls | Normative | How to implement each Annex A control — the longest and most useful part |
| C | Potential AI-related organizational objectives and risk sources | Informative | An idea bank for risk assessment workshops |
| D | Use of the AI management system across domains or sectors | Informative | Sector adaptation |
Clause 6.1 first — everything downstream is driven by risk and impact assessment. Then Annex A to see the control vocabulary, then Annex B for what each control means in practice. Read clauses 9 and 10 early rather than last: they tell you what evidence the system must be generating from day one, and retrofitting records is far more expensive than capturing them as you go.
05Clause 4 — Context of the organization
Understanding the organization and its context
Determine the external and internal issues relevant to your purpose that affect your ability to achieve the AIMS's intended results. For AI this reliably includes: your role — developer, provider, user, or several at once; the regulatory environment you sell into; the maturity of your data estate; the pace at which the technology and your own use of it is changing.
Auditor wants A context analysis that is current, specific and evidently used — not a PESTLE grid written once and never reopened.
Understanding the needs and expectations of interested parties
Identify the parties relevant to the AIMS and their relevant requirements. In AI this list is longer than in most management systems and reaches further: customers, regulators, employees, suppliers and model providers — but also the people your systems make decisions about, who are usually not your customers and have no contract with you.
Auditor wants A register naming parties and their specific requirements, traceable into your objectives and controls.
Determining the scope of the AI management system
Set and document the boundaries: which organisational units, which AI systems, which activities, which roles you occupy for each. Exclusions must be justified and must not undermine the credibility of the certificate.
Auditor wants A documented scope statement, and evidence that anything excluded genuinely is out of reach of the system.
AI management system
Establish, implement, maintain and continually improve the system, including the processes needed and their interactions. The short clause with the largest implication: a set of documents that do not interact is not a management system.
Auditor wants A process map showing how the parts connect — how a risk becomes a control, how an incident becomes a corrective action.
06Clause 5 — Leadership
Leadership and commitment
Top management must demonstrate leadership: ensuring the policy and objectives are compatible with strategic direction, integrating AIMS requirements into business processes, providing resources, communicating why it matters, and directing people to contribute. Demonstrating is the operative word — this clause is evidenced by behaviour, not by a signed statement.
Auditor wants Management review records, resource decisions, and — most persuasively — an instance where leadership chose the AIMS position over a commercial one.
AI policy
Establish a policy appropriate to your purpose, providing a framework for AI objectives, committing to satisfying applicable requirements and to continual improvement. It must be documented, communicated internally, and available to interested parties as appropriate. A good AI policy takes a position on something contestable — what you will not build, where a human must decide — rather than restating the standard back to itself.
Auditor wants A current, approved, communicated policy — and staff who can say what it means for their work.
Roles, responsibilities and authorities
Assign and communicate responsibilities and authorities for relevant roles, including responsibility for conformity and for reporting on performance. Note that Annex A adds more here (A.3.2, A.3.3), and that the reporting-of-concerns control expects a route that works even when the concern is unwelcome.
Auditor wants Named individuals, documented authority, and a reporting line to top management that has actually carried traffic.
07Clause 6 — Planning
The engine room. Everything else in the standard is downstream of what happens here.
General
Considering context (4.1) and interested parties (4.2), determine the risks and opportunities to be addressed, plan actions, and plan how to integrate and evaluate them.
AI risk assessment
Define and apply a process that establishes risk criteria, identifies AI risks, analyses and evaluates them, and produces consistent, valid and comparable results. Consistency is the auditable property: two assessors on comparable systems should land in comparable places.
Auditor wants A documented method with criteria, and a set of assessments demonstrating it was followed.
AI risk treatment
Select treatment options, determine the controls necessary, compare against Annex A to check nothing has been overlooked, produce the Statement of Applicability, formulate a treatment plan, and obtain risk owners' approval of the plan and their acceptance of residual risk.
Auditor wants The SoA, the treatment plan, and documented residual-risk acceptance by a named owner with the authority to accept it.
AI system impact assessment
Define a process for assessing potential consequences for individuals, groups of individuals and societies throughout the AI system life cycle. This is the clause that has no counterpart in 27001 or 9001, and the one ISO/IEC 42005 was written to serve. It is a distinct exercise from 6.1.2 — that one asks what could happen to the organisation, this one asks what could happen to everyone else.
Auditor wants A documented impact assessment process, and completed assessments for the AI systems in scope.
AI objectives and planning to achieve them
Set objectives at relevant functions and levels: consistent with the policy, measurable where practicable, monitored, communicated, updated. Then plan what will be done, with what resources, by whom, by when, and how results are evaluated. Annex C is the idea bank if the objectives are not obvious.
Auditor wants Objectives that are actually measured, with results that occasionally show a miss. Objectives that are always met are not measuring anything.
Planning of changes
Changes to the AIMS must be carried out in a planned manner. In AI this is doing more work than it appears to: a model retrained, a data source swapped, a vendor upgrading a foundation model beneath you — each is a change that can invalidate an assessment made against the previous state.
Auditor wants A change process where AI-specific changes trigger re-assessment, plus evidence it fired at least once.
08Clause 7 — Support
Resources
Determine and provide the resources needed. Annex A area A.4 expands this into AI-specific resource categories — data, tooling, compute, human — and expects each to be documented.
Competence
Determine necessary competence, ensure people are competent, take action where they are not, and retain evidence. The AI-specific edge: competence here is not only technical. Someone must be competent to judge fairness, someone to judge the legal position, someone to judge what happens to the affected person. A team of excellent engineers can be collectively incompetent for this clause.
Auditor wants A competence matrix mapped to roles, training records, and evidence that a gap was identified and closed.
Awareness
People doing work under your control must be aware of the AI policy, their contribution, and the implications of not conforming. Tested by asking them, not by counting attendance at a briefing.
Communication
Determine internal and external communications relevant to the AIMS: what, when, with whom, how. Annex A area A.8 substantially extends the external side — user documentation, external reporting, incident communication.
Documented information
7.5.1 what must exist, 7.5.2 creating and updating it, 7.5.3 controlling it — availability, protection, distribution, retention, version control. Unglamorous and the most common source of minor nonconformities, because uncontrolled documents are trivially easy to find and impossible to argue about.
Auditor wants Version control, approval, and a retention schedule that is followed.
09Clause 8 — Operation
Clause 6 plans it; clause 8 does it. The pairing is deliberate and auditors check both halves.
Operational planning and control
Plan, implement and control the processes needed to meet requirements and implement clause 6 actions; control planned changes and review unintended ones, acting to mitigate adverse effects; and control externally provided processes, products and services. That last item is where foundation-model vendors and AI SaaS land.
Auditor wants Operating procedures, change records, and supplier controls that match Annex A area A.10.
AI risk assessment
Perform assessments at planned intervals and when significant changes occur; retain the results. The operational counterpart to 6.1.2.
AI risk treatment
Implement the treatment plan and retain results. The counterpart to 6.1.3, and the place where a plan that was never resourced becomes visible.
AI system impact assessment
Perform impact assessments at planned intervals and on significant change, and retain documented information on the results. The counterpart to 6.1.4 — and the clause that turns your 42005-shaped process into evidence.
Auditor wants Completed, dated, approved impact assessments for in-scope systems, with review dates that have not silently passed.
10Clause 9 — Performance evaluation
Monitoring, measurement, analysis and evaluation
Determine what needs monitoring, by what methods, when, and when results are analysed and evaluated — then evaluate AIMS performance and effectiveness and retain the evidence. For AI, monitoring must reach the systems themselves, not just the process: drift, disaggregated performance, incident rates, override rates.
Auditor wants Defined measures with defined methods, and a trend line rather than a snapshot.
Internal audit
Conduct internal audits at planned intervals (9.2.1) under a documented programme (9.2.2) covering frequency, methods, responsibilities, planning and reporting — selecting auditors who ensure objectivity and impartiality. ISO 19011 is the standard that tells you how to do this properly, and it is the reason the two documents are so often implemented together.
Auditor wants An audit programme, competent and impartial auditors, findings that are not all positive, and closure evidence.
Management review
Top management reviews the AIMS at planned intervals (9.3.1) against a defined input set (9.3.2) — status of prior actions, changes in issues and interested parties, performance and trends, nonconformities, audit results, opportunities for improvement — and produces decisions and actions (9.3.3).
Auditor wants Minutes covering every required input, with decisions and owners. A review with no decisions reads as a briefing.
11Clause 10 — Improvement
Continual improvement
Continually improve the suitability, adequacy and effectiveness of the AIMS.
Nonconformity and corrective action
When a nonconformity occurs: react, control and correct it, deal with the consequences; then evaluate whether action is needed to eliminate the cause so it does not recur — including reviewing the nonconformity, determining its causes, and checking whether similar ones exist elsewhere. Implement, review effectiveness, update risks if needed, change the AIMS if needed. Retain evidence of the nature of the nonconformity, the actions and the results.
Auditor wants A nonconformity log with genuine root-cause analysis and effectiveness checks. “Retrained the staff member” as a root cause is the classic weak entry.
An AIMS with no recorded nonconformities in twelve months is not a mature system — it is a system that is not looking. Experienced auditors read an empty log as a finding in itself, and a healthy log of small, well-closed nonconformities as evidence the loop is running.
12Annex A — the 38 controls
Nine objective areas, numbered A.2 to A.10. Normative, but selectively applied: you draw from the catalogue, justify what you take and what you leave, and record both in the Statement of Applicability. Annex B gives implementation guidance for each.
| Ref | Control |
|---|---|
| A.2 — Policies related to AI | |
| A.2.2 | AI policy |
| A.2.3 | Alignment with other organizational policies |
| A.2.4 | Review of the AI policy |
| A.3 — Internal organization | |
| A.3.2 | AI roles and responsibilities |
| A.3.3 | Reporting of concerns |
| A.4 — Resources for AI systems | |
| A.4.2 | Resource documentation |
| A.4.3 | Data resources |
| A.4.4 | Tooling resources |
| A.4.5 | System and computing resources |
| A.4.6 | Human resources |
| A.5 — Assessing impacts of AI systems | |
| A.5.2 | AI system impact assessment process |
| A.5.3 | Documentation of AI system impact assessments |
| A.5.4 | Assessing AI system impact on individuals or groups of individuals |
| A.5.5 | Assessing societal impacts of AI systems |
| A.6 — AI system life cycle | |
| A.6.1.2 | Objectives for responsible development of AI system |
| A.6.1.3 | Processes for responsible design and development of AI systems |
| A.6.2.2 | AI system requirements and specification |
| A.6.2.3 | Documentation of AI system design and development |
| A.6.2.4 | AI system verification and validation |
| A.6.2.5 | AI system deployment |
| A.6.2.6 | AI system operation and monitoring |
| A.6.2.7 | AI system technical documentation |
| A.6.2.8 | AI system recording of event logs |
| A.7 — Data for AI systems | |
| A.7.2 | Data for development and enhancement of AI system |
| A.7.3 | Acquisition of data |
| A.7.4 | Quality of data for AI systems |
| A.7.5 | Data provenance |
| A.7.6 | Data preparation |
| A.8 — Information for interested parties | |
| A.8.2 | System documentation and information for users |
| A.8.3 | External reporting |
| A.8.4 | Communication of incidents |
| A.8.5 | Information for interested parties |
| A.9 — Use of AI systems | |
| A.9.2 | Processes for responsible use of AI systems |
| A.9.3 | Objectives for responsible use of AI system |
| A.9.4 | Intended use of the AI system |
| A.10 — Third-party and customer relationships | |
| A.10.2 | Allocation of responsibilities |
| A.10.3 | Suppliers |
| A.10.4 | Customers |
Reading the catalogue by role
The controls are not equally weighted for everyone, and pretending otherwise produces a bloated SoA.
| If you are a… | Centre of gravity | Often light or excluded |
|---|---|---|
| Developer | A.6 life cycle, A.7 data, A.4 resources, A.5 impact | Parts of A.9 (use), where you do not operate the system |
| Provider | A.8 information for interested parties, A.10 customers, A.6, A.5 | Parts of A.7 where data is the customer's |
| User / deployer | A.9 use, A.10 suppliers, A.5 impact, A.8 to your own affected parties | Much of A.6 development, where you build nothing |
An exclusion must be justified by applicability, not by inconvenience. “We do not develop AI systems; we deploy a third-party model under contract, and development controls sit with the provider under A.10.2” is a justification. “Not applicable” on its own is a nonconformity waiting to be written — and where you have pushed responsibility to a supplier, the auditor will ask to see the contract that carries it.
13Annexes B, C and D
Annex B — Implementation guidance for AI controls
Normative, and the longest part of the standard. It walks each Annex A control and explains what implementing it actually involves. If you are writing controls from the one-line titles in Annex A alone, you are guessing at something the standard already tells you. Read Annex B before drafting a single control statement.
Annex C — Potential AI-related organizational objectives and risk sources
Informative, and the most useful thing to have open during a risk workshop. It is a prompt list — objectives you might set, risk sources you might have missed. Teams that run clause 6.1.2 from a blank page produce risk registers that mirror their own professional blind spots; Annex C is the corrective.
Annex D — Use of the AI management system across domains or sectors
Informative. How the AIMS adapts to a sector — health, finance, public administration — and how it coexists with sector-specific regimes. Short, but relevant if you are integrating with an existing regulated quality system.
14The Statement of Applicability
The single document an auditor will spend the most time on, because it is where risk assessment, control selection and reality are supposed to reconcile.
Clause 3.26 defines it as documentation of all necessary controls plus justification for inclusion or exclusion. In practice it is a table, and it has to answer four questions per row without the reader having to open anything else.
| Column | Content | What makes it fail |
|---|---|---|
| Control | Annex A reference and title, plus any control you added yourself | Only Annex A rows — the standard explicitly allows exceeding the list, and mature systems do |
| Applicable? | Yes / no | Everything marked yes, to look thorough. It reads as a system that has not thought about its role. |
| Justification | Why included — traced to a specific risk or impact finding; or why excluded, on applicability grounds | “Best practice” as an inclusion reason. Inclusion should trace to something you assessed. |
| Implementation | How it is implemented and where the evidence lives | A policy reference with no procedure and no record behind it |
| Status | Implemented / partial / planned, with owner and date | Everything “implemented” on day one. Partial with a credible date is more believable and audits better. |
Pick any row marked applicable and walk backwards: which risk or impact finding drove it? Then forwards: what evidence proves it operates? An SoA that survives that walk in both directions on a random sample is a system. One that does not is a spreadsheet.
15What you actually have to write
The documented information an AIMS needs, in the order it tends to get created. Depth should be proportionate — a small organisation's version of each can be a page.
Context
- Context analysis — internal and external issues
- Interested parties register with their requirements
- AIMS scope statement (required documented information)
- AI system inventory, with your role for each: develop / provide / use
Leadership
- AI policy (required)
- Roles, responsibilities and authorities
- Route for reporting concerns (A.3.3)
Planning
- AI risk assessment process and criteria (required)
- Risk register with owners
- AI risk treatment process and treatment plan (required)
- Statement of Applicability (required)
- Residual risk acceptance records
- AI system impact assessment process (required) — see ISO/IEC 42005
- AI objectives and plans (required)
Support
- Competence matrix and training records (required as evidence)
- Awareness materials
- Communication plan
- Documented information control procedure
- Resource documentation per A.4 — data, tooling, compute, people
Operation
- Operational procedures per applicable Annex A controls
- Change control procedure with AI-specific triggers
- Completed risk assessments (required records)
- Completed impact assessments (required records)
- Supplier and customer responsibility allocations (A.10)
- Incident response and communication procedure (A.8.4)
Evaluation and improvement
- Monitoring and measurement plan and results (required)
- Internal audit programme and reports (required)
- Management review minutes with decisions (required)
- Nonconformity and corrective action log (required)
- Improvement register
16Getting certified
-
Choose an accredited body
Accreditation is what makes a certificate mean anything. Check the certification body is accredited for ISO/IEC 42001 by a recognised national accreditation body — the scheme is young, and unaccredited certificates exist.
-
Stage 1 — readiness review
Largely documentary. The auditor checks the scope, the policy, the SoA, the risk and impact assessment processes, and whether internal audit and management review have run at least once. Stage 1 findings are normal and are meant to be actionable before stage 2.
-
Close the gaps
Typically weeks. The most common stage 1 gaps: an SoA that does not trace to risk, an impact assessment process defined but never performed, and a management review that has not happened yet because the system is too new.
-
Stage 2 — certification audit
On site and in depth. The auditor samples, follows threads and talks to people who are not in the governance team. Evidence of the loop operating over time is what is being tested — which is why you cannot compress the run-up below a few months of real operation.
-
Certificate and surveillance
A three-year cycle with surveillance audits, usually annual. Recertification at the end. Surveillance is where systems built for the audit rather than for use tend to unravel.
From a standing start, six to twelve months is the honest range for a first certification, and the binding constraint is rarely documentation — it is that clauses 9 and 10 need operating history. You cannot show an internal audit programme, a management review with trend data, and a closed corrective action if the system has only existed for three weeks.
1742001 and its neighbours
| Standard | Asks | Type | Relationship to 42001 |
|---|---|---|---|
| ISO/IEC 42001 | Is AI governed here, systematically? | Requirements, certifiable | The frame everything else hangs on |
| ISO/IEC 42005 | What could this system do to people? | Guidance | How to satisfy 6.1.4, 8.4 and A.5 |
| ISO/IEC 23894 | What could this do to the organisation? | Guidance | How to satisfy 6.1.2 and 8.2 |
| ISO/IEC 38507 | What does using AI mean for the board? | Guidance | Speaks to the governing body (3.22), above the AIMS |
| ISO/IEC 22989 | What do these words mean? | Terminology | Normative reference — the shared vocabulary |
| ISO 19011 | How do we audit a management system? | Guidance | How to satisfy 9.2 internal audit |
| ISO/IEC 5259 | Is the data good enough? | Guidance | Supports A.7 data controls |
| ISO/IEC 5338 | What are the AI life cycle processes? | Guidance | Supports A.6 life cycle controls |
Running it alongside 27001 and 9001
The harmonized structure means clauses 4, 5, 7, 9 and 10 are structurally near-identical across the three. That is a genuine and often underclaimed saving: one context analysis, one interested-parties register, one documented information procedure, one internal audit programme, one management review covering all systems. What does not merge is clause 6 and clause 8 — AI risk assessment, AI risk treatment and AI system impact assessment are specific, and an information security risk assessment does not discharge any of them.
The trap runs the other way too. Teams with a mature ISMS often try to extend it by adding AI risks to the existing register. It looks efficient and it fails the impact requirement completely, because an ISMS register is scoped to the organisation's own exposure and has nowhere to record a harm borne by someone else.
18Regulatory relationship
42001 is not a compliance certificate for any statute. What it gives you is the governance apparatus most AI regulation assumes you already have.
- EU AI Act. Providers of high-risk systems must operate a quality management system and a risk management system, keep technical documentation, enable logging, ensure human oversight, and run post-market monitoring. Every one of those has a home in 42001 — A.6.2.7, A.6.2.8, A.6.2.6, clause 8, clause 9. Harmonised standards under the Act are a separate track and 42001 is not one of them, so conformity here is not presumption of conformity there. But an organisation with a working AIMS is doing most of the underlying work already.
- Sectoral regulators. In finance, health and the public sector, a certificate is increasingly what a supervisor accepts as evidence that AI governance is systematic rather than improvised.
- Procurement. The fastest-moving driver in practice. Enterprise and public buyers have started asking for 42001 in RFPs, and for many organisations that commercial pull, not regulation, is what actually funds the programme.
19Where it goes wrong
Generic IT governance in AI clothing
Controls that would read identically for a database. The introduction asks you to focus on what is unique to AI — continuous learning, opacity, data-derived behaviour. If none of your controls address those, the system is not really about AI.
Impact assessment collapsed into risk assessment
The most common substantive failure. 6.1.2 and 6.1.4 are separate clauses with separate operational counterparts for a reason. Merging them always produces the organisational lens, because that is the one with a budget attached.
An SoA that traces to nothing
Controls selected because they are in Annex A rather than because a risk or impact finding demanded them. It inverts the standard's logic and it collapses the first time an auditor picks a row at random.
A scope that flatters
Certifying the one well-governed product while the AI features shipping across the rest of the business sit outside. Legal, and corrosive — customers read the certificate as covering you, and the gap between the scope statement and their assumption is where the reputational damage lives.
No AI inventory
You cannot govern a portfolio you have not enumerated, and the enumeration is nearly always a surprise — embedded AI features in SaaS tools, models a team stood up without telling anyone, vendor capabilities switched on by default.
Certification as the objective
Systems built to pass an audit pass the audit and then decay through the surveillance cycle. The audit tests the loop; a loop that only runs when an auditor is booked is visible by the second surveillance visit.
Top management commitment on paper
Clause 5.1 says demonstrate. A signed policy and no attendance at management review is the pattern auditors are trained to spot, and it undermines everything downstream because nothing has authority behind it.
Nothing changes when a control fails
The deepest failure and the hardest to fix late. If a monitoring signal breaching its threshold produces no action, the control is decorative. Wire consequences in from the start.
20A six-month rollout
For an organisation starting from nothing and aiming at certification. Months 5 and 6 exist because clauses 9 and 10 need operating history — they cannot be compressed.
-
Month 1 · Inventory and scope
Enumerate every AI system you develop, provide or use, including the embedded ones. Decide your role for each. Draft the AIMS scope (4.3) and get top management to own it. Do the context analysis and interested-parties register while the inventory is fresh.
-
Month 2 · Policy and risk method
Write the AI policy (5.2) and make it take a position. Define the risk assessment method and criteria (6.1.2) and the impact assessment process (6.1.4) — the latter built to ISO/IEC 42005. Assign roles and authorities (5.3) with names.
-
Month 3 · Assess
Run risk assessments and impact assessments on the in-scope systems, starting with the highest-exposure. Resist the urge to write controls first; the assessments are what justify them.
-
Month 4 · Controls and SoA
Select controls against Annex A, reading Annex B as you go. Build the Statement of Applicability with real justifications and honest status. Write the treatment plan and get residual risk formally accepted by named owners.
-
Month 5 · Operate and evidence
Run the system. Start monitoring (9.1), generate records, work the treatment plan. This is the month that creates the evidence stage 2 will sample, and there is no substitute for elapsed time.
-
Month 6 · Audit and review
Run the first internal audit (9.2) using ISO 19011, with auditors who are competent and genuinely impartial. Raise real nonconformities and close them properly (10.2). Hold the first management review (9.3) with the full input set and recorded decisions. Then book stage 1.
21What it will not do
- It does not make your AI safe. It makes your governance systematic. A well-run AIMS around a badly conceived system produces excellent documentation of a bad idea.
- It does not make you legally compliant. Not with the EU AI Act, not with any sectoral regime. It builds the apparatus those regimes assume.
- It does not tell you what to build or what to refuse. Where your line sits is a judgement the standard deliberately leaves with you and your governing body.
- It does not assess AI systems. It requires that you assess them. The methods live in 42005, 23894, 5259, 5338 and TS 4213.
- It does not replace domain expertise. Clause 7.2 asks for competence precisely because the standard cannot supply it.
- A certificate is not a rating. It says a management system meeting the requirements was operating within a stated scope at a point in time. Read the scope, always.
22Sources
- ISO/IEC 42001:2023 on the ISO Online Browsing Platform — foreword, introduction, scope, normative references, all 26 terms and the bibliography are publicly viewable. Clauses 4–10 and Annexes A–D are not.
- ISO catalogue entry — ISO/IEC 42001:2023. Clause and annex numbering confirmed against the publicly available document preview.
- Annex A control titles compiled from public control listings, cross-checked against the A.5 series: Mindset Cyber, Konfirmity, ISMS.online.
- Companion guides in this series: ISO/IEC 42005 — AI system impact assessment.
ISO/IEC 42001:2023 is a copyrighted work of ISO and IEC. Nothing here reproduces its requirement text; clause and control titles are cited as references, and the publicly viewable scope and definitions are paraphrased. This is an independent implementation reading, not a substitute for the standard, and not endorsed by ISO or IEC. Purchase the standard before relying on it for certification work.