# 03 — ISO/IEC 42001:2023 (AIMS) Deep Reference

ISO/IEC 42001:2023 *Information technology — Artificial intelligence — Management system* is the **certifiable management standard** for organisations that provide or use AI systems. It is the AI-specific counterpart to ISO/IEC 27001 (information security) — same Annex SL High-Level Structure, but with AI-specific requirements anchored in clauses 4–10 and 38 reference controls in Annex A.

This reference is the substantive standards content. For mapping to AI Act articles, see `05-crosswalk-aiact-iso.md`.

## 1. Scope and key concepts

**Scope (clause 1)**: Specifies requirements for establishing, implementing, maintaining and continually improving an AI management system within an organization. The scope is **broader than ISO 27001's** because the "interested parties" explicitly include **affected individuals and society**, not just customers — reflecting AI's externalities (fairness, autonomy, environmental impact).

**Normative references (clause 2)**: ISO/IEC 22989:2022 (AI concepts and terminology). Clause 3 inherits 22989's vocabulary plus AIMS-specific terms.

**Key terms** (from ISO/IEC 22989 and 42001 cl. 3):

- **AI system** — engineered system that generates outputs (predictions, recommendations, content, decisions) for a given set of human-defined objectives
- **AI lifecycle** — the phases an AI system passes through: inception, design, development, verification, deployment, operation, monitoring, decommissioning
- **AI provider, AI developer, AI deployer, AI user, AI subject** — distinct roles in the AI value chain (note: 42001's "AI user" ≠ AI Act's "deployer"; 42001's "AI deployer" matches AI Act's deployer)
- **Intended use** — use of an AI system in a given context as specified by the provider
- **AI system impact assessment (AISIA)** — structured assessment of AI system impacts on individuals, groups, society, and environment

## 2. The 10 clauses (Annex SL HLS — AI-specific layer)

### Clause 4 — Context of the organization

| Sub-clause | Title | What's AI-specific |
|------------|-------|-------------------|
| 4.1 | Understanding the organization and its context | Internal/external issues including AI ethics, fairness, societal effect; legal/regulatory landscape (AI Act, sector laws) |
| 4.2 | Understanding the needs and expectations of interested parties | Explicitly extends to **AI subjects** (affected individuals), workers' representatives, regulators, civil society |
| 4.3 | Determining the scope of the AIMS | Must document the **AI roles** played per system (provider/developer/deployer/user) — this drives different control selections |
| 4.4 | AI management system | The AIMS itself: documented, integrated with other management systems where appropriate |

### Clause 5 — Leadership

| Sub-clause | Title | Notes |
|------------|-------|-------|
| 5.1 | Leadership and commitment | Top management establishes AI policy, ensures resources, communicates importance |
| 5.2 | AI policy | Must address responsible AI principles: **fairness, accountability, transparency, explainability, safety, security, privacy, human oversight**. Documented, communicated, available to interested parties |
| 5.3 | Roles, responsibilities and authorities | Assignment of AIMS roles; reporting on performance and improvement to top management |

### Clause 6 — Planning (the AIMS-distinctive heart)

| Sub-clause | Title | What's AI-specific |
|------------|-------|-------------------|
| 6.1.1 | Actions to address risks and opportunities — General | High-level planning hooks |
| **6.1.2** | **AI risk assessment** | Identify, analyse, evaluate AI risks per ISO/IEC 23894. Risk sources include: **autonomy, opacity, complexity, data dependency, robustness limitations, bias, hallucination, environmental impact, manipulation, value alignment** |
| **6.1.3** | **AI risk treatment** | Select and apply controls (Annex A reference plus organization-specific). Document a **Statement of Applicability (SoA)** justifying inclusion/exclusion of each Annex A control |
| **6.1.4** | **AI system impact assessment (AISIA)** | A *separate, structured* assessment of impacts on individuals, groups of individuals, and society. **Unique to 42001** — not present in 27001. Mirrors and operationalizes AI Act art. 27 FRIA. ISO/IEC 42005:2025 elaborates this clause |
| 6.2 | AI objectives and planning to achieve them | Measurable AI objectives aligned with AI policy |
| 6.3 | Planning of changes | Change management for the AIMS — version control, impact assessment of changes |

### Clause 7 — Support

| Sub-clause | Title | AI-specific notes |
|------------|-------|-------------------|
| 7.1 | Resources | Compute, data, tooling, human resources sufficient for AI lifecycle |
| 7.2 | Competence | **AI/ML-specific skills**: data scientists, ML engineers, AI ethicists, domain experts. Document competence requirements + evidence (training records, certifications) |
| 7.3 | Awareness | All persons doing work under organization's control aware of AI policy + their contribution to AIMS effectiveness + implications of non-conformance |
| 7.4 | Communication | Internal + external communication about AI systems and AIMS — what, when, with whom, how |
| 7.5 | Documented information | Document control + retention. AIMS minimum: policy (5.2), AISIA process (6.1.4), risk register (6.1.2), SoA (6.1.3), objectives (6.2), audit results (9.2), management review outputs (9.3) |

### Clause 8 — Operation

| Sub-clause | Title | Notes |
|------------|-------|-------|
| 8.1 | Operational planning and control | Implement processes to meet requirements + perform actions per cl. 6 |
| 8.2 | AI risk assessment (operational) | Recurring re-execution of cl. 6.1.2 at planned intervals AND on significant changes |
| 8.3 | AI risk treatment (operational) | Recurring re-execution of cl. 6.1.3 |
| **8.4** | **AI system impact assessment (operational)** | **Dynamic** AISIA re-execution at lifecycle milestones — distinguishes 42001 from static ISMS approaches. Triggers: major release, change in intended use, regulatory change, post-market signal |

### Clause 9 — Performance evaluation

| Sub-clause | Title | Notes |
|------------|-------|-------|
| 9.1 | Monitoring, measurement, analysis and evaluation | Determine what, when, how. **AI-specific KPIs**: bias metrics, drift, accuracy in production, incident rate, complaint rate |
| 9.2 | Internal audit | Planned audits of AIMS at planned intervals — document audit programme, criteria, scope |
| 9.3 | Management review | Top management reviews AIMS at planned intervals — inputs include risks, objectives, audit results, complaints, opportunities |

### Clause 10 — Improvement

| Sub-clause | Title | AI-specific notes |
|------------|-------|-------------------|
| 10.1 | Continual improvement | Ongoing improvement of AIMS suitability, adequacy, effectiveness |
| 10.2 | Nonconformity and corrective action | **Explicitly extended** to cover AI-specific incidents: drift, bias incidents, hallucination, model failures, data quality regressions. Tied to AI Act art. 73 serious-incident reporting |

## 3. Annex A — 38 reference controls (normative)

Annex A is **normative** ("Reference control objectives and controls"); Annex B is **informative** implementation guidance. Categories are numbered A.2 through A.10 (no A.1).

The Statement of Applicability (SoA, clause 6.1.3) documents inclusion/exclusion of **each** of these 38 controls with justification.

### A.2 — Policies related to AI (3 controls)

**Objective**: Provide management direction and support for AI through documented policies aligned with stakeholder needs.

| Control | Title | Intent |
|---------|-------|--------|
| A.2.2 | AI policy | Establish, communicate, review AI policy |
| A.2.3 | Alignment with other organizational policies | Ensure AI policy aligns with privacy, security, HR, ethics, sustainability policies — handle conflicts |
| A.2.4 | Review of the AI policy | Periodic review (planned intervals + on significant change); approval by top management |

### A.3 — Internal organization (2 controls)

**Objective**: Allocate responsibilities for AI system development, deployment, operation, and oversight.

| Control | Title | Intent |
|---------|-------|--------|
| A.3.2 | AI roles and responsibilities | Document AI-specific roles (data steward, ML engineer, model owner, AI ethics lead, deployer ops). Map to RACI |
| A.3.3 | Reporting of concerns | Provide channels for personnel to report AI-related concerns (bias, harm, ethics) without retaliation — **whistleblower-style** |

### A.4 — Resources for AI systems (5 controls)

**Objective**: Identify and document the resources used for AI systems.

| Control | Title | Intent |
|---------|-------|--------|
| A.4.2 | Resource documentation | Inventory of AI resources (data, tools, compute, models, humans) — equivalent to a CMDB for AI |
| A.4.3 | Data resources | Identify, document, and govern data resources used by/for AI |
| A.4.4 | Tooling resources | ML platforms, frameworks, MLOps tooling |
| A.4.5 | System and computing resources | Compute infrastructure (GPU clusters, TPU, edge), cost tracking, environmental footprint |
| A.4.6 | Human resources | Internal humans + outsourced. Skills, competence, training, ethics-of-AI awareness |

### A.5 — Assessing impacts of AI systems (4 controls)

**Objective**: Mandate structured, documented evaluation of AI system effects on individuals, groups, and society — operationalizes clause 6.1.4 + 8.4.

This is the **AISIA** family — the management-system equivalent of FRIA, DPIA, and ethics review. **ISO/IEC 42005:2025** is the elaboration standard.

| Control | Title | Intent |
|---------|-------|--------|
| A.5.2 | AI system impact assessment process | Define and document the AISIA process — methodology, triggers, roles, outputs |
| A.5.3 | Documentation of AI system impact assessments | Each individual AISIA documented; retain |
| A.5.4 | Assessing AI system impact on individuals or groups of individuals | Specific assessment of individual-level harms (privacy, autonomy, dignity, fundamental rights) |
| A.5.5 | Assessing societal impacts of AI systems | Specific assessment of collective/societal harms (information environment, labour market, environmental footprint, democracy) |

**Direct mapping**: AI Act art. 27 (FRIA) requires precisely the artefacts produced by A.5.4 + A.5.5.

### A.6 — AI system life cycle (9 controls)

**Objective**: Embed responsible-AI controls across the entire ML lifecycle. Aligns with ISO/IEC 5338 (lifecycle processes).

This is the **operational core of the AIMS** — the controls a typical AI engineering team interacts with daily.

| Control | Title | Intent |
|---------|-------|--------|
| A.6.1.2 | Objectives for responsible development of AI systems | Define and communicate development objectives consistent with AI policy |
| A.6.1.3 | Processes for responsible AI system design and development | Methodology (which lifecycle, e.g., 5338-aligned), gates, reviews |
| A.6.2.2 | AI system requirements and specification | Functional + non-functional requirements: accuracy, robustness, fairness, explainability, latency, cost, environmental |
| A.6.2.3 | Documentation of AI system design and development | Design records: architecture, model selection rationale, training procedure, hyperparameters |
| A.6.2.4 | AI system verification and validation | V&V plan + execution: unit/integration/system testing, performance evaluation, robustness testing, fairness testing |
| A.6.2.5 | AI system deployment | Deployment plan: environment, rollout strategy (canary, blue-green), rollback, deployer onboarding |
| A.6.2.6 | AI system operation and monitoring | Operational monitoring: drift, performance, fairness in production, complaints, incident detection |
| A.6.2.7 | AI system technical documentation | The technical documentation kept current with the system — model card, data card, system card, deployment doc |
| A.6.2.8 | AI system recording of event logs | Event logging — input/output, decisions, overrides, configuration changes — **direct mapping to AI Act art. 12** |

### A.7 — Data for AI systems (5 controls)

**Objective**: Establish data governance specifically for AI training/validation/test data — addressing provenance, quality, bias, representativeness. **Direct counterpart to AI Act art. 10**.

ISO/IEC 5259 series is the depth standard.

| Control | Title | Intent |
|---------|-------|--------|
| A.7.2 | Data for development and enhancement of AI system | Define what data is needed across the lifecycle |
| A.7.3 | Acquisition of data | Document acquisition methods, lawful basis, contracts with data providers |
| A.7.4 | Quality of data for AI systems | Quality measures (per ISO 5259-2), validation processes |
| A.7.5 | Data provenance | Track origin, transformations, lineage — ML-BOM concept |
| A.7.6 | Data preparation | Pre-processing decisions documented (cleaning, augmentation, balancing, feature engineering) |

### A.8 — Information for interested parties (4 controls)

**Objective**: Operationalize transparency duties owed to deployers, end-users, affected persons, regulators. **Direct mapping to AI Act arts. 13, 50, 73**.

| Control | Title | Intent |
|---------|-------|--------|
| A.8.2 | System documentation and information for users | What deployers/users need to operate responsibly — instructions for use |
| A.8.3 | External reporting | Reporting to regulators, certification bodies, market — including post-market monitoring data |
| A.8.4 | Communication of incidents | Process for communicating AI incidents to affected parties + regulators (AI Act art. 73 anchor) |
| A.8.5 | Information for interested parties | Broader transparency: AI policy public statement, model cards published, environmental disclosures |

### A.9 — Use of AI systems (3 controls)

**Objective**: Govern the **deployer-side** responsibilities. Direct counterpart to AI Act arts. 14 (human oversight) and 26 (deployer use).

| Control | Title | Intent |
|---------|-------|--------|
| A.9.2 | Processes for responsible use of AI systems | Operational processes for using AI: who can deploy, how monitored, override, escalation |
| A.9.3 | Objectives for responsible use of AI system | Use-time objectives — distinct from development objectives in A.6.1.2 |
| A.9.4 | Intended use of the AI system | Document and bound the intended use; control deviation |

### A.10 — Third-party and customer relationships (3 controls)

**Objective**: Manage AI supply chain (model vendors, data providers, hosting) and customer relationships.

| Control | Title | Intent |
|---------|-------|--------|
| A.10.2 | Allocating responsibilities | RACI across organization, suppliers, customers — especially for AI Act provider/deployer split |
| A.10.3 | Suppliers | Supplier due diligence, contracts requiring 42001-aligned practices, data-rights clauses |
| A.10.4 | Customers | Information to customers about AI capabilities/limitations; complaint mechanism; right-to-explanation interface |

## 4. Companion ISO/IEC standards (the AI standards stack)

ISO 42001 references and is supported by an ecosystem. Mastery of these is what differentiates rigorous AIMS implementation from check-box compliance.

| Standard | Title | Role |
|----------|-------|------|
| **ISO/IEC 22989:2022** | AI concepts and terminology | Vocabulary baseline (clause 2 normative ref) |
| **ISO/IEC 23053:2022** | Framework for AI systems using ML | ML pipeline reference framework — vocabulary for cl. 3 + technical scope |
| **ISO/IEC 23894:2023** | AI risk management — guidance | **Companion to clauses 6.1.2, 6.1.3, 8.2, 8.3** — tailors ISO 31000 to AI. The single most important guidance for satisfying AI Act art. 9 |
| **ISO/IEC 5259-1 to -5** | Data quality for analytics and ML | Companion to A.7 family (data for AI) — overview, measures, management requirements, process framework, governance |
| **ISO/IEC 8183:2023** | Data life cycle framework | Lifecycle-of-data view complementing 5259 |
| **ISO/IEC 5338:2023** | AI system life cycle processes | Adapts ISO/IEC/IEEE 12207 to AI — companion to A.6 lifecycle controls |
| **ISO/IEC TR 5339:2024** | Guidance for AI applications | Use-case context for clause 4 + intended use A.9.4 |
| **ISO/IEC 42005:2025** | AI system impact assessment | **Direct elaboration of clause 6.1.4 + A.5 family** — the AISIA depth standard |
| **ISO/IEC 42006:2025** | Audit and certification body requirements for AIMS | Conformity assessment of certification bodies |
| **ISO/IEC TR 24028:2020** | Overview of trustworthiness in AI | Cross-cutting trustworthiness reference |
| **ISO/IEC 24029-1, -2 (-3 forthcoming)** | Robustness assessment of neural networks | Depth standard for AI Act art. 15 robustness |
| **ISO/IEC TS 4213:2022** | Assessment of classification model performance | Depth for AI Act art. 15 accuracy metrics |
| **ISO/IEC 25059** | Quality model for AI systems | Quality characteristics (extending 25010 SQuaRE) for AI |
| **ISO/IEC TR 24027** | Bias in AI systems and AI-aided decision making | Companion to A.7 + AI Act art. 10(2)(f)(g) bias examination + mitigation |
| **ISO/IEC TR 24368:2022** | Overview of ethical and societal concerns | Ethics framing for clause 4 + A.5 |
| **ISO/IEC 12791** | Treatment of unwanted bias in classification + regression ML | Practitioner depth on bias mitigation |
| **ISO/IEC 27090:2025** | Cybersecurity guidance for AI | **Depth standard for AI Act art. 15 cybersecurity** + A.6 + A.10 supplier security. See `04-iso-27090-ai-security.md` |
| **ISO/IEC 27001:2022** | Information security management systems | Baseline ISMS — assumed by 42001 + 27090, integrate via Annex SL |

## 5. Certification and presumption of conformity

### 5.1 The audit cycle (ISO/IEC 17021-1 + ISO/IEC 42006)

| Stage | Activity | Typical duration |
|-------|----------|------------------|
| Pre-audit | Gap analysis (optional, common for first cert) | 2–4 weeks |
| **Stage 1 audit** | Documentation review (policy, scope, AISIA, risk register, SoA) | 1–3 days on-site/remote |
| Bridge | Address Stage-1 findings | 4–12 weeks |
| **Stage 2 audit** | Implementation effectiveness verification | 3–10 days on-site/remote |
| Certification decision | Independent reviewer at certification body | 2–6 weeks |
| **Surveillance audit (Y1)** | Sample of controls | 1–3 days |
| **Surveillance audit (Y2)** | Sample of controls | 1–3 days |
| **Recertification audit (Y3)** | Full re-audit | 5–10 days |

The Statement of Applicability (SoA) is the **central document** linking risk treatment to controls. For each of the 38 Annex A controls, document: status (implemented / planned / excluded), justification, ownership, evidence references.

### 5.2 Accreditation bodies

National accreditation bodies operating under IAF MLA accredit certification bodies against ISO/IEC 17021-1 + ISO/IEC 42006. Active accreditors for 42001 include:

- **UKAS** (UK)
- **ANAB** (United States)
- **DAkkS** (Germany)
- **COFRAC** (France)
- **Accredia** (Italy)
- **JAS-ANZ** (Australia/New Zealand)
- **RVA** (Netherlands)
- **ENAC** (Spain)

### 5.3 Notable certified organizations (as of 2026)

First public 42001 certifications appeared late 2024 through 2025. Notable scopes:

- **Anthropic** — first frontier AI lab (Schellman, 2025)
- **Amazon Web Services** — Amazon Bedrock + Amazon Q
- **Microsoft** — Azure AI Foundry + Microsoft 365 Copilot scopes
- **EY**, **KPMG** — professional-services AIMS scopes
- **Workday** — HCM AI features
- **Booz Allen Hamilton** — federal AI services
- **TÜV SÜD**, **TÜV Rheinland**, **DNV**, **LRQA**, **BSI** — both certifying and certified

**Always inspect the certificate's scope statement** — certifications cover specific products/services, not the entire enterprise. A "certified company" may have only its consumer-LLM division in scope, with enterprise products excluded.

### 5.4 Relationship to AI Act art. 40 presumption of conformity

Article 40 of the AI Act establishes that high-risk AI systems conforming to **harmonised standards** published in the *Official Journal of the European Union* enjoy a **presumption of conformity** with the corresponding essential requirements (arts. 9–15, 17). Article 41 permits the Commission to adopt **common specifications** where harmonised standards are insufficient or delayed.

The **CEN-CENELEC JTC 21 "Artificial Intelligence"** committee holds the standardization mandate **M/593** (issued by the European Commission on 22 May 2023) to deliver harmonised standards covering: risk management, data governance, transparency, human oversight, accuracy/robustness/cybersecurity, conformity assessment, and quality management.

JTC 21's strategy is largely "adopt with modifications" of ISO/IEC deliverables — including 42001, 23894, 5259, 12791, 24029-2, and 42005 — supplemented by purely European deliverables where ISO output does not fully cover AI Act essential requirements.

**Important caveat (April 2026)**: ISO/IEC 42001 is **not itself a harmonised standard**. The forthcoming European adaptation (provisionally referenced as **EN ISO/IEC 42001** or a JTC 21-authored equivalent) is expected to be cited in the OJEU during 2026, after which compliance with that EN standard will trigger the art. 40 presumption.

Until then:
- 42001 certification provides **strong evidentiary support** for conformity assessment under arts. 17, 43, and 61
- Demonstrates **due diligence** for arts. 9, 26, and 27
- Materially **streamlines preparation** for harmonised-standard alignment
- But is not by itself a legal conformity shortcut

Track:
- JTC 21 work programme (publicly available on CEN-CENELEC site)
- OJEU citations of harmonised standards under Regulation (EU) 2024/1689
- Commission delegated and implementing acts under arts. 6, 7, 41, 51, 96

## 6. Implementation roadmap (typical AIMS programme)

A first-time AIMS implementation in a moderate-complexity organization (1–10 AI systems, dozens of staff) typically runs **9–18 months** from kick-off to Stage 2 audit:

```
Month 1-2:  Scoping (cl. 4) — context, interested parties, scope statement, AI system inventory
Month 2-3:  Leadership (cl. 5) — AI policy approved by top management, roles assigned
Month 3-5:  Planning (cl. 6) — AI risk assessment, risk treatment plan, AISIA process,
            SoA (Annex A) drafted, objectives set
Month 4-7:  Implementation (cl. 7-8) — controls deployed, processes operational,
            evidence collection started, training delivered
Month 7-9:  Operation (cl. 8) — recurring AI risk assessment + AISIA cycles
Month 9-11: Performance evaluation (cl. 9) — first internal audit, management review
Month 11-12: Improvement (cl. 10) — corrective actions, refinements
Month 12-15: External audit — Stage 1 + Stage 2 + certification decision
```

For organizations already certified to **ISO/IEC 27001**, integration is materially faster: Annex SL HLS is shared, so clauses 4–10 governance, internal audit, management review can be reused. The AI-specific work concentrates on cl. 6.1.4 (AISIA), cl. 8.4 (operational AISIA), Annex A.5 (impacts), A.6 (lifecycle), A.7 (data), A.9 (use). Plan **6–9 months** of additional effort.

## 7. Codified expertise from the Navigator project

The Navigator's `maturityService.ts` operationalizes a **5-level maturity model** that aligns with ISO 42001 implementation maturity:

| Level | Name | AIMS maturity signals |
|-------|------|------------------------|
| 1 | **Initial** | Ad-hoc, no formal AI policy or AIMS scope |
| 2 | **Developing** | AI policy drafted, awareness building, partial control coverage |
| 3 | **Defined** | AIMS scope documented, AI risk + AISIA processes established, SoA drafted |
| 4 | **Managed** | AIMS operational, monitoring + internal audits running, controls effective |
| 5 | **Optimizing** | AIMS continually improving, certified, performance metrics drive improvement |

For implementation prioritisation, organize maturity tracking around the **ISO/IEC 42001 Annex A control families** themselves — they are the reference taxonomy of the standard:

| Annex A family | Implementation focus | AI Act anchor |
|----------------|----------------------|---------------|
| **A.2** Policies | AI policy, alignment, review | art. 17 QMS umbrella |
| **A.3** Internal organization | AI roles, reporting concerns | arts. 17, 22 |
| **A.4** Resources | Data, tooling, compute, human resources documentation | arts. 10, 11 |
| **A.5** Impacts | AISIA process, individual + societal impact assessment | art. 27 FRIA |
| **A.6** Lifecycle | Design, V&V, deployment, operation/monitoring, technical doc, event logs | arts. 11, 12, 14, 15 |
| **A.7** Data | Acquisition, quality, provenance, preparation, bias mitigation | art. 10 |
| **A.8** Information for parties | System documentation, external reporting, incident communication | arts. 13, 50, 73 |
| **A.9** Use | Responsible-use processes, intended use, oversight | arts. 14, 26 |
| **A.10** Third parties | Suppliers, customers, allocation of responsibilities | arts. 22-24, 26(8) |

Use the lowest-coverage Annex A family as the prioritisation lever for AIMS implementation effort. This mapping is **factual** (it lists the 9 normative Annex A categories of ISO/IEC 42001:2023) and is the first-line reference for any AIMS gap analysis.

For organizations layering an internal multi-dimension scoring framework on top (e.g., bias / transparency / oversight scorecards), use it as **augmentative** signal feeding into the Annex A prioritisation — never as a substitute for the ISO 42001 control structure.