
AI management systems
ISO/IEC 42001 implementation guide
A practical roadmap for building, operating, auditing, and improving an Artificial Intelligence Management System without reducing it to a document exercise.
By Kesho Partners
15 minute read
ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System. Implementation requires a defined scope, accountable leadership, AI policy and objectives, risk and impact processes, lifecycle and supplier controls, competence, documented evidence, performance evaluation, internal audit, management review, and corrective improvement. ISO does not certify organizations; certification is performed by external certification bodies.
What ISO/IEC 42001 is designed to do
ISO/IEC 42001:2023 is an international management-system standard for organizations that provide or use AI products and services. ISO describes it as specifying requirements to establish, implement, maintain, and continually improve an Artificial Intelligence Management System, or AIMS.
An AIMS is the organizational system around AI: policy, responsibilities, objectives, resources, operational controls, risk and impact processes, performance evaluation, and improvement. It should govern the AI systems inside an agreed scope and connect to the organization's existing management and delivery processes.
ISO/IEC 42001 does not certify an individual model as accurate, safe, fair, or compliant. It assesses whether an organization has a management system that meets the standard's requirements and operates that system. Product, legal, technical, and sector assurance remain necessary.
Sources: [1]
Who certifies ISO 42001
ISO develops standards but does not perform certification or issue certificates. ISO states that certification is carried out by external certification bodies. Accreditation provides independent recognition of a certification body's competence, although ISO notes that accreditation is not compulsory.
An organization preparing for certification should define why certification matters, which entities and activities are in scope, which certification body requirements apply, and how it will verify the body's competence and accreditation status. Avoid claims that an organization is certified by ISO.
| Party | Responsibility | Evidence to verify |
|---|---|---|
| Organization | Implement and operate the AIMS | Scope, controls, records, audits and improvement |
| Certification body | Independently assess conformity and issue certification | Contract, audit programme and certificate |
| Accreditation body | Recognize certification-body competence | Accreditation scope and current status |
| ISO | Develop and publish the international standard | Published standard and official guidance |
Sources: [2]
Set a scope that matches real AI accountability
A scope that is too broad can produce an unmanageable first implementation. A scope that excludes the people, suppliers, products, or operating processes that control material AI risk will not describe reality. Define legal entities, business functions, locations, products, lifecycle activities, and interfaces with other management systems.
Create an AI inventory before finalizing scope. Include internally developed models, model APIs, embedded vendor AI, automated decisions, AI-enabled security tools, and material experiments approaching production. Record who provides and who uses each system, because controls differ across those roles.
- Organizational boundary
- Legal entities, teams, locations, products and services covered by the AIMS.
- AI boundary
- Systems, models, data, third parties, lifecycle activities and operating contexts covered.
- Interfaces
- Connections to security, privacy, quality, procurement, product, legal, audit and enterprise risk.
- Exclusions
- Explicit exclusions with evidence that they do not undermine the management system's purpose.
The eight implementation workstreams
The workstreams below translate management-system requirements into an operating programme without reproducing the standard. The authoritative requirements remain in the licensed ISO/IEC 42001 text.
| Workstream | Core decision | Practical evidence |
|---|---|---|
| 1. Context and scope | What must the AIMS govern and why? | Context analysis, interested parties, scope and AI inventory |
| 2. Leadership and policy | Who is accountable and what commitments apply? | AI policy, roles, decision rights and governance forums |
| 3. Planning | Which risks, opportunities, impacts and objectives matter? | Assessment criteria, risk files, objectives and action plans |
| 4. Support | Do people have competence, resources and controlled information? | Skills matrix, training, communications and document controls |
| 5. Lifecycle operation | How are AI systems acquired, built, used, changed and retired? | Lifecycle gates, supplier controls, instructions and system records |
| 6. Performance evaluation | How does the organization know the AIMS and AI controls work? | Metrics, monitoring, evaluation and assurance results |
| 7. Internal audit | Is conformity assessed independently and systematically? | Audit programme, findings, evidence and follow-up |
| 8. Management review and improvement | Does leadership act on results and change? | Review minutes, decisions, corrective actions and improvement backlog |
Sources: [1]
Connect risk and impact assessment to lifecycle decisions
Do not operate risk assessment as an annual register exercise. Define when an assessment starts, who contributes, how affected people and contexts are considered, how criteria are applied, and which decisions follow from the result. Trigger reassessment when intended use, data, models, suppliers, users, permissions, law, or operating context changes materially.
Risk and impact records should connect to requirements, evaluations, controls, residual risk, approval, and monitoring. The AIMS should make it possible to trace why a system was permitted, restricted, changed, or retired.
| Evidence | Question answered |
|---|---|
| Intended-use and system record | What is the system expected and prohibited from doing? |
| Risk and impact assessment | Who or what can be affected, and how materially? |
| Control plan | How are material risks prevented, detected and corrected? |
| Evaluation report | Does evidence meet approved performance and control thresholds? |
| Release or use decision | Who accepted residual risk and under which conditions? |
| Monitoring and incident record | Does the system remain within its approved operating boundary? |
Treat supplier AI as part of the management system
Buying AI does not transfer accountability for how it is selected, integrated, configured, used, monitored, or changed. Supplier controls should be proportional to the system's impact, data, authority, criticality, and substitutability.
Procurement evidence should cover intended use, data flows, models and subprocessors, evaluation, security, availability, changes, incidents, human oversight, monitoring, contractual rights, and exit. Where a supplier cannot provide evidence, record the uncertainty and decide whether technical or operational controls reduce it sufficiently.
Score readiness by evidence, not policy existence
A readiness assessment should test whether the management system operates. Score each workstream against evidence and repeatability rather than whether a document exists. The scale below is Kesho's assessment model, not an ISO maturity model.
| Level | Meaning | Evidence pattern |
|---|---|---|
| 0. Absent | No defined process or accountable owner | Activity is unknown or unmanaged |
| 1. Ad hoc | Some teams act, but practice is inconsistent | Evidence depends on individuals |
| 2. Defined | Process, owner and expected records are documented | Use is partial or recently introduced |
| 3. Operating | Process is used across scope and exceptions are managed | Current records show repeated operation |
| 4. Assured | Effectiveness is measured, challenged and improved | Audit, management review and corrective action are effective |
A 90-day implementation sequence
Ninety days can establish the operating core for a bounded scope; it does not guarantee certification readiness. Certification timing depends on scope, existing systems, risk, evidence maturity, audit findings, and certification-body arrangements.
| Period | Work | Output |
|---|---|---|
| Days 1-15 | Confirm objectives, sponsor, scope hypothesis, interested parties and existing management systems | Implementation charter |
| Days 16-30 | Build inventory, assign owners, complete gap assessment and prioritize material systems | Current-state evidence map |
| Days 31-45 | Approve policy, governance, risk criteria, objectives and lifecycle decision points | AIMS design and ownership model |
| Days 46-65 | Implement risk, impact, supplier, evaluation, release, monitoring and incident records | Operating control set |
| Days 66-75 | Train role holders and run the process on representative systems | Completed system evidence |
| Days 76-90 | Run internal audit, management review and corrective-action planning | Readiness decision and remediation plan |
ISO 42001 and NIST AI RMF serve different purposes
NIST AI RMF is a voluntary, flexible risk framework organized around Govern, Map, Measure, and Manage. ISO/IEC 42001 is a requirements-based management-system standard. An organization can use AI RMF outcomes and Playbook suggestions inside an AIMS, but one does not automatically establish conformity with the other.
Map controls once and preserve the source requirement. A useful crosswalk identifies common evidence, partial coverage, and obligations unique to each framework. Avoid treating a crosswalk as proof that implementation or certification has been achieved.
Sources: [3]
What certification readiness looks like
The organization should be able to explain its scope, show that roles understand their responsibilities, produce current records from representative AI systems, demonstrate internal audit and management review, and show that findings lead to corrective action. Evidence should be consistent with actual product and operating practice.
- Traceable
- Requirements connect to controls, owners, systems, records, findings and decisions.
- Operating
- Records come from real cycles of assessment, release, monitoring, incident handling and improvement.
- Proportionate
- Control depth follows risk and impact rather than applying identical paperwork to every system.
- Integrated
- The AIMS works with product, security, privacy, procurement, quality and enterprise risk.
- Corrective
- Nonconformities and weaknesses have root causes, owners, deadlines, verification and closure.
Related service
ISO 42001 implementation and AI governance
Kesho helps organizations define AIMS scope, implement lifecycle controls, produce operating evidence, run readiness assessments, and prepare for independent audit.
Explore the service