ISO 42001 implementation framework means the sequence in which the AIMS is built. Governance means the structures, roles, and decision rights that keep it operating once built. The two are inseparable: an AIMS implemented without governance becomes documentation that decays; governance designed before the AIMS exists has nothing to govern. This guide treats them together.
The four-phase ISO 42001 implementation sequence
ISO 42001 implementations divide cleanly into four phases. The phases are not interchangeable — each produces inputs the next depends on — but the work within a phase can run in parallel.
| Phase | Duration (typical) | Output |
|---|---|---|
| 1. Foundation | 4–8 weeks | Scope, role declaration, gap analysis, governance design, project plan |
| 2. Design | 8–12 weeks | AI policy, risk and impact assessment methodology, Statement of Applicability, control design |
| 3. Implementation | 12–24 weeks | Operational controls, documented procedures, evidence systems, training |
| 4. Operation and audit readiness | 8–12 weeks | Internal audit cycle complete, management review held, corrective actions closed, Stage 1 ready |
End-to-end timelines run six to twelve months. Organisations with mature ISO 27001 or ISO 9001 implementations compress the lower end; organisations starting from scratch run to the upper end or beyond.
ISO 42001 Phase 1 — Foundation
The foundation phase produces the answers ISO 42001 Clause 4 requires before any operational work begins. Five deliverables:
| Deliverable | Source | Purpose |
|---|---|---|
| Role declaration | 4.1 | States whether the organisation is provider, developer, deployer, user, or a combination. Determines which Annex A controls bear most heavily. |
| AIMS scope statement | 4.3 | Defines AI systems, business units, geographies, and lifecycle stages covered. The document an auditor reads first. |
| Interested parties register | 4.2 | Identifies parties whose needs the AIMS addresses. Input to AI policy, risk, and impact assessment. |
| Gap analysis | — | Compares current state to Standard requirements. Sizes the implementation effort. |
| Governance design | 5.3 | Names the AIMS owner, defines committee structure, allocates authority. Set before substantive work begins. |
The gap analysis is the most important phase 1 deliverable for resource planning. A credible gap analysis covers all ten clauses and all 38 Annex A controls, identifies what exists, what partially exists, and what is absent, and produces an estimate of effort by clause and control objective. Gap analyses that compress to “high/medium/low” without underlying detail produce implementation plans that miss material work.
The role declaration is the most important phase 1 deliverable for control selection. A provider building foundation models faces a different Annex A surface than a deployer integrating a third-party system or a user procuring AI-enabled software. Organisations with multiple roles must declare each and work through the implications — the Standard accommodates multiple roles but expects each to be addressed.
ISO 42001 Phase 2 — Design
The design phase produces the documents the AIMS will operate on. Six deliverables:
| Deliverable | Source | Purpose |
|---|---|---|
| AI policy | 5.2 | Top-management statement of direction. Framework for objectives. |
| AI risk assessment methodology | 6.1.2 | Criteria, identification approach, analysis, evaluation. Reusable across cycles. |
| AI risk treatment methodology | 6.1.3 | Treatment options, control selection logic, SoA structure. |
| AI impact assessment methodology | 6.1.4 | Approach to assessing effects on individuals, groups, societies. Distinct from risk assessment. |
| Statement of Applicability (first version) | 6.1.3 | Applied controls, justifications, planned implementation. Evolves through phase 3. |
| AI objectives | 6.2 | Measurable, time-bound, resourced, assigned. Linked to AI policy. |
The risk and impact assessment methodologies are the design decisions that determine the AIMS’s substantive quality. Methodologies imported wholesale from ISO 27001 or DPIA frameworks produce assessments that conform on paper and miss the Standard’s substance. The risk methodology should address AI-specific risk sources (Annex C is the conventional reference); the impact methodology should address effects on individuals, groups, and societies across the lifecycle (not effects on the organisation).
The AI policy is the design deliverable most often produced badly. Common failure modes: borrowed from an ethics statement or existing information security policy; written as marketing language; missing the framework-for-objectives requirement in 5.2; signed by someone other than top management. The policy is the document leadership commitment is evidenced against — it must be specific to AI, owned by top management, and structurally connected to the objectives that follow.
ISO 42001 Phase 3 — Implementation
The implementation phase translates design into operation. The work breaks across the nine Annex A objectives and produces the evidence base certification audits sample.
| Annex A objective | Implementation work |
|---|---|
| A.2 Policies | AI policy implementation, supporting policies, policy review cycle |
| A.3 Internal organisation | Roles and responsibilities documented, accountability assigned, reporting lines |
| A.4 Resources | Resource inventory, allocation, lifecycle management |
| A.5 Impact assessment | Impact assessment process operational, assessments performed, results documented |
| A.6 AI system lifecycle | Lifecycle stages defined, processes per stage, gates and evidence |
| A.7 Data | Data governance, provenance, quality, preparation processes |
| A.8 Information for interested parties | User documentation, transparency notices, limitation disclosures |
| A.9 Use of AI systems | Use policies, intended-use documentation, monitoring of use |
| A.10 Third-party and customer relationships | Supplier assessment, customer obligations, contracts |
Implementation work is rarely sequential across objectives — most teams run lifecycle (A.6), data (A.7), and impact (A.5) in parallel because they are the heaviest and most interdependent. Third-party (A.10) is often left late and frequently underestimated; foundation model procurement, AI-enabled SaaS, and AI components from suppliers carry control obligations that must be evidenced through contracts, assessments, and ongoing monitoring.
Training and competence work runs through the entire implementation phase. Clause 7.2 requires evidenced competence for everyone whose work affects the AIMS; Clause 7.3 requires awareness for everyone whose work touches the system. Both must be operational before Stage 1 — training records created the week before audit do not satisfy the requirement.
ISO 42001 Phase 4 — Operation and audit readiness
The fourth phase runs the AIMS for long enough to produce the operational evidence Stage 2 requires. Five deliverables:
| Deliverable | Source | Purpose |
|---|---|---|
| Operational risk and impact assessments | 8.2, 8.4 | Evidence the assessments are recurring, not one-off |
| Monitoring and measurement results | 9.1 | Evidence the AIMS is measured against its objectives |
| Internal audit programme and reports | 9.2 | Evidence of independent audit, findings, closure |
| Management review minutes | 9.3 | Evidence of top-management engagement with prescribed inputs and outputs |
| Nonconformity and corrective action register | 10.2 | Evidence the AIMS responds to its own findings |
A common audit failure mode is reaching Stage 1 with documentation complete and Clauses 9 and 10 evidence absent — no internal audit performed, no management review held, no corrective actions logged. Certification bodies vary in tolerance, but most expect at least one cycle of each before Stage 2.
ISO 42001 governance structures
Governance is the standing architecture that owns the AIMS once built. The Standard requires assignment of responsibility (5.3) but does not specify structure. Practice converges on three layers:
| Layer | Role | Cadence |
|---|---|---|
| Strategic | AIMS owner reporting to top management; AI policy ownership; objectives setting | Annual policy review; quarterly objective review |
| Tactical | AI Management Committee — cross-functional oversight of risk, impact, controls, third-party AI | Monthly |
| Operational | Control owners across the nine Annex A objectives; lifecycle stage owners | Continuous |
The AIMS owner is the most consequential governance role. The Standard does not name the role — Chief AI Officer, Chief Compliance Officer, CISO, Head of AI Governance are all common — but it must be a single named individual with the authority to perform the role and direct reporting to top management. Diffuse ownership across a committee, without a named owner, fails 5.3.
The AI Management Committee is the standing forum where most operational governance happens. Typical composition: AIMS owner (chair), heads of engineering or ML, data governance, security, legal, product, and where relevant ethics or responsible AI. The committee reviews risk and impact assessments, approves Statement of Applicability changes, oversees third-party AI procurement, and prepares inputs for management review.
Management review under 9.3 is the standing forum at the top-management layer. It is the single most concrete evidence of leadership engagement required by the Standard and is checked against Clause 5 commitments. Minutes must show the specific inputs and outputs the Standard requires — not generic leadership-meeting notes that touch on AI.
Decision rights according to ISO 42001
Governance is operative when decision rights are clear. Five decisions recur and benefit from being mapped explicitly:
| Decision | Typical owner | Reviewed by |
|---|---|---|
| AI policy and changes | Top management | — |
| AIMS scope changes | AIMS owner | Top management |
| Statement of Applicability changes (control inclusion/exclusion) | AIMS owner | AI Management Committee |
| AI system entering lifecycle (inception gate) | Lifecycle stage owner | AI Management Committee for high-risk systems |
| Third-party AI procurement above threshold | AIMS owner | AI Management Committee |
Decision rights left implicit produce decisions that get made without the appropriate review and surface as nonconformities at audit. The Statement of Applicability is the document most affected: SoA changes made by individual control owners without committee review are a frequent finding.
What ISO 42001 integration with other management systems looks like
Annex D explicitly supports integration with existing management systems. Where ISO 27001, ISO 9001, or both are in place, integration is generally more efficient than parallel implementation.
| AIMS element | Shared with ISO 27001 / ISO 9001 | AI-specific |
|---|---|---|
| Leadership commitment (5.1) | Shared | — |
| Documented information control (7.5) | Shared | — |
| Internal audit (9.2) | Shared (programme; AI-specific audit content) | Content |
| Management review (9.3) | Shared (cycle; AI-specific inputs) | Inputs |
| Corrective action (10.2) | Shared (process) | — |
| AI policy (5.2) | — | AI-specific |
| AI risk and impact assessment (6.1) | Methodology may extend existing risk framework | AI-specific scope |
| Annex A controls | — | AI-specific |
Integration is structural, not cosmetic. A genuinely integrated AIMS shares the management system spine — leadership, documented information, audit, review, corrective action — and runs the AI-specific obligations as a distinct workstream within it. Implementations that label themselves integrated but maintain parallel policy stacks, parallel audit programmes, and parallel review cycles capture the cost of integration and none of the benefit.
Common ISO 42001 implementation failure modes
Five failure modes recur and account for a disproportionate share of nonconformities and delays:
| Failure mode | Where it surfaces | Underlying cause |
|---|---|---|
| Role ambiguity | Stage 1 audit, scope review | 4.1 role declaration deferred or hedged |
| Borrowed AI policy | Stage 1, document review | 5.2 treated as administrative |
| SoA as inventory | Stage 1 and Stage 2 | 6.1.3 worked as checklist, not risk-driven |
| Impact assessment as risk assessment | Stage 2, sampling | 6.1.4 conflated with 6.1.2 |
| Clause 9 evidence absent at Stage 1 | Stage 1 readiness review | Phase 4 compressed or skipped |
The third and fourth are the most consequential because they reflect the AIMS not internalising the Standard’s worldview. An SoA that catalogues Annex A controls without traceability to identified risks is a structural error, not a documentation oversight. An impact assessment that addresses business risk rather than effects on individuals and societies misses the requirement that most distinguishes ISO 42001 from ISO 27001.
What this guide cannot tell you
Two decisions are organisation-specific and must be made internally:
- Where the AIMS owner sits. Compliance, security, engineering, legal, and product all have plausible claims, and the right answer depends on the organisation’s AI portfolio, regulatory exposure, and existing governance structures. The Standard is silent; practice varies.
- Which certification body to use. ISO 42001 is new, the accredited certification body market is still forming, and accreditation status should be verified directly with national accreditation bodies (UKAS, ANAB, DAkkS, and other IAF MLA signatories) before engagement. Selecting a body without accreditation for ISO 42001 specifically produces a certificate that may not be recognised by customers and partners.
Both decisions are worth deliberate analysis before phase 1 begins. They shape the implementation more than any single technical choice that follows.
