You implement ISO/IEC 42001:2023 on iso.org, the AI management system standard published on 18 December 2023, by working through its clauses 4 to 10 in nine phases and producing a record at each one. The stages run from a gap analysis and your AI roles under clause 4.1, through policy, risk, impact assessment and the Statement of Applicability, to operation, internal audit, management review and the certification audit.
Each phase leaves documented information behind, and those records are what a certification auditor samples. The standard’s own introduction says the order of its requirements does not set the order you implement them in, so the sequence below is a working method, not ISO text. It is the build sequence an implementer runs, and it describes the ISO 42001 implementer job, not the title.
ISO 42001 implementation steps, with clause, record, owner and auditor check
Every ISO 42001 implementation step produces at least one record, and every record has an owner and something an auditor will test. The table is the whole build on one screen.
How to implement ISO/IEC 42001 in nine phases: 1 mandate and gap analysis (clauses 5.1, 4.4), 2 context, AI roles and scope (4.1 to 4.3), 3 AI system register, 4 AI policy, roles and objectives (5.2, 5.3, 6.2), 5 risk assessment, treatment and Statement of Applicability (6.1.1 to 6.1.3), 6 AI system impact assessment (6.1.4), 7 resources, competence and documents (7.1 to 7.5), 8 operate and repeat assessments (8.1 to 8.4), 9 monitor, audit, review and improve (9.1 to 10.2), then the Stage 1 and Stage 2 certification audit
| Step | Clause | Record it produces | Usual owner | What an auditor checks |
| 1. Get a mandate and run a gap analysis | 5.1, 4.4 | Gap analysis report; project mandate | Implementer drafts; top management signs | Top management directs the AIMS, not only funds it |
| 2. Determine internal and external issues, including climate change | 4.1 | Context record | Implementer with legal and strategy | Issues are specific to your AI use and feed the risk assessment |
| 3. Define your AI role for each system | 4.1 | Role determination per AI system (provider, producer, customer, partner, subject) | Implementer with legal and system owners | Roles match what you actually do with each system |
| 4. Identify interested parties and their requirements | 4.2 | Interested parties register, marked with what the AIMS will address | Implementer with legal and privacy | Contract terms and legal requirements are on it |
| 5. Set the scope | 4.3 | Scope statement (documented information) | Top management approves | Boundaries match the AI systems actually in use |
| 6. Build the AI system register | 4.1, 4.3 | AI system register with intended purpose, role and owner | System owners confirm entries | Systems seen in operation appear in the register |
| 7. Write and approve the AI policy | 5.2 | AI policy | Top management | Approval date, communication evidence, staff awareness |
| 8. Assign roles and authorities | 5.3 | Roles, responsibilities and authorities record | Top management | Named people for conformance and for reporting performance |
| 9. Set the risk method and assess AI risk | 6.1.1, 6.1.2 | Risk assessment process, criteria and AI risk register | Risk owners, with the implementer | The method gives repeatable results; each risk has an owner |
| 10. Plan risk treatment and decide controls | 6.1.3 | Risk treatment plan; Statement of Applicability | Management approves | Every Annex A control is applied or excluded with a reason |
| 11. Assess impacts on people and society | 6.1.4 | AI system impact assessments | System owner and named approver | Impacts on individuals, groups and societies were considered |
| 12. Set AI objectives | 6.2 | AI objectives and plans to achieve them | Top management | Objectives are consistent with the policy, measurable where practicable and tracked |
| 13. Plan changes to the AIMS | 6.3 | Change records | Implementer | Changes were made in a planned way |
| 14. Provide resources, competence, awareness and communication | 7.1 to 7.4 | Competence records, awareness evidence, communication plan | Line managers and HR | People in AIMS roles have evidence of competence |
| 15. Control documents and records | 7.5 | Document control rules and version history | Implementer | Current versions are in use; old ones are withdrawn |
| 16. Run operational controls | 8.1 | Records that processes ran as planned | System owners | Deployment approvals, change records and supplier checks exist |
| 17. Repeat AI risk assessment in operation | 8.2 | Updated risk assessments | Risk owners | A significant change triggered a reassessment |
| 18. Implement the treatment plan | 8.3 | Risk treatment results | Control owners | Controls in the Statement of Applicability work, not only exist on paper |
| 19. Repeat impact assessment in operation | 8.4 | Updated impact assessments | System owner | Reassessment followed a change in purpose, data or model |
| 20. Monitor and measure | 9.1 | Monitoring and measurement results | Process owners | Results exist at the frequency you set |
| 21. Audit internally | 9.2 | Internal audit program and reports | Internal audit | Auditors are objective; the whole scope is covered over the cycle |
| 22. Hold a management review | 9.3 | Management review minutes and decisions | Top management | Required inputs were considered; decisions are recorded |
| 23. Correct and improve | 10.1, 10.2 | Nonconformity and corrective action log | Action owners; implementer verifies | The cause was removed and effectiveness was checked |
Source: AI Training Skool implementation map, built on the clause titles in ISO/IEC 42001:2023 (official preview, table of contents). The owner column shows common practice, not wording from the standard.
Two rows trip up most first builds. Row 3 asks you to decide your AI role before anything else, because the role changes which requirements and controls apply. Rows 17 to 19 repeat the clause 6 assessments under clause 8, which many guides skip: planning sets the method, and operation keeps running it.
The table names the records. Separate the ones the standard mandates from the ones you choose to keep, and adapt any starting layout for the register, risk register and Statement of Applicability to your scope. The clause titles come from the free official ISO 42001 preview, since the full standard is sold.
Phase 1: Get a mandate and run a gap analysis (clauses 5.1 and 4.4)
An ISO 42001 implementation starts with two things: top management agreeing to own the AI management system, and a gap analysis that shows how far you are from the requirements. Clause 5.1 puts leadership and commitment on top management, and clause 4.4 requires you to establish, implement, maintain, continually improve and document the AIMS.
Run an ISO 42001 gap analysis against clauses 4 to 10 and the Annex A controls. Score each requirement as in place, partly in place or missing, and attach the evidence you saw. The gap report becomes your project plan and your baseline.
Get the mandate in writing. It should name the sponsor, the implementer, the budget owner and the date of the first management review. An auditor will later ask how top management directs the AIMS, and a signed mandate plus review minutes answers that.
Phase 2: Context, AI roles and scope (clauses 4.1 to 4.3)
Clause 4 is where you decide what the AI management system covers, and the first decision is your AI role. Clause 4.1 says the organization shall “determine its roles with respect to these AI systems”, meaning the systems it develops, provides or uses.
Define your AI role under clause 4.1
The roles listed in clause 4.1 include AI providers, AI producers, AI customers (including users), AI partners and AI subjects, along with relevant authorities. The standard points to ISO/IEC 22989:2022 for a detailed description of the roles. It also notes that roles and their link to the AI life cycle are described in the NIST AI Risk Management Framework, version 1.0, released 26 January 2023. If you plan to run NIST AI RMF and ISO 42001 together, use the same role names in both.
Record the role per AI system, not once for the whole company. For example, a software company can be a provider for the product it sells and a customer for the coding assistant its engineers use. Clause 4.1 also notes that roles can determine how far requirements and controls apply.
Record issues, climate change and interested parties
Clause 4.1 asks for the internal and external issues that affect your AIMS, and it adds one line many teams miss: you must “determine whether climate change is a relevant issue”. Write the answer down either way, with a reason.
Clause 4.2 asks for the relevant interested parties, their requirements and which of those requirements the AIMS will address. Customers’ contract terms, regulators and the people your AI systems make decisions about usually belong on that list.
Set the AIMS scope
Clause 4.3 requires the scope to be available as documented information, built from the issues in 4.1 and the requirements in 4.2. Draw the boundaries around the AI systems actually in use, and record any exclusions with a reason.
Phase 3: Build the AI system register (clauses 4.1 and 4.3)
The AI system register is the list every later phase depends on. ISO/IEC 42001 does not name a mandatory document called an AI inventory, but clause 4.1 requires you to consider the intended purpose of each AI system you develop, provide or use, and clause 4.3 needs a scope you can defend.
A register with one row per AI system is the practical way to evidence both. It also tells you which systems need risk and impact assessments in Phases 5 and 6. Start discovery early, because vendor AI features and unapproved tools rarely show up in a survey. The fields, discovery sources and review triggers are set out in the inventory of AI systems behind an AIMS.
Phase 4: AI policy, roles and objectives (clauses 5.2, 5.3 and 6.2)
Phase 4 of an ISO 42001 implementation produces the leadership records: an AI policy, named roles and AI objectives. Clause 5.2 requires top management to establish an AI policy, clause 5.3 requires responsibilities and authorities to be assigned and communicated, and clause 6.2 requires AI objectives with plans to achieve them.
Write the policy only after the register and scope exist, so it describes the AI you actually run. A policy full of commitments nobody can prove becomes an audit finding. The section-by-section approach is in writing an AI policy you can evidence.
For clause 5.3, name at least two things: who makes sure the AIMS conforms to the standard, and who reports AIMS performance to top management. Then set two or three AI objectives you can measure; one example is the share of in-scope systems with a current impact assessment.
Phase 5: AI risk assessment, risk treatment and the Statement of Applicability (clauses 6.1.1 to 6.1.3)
AI risk work in ISO 42001 runs in three steps: define a method, assess the risks, then choose treatments and controls. Clause 6.1.2 covers the AI risk assessment and clause 6.1.3 the AI risk treatment, which produces the risk treatment plan and the Statement of Applicability.
Define the method before you score anything: the scales, the criteria for acceptable risk and who may accept a residual risk. Good criteria give the same answer when two people score the same system. Scales, criteria and treatment are worked through in ISO 42001 risk assessment with ISO 31000 terms.
Risk treatment means comparing the controls you need with Annex A. The standard defines the Statement of Applicability (definition 3.26) as documentation of all necessary controls and the justification for including or excluding them. You do not have to apply every Annex A control, and you may add your own. Check coverage against Annex A of ISO/IEC 42001 by theme, then record each decision in the ISO 42001 Statement of Applicability.
Annex A is normative, and so is Annex B, its implementation guidance, according to the official table of contents. Annexes C and D are informative.
Phase 6: AI system impact assessment (clause 6.1.4)
The AI system impact assessment asks a different question from the risk assessment: what could this system do to people outside the organization? ISO/IEC 42001 defines it (definition 3.24) as a formal, documented process that identifies, evaluates and addresses impacts on individuals, groups of individuals, or both, and societies.
Risk assessment protects the organization’s objectives; impact assessment looks at the people a system affects. Run it before deployment and again when the system’s purpose, data or model changes. The method, from affected groups to sign-off, is in running an ISO 42001 AI system impact assessment.
Feed the results back into the risk register. An impact on a group of people that you cannot reduce usually becomes a risk with a treatment and an owner.
Phase 7: Resources, competence, awareness and documented information (clauses 7.1 to 7.5)
Clause 7 supplies what the AIMS runs on: resources (7.1), competence (7.2), awareness (7.3), communication (7.4) and documented information (7.5). Most of the evidence here is ordinary HR and document control, applied to the people doing AI governance work.
For competence, decide what each AIMS role needs to know, close the gaps through training or hiring, and keep the evidence. An auditor will pick a risk owner or an impact assessor and ask how you know that person is competent. Keep the records that answer that question for every person in an AIMS role.
For communication, write down what you will communicate, when, to whom and how, internally and externally. For documented information, set the rules for naming, versioning, approval and retention once, and apply them to every record in the table above.
Phase 8: Operate the AIMS and repeat the assessments (clauses 8.1 to 8.4)
ISO/IEC 42001 clause 8, Operation, is where the clause 6 work becomes routine. Clause 8.1 requires you to plan and control the processes the AIMS needs. Clauses 8.2, 8.3 and 8.4 then repeat the three assessment titles from planning: AI risk assessment, AI risk treatment and AI system impact assessment.
Planning (6.1.2 to 6.1.4) sets up the processes. Operation (8.2 to 8.4) requires you to run them: published clause summaries describe risk assessment at planned intervals and when significant changes are proposed or occur, with the results kept as documented information. An AIMS that assessed every system once, during the project, and never again fails here.
Write down what counts as a significant change. Common triggers are a new intended use, a new data source, a model version change, a new vendor AI feature switched on and a new group of people affected. Then keep operational records: deployment approvals, change approvals, supplier checks and monitoring output, such as performance and model drift checks.
Let the AIMS run for long enough to produce evidence before you book the audit. An auditor wants to see processes operating, not documents dated the week before Stage 1.
Phase 9: Monitor, audit, review and improve (clauses 9.1 to 10.2)
Phase 9 of an ISO 42001 implementation proves the AIMS works and fixes what does not. Clause 9.1 covers monitoring and measurement, 9.2 internal audit, 9.3 management review, 10.1 continual improvement and 10.2 nonconformity and corrective action.
Set up the audit program early, so the first internal audit can cover the full scope before certification. Internal auditors must be objective, so the person who built a process should not audit it. Plan the program, the sampling and the report format before the first audit starts.
Management review is top management’s formal look at the AIMS, with inputs set by clause 9.3.2 and results by 9.3.3. Check the clause 9.3.2 inputs before the first meeting so the minutes show every required input.
Findings from audits, reviews and incidents go into one log. For each entry, find the cause, act on it and check that the fix worked.
What carries over if you already hold ISO/IEC 27001
If you run an ISO/IEC 27001 information security management system, much of the ISO 42001 management system already exists. ISO/IEC 42001 applies the harmonized structure (identical clause numbers, clause titles, text, and common terms and core definitions shared by management system standards), so the clause 4 to 10 machinery carries over.
| Area | Reuse from your ISO/IEC 27001 system | New work for ISO/IEC 42001 |
| Context and scope | Issues method, interested parties method, scope format | AI roles per system (4.1), intended purpose of each AI system, the AI system register |
| Climate change | The climate change determination added to ISO/IEC 27001:2022 by Amendment 1:2024 | Repeat the determination for the AIMS context |
| Leadership | Policy format, approval route, roles matrix | The AI policy and AI-specific responsibilities |
| Risk | Risk process skeleton, scales, risk owner model | AI risk sources and criteria; the AI system impact assessment (6.1.4, 8.4), which has no ISO/IEC 27001 equivalent |
| Controls | Statement of Applicability format; security controls such as access control, logging and supplier management | Annex A AI control areas, such as AI system life cycle, data for AI systems and use of AI systems (area names as listed by the IAPP) |
| Support | Document control, competence process, awareness program | AI competence requirements for assessors and system owners |
| Evaluation and improvement | Internal audit program, management review, corrective action process | AI objectives, AI monitoring measures, AIMS scope added to audits and reviews |
Source: AI Training Skool, from the harmonized structure statement in the ISO/IEC 42001:2023 introduction (official preview) and the ISO/IEC 27001:2022 record on iso.org (Amd 1:2024, climate action changes). Annex A area names follow the IAPP’s June 2024 summary of the standard. The split shows typical reuse, not a measured saving.
Run one integrated system where you can: one document control process, one internal audit program covering both scopes and one management review with both sets of inputs. Keep the AI system impact assessment as its own process, because a security risk method will not ask about effects on people. If your security team is new to the AI side, start with the AI management system requirements in ISO/IEC 42001 before you map the two systems.
How long does ISO 42001 implementation take?
ISO/IEC 42001 sets no implementation timeline, and no published primary source gives a standard duration. The ranges below are AI Training Skool planning assumptions for one scope with a few AI systems, not survey data.
| Phase | Typical planning range (assumption) | What stretches it |
| 1. Mandate and gap analysis | 2 to 4 weeks | Sponsor not yet named |
| 2. Context, AI roles and scope | 2 to 4 weeks | Several business units, unclear roles |
| 3. AI system register | 3 to 6 weeks | Shadow AI, embedded vendor AI, AI agents |
| 4. Policy, roles and objectives | 2 to 4 weeks | Approval cycles at board level |
| 5 and 6. Risk, treatment, Statement of Applicability, impact assessment | 4 to 10 weeks | Many systems, systems you develop rather than buy |
| 7. Support | Runs alongside Phases 4 to 6 | Hiring for competence gaps |
| 8. Operation producing evidence | Plan for at least one full review cycle | Systems changing during the project |
| 9. Internal audit and management review | 3 to 6 weeks | Findings that need corrective action before Stage 1 |
Source: AI Training Skool planning assumptions. Not a measured average; your gap analysis sets the real plan.
An existing ISO/IEC 27001 system usually shortens Phases 4, 7 and 9, since those processes already run. Developing AI systems, rather than only using them, lengthens Phases 5 and 6. Build your month-by-month plan from the Phase 1 gap analysis, not from these ranges.
Stage 1 and Stage 2 certification audits
The ISO/IEC 42001 certification audit runs in two parts: Stage 1 reviews your documented AIMS and readiness, and Stage 2 tests whether the system is implemented and effective. Certification is a separate step from implementation, carried out by an accredited certification body, not by ISO. Annual surveillance audits follow, with recertification in year three.
In the US, ANAB launched its ISO/IEC 42001 accreditation program for certification bodies in January 2024. ISO/IEC 42006:2025 sets extra requirements for bodies that audit and certify AI management systems. Bring every record from the table above to Stage 1, with the clause and owner for each.
Before you book, check that the certification body is accredited for ISO/IEC 42001 and agree on the certified scope with it.
Who should lead an ISO 42001 implementation?
An ISO 42001 implementation needs one named implementer to own the sequence, with system owners, legal, security and top management each signing their own records. The implementer drafts, coordinates and keeps the evidence current; risk owners, approvers and top management make the decisions.
That person needs to read the clauses, run assessments with technical teams and turn decisions into records an auditor can follow. If you plan to lead the build yourself and want structured practice first, ISO/IEC 42001 Lead Implementer training with implementation templates and checklists covers clauses 4 to 10 and Annex A. Its case study works an AI register, impact assessment, risk register and Statement of Applicability end to end.
Frequently Asked Questions
What are the steps to implement ISO 42001?
ISO 42001 implementation runs in nine phases. Start with a gap analysis and mandate (clauses 5.1, 4.4), then context, AI roles and scope (4.1 to 4.3) and the AI system register. Next come policy, roles and objectives (5.2, 5.3, 6.2), risk and treatment (6.1.1 to 6.1.3), impact assessment (6.1.4) and support (7). Finish with operation (8.1 to 8.4), followed by audit, review and improvement (9 and 10).
What does ISO 42001 require an organization to do first?
ISO/IEC 42001:2023 does not fix an order; its introduction says the order of requirements does not imply the order of implementation. In practice, start with top management’s mandate under clause 5.1 and the clause 4.1 decisions: your internal and external issues, whether climate change is relevant, and your role for each AI system, such as provider, producer or customer.
Is ISO 42001 implementation mandatory?
No. ISO/IEC 42001:2023 is a voluntary international standard. None of the US instruments we track as of October 2026, including Texas TRAIGA and the NIST AI RMF, requires ISO/IEC 42001 certification. Organizations implement it to answer customer and regulator questions with evidence. Certification is optional too, and accredited certification bodies issue it, not ISO.
How do you apply for ISO 42001 certification?
You do not apply to ISO, which does not issue certificates. ISO/IEC 42001 certification comes from a certification body, preferably one accredited for ISO/IEC 42001 by an accreditation body such as ANAB in the US. Once your AIMS has produced records, including an internal audit and a management review, request a quote, agree on the certified scope, then book the Stage 1 and Stage 2 audits.
Can an ISO 27001-certified company implement ISO 42001 faster?
Usually yes. ISO/IEC 42001 uses the same harmonized structure as ISO/IEC 27001, so document control, internal audit, management review and corrective action processes carry over. The new work is AI-specific: AI roles under clause 4.1, the AI system register, the AI policy, AI risk criteria, the AI system impact assessment under clauses 6.1.4 and 8.4, and the Annex A AI controls.
Why does ISO 42001 repeat risk and impact assessment in clause 8?
Clauses 6.1.2 to 6.1.4 set up the AI risk assessment, risk treatment and impact assessment processes as planning. Clauses 8.2 to 8.4 require you to perform them in operation, at planned intervals and when significant changes occur. An AIMS that assessed each system once during the project, and never again, does not meet clause 8.
