Customers, auditors and regulators increasingly ask organisations to prove that their AI is governed, and ISO/IEC 42001 is the international management system standard written for that purpose, with accredited certification available. Published in December 2023, it sets requirements for an AI management system (AIMS) covering how an organisation that develops, provides or uses AI sets policy, assesses risk and impact, controls the AI life cycle and improves over time. This guide walks through clauses 4 to 10, the Annex A control areas and Annex B guidance, AI system impact assessment with ISO/IEC 42005, how 42001 fits with ISO/IEC 27001, the NIST AI RMF and the EU AI Act, and what certification involves. It is written for GRC leads, CISOs, AI platform owners and compliance teams preparing for an AIMS or a certification audit. ISO texts are paywalled: where a detail comes from a secondary summary rather than ISO's own catalogue pages, this guide says so.
Key takeaways
- It is a management system, not a technical checklist. ISO/IEC 42001 requires a governed cycle of context, leadership, planning, support, operation, evaluation and improvement around AI, in the same harmonised clause structure as ISO/IEC 27001.
- Two assessments drive everything. Clause 6.1.2 AI risk assessment and clause 6.1.4 AI system impact assessment feed control selection and the Statement of Applicability; ISO/IEC 42005:2025 gives guidance on the impact assessment.
- Annex A is a reference set, not a mandate. Secondary sources agree it lists 38 controls in nine areas, from AI policy to third-party relationships; you select, justify and document them, and Annex B explains how to implement them.
- Build on what you have. An existing ISO/IEC 27001 ISMS already provides document control, internal audit, management review and corrective action, so most organisations integrate the two rather than run a separate system.
- Certification is not EU AI Act compliance. ISO/IEC 42001 is not a harmonised standard under the AI Act; the AI Act quality management standard, prEN 18286, was still at public enquiry stage according to the European Commission's August 2026 update.
What ISO/IEC 42001 is and who it applies to
ISO's catalogue page describes ISO/IEC 42001:2023 (Information technology, Artificial intelligence, Management system) as specifying "requirements for establishing, implementing, maintaining, and continually improving" an AIMS. It is a 51-page first edition, published on 18 December 2023 by ISO/IEC JTC 1/SC 42 (Artificial intelligence), with no amendment listed. It applies to "organizations of any size involved in developing, providing, or using AI-based products or services", in any sector, public or private.
- Developers and providers: build models or AI systems and offer them to others. The life cycle and data control areas carry most weight.
- Users (deployers): buy or embed third-party AI. The use, third-party and impact assessment areas carry most weight, and supplier evidence becomes central.
- Both: most enterprises are both, for example building copilots on a third-party foundation model. Scope should say which role applies to which AI system.
The standard is outcome-oriented: it says what the management system must achieve, not which tools or model types to use. That is why it suits mixed estates of machine learning, generative AI and agents.
Clauses 4 to 10: the requirements
Clauses 1 to 3 (scope, references, terms) are informative; clauses 4 to 10 are the auditable requirements. Sub-clause titles below follow Advisera's published structure of the standard (a secondary source).
| Clause | Sub-clauses | What an auditor expects to see |
|---|---|---|
| 4 Context of the organization | 4.1 Context; 4.2 Interested parties; 4.3 Scope of the AIMS; 4.4 AI management system | Documented scope naming AI systems, roles (developer, provider, user), internal and external issues, legal requirements and interested parties |
| 5 Leadership | 5.1 Leadership and commitment; 5.2 AI policy; 5.3 Roles, responsibilities and authorities | Approved AI policy, named accountable owners, evidence that top management reviews and resources the AIMS |
| 6 Planning | 6.1.1 General; 6.1.2 AI risk assessment; 6.1.3 AI risk treatment; 6.1.4 AI system impact assessment; 6.2 AI objectives; 6.3 Planning of changes | Risk criteria and method, risk register, treatment plan, Statement of Applicability, impact assessment method, measurable objectives |
| 7 Support | 7.1 Resources; 7.2 Competence; 7.3 Awareness; 7.4 Communication; 7.5 Documented information | Training records for AI roles, awareness of the AI policy, controlled documents |
| 8 Operation | 8.1 Operational planning and control; 8.2 AI risk assessment; 8.3 AI risk treatment; 8.4 AI system impact assessment | Assessments run at planned intervals and on significant change, treatment actions implemented, life cycle controls operating |
| 9 Performance evaluation | 9.1 Monitoring and measurement; 9.2 Internal audit; 9.3 Management review | Metrics, an internal audit programme covering the whole AIMS, management review minutes with decisions |
| 10 Improvement | 10.1 Continual improvement; 10.2 Nonconformity and corrective action | Nonconformity log with root cause and closure evidence |
Clause 6 appears twice by design: clause 6 plans the method, clause 8 runs it in operation. Auditors test both, so a method document without completed assessments for each in-scope system fails.
Risk assessment, risk treatment and the Statement of Applicability
- Risk criteria first: define what counts as acceptable AI risk, covering harm to the organisation and to people affected by AI systems. ISO/IEC 23894:2023, ISO's guidance on AI risk management for organisations that "develop, produce, deploy or use" AI, builds on the ISO 31000 process and is the natural method reference.
- Risk sources: Annex C lists suggested AI-related organisational objectives and risk sources (per Advisera's summary). Use it as a prompt list alongside sources from your own threat modelling.
- Treatment and control selection: clause 6.1.3 requires organisations to "determine all controls that are necessary to implement the AI risk treatment options chosen" and compare them with Annex A, as quoted in a Cloud Security Alliance summary. Controls can come from Annex A or anywhere else, including ISO/IEC 27001 Annex A.
- Statement of Applicability (SoA): list each Annex A control, whether it is included, why, and whether it is implemented; justify every exclusion. A one-line "not applicable" for data controls in an organisation that fine-tunes models will not survive the audit.
- Security risk is part of AI risk: prompt injection, data poisoning, model theft and credential misuse belong in the register. See the LLM Security Guide and the AI Agent Threat Modelling Guide.
AI system impact assessment and ISO/IEC 42005
The AI risk assessment asks what could go wrong for the organisation; the AI system impact assessment (clauses 6.1.4 and 8.4, plus the Annex A.5 control area) asks what the system could do to individuals, groups and society. ISO/IEC 42005:2025, published on 28 May 2025, gives guidance on performing these assessments "throughout the AI system lifecycle", from design to post-market monitoring, considering how AI systems "may affect individuals, groups, or society at large". ISO positions it as complementing 42001 and 23894.
| Assessment | Source | Question it answers | Trigger |
|---|---|---|---|
| AI risk assessment | ISO/IEC 42001 6.1.2 and 8.2; guidance ISO/IEC 23894 | What AI risks threaten the organisation's objectives? | Planned intervals and significant change |
| AI system impact assessment | ISO/IEC 42001 6.1.4 and 8.4; guidance ISO/IEC 42005 | What could this system do to people and society? | Each in-scope AI system, across its life cycle |
| Data protection impact assessment | GDPR Article 35 | Is processing of personal data likely to result in high risk to individuals' rights? | High-risk personal data processing |
| Fundamental rights impact assessment | EU AI Act Article 27 | What are the impacts on fundamental rights of deploying this high-risk system? | Specified deployers of high-risk AI, before first use |
Run one combined template with sections for each legal or standard requirement, so a single workshop produces the 42001 record, the DPIA input and, where relevant, the FRIA input. See the DPIA Guide: Running a Data Protection Impact Assessment.
Annex A controls and Annex B guidance
ISO's own page does not list the controls. Two secondary sources, Advisera and Vanta, both state that Annex A contains 38 controls in nine areas; one other published list gives 39 controls with different titles, which is a good reason to work from a purchased copy. Area names below are as given by Vanta; example control references use the numbering in the NIST AI Resource Center's RMF-to-42001 crosswalk, which was prepared against the final draft (FDIS) and refers to the matching Annex B guidance items (B.x.y gives guidance for A.x.y).
| Area | Name | What it covers | Example evidence |
|---|---|---|---|
| A.2 | Policies related to AI | AI policy (A.2.2) and its review (A.2.4) | Approved AI policy with review date |
| A.3 | Internal organization | Accountability and roles for AI within the organisation | RACI per AI system, concern reporting channel |
| A.4 | Resources for AI systems | Resource documentation (A.4.2), data (A.4.3), tooling (A.4.4), system and computing (A.4.5) and human resources (A.4.6) | AI system inventory with models, datasets, tools, infrastructure and owners |
| A.5 | Assessing impacts of AI systems | Impact assessment process, documentation, impacts on individuals or groups and on society (A.5.2 to A.5.5) | Completed impact assessments |
| A.6 | AI system life cycle | Objectives and processes for responsible development, verification and validation (A.6.2.4), deployment, operation and monitoring (A.6.2.6), technical documentation (A.6.2.7), event logs (A.6.2.8) | Release gates, test reports, monitoring dashboards, log retention |
| A.7 | Data for AI systems | Data for development, acquisition, quality, provenance and preparation (A.7.2 to A.7.6) | Dataset records with source, licence, quality checks and lineage |
| A.8 | Information for interested parties of AI systems | Information for users and others, external reporting (A.8.3), communication of incidents (A.8.4), information for interested parties (A.8.5) | User notices, incident communication procedure |
| A.9 | Use of AI systems | Responsible use of AI systems in line with their intended use | Acceptable use rules, intended-use statements |
| A.10 | Third-party and customer relationships | Responsibilities shared with suppliers and with customers (A.10.4) | Supplier assessments, contract clauses, customer documentation |
Annex B gives implementation guidance per control, Annex C the objectives and risk sources, and Annex D how the AIMS applies across sectors and integrates with other management system standards (per Advisera). Supplier controls are where most deployers need work; see the AI Supply Chain and AI-BOM Guide.
The related standards
| Standard | Role relative to 42001 |
|---|---|
| ISO/IEC 22989 and ISO/IEC 23053 | AI concepts and terminology, and the AI and machine learning framework; listed by ISO alongside 42001 |
| ISO/IEC 23894:2023 | Guidance on AI risk management; the method behind clauses 6.1.2 and 8.2 |
| ISO/IEC 42005:2025 | Guidance on AI system impact assessment; supports 6.1.4, 8.4 and A.5 |
| ISO/IEC 42006:2025 | Requirements for bodies auditing and certifying an AIMS; "supplements ISO/IEC 17021-1 with AI-specific requirements"; published July 2025 |
| ISO/IEC 38507:2022 | Governance implications of AI use, aimed at boards and governing bodies rather than the management system |
| ISO/IEC 27001:2022 | Information security management system; shares the harmonised clause structure and is the usual foundation |
| ISO/IEC 27701 | Privacy information management; relevant where AI processes personal data |
ISO/IEC 42001 and ISO/IEC 27001
Both standards use the harmonised structure, so clauses 4 to 10 line up: context, leadership, planning, support, operation, evaluation and improvement. The differences are in what is assessed and controlled.
- Shared and reusable: document control, competence records, internal audit programme, management review, nonconformity and corrective action, supplier management process and the risk method framework.
- New for 42001: AI-specific risk criteria, the impact assessment on people and society, AI life cycle controls, data provenance and quality, information for users and affected parties, and responsible-use objectives.
- Still from 27001: access control, cryptography, logging infrastructure, secure development and vulnerability management. 42001 does not replace them for AI systems; it assumes them.
- Integrated audits: a certification body accredited for both can audit them together, reducing duplicate evidence. Ask for this at quotation.
Certification mechanics, scoping and the 27001 Annex A themes are covered in the ISO 27001 Certification Guide.
Mapping to the NIST AI RMF and the EU AI Act
The NIST AI Resource Center lists a crosswalk from the AI RMF to ISO/IEC 42001. It is many-to-many, and its examples show where each RMF function lands:
| NIST AI RMF subcategory | ISO/IEC 42001 references in the crosswalk |
|---|---|
| GOVERN 1.1 legal and regulatory requirements | 4.1, 6.2, B.2.2 AI policy, B.2.4 review of the AI policy |
| GOVERN 1.6 inventory of AI systems | B.4.2 to B.4.6 resource documentation, data, tooling, computing and human resources |
| GOVERN 2.3 executive responsibility | 5.1, 5.2, 9.3 management review |
| MAP 1.1 intended purpose and context | 6.1.4, B.5.2 to B.5.5 impact assessment |
| MEASURE 2.4 production monitoring | 9.1, B.6.2.6 operation and monitoring, B.6.2.8 event logs |
| MANAGE 2.3 responding to unknown risks | 6.1.1 to 6.1.3, 10.2 nonconformity and corrective action |
| MANAGE 4.1 post-deployment monitoring | 9.2, B.6.2.6, B.8.3 external reporting, B.10.4 customers |
Choose the RMF when you need a flexible, non-certifiable vocabulary for US public-sector or internal risk work; choose 42001 when customers want third-party assurance. The RMF's Generative AI Profile (NIST AI 600-1) is a useful source of risks for the 42001 register. In NIST CSF 2.0 terms the AIMS sits mainly in the GOVERN function (GV.OC context, GV.RM risk strategy, GV.PO policy, GV.SC supply chain).
EU AI Act status
- Presumption of conformity: under the AI Act, harmonised standards referenced in the Official Journal give a presumption of conformity. CEN-CENELEC describes this as a "legal presumption of conformity".
- Who is writing them: CEN-CENELEC JTC 21, set up on 1 June 2021, works under a Commission request covering ten areas: risk management, data governance and quality, record keeping, transparency, human oversight, accuracy, robustness, cybersecurity, quality management and conformity assessment.
- Where they are: the Commission's page (last updated 3 August 2026) names prEN 18286, Quality Management System for EU AI Act Regulatory Purposes, as the first to reach public enquiry, on 30 October 2025, with the rest "currently under development". None was listed as referenced in the Official Journal.
- What it means: 42001 certification is useful evidence of governance for providers preparing Article 17 quality management, but it does not by itself give presumption of conformity. Plan to map your AIMS to prEN 18286 once it is final.
For the AI Act timeline after the Digital Omnibus see the AI Governance Guide.
Choosing scope and approach
| Situation | Recommended approach | Trade-off |
|---|---|---|
| SaaS provider whose buyers ask for AI assurance | Certify the AI product line, integrated with an existing 27001 scope | Narrow scope is quicker but buyers will read the certificate scope statement |
| Enterprise deploying third-party AI | Implement the AIMS, certify later if contracts require it; focus on A.9 and A.10 | Less external assurance, lower cost |
| Model developer or high-risk AI Act provider | Full life cycle scope, align documentation with Article 17 and prEN 18286 | Highest effort; largest evidence base |
| Small organisation with one AI product | Single AIMS integrated with the ISMS, one owner, quarterly review | Heavy reliance on few people |
| Group with many business units | Central AI policy and method, local registers, staged scope expansion | Consistency effort across units |
Implementing and certifying an AIMS
- Gap analysis: assess clauses 4 to 10 and the Annex A areas against current practice; reuse any 27001 gap work.
- Scope and inventory: list AI systems, their role (developer, provider, user), owners, models, datasets and suppliers. See the Shadow AI Discovery Guide for finding unregistered tools.
- Policy and roles: approve the AI policy and accountable owners under clause 5.
- Assess: run the AI risk assessment and impact assessments for each in-scope system, then select controls and write the SoA.
- Pilot: operate the controls on one or two AI systems for at least one review cycle; run a dry-run internal audit and fix findings before widening scope.
- Operate and record: release gates, monitoring, incident communication and supplier reviews produce the evidence auditors sample.
- Internal audit and management review: cover the whole AIMS before the external audit.
- Certification audit: under ISO/IEC 17021-1, a stage 1 audit checks readiness and documentation and a stage 2 audit tests implementation; certification is followed by surveillance audits and recertification on a three-year cycle. ISO/IEC 42006 adds AI-specific competence requirements for the auditing body.
Pick a certification body accredited for ISO/IEC 42001 by a national accreditation body (for example, BSI announced ANAB accreditation in March 2026 in addition to UKAS and RvA), and check the accreditation scope. If a control proves unworkable during the pilot, revise the risk treatment and SoA through clause 6.3 planning of changes rather than quietly dropping it; that change record is itself audit evidence.
Where identity fits
AI agents and pipelines run on service accounts, API keys and workload identities. The A.4 resource records (tooling, system and computing resources) and A.6.2.8 event logs are only credible if every AI system's credentials are inventoried, owned and logged under a named identity. Include agent identities in the AI system inventory and in access reviews. See the Agentic AI Identity Guide.
Measuring the AIMS
- Inventory coverage: AI systems found by discovery that were already in scope and registered; target above 95%.
- Assessment currency: in-scope systems with a risk and impact assessment reviewed within the defined interval; target 100%.
- Release gate compliance: AI releases that passed verification and validation sign-off before deployment.
- Supplier evidence: AI suppliers with a completed assessment and contract clauses for AI-specific responsibilities.
- Nonconformity closure: median days to close internal and external audit findings.
- AI incidents: number, severity and time to communicate to affected parties under the incident procedure.
Common failure patterns
- Scope that excludes the AI people actually use. Certifying one product while shadow tools and copilots sit outside scope impresses nobody who reads the scope statement.
- Copying the ISMS risk register. Confidentiality, integrity and availability ratings alone miss impacts on people, fairness and misuse.
- Impact assessments done once. Model changes, new data sources and new uses need reassessment under clause 8.4.
- SoA exclusions without reasons. Excluding data or supplier controls because "we use a vendor model" is the opposite of what A.10 expects.
- No owner for user-facing information. When an AI system gives users wrong information, the organisation still answers for it, as the Air Canada chatbot ruling showed; A.8 and A.9 controls exist for this.
- Treating the certificate as AI Act compliance. Harmonised standards and conformity assessment are separate obligations.
Practitioner checklist
- Define AIMS scope with each AI system's role as developer, provider or user.
- Build and maintain an AI system inventory covering models, datasets, tools, infrastructure, suppliers, owners and identities.
- Approve an AI policy and assign accountable owners under clause 5.
- Adopt an AI risk method based on ISO/IEC 23894 and an impact assessment method based on ISO/IEC 42005.
- Write a Statement of Applicability covering all Annex A controls with justified inclusions and exclusions.
- Integrate with the ISO/IEC 27001 ISMS for document control, audit, management review and corrective action.
- Pilot on one or two AI systems and run a dry-run internal audit before stage 1.
- Choose an accredited certification body and confirm 42001 is in its accreditation scope.
- Map the AIMS to the NIST AI RMF and track prEN 18286 for EU AI Act alignment.
Standards and references
- ISO: ISO/IEC 42001:2023 Information technology, Artificial intelligence, Management system
- ISO: ISO/IEC 42005:2025 AI system impact assessment
- ISO: ISO/IEC 42006:2025 Requirements for bodies providing audit and certification of AI management systems
- ISO: ISO/IEC 23894:2023 Guidance on risk management
- European Commission: Standardisation of the AI Act
- CEN-CENELEC: Artificial Intelligence (JTC 21)
- NIST AI Resource Center: NIST AI RMF to ISO/IEC 42001 Crosswalk
- Advisera: ISO 42001 Requirements: Clauses and Structure
Related NHI Mgmt Group resources: AI Governance Guide · ISO 27001 Certification Guide · Agentic AI Compliance Guide · Control Mapping Guide · DPIA Guide: Running a Data Protection Impact Assessment