FAQGlobalISO/IEC 42001

ISO/IEC 42001 FAQ Risk Controls

Select AI controls through documented risk treatment: determine necessary controls, compare them with Annex A, consider Annex B guidance, add other controls where needed, and retain the rationale.

Annex A is a reference set, not an exhaustive universal checklist. Control suitability and effectiveness depend on the organisation's objectives, context, AI activities, impacts, risks, and interested-party requirements.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Questions
4

Structured answer sets in this page tree.

Primary sources
2

Cited legal and guidance references.

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

Start with assessed AI risks and treatment options, not an Annex A checklist. Determine every control needed for the chosen treatment, compare that set with Annex A, consider Annex B guidance, add different or additional controls when needed, and document the result in the and approved risk-treatment plan.

Search this module

Find a question or answer quickly

4 of 4 questions
Question 1

How should teams handle Risk Controls under ISO/IEC 42001?

Follow the Clause 6.1.3 sequence for each assessed risk: select a treatment option; determine every ; compare that set with Annex A to check for omissions; consider relevant Annex A controls and Annex B implementation guidance; add different or additional controls where needed; produce the ; formulate the treatment plan; and obtain designated-management approval of the plan and .

Annex A is normative as a reference control set within ISO/IEC 42001, but not every listed control applies to every organisation or system. Annex B is normative implementation guidance, although the organisation does not have to document or justify the inclusion or exclusion of that guidance in the . The risk assessment, chosen treatment, objectives, and applicable external requirements determine the actual control set; a team may need controls beyond Annex A.

Use system-specific examples to test the reasoning. A supplied AI service can require supplier documentation, intended-use instructions, logging, monitoring, and incident routes. A model trained internally can also require data acquisition, quality, provenance, preparation, verification, release, and change controls. An AI tool affecting people can require impact assessment, accessible user information, adverse-impact reporting, and meaningful human oversight. These examples are not a universal checklist.

The must contain the necessary controls and justify their inclusion and exclusion. An exclusion can be justified when a control is not necessary under the risk assessment or an applicable external requirement does not require it or provides an exception. The statement is not permission to omit a control that the selected treatment or an external requirement makes necessary.

  • Do not treat Annex A as an automatic universal checklist.
  • For each included control, state the risk or requirement, objective, scope, owner, implementation, evidence, effectiveness measure, exception route, and review trigger.
  • For each excluded control, state why it is unnecessary for the scoped system or activity and identify the evidence and approver supporting that conclusion.
  • Document different or additional controls needed beyond Annex A and map them into the same treatment and evidence chain.
  • Obtain designated-management approval for the treatment plan and acceptance of residual AI risks before relying on that acceptance.
Citations
ISO/IEC 42001:2023 standard page

ISO/IEC 42001:2023 Clause 6.1.3 sets the required treatment sequence, Annex A comparison, Annex B consideration, statement of applicability, treatment plan, and management approval of residual risk.

ISO/IEC 23894:2023 standard page

ISO/IEC 23894:2023 is the companion guidance standard for organisations managing AI-related risk; it does not replace ISO/IEC 42001's auditable requirements.

Question 2

What evidence should prove Risk Controls is current under ISO/IEC 42001?

Evidence should show design, implementation, operation, and effectiveness: the risk assessment, treatment decision, , control description, scope, owner, procedure or technical configuration, implementation record, sampled transactions or logs, monitoring method and result, exceptions, residual-risk approval, findings, corrective actions, and review date.

A reviewer should be able to trace from an AI objective and assessed risk to the selected control, its implementation, current operating samples, effectiveness result, exception handling, and residual-risk decision. A policy, screenshot, vendor claim, or control title by itself rarely shows the full chain.

Match the evidence to the control. Supplier controls can use due-diligence records, contract requirements, documentation received, change notices, service reviews, and correction requests. Data controls can use acquisition approvals, provenance, quality criteria and results, lineage, and preparation records. Human-oversight controls can use competence evidence, interface tests, sampled interventions, escalations, and workload measures.

  • Use controlled source records from the system of work and preserve the system version, population, period, criteria, result, and approver they cover.
  • Keep exceptions visible with an owner, expiry or review trigger, compensating control where applicable, and a risk-acceptance or corrective-action decision.
  • Test whether the control changes the assessed likelihood, consequence, exposure, detectability, or response as intended; do not equate activity completion with effectiveness.
  • Update linked registers when the answer changes an owner, risk, control, service, supplier, evidence source, or review date.
Citations
ISO/IEC 42001:2023 standard page

ISO/IEC 42001:2023 Clauses 7.5, 8.1, 8.3, and 9.1 require controlled documented information, operating evidence, treatment results, effectiveness verification, and monitoring results.

Question 3

Who should approve Risk Controls decisions under ISO/IEC 42001?

Control owners design, implement, operate, and monitor controls within their authority. Risk owners evaluate the remaining exposure. The designated management authority approves the risk-treatment plan and accepts . AIMS governance can check coverage and consistency, while top management addresses resources or risk decisions outside delegated authority.

Security, privacy, safety, supplier, legal, product, and business owners should approve matters within their authority. Acceptance of under the AIMS cannot waive a binding legal, contractual, or sector requirement.

  • Name the control owner, risk owner, evidence owner, residual-risk approver, and escalation authority.
  • Separate control design and testing from residual-risk acceptance where practical.
  • Keep approval records with the evidence rather than in disconnected email threads.
Citations
ISO/IEC 42001:2023 standard page

ISO/IEC 42001:2023 Clauses 5.3 and 6.1.3 require assigned authorities and designated management approval of treatment and residual AI risks.

Question 4

When should Risk Controls be reviewed under ISO/IEC 42001?

Review controls through planned monitoring and whenever risks, impacts, intended purpose, users, affected populations, data, model or system design, suppliers, deployment context, incidents, performance, or applicable requirements change. Review before a significant planned change and after an unintended change or control failure.

When a treatment option is ineffective, ISO/IEC 42001 requires review and revalidation through the treatment process and an updated plan. Determine whether to redesign, add, replace, or withdraw controls; reassess the risk and impact; update the ; obtain approval; and verify the revised treatment.

After a nonconformity, control and correct it, deal with consequences, examine causes and similar potential failures where applicable, implement corrective action, and review effectiveness. Keep the remaining risk open until the relevant approval authority accepts it against current criteria.

  • Reassess residual risk after material change or control failure.
  • Add, replace, or redesign controls when the necessary treatment is not covered or the existing control is ineffective.
  • Verify corrective-action effectiveness and update management-review inputs.
Citations
ISO/IEC 42001:2023 standard page

ISO/IEC 42001:2023 Clauses 8.2-8.4 and 10.2 require change-triggered reassessment, revalidation of ineffective treatment, updated plans, and review of corrective-action effectiveness.

Primary sources

References and citations

iso.org
Referenced sections
  • ISO/IEC 23894:2023 provides guidance for iterative AI risk monitoring and review.
"Guidance on risk management"
iso.org
Referenced sections
  • ISO/IEC 42001:2023 Clauses 8.2-8.4 and 10.2 require change-triggered reassessment, revalidation of ineffective treatment, updated plans, and review of corrective-action effectiveness.
"requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System"
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 Controls and Governance Model Guide
ISO/IEC 42001 governance model linking leadership, policy, risk and impact assessment, Annex controls, lifecycle roles, monitoring, audit, and improvement.
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 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.