Appearance
ISO/IEC 42001:2023 — Clauses 4–10 implementation guide
ISO/IEC 42001 follows the Annex SL harmonized structure. Clauses 4–10 describe how to run an AI management system; the AIMS-specific additions (AI policy in 5.2, AI risk and impact in 6.1.2 / 6.1.3 / 6.1.4, AI lifecycle controls in Clause 8 + Annex A) sit on top of the shared backbone. This page is the implementation playbook — not a restatement of the standard text.
Quick decision
- You already operate ISO 27001 → Clauses 4–10 are mostly in place; focus on the AIMS-specific additions (5.2 AI policy, 6.1.2/3/4 risk + impact, 8 lifecycle, Annex A controls).
- You are starting from scratch → stand up the Annex SL backbone (4 Context, 5 Leadership, 6 Planning, 7 Support, 8 Operation, 9 Performance evaluation, 10 Improvement) before layering the AIMS-specific work.
- You need to write the AI risk assessment (6.1.2) → define criteria, thresholds, cadence and approval authority. Lifecycle, not one-shot.
- You need to perform the AI impact assessment (6.1.4) → describe potential consequences for individuals, groups and society. Distinct from 6.1.2 risk assessment.
- You need to track Annex A control selection → an SoA-equivalent record, produced as part of AI risk treatment under 6.1.3, records what is in, what is out and why. ISO 42001 Annex A remains informative, not normative.
TL;DR
- Annex SL backbone shared with ISO 27001 / 27701 / 9001 — Clauses 4 (Context), 5 (Leadership), 6 (Planning), 7 (Support), 8 (Operation), 9 (Performance evaluation), 10 (Improvement).
- AIMS-specific additions inside the shared clauses: AI policy (5.2), AI risk assessment (6.1.2), AI risk treatment (6.1.3), AI impact assessment (6.1.4), AI lifecycle operational control (Clause 8 + Annex A.6).
- Risk assessment ≠ impact assessment. 6.1.2 = risks to the organisation; 6.1.4 = consequences for individuals, groups, society.
- SoA-equivalent control-selection record documents Annex A selection based on 6.1.2 / 6.1.4 inputs; ISO 42001 Annex A remains informative.
- Internal audit (9.2) + management review (9.3) + corrective action (10.2) = the operating loop that supports a conformity and effectiveness finding.
- Modulos models Clauses 4–10 via the OFF-10 / MFF-10 framework templates.
Primary source
ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system, Clauses 4 through 10. Available via the ISO Online Browsing Platform. © ISO.
Annex SL backbone
| Clause | Headline | What you put in place | Typical evidence |
|---|---|---|---|
| 4 Context | Boundaries the AIMS operates in | AIMS scope statement, interested-parties register, role determination under 4.1 | Scope document, stakeholder map, AIMS description |
| 5 Leadership | Accountability and direction | AI policy, roles, authorities, escalation | Approved AI policy, RACI, governance-meeting minutes |
| 6 Planning | Objectives, risk/impact logic, change planning | AI objectives, AI risk + impact + treatment records | Risk register, impact assessments, treatment plans, change log |
| 7 Support | People, resources, documented information | Competence plan, training, document control | Competence matrix, training records, document register |
| 8 Operation | Repeatable lifecycle execution | Operational planning, AI lifecycle procedures, supplier governance | Runbooks, lifecycle records, supplier assessments |
| 9 Performance evaluation | Measurement + governance cadence | Monitoring metrics, internal audit, management review | Metric reports, audit findings, review minutes |
| 10 Improvement | Fix and learn | Nonconformity + corrective action, continual improvement | Corrective-action records, improvement backlog |
Framework mapping
Four layers, one reusable spine.
Frameworks
EU AI Act
ISO 42001
Requirements
Art. 9.1Risk management
Art. 10.2Data governance
6.1.1Risk assessment
Components
Risk identification
Impact analysis
Evidence
Risk register
Test results
Controls
The reusable spine
One control satisfies many requirements across many frameworks, and groups the components and evidence beneath them.
Risk assessment process
Data validation checks
Edge from any layer card crosses into the Controls spine — the same control may serve a regulatory article, a standards clause, a downstream component, and the evidence that closes it.
Clause 4 — Context of the organization
Goal: define the AIMS boundaries and the reality it operates in.
What to implement:
- An AIMS scope statement (Clause 4.3) — what is in, what is out, where AI is used, which functions are covered.
- An interested-parties register (4.2) — regulators, customers, users, staff, vendors, AI subjects.
- An AIMS description (4.4) — how it interacts with existing management systems (security, privacy, quality).
- Role determination under 4.1 — provider, producer, customer, partner, subject, regulator (or several).
- A climate-change relevance determination (4.1) — record whether climate change is a relevant issue for the management system. This obligation comes from the 2024 climate-action amendment to the Annex SL management-system structure (ISO/IEC 27001:2022/Amd 1:2024 and its parallels), not the originally published Clause 4.1/4.2 text; Modulos shares the same determination across ISO 42001, 27001 and 27701.
Common pitfalls:
- Scope creep — starts with one AI system, silently expands to "all AI".
- Treating scope as static instead of revisiting it as systems and suppliers change.
Evidence patterns:
- Approved scope statement with exclusions and rationale.
- Living interested-parties register, often maintained alongside risk and compliance obligations.
- Governance structure diagram or operating-model document.
Clause 5 — Leadership
Goal: make accountability real — leadership commitment, policy direction, explicit responsibilities.
What to implement:
- An AI policy (5.2) — short enough to be used, specific enough to be audited.
- Roles and authorities (5.3) — who can approve, who can override, who owns risk decisions.
- A governance cadence — steering meetings, reviews, escalation for incidents and nonconformities.
Common pitfalls:
- A policy that reads like marketing ("we do ethical AI") but doesn't bind decisions.
- Ambiguous authority — "everyone is responsible" usually means "no one is accountable".
Evidence patterns:
- AI policy with approval record and review cadence.
- RACI-style role descriptions or equivalent.
- Minutes and decision records from governance meetings.
Clause 6 — Planning
Goal: turn intent into a plan — objectives, risk/impact discipline, change planning.
What to implement:
- A consistent method for AI risk assessment (6.1.2) — criteria, thresholds, cadence, approval authority.
- A method for AI risk treatment (6.1.3) — treatment options, ownership, timeline, residual-risk acceptance.
- An AI system impact assessment (6.1.4) — consequences for individuals, groups, society.
- Measurable AI objectives (6.2) — not just principles.
- Planning of changes (6.3) — what triggers reassessment (model change, data change, deployment change, supplier change).
The 6.1.2 / 6.1.4 distinction:
- Risk assessment (6.1.2) = organisational risks to the AIMS and its objectives.
- Impact assessment (6.1.4) = consequences for individuals, groups and society from AI deployment.
- The two feed each other but are distinct artefacts. 6.1.4 is the AIMS analogue of the EU AI Act Article 27 FRIA.
Common pitfalls:
- Treating risk assessment as a one-time exercise rather than a lifecycle mechanism.
- Confusing tests with assurance — test results are inputs; governance decisions are separate and must be recorded.
Clause 7 — Support
Goal: ensure people, resources, competence, awareness and controlled documentation to run the AIMS reliably.
What to implement:
- Resource planning — time and expertise for risk, testing, documentation, review.
- Role-based competence and training, including reviewers and approvers.
- Communication — who needs to know what, when (internal and external).
- Documented-information discipline (7.5) — versioning, review cadence, access control.
Common pitfalls:
- Documentation debt — artefacts exist but no one owns them; they silently rot.
- Uncontrolled working docs — critical decisions live in chat threads and get lost.
Clause 8 — Operation
Goal: run AI governance as an operational system — lifecycle controls, supplier management, repeatable execution.
What to implement:
- Operational planning and control (8.1) for the AI system lifecycle — build, deploy, monitor, change, retire.
- Operational cadence for AI risk assessment (8.2) and AI risk treatment (8.3) — not only during planning.
- AI system impact assessment (8.4) operationalised through Annex A.5 controls.
- Supplier and third-party governance for model providers, data providers and critical infrastructure (Annex A.10).
- Controls for data quality, transparency, oversight, monitoring and incident handling — tailored by risk (Annex A.6 lifecycle controls).
Common pitfalls:
- Governance stops at "go-live" — most failures happen after deployment.
- Monitoring exists but isn't connected to governance decisions or corrective actions.
Clause 9 — Performance evaluation
Goal: prove the AIMS works — monitoring, internal audit, management review.
What to implement:
- Monitoring and measurement (9.1) — what signals indicate the AIMS controls are working (or failing).
- Internal audit programme (9.2) — scope, cadence, sampling approach, auditor competence.
- Management review (9.3) — what leadership reviews, how often, what outcomes are expected. Inputs include internal-audit findings, monitoring results, supplier evaluations, nonconformities and resourcing.
Common pitfalls:
- "Internal audit" treated as document review only — weak signal that doesn't catch operational gaps.
- Management review becomes a status meeting, not a decision point.
Clause 10 — Improvement
Goal: make failures productive — fix nonconformities and continually improve the system.
What to implement:
- Nonconformity and corrective action (10.2) — ownership, deadlines, root cause analysis, effectiveness verification.
- Continual improvement (10.1) — driven by audits, incidents, monitoring, stakeholder feedback.
Common pitfalls:
- Corrective actions closed without verifying effectiveness.
- Improvements tracked informally without traceability back to the trigger (audit finding, incident, measurement).
How to operationalise Clauses 4–10 in Modulos
The OFF-10 / MFF-10 framework template pair records and links ISO 42001 requirements — OBP clause titles with a full Clauses 4–10 inventory, mapped to ORF-162…ORF-195 and MRF-213…MRF-220.
The OFF-10 / MFF-10 clause mapping (showing the clean Annex SL coverage):
| Requirement | ISO 42001 clause | Topic |
|---|---|---|
ORF-162 | 4.1 | Understanding the organisation and its context |
ORF-163 | 4.2 | Understanding the needs and expectations of interested parties |
ORF-164 | 4.3 | Determining the scope of the AI management system |
ORF-165 | 4.4 | AI management system |
ORF-166 | 5.1 | Leadership and commitment |
ORF-167 | 5.2 | AI Policy |
ORF-168 | 5.3 | Organisational roles, responsibilities and authorities |
ORF-169 | 6.1.1 | Actions to address risks and opportunities — general |
ORF-170 | 6.1.2 | AI risk assessment |
ORF-171 | 6.1.3 | AI risk treatment |
ORF-172 | 6.1.4 | AI system impact assessment |
ORF-173 | 6.2 | AI objectives and planning to achieve them |
ORF-174 | 6.3 | Planning of changes |
ORF-175 | 7.1 | Resources |
ORF-176 | 7.2 | Competence |
ORF-177 | 7.3 | Awareness |
ORF-178 | 7.4 | Communication |
ORF-179 / ORF-180 / ORF-181 | 7.5.1 / 7.5.2 / 7.5.3 | Documented information |
ORF-182 | 8.1 | Operational planning and control |
ORF-183 | 9.1 | Monitoring, measurement, analysis and evaluation |
ORF-184 / ORF-185 | 9.2.1 / 9.2.2 | Internal audit |
ORF-186 / ORF-187 / ORF-188 | 9.3.1 / 9.3.2 / 9.3.3 | Management review |
ORF-189 | 10.1 | Continual improvement |
ORF-190 | 10.2 | Nonconformity and corrective action |
ORF-191…ORF-194 | A.2…A.5 | Annex A reference control areas (org-side scope) |
App-side (MFF-10) records and links the operational AI-system lifecycle requirements:
| Requirement | ISO 42001 clause | Topic |
|---|---|---|
MRF-213 | 8.2 | AI risk assessment (operational) |
MRF-214 | 8.3 | AI risk treatment (operational) |
MRF-215 | 8.4 | AI system impact assessment (operational) |
MRF-216 | A.6.2 | AI system life cycle |
MRF-217 | A.7 | Data for AI systems |
MRF-218 | A.8 | Information for interested parties of AI systems |
MRF-219 | A.9 | Use of AI systems |
MRF-220 | A.10 | Third-party and customer relationships |
Operating rules:
- Scope statement, AI policy, internal audit, management review live on OFF-10. One org-level project per organisation.
- AI risk + impact assessments + lifecycle + data controls live on MFF-10. One app-level project per AI system in scope.
- Control-level evidence backs each requirement. Modulos does not provide a dedicated Statement of Applicability surface — the SoA-equivalent record is owner-authored documentation stored as evidence on the relevant Annex A requirements.
Integrated Management System (IMS) with ISO 27001 / 27701
The management-system layer (Clauses 4–10) is designed to integrate across ISO standards. Many organisations operate ISO/IEC 42001 alongside:
- ISO/IEC 27001 (ISMS) — shares Annex SL clauses; the AIMS adds AI-specific Clauses 5.2 / 6.1.2 / 6.1.3 / 6.1.4 + Annex A.
- ISO/IEC 27701 (PIMS) — shares Annex SL clauses; adds privacy-specific risk and processing-role obligations.
The practical pattern: share the management-system processes (document control, internal audit, management review, corrective action) while keeping the standard-specific risk and impact mechanisms explicit and auditable on their own.
How Modulos shares the Clauses 4–10 controls
Modulos implements the organisation-level Clauses 4–10 as one shared set of controls used across ISO 27001, ISO 27701 and ISO 42001 (and reused by NIS2 and DORA). Each shared control is written to read correctly under whichever management system applies — information security, privacy or AI management — so you are not maintaining three near-duplicate copies of the same document-control or management-review process.
Where one standard imposes work the others do not, that obligation is a separate control mapped only to that standard — so it never appears in another framework's checklist. For example:
- Monitoring and measurement (Clause 9.1) — determining who is responsible for what is monitored is ISO 27001-only.
- Risk-owner identification (Clause 6.1.2) — shared by ISO 27001 and ISO 27701.
- Information-security-programme documentation (Clause 6.1.3) — ISO 27701-only.
- AI-policy alignment and AIMS documentation — ISO 42001-only.
- Communication methods (Clause 7.4) — a shared control that completes Clause 7.4 for all three standards.
Harmonized cross-references on every requirement
Every ISO requirement in Modulos names its exact clause or Annex reference (Standard reference) and summarises the clause in plain language (What this clause requires). On the shared Clauses 4–10 requirements it also links the matching requirement in the sibling ISO standards (Harmonized with), and related requirements are linked where relevant (Related to). Requirement names match the standard's own clause titles, so an ISO 42001 clause lines up directly with its ISO 27001 and ISO 27701 counterparts when you operate an integrated management system.
Related: ISO 27001 integration with AI governance · ISO 42001 vs ISO 27001 comparison.
Cross-framework mapping (preview)
| ISO 42001 clause | Adjacent provision |
|---|---|
| Clause 4.3 AIMS scope | ISO 27001 Clause 4.3 ISMS scope; ISO 27701 Clause 4.3 PIMS scope |
| Clause 5.2 AI policy | ISO 27001 Clause 5.2 information-security policy; EU AI Act Article 17 QMS |
| Clause 6.1.2 AI risk assessment | EU AI Act Article 9 RMS; NIST AI RMF MAP / MEASURE / MANAGE; ISO 31000 |
| Clause 6.1.3 AI risk treatment | ISO 31000 risk-treatment process |
| Clause 6.1.4 AI impact assessment | EU AI Act Article 27 FRIA; algorithmic-impact-assessment frameworks |
| Clause 8 operational planning + control | EU AI Act Articles 8–15 substantive obligations |
| Clause 9.1 monitoring | EU AI Act Article 72 post-market monitoring; ISO 27001 Clause 9.1 |
| Clause 9.2 internal audit | ISO 27001 Clause 9.2; ISO 9001 Clause 9.2 |
| Clause 10.2 corrective action | ISO 27001 Clause 10.2; EU AI Act Article 20 corrective actions |
Related pages
ISO 42001 overview
Hub: AIMS structure, Annex SL backbone, certification path
Scope and certification
AIMS scope, Statement of Applicability, Stage 1 / Stage 2 / surveillance / recertification
Annex A and informative annexes
How to use the Annex A reference controls and informative Annexes B / C / D
Operationalizing in Modulos
OFF-10 / MFF-10 rollout
Source attribution
ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system, Clauses 4 through 10 + Annex A.2 through A.10. © ISO/IEC. Available via the ISO Online Browsing Platform.
Disclaimer
This page is for general informational purposes and does not constitute legal or certification advice.