GuideGlobalISO/IEC 42001

ISO/IEC 42001 Controls and Governance Model

Connect leadership and policy to risk treatment, AI-system impact assessment, lifecycle controls, data and resource controls, interested-party information, responsible use, and third-party relationships.

Annex A and Annex B are normative: A is the reference control set and B is its implementation guidance. The organisation still determines and justifies the controls needed for its own risks, objectives, and context.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
1

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

Build the governance model from decisions and accountability. Top management sets policy, objectives, roles, and resources; system and owners operate each selected control; internal audit evaluates the AIMS objectively; authorised decision-makers address risk, exceptions, and corrective action. Match ownership to the actual AI lifecycle and supplier or customer boundary.

Section 1

Connect governance authority to the AIMS lifecycle

Start with the AIMS scope, context, interested parties, AI policy, objectives, and assigned roles. For each in-scope AI system, connect risks and impacts to treatment decisions, controls, accountable owners, operating evidence, monitoring criteria, escalation authority, and review forums.

Separate authority clearly. A governing body, where one exists, is accountable for organisational performance and conformance; top management leads the AIMS under Clause 5; named AIMS roles report performance; system and owners operate processes; internal audit evaluates the AIMS objectively; authorised roles decide risk acceptance and corrective action.

Annex A is the reference set. Its groups cover policy, internal organisation, resources, impact assessment, lifecycle processes, data, information for interested parties, responsible use, and third-party and customer relationships. Annex B is normative implementation guidance, but it is not always suitable or sufficient and can be extended or modified for organisation-specific risk treatment.

Annex A.8 supports information and communication decisions, but it does not create one universal public-disclosure rule. Record which information must be provided, to whom, when, in what form, and from which organisational, legal, regulatory, or contractual source.

  • Authority map: governing body if present, top management, AIMS owner, system owner, owner, risk authority, internal audit, management review, and corrective-action owner.
  • Decision map: scope, policy, objectives, risk and impact evaluation, treatment, statement of applicability, release, exception, incident, change, and retirement.
  • Evidence map: required input, operating record, effectiveness measure, reviewer, escalation threshold, retention owner, and next trigger.
Section 2

Select and justify controls through risk treatment

Clause 6.1.3 requires an AI risk treatment process. The organisation chooses treatment options, determines necessary controls, compares them with Annex A so no necessary is omitted, and produces a statement of applicability that documents necessary controls and justifies inclusion or exclusion. The organisation can add controls beyond Annex A.

A selected needs more than a policy reference. Record the risk or requirement it addresses, control objective, owner, procedure, affected systems and lifecycle stages, dependencies, evidence, effectiveness criterion, monitoring frequency, exception authority, and change trigger.

  • Treatment record: assessed risk, selected option, necessary , owner, approval, residual-risk decision, and implementation status.
  • Statement of applicability: necessary controls, inclusion or exclusion rationale, implementation status, and organisation-defined controls beyond Annex A.
  • Operating evidence: current procedure plus records showing the ran for the relevant system, period, sample, or event.
  • Effectiveness evidence: criterion, result, evaluator, finding, action, and follow-up result.
Section 3

Operate the governance cycle

Route new systems and significant changes through inventory, scope, risk, impact, treatment, implementation, release, and monitoring decisions. Route incidents, adverse trends, audit findings, complaints, supplier changes, and nonconformities back to the affected assessment or control owner.

Management review uses performance, monitoring, audit, interested-party, risk, opportunity, and resource information to decide changes and improvement. Corrective action remains open until the organisation has addressed the cause and reviewed effectiveness.

  • Plan: determine scope, policy, objectives, risks, impacts, treatment, controls, owners, resources, and acceptance criteria.
  • Operate: implement lifecycle, data, information, responsible-use, supplier, customer, and other selected controls.
  • Evaluate: monitor results and effectiveness, conduct internal audit, and hold management review.
  • Improve: correct nonconformities, address causes, verify effectiveness, and update scope, assessments, controls, resources, or objectives as needed.
Section 4

What mistakes make ISO/IEC 42001 Controls and Governance Model weak or hard to audit?

A copied Annex A checklist is not a completed governance model. Without organisation-specific risk treatment, a statement of applicability, owners, operating evidence, and effectiveness criteria, it cannot show why a is needed or whether it works.

Keep standards, law, regulation, contracts, and policy distinct in the record. ISO/IEC 42001 can organise the process, while another source may create a binding disclosure, retention, testing, approval, or notification duty.

  • Do not assign operation and independent audit of that same work to one person without safeguards for objectivity.
  • Do not treat Annex B guidance as universally sufficient; adapt or add implementation measures when the risk treatment requires it.
  • Do not leave supplier or customer interfaces unallocated because an external party owns part of the system.
Section 5

How should teams review and improve ISO/IEC 42001 Controls and Governance Model over time?

Review a when the system, intended use, risk, impact, data, technology, supplier, customer allocation, performance, incident pattern, applicable requirement, or organisational context changes. Review it when evidence shows that the control did not achieve its intended result.

Management review should produce decisions and actions, not only minutes. Record changes to the AIMS, resources, objectives, controls, risk acceptance, scope, and improvement priorities, with owners and follow-up dates.

  • Track coverage, operating evidence, effectiveness results, exceptions, overdue actions, and unsupported interfaces.
  • Connect internal-audit findings and monitoring breaches to correction, cause analysis, corrective action, and effectiveness review.
  • Update the statement of applicability when necessary controls, rationales, or implementation status change.
Primary sources

References and citations

iso.org
Referenced sections
  • Clauses 9.1-10.2 require performance evaluation, internal audit, management review, continual improvement, and effectiveness review of corrective action.
Related guides

Explore more topics

ISO/IEC 42001 AI Impact Assessment Template
ISO/IEC 42001 AI-system impact assessment template for consequences, affected people, foreseeable misuse, context, evidence, approval, and reassessment.
ISO/IEC 42001 AI Management FAQ
Plain-language ISO/IEC 42001 FAQ covering scope, policy, Annex controls, risk and impact assessment, suppliers, monitoring, certification, and legal limits.
ISO/IEC 42001 AI Policy FAQ
ISO/IEC 42001 AI policy requirements, approval, communication, evidence, alignment with other policies, and review triggers.
ISO/IEC 42001 AI System Inventory Guide
Build an ISO/IEC 42001 AI inventory covering purpose, owners, lifecycle roles, data, resources, suppliers, impacts, risks, controls, and monitoring.
ISO/IEC 42001 AI System Inventory Workflow
ISO/IEC 42001 workflow for creating, approving, maintaining, changing, and retiring AI-system inventory records with accountable evidence.
ISO/IEC 42001 AIMS Scope Decision Guide
Define an auditable ISO/IEC 42001 AIMS boundary across organisational units, AI activities, products, services, interfaces, suppliers, and customers.
ISO/IEC 42001 AIMS Scope Decision Workflow
ISO/IEC 42001 AIMS scope workflow for context, interested parties, AI activities, external dependencies, boundary approval, and change review.
ISO/IEC 42001 Certification FAQ
ISO/IEC 42001 certification scope, readiness evidence, internal audit, management review, corrective action, and claim limits.
ISO/IEC 42001 Compliance Guide
ISO/IEC 42001 conformance guide for Clauses 4-10, risk treatment, controls, operating evidence, internal audit, management review, and correction.
ISO/IEC 42001 Generative AI FAQ
Apply ISO/IEC 42001 to generative AI development, procurement, integration, employee use, supplier evidence, impacts, controls, and monitoring.
ISO/IEC 42001 High Risk AI FAQ
Separate ISO/IEC 42001 organisational risk criteria from legal high-risk AI classifications, with evidence, approval, and reassessment triggers.
ISO/IEC 42001 Human Oversight FAQ
Design and evidence effective human oversight under ISO/IEC 42001, including competence, information, intervention authority, testing, and review.
ISO/IEC 42001 Model Monitoring Evidence Guide
ISO/IEC 42001 monitoring evidence for AIMS performance, AI-system outcomes, impacts, control effectiveness, supplier signals, escalation, and correction.
ISO/IEC 42001 Post Market Monitoring FAQ
Distinguish ISO/IEC 42001 operational monitoring from legal post-market monitoring and connect real-world evidence to risk, review, incidents, and correction.
ISO/IEC 42001 Provider and Deployer Roles FAQ
Map ISO/IEC 42001 lifecycle responsibilities across developers, users, suppliers, customers, and third parties while keeping legal operator roles separate.
ISO/IEC 42001 Requirements Guide
ISO/IEC 42001:2023 requirements explained across Clauses 4-10, Annex A controls, Annex B guidance, evidence, audit, review, and improvement.
ISO/IEC 42001 Risk Controls FAQ
Select, justify, approve, operate, and review ISO/IEC 42001 risk controls, including Annex A comparison, the statement of applicability, residual risk, and evidence.
ISO/IEC 42001 vs EU AI Act Comparison
Compare voluntary ISO/IEC 42001 AIMS certification with binding EU AI Act roles, classifications, duties, evidence, dates, and enforcement.
ISO/IEC 42001 vs ISO/IEC 23894 Comparison
Compare certifiable ISO/IEC 42001 AIMS requirements with ISO/IEC 23894 AI risk-management guidance and see how to integrate their evidence.
ISO/IEC 42001 vs NIST AI RMF Comparison
Compare ISO/IEC 42001 AIMS requirements with the voluntary NIST AI RMF GOVERN, MAP, MEASURE, and MANAGE functions and evidence.