ISO 42001 clause guide
Build your AI management system around its scope, owners, risks and operating evidence. This working guide follows the management-system clauses in ISOQAR’s public gap analysis and gives each clause a working file to build and a question to test it with. Public summaries accessed 2026-11-11.
ISO describes the standard as a framework for managing AI across an organization. Use the licensed ISO/IEC 42001:2023 standard for the normative requirements and control text.
4 Context
Set the boundary: the organization’s AI role, interested parties and management-system scope.
Working file: AI inventory, role map and a scope statement tied to the services you operate.
Review question: Can a buyer identify the covered systems, sites and AI roles from the scope alone? Keep excluded activities visible in the scope discussion.
5 Leadership
Make AI governance a management responsibility, with policy and accountable roles.
Working file: approved AI policy, assigned owners and a route for decisions that need executive review.
Review question: Who can approve an AI deployment, accept residual risk and stop an activity? Record the decision route as well as job titles.
6 Planning
Translate AI risks, impacts and opportunities into treatment decisions and objectives.
Working file: risk register, impact-assessment approach, treatment plan and Statement of Applicability.
Review question: Can each treatment decision be traced to a risk or impact, an owner and an objective? Keep the applicability rationale alongside the selected controls.
7 Support
Provide the people, skills, communications and controlled information needed to run the system.
Working file: competence records, training evidence and a controlled document register.
Review question: Can the people assigned to operate the system find the current procedure and demonstrate the relevant skills? Include supplier-facing responsibilities in that review.
8 Operation
Carry out the planned processes and revisit AI risks and impacts as operations change.
Working file: completed risk and impact assessments, supplier reviews and lifecycle change records.
Review question: Does evidence show the process running after a model, dataset, supplier or intended-use change? Retain the resulting assessment and release decisions.
9 Performance evaluation
Use monitoring, internal audit and management review to evaluate the system.
Working file: monitoring results, internal audit findings and management review decisions.
Review question: Do monitoring, internal audit and management review identify decisions and follow-up work? A dashboard alone does not show the management response.
10 Improvement
Address nonconformities and improve the management system.
Working file: root-cause analysis, corrective-action owners and evidence that actions worked.
Review question: What changed after a nonconformity, and how was effectiveness checked? Connect corrective actions to the underlying cause and subsequent operating evidence.
Annex A: control planning map
38 control referencesChoose controls through risk treatment and explain the choices in the Statement of Applicability. Compare your selection with Annex A to identify omissions. Consult Annex B when planning implementation. Modulos’s public annex summary explains the relationship.
The labels below are our own planning prompts, each paired with a working file you can build. Control references follow ISOQAR’s public controls summary and Modulos’s reference table. Both accessed 2026-11-11.
A.2 · Policy direction
A.3 · Internal accountability
A.4 · Resource dependencies
| Reference | Planning prompt | Working file to build |
|---|---|---|
| A.4.2 | Map system dependencies | System resource inventory |
| A.4.3 | Describe available datasets | Dataset resource catalogue |
| A.4.4 | Track engineering tools | Model and tooling inventory |
| A.4.5 | Plan computing needs | Capacity and infrastructure map |
| A.4.6 | Identify specialist capacity | Staffing and competence plan |
A.5 · Impact assessment
A.6 · Development and operation
| Reference | Planning prompt | Working file to build |
|---|---|---|
| A.6.1.2 | Set development goals | Responsible engineering objectives |
| A.6.1.3 | Organize development gates | Development approval workflow |
| A.6.2.2 | Define system expectations | Accepted requirements baseline |
| A.6.2.3 | Record engineering choices | Versioned design decisions |
| A.6.2.4 | Test before acceptance | Verification and validation results |
| A.6.2.5 | Control production releases | Deployment approval record |
| A.6.2.6 | Monitor running systems | Performance and maintenance runbook |
| A.6.2.7 | Prepare technical explanations | Audience-specific technical pack |
| A.6.2.8 | Preserve operational events | Event logging specification |
A.7 · Data stewardship
| Reference | Planning prompt | Working file to build |
|---|---|---|
| A.7.2 | Govern development data | Data management workflow |
| A.7.3 | Evaluate incoming data | Data acquisition review |
| A.7.4 | Check dataset suitability | Data quality acceptance results |
| A.7.5 | Trace dataset origins | Lineage and provenance register |
| A.7.6 | Record data transformations | Preparation pipeline change log |
A.8 · Information exchange
A.9 · Responsible adoption
A.10 · External relationships
Turn the evidence into a proposal
Send your intended scope, AI roles, sites and existing management-system certifications to the bodies on your shortlist. Ask them to distinguish audit duration from elapsed readiness time. The cost guide shows why this matters, and the company examples illustrate specific scopes.