Appearance
Operationalizing ISO/IEC 42001:2023 in Modulos
ISO 42001 becomes manageable when the AIMS is treated as a living operating model: governance work is executed continuously and evidence is produced as a byproduct. This page is the implementation playbook for running the AIMS on Modulos using the OFF-10 / MFF-10 framework templates.
Quick decision
- You are starting a fresh AIMS rollout → one organisation project with OFF-10, plus one AI-application project per AI system with MFF-10.
- You already operate ISO 27001 or 27701 → add the ISO 42001 OFF template to the existing organisation project; reuse the shared Annex SL management-system processes; only stand up AI-specific clauses and Annex A controls.
- You are building the Statement of Applicability → record control selection as evidence on the Annex A area requirements (
ORF-191–ORF-194org-side;MRF-216–MRF-220app-side).
TL;DR
- OFF-10 + MFF-10 framework templates record and link ISO 42001 requirements, with clause-aligned requirement names matching the OBP titles.
- Two project layers: organisation project for the AIMS spine; AI-system projects for per-system execution.
- AIMS spine on the org project: scope statement, AI policy, AI risk-management process, internal audit, management review, corrective action.
- AI-system execution on the app project: AI impact assessment, lifecycle controls, data controls, monitoring evidence.
- Statement of Applicability is owner-authored documentation stored as evidence on Annex A area requirements.
- IMS integration with ISO 27001 / 27701: share Clauses 4–10 processes; keep AI-specific Clauses 5.2 / 6.1.2 / 6.1.3 / 6.1.4 and Annex A controls explicit.
Primary source
ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. Modulos framework templates: OFF-10 / MFF-10 in modulos_platform/content/templates/frameworks/. Available via the ISO Online Browsing Platform. © ISO.
Recommended project structure
| Project | Template | When to use |
|---|---|---|
| One organisation project | OFF-10 (add to existing org project if you already run ISO 27001 / 27701) | Scope statement, AI policy, Annex SL management-system processes, internal audit, management review, corrective action |
| One AI-application project per AI system | MFF-10 | AI impact assessment, lifecycle controls (Annex A.6), data controls (Annex A.7), monitoring evidence, supplier evidence |
The split mirrors the standard's own structure: organisation-wide management-system layer on one side; per-AI-system operational layer on the other.
Set up: a sequence that works
1
Add OFF-10 to your org project
Apply the clause-aligned AIMS template.
2
Create one app project per AI system
Apply MFF-10. Each AI system gets its own evidence trail.
3
Define the AIMS scope
Clause 4.3 scope statement: AI systems, processing activities, boundaries.
4
Run AI risk + impact assessments
Clause 6.1.2 risk and 6.1.4 impact assessment, with cadence and approvals.
5
Record Annex A control selection
SoA-equivalent record under Clause 6.1.3 — Annex A remains informative.
6
Operate, audit, review, improve
Controls, internal audit, management review, corrective action.
How to operationalise ISO 42001 in Modulos
OFF-10 / MFF-10 mapping:
| AIMS element | OFF-10 / MFF-10 requirement | Clause |
|---|---|---|
| Organisational context | ORF-162 | 4.1 |
| Interested parties | ORF-163 | 4.2 |
| AIMS scope statement | ORF-164 | 4.3 |
| AIMS itself | ORF-165 | 4.4 |
| Leadership commitment | ORF-166 | 5.1 |
| AI policy | ORF-167 | 5.2 |
| Roles and responsibilities | ORF-168 | 5.3 |
| AI risk-management general | ORF-169 | 6.1.1 |
| AI risk assessment | ORF-170 | 6.1.2 |
| AI risk treatment + Statement of Applicability | ORF-171 | 6.1.3 |
| AI impact assessment (org-level scoping) | ORF-172 | 6.1.4 |
| AI objectives | ORF-173 | 6.2 |
| Planning of changes | ORF-174 | 6.3 |
| Resources / competence / awareness / communication | ORF-175–ORF-178 | 7.1–7.4 |
| Documented information | ORF-179 / ORF-180 / ORF-181 | 7.5.1–7.5.3 |
| Operational planning + control | ORF-182 | 8.1 |
| Monitoring + measurement | ORF-183 | 9.1 |
| Internal audit + audit programme | ORF-184 / ORF-185 | 9.2.1 / 9.2.2 |
| Management review (process / inputs / outputs) | ORF-186 / ORF-187 / ORF-188 | 9.3.1 / 9.3.2 / 9.3.3 |
| Continual improvement | ORF-189 | 10.1 |
| Nonconformity + corrective action | ORF-190 | 10.2 |
| Annex A.2 Policies related to AI | ORF-191 | A.2 |
| Annex A.3 Internal organization | ORF-192 | A.3 |
| Annex A.4 Resources for AI systems | ORF-193 | A.4 |
| Annex A.5 Assessing impacts of AI systems | ORF-194 | A.5 |
| AI risk assessment (operational) | MRF-213 | 8.2 |
| AI risk treatment (operational) | MRF-214 | 8.3 |
| AI system impact assessment (operational) | MRF-215 | 8.4 |
| Annex A.6 AI system life cycle | MRF-216 | A.6.2 |
| Annex A.7 Data for AI systems | MRF-217 | A.7 |
| Annex A.8 Information for interested parties | MRF-218 | A.8 |
| Annex A.9 Use of AI systems | MRF-219 | A.9 |
| Annex A.10 Third-party and customer relationships | MRF-220 | A.10 |
What is first-class UI vs evidence-attached
- First-class — Modulos exposes the framework template ID on the project (Settings → Frameworks) and the requirement readiness signal on each ORF / MRF requirement.
- Evidence-attached (no dedicated UI) — the Statement of Applicability, the AI risk-assessment method document, the AI impact-assessment artefact, internal-audit reports, management-review minutes, corrective-action records, supplier assessments. Each is owner-authored documentation stored as control-level evidence on the relevant requirement.
This is deliberate. ISO 42001 expects the organisation to own the form of its AIMS artefacts; locking them into a prescribed workflow would defeat the standard's risk-driven, context-specific intent.
IMS integration — ISO 42001 + 27001 + 27701
ISO management-system standards share the Annex SL backbone, which makes IMS integration realistic. The shared layer:
- document control (Clause 7.5)
- internal audit (Clause 9.2)
- management review (Clause 9.3)
- corrective action (Clause 10.2)
- competence (Clause 7.2)
What stays standard-specific:
- ISO 27001: information-security risk and Annex A (normative) information-security controls.
- ISO 42001: AI policy (5.2), AI risk + impact (6.1.2 / 6.1.3 / 6.1.4), Annex A (informative) AI lifecycle and data controls.
- ISO 27701: privacy risk, PII processor / controller distinctions, Annex A and B privacy controls.
Practical pattern in Modulos: add the relevant OFF templates to the same organisation project; share evidence across them where a single control satisfies multiple obligations (e.g., a single internal-audit programme that covers ISMS + AIMS).
One shared control set, per-standard exceptions
The organisation-level Clauses 4–10 are backed by one shared set of controls in Modulos, reused across ISO 27001, ISO 27701 and ISO 42001 (and by NIS2 and DORA). Adding a second ISO OFF template to the same organisation project reuses those controls rather than duplicating them — a single internal-audit, management-review or document-control control satisfies every management system that references it, and each is written to read correctly under whichever standard applies.
Where a standard imposes an obligation the others do not, Modulos carries it as its own control mapped only to that standard, so it never appears in another framework's checklist:
- Monitoring-responsibility determination (Clause 9.1) — 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) — shared, completing Clause 7.4 for all three.
Harmonized cross-references
Each ISO requirement panel names its exact clause or Annex reference (Standard reference) and gives a plain-language summary of the clause (What this clause requires); shared Clauses 4–10 requirements also link the matching requirement in the sibling ISO standards (Harmonized with) and related requirements (Related to). Requirement names match the standards' own clause titles, so shared and standard-specific controls are easy to trace across the ISMS, PIMS and AIMS.
Related: ISO 27001 integration with AI governance · ISO 42001 vs ISO 27001 comparison.
Cross-framework mapping (preview)
| ISO 42001 element | Adjacent framework |
|---|---|
| Clause 4.3 AIMS scope | EU AI Act Articles 6 + 25 system classification; ISO 27001 Clause 4.3 ISMS scope |
| Clause 6.1.2 AI risk assessment | EU AI Act Article 9 risk-management system; NIST AI RMF MAP / MEASURE / MANAGE |
| Clause 6.1.3 AI risk treatment + SoA | EU AI Act Article 9 mitigation; ISO 27001 Clause 6.1.3 |
| Clause 6.1.4 / 8.4 AI impact assessment | EU AI Act Article 27 FRIA; NIST AI RMF MAP |
| Annex A.6 AI system lifecycle | EU AI Act Articles 8–15 substantive obligations |
| Annex A.7 Data for AI systems | EU AI Act Article 10 data governance; GDPR Articles 5, 6, 9; ISO/IEC 27701 PIMS |
| Annex A.8 Information for interested parties | EU AI Act Article 13 transparency; Article 50 transparency |
| Annex A.10 Third-party / customer relationships | EU AI Act Article 25 value chain; ISO 27001 Annex A supplier controls |
| Clauses 9.1 / 9.2 / 9.3 monitoring + audit + review | EU AI Act Article 72 post-market monitoring; ISO 27001 / 27701 Clauses 9 |
| Clause 10.2 corrective action | EU AI Act Article 73 incident reporting; ISO 27001 / 27701 Clause 10.2 |
Common pitfalls
- Copying Annex A control text into a spreadsheet and calling it an implementation. The SoA is the output of the risk-driven selection, not the input.
- Treating the AI risk assessment as a one-time gap analysis. Clause 6.1.2 expects a continuous lifecycle mechanism — the risk register should change as systems, suppliers and the threat environment change.
- Confusing the AI risk assessment with the AI impact assessment. 6.1.2 = organisational risk; 6.1.4 = consequences for individuals, groups, society.
- Internal audit as a documentation review. Auditors expect operational sampling — control execution records, decisions, evidence — not just policy completeness.
- Mixing AIMS work with product execution. The org project holds the management-system spine; per-system MFF projects hold the operational evidence. Keeping them separate keeps review queues legible.
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
Clauses 4–10 (implementation guide)
Annex SL backbone with AIMS-specific additions
Annex A and informative annexes
How to use the Annex A reference controls and informative Annexes B / C / D
ISO 27001 integration with AI governance
How an existing ISMS supports the AIMS
Source attribution
ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system, Clauses 4–10 + Annex A. © ISO/IEC. Available via the ISO Online Browsing Platform. Modulos framework templates OFF-10, MFF-10 in modulos_platform/content/templates/frameworks/.
Disclaimer
This page is for general informational purposes and does not constitute legal or certification advice.