ISO 42001 risk assessment and treatment: clauses 6.1.2, 6.1.3, 8.2 and 8.3, with ISO/IEC 23894

What does ISO 42001 require for AI risk assessment and treatment?

ISO/IEC 42001:2023 designs the AI risk method in clause 6 and runs it in clause 8. Clause 6.1.1 sets the general frame, including the risk criteria. Clause 6.1.2 then asks for an assessment process that is aligned with the AI policy and objectives and built so that doing it again produces results that are consistent, valid and comparable.

You identify risks that could support or block the AI objectives, analyse realistic likelihood and consequences, for individuals and societies as well as the organisation, and set a level. Each risk is then evaluated against the criteria and prioritised, and the process is retained as documented information.

Where ISO/IEC 23894 and Annex C fit

ISO/IEC 23894:2023, "Guidance on risk management" for artificial intelligence, was published in February 2023 as a first edition of 26 pages. It is guidance: nobody is certified to it, but it can inform the method clause 6.1.2 asks you to write.

Annex C of ISO/IEC 42001, which is informative, lists potential AI-related organisational objectives and risk sources: a useful prompt list for identification workshops. Teams already using the NIST AI Risk Management Framework can use the revised crosswalk between ISO/IEC 23894 and the AI RMF, published by INCITS/AI in August 2025 and listed on NIST's resource site.

Clause 6.1.4 requires the results of the impact assessment to be considered here, so every significant impact should appear as a risk entry; that assessment is explained in our AI system impact assessment guide.

Setting the criteria and choosing a method

ISO/IEC 42001 prescribes no scale, matrix or tool. The auditor's test comes from the clause itself: would different people assessing the same system reach broadly the same result? Clear criteria decide that, not the spreadsheet.

Sterling's recommended practice is a small scale, usually four or five levels for likelihood and for consequence, each described in a sentence. Consequence levels cover three angles, as the clause does: harm to the organisation (contracts, regulators, reputation, cost), harm to individuals (a wrong decision, exposed data, unfair treatment) and harm to society (scale effects, public trust). The highest of the three sets the rating.

Fix the acceptance threshold at the same time. Risks above it are treated or explicitly accepted; risks below it are monitored. Name that designated management, since 6.1.3 requires their approval.

Identify by system, then by objective

Work from the AI system inventory. For each system, walk the life cycle from data acquisition to monitoring, then test the list against each AI objective and the Annex C risk sources. Cross-cutting risks, such as reliance on one model supplier, go on the register at organisation level.

From treatment options to the Statement of Applicability

Clause 6.1.3 asks you to select treatment options and then determine every control needed to carry them out. Sterling's recommended practice is to record one decision per risk from four: reduce it with controls, avoid it by changing or dropping the use, share it through a contract or insurance, or accept it with a reason.

The controls you choose are then compared with the 38 reference controls of Annex A, so that nothing necessary has been missed. Annex A is not exhaustive, so add your own control, such as a model rollback procedure, where a risk needs it, and consider the implementation guidance in Annex B.

The comparison produces the Statement of Applicability: every Annex A control listed, marked included or excluded, each with a justification. The treatment plan then names, for each risk, the actions, owner, target date and expected residual level. Designated management approves the plan and accepts what risk remains. Our Annex A guide explains the controls themselves.

A worked example: a customer-service chatbot on a third-party model

A software company provides a support chatbot to its business customers, built on a generative AI model licensed from a vendor. Four illustrative lines from its register, on a five-level scale, show how analysis, evaluation and treatment connect.

The first three enter the treatment plan; the fourth is accepted by designated management and reviewed at the next reassessment.

Keeping the assessment current, and what auditors test

Clause 8.2 requires reassessment at planned intervals and whenever a significant change is proposed or happens. Sterling's recommended triggers include a new model or model version, a new data source, a new customer segment or country, a move from assisted to automated decisions, and a serious incident. Clause 8.3 then asks for evidence, from monitoring rather than a tick in the plan, that each treatment worked.

In the certification audit, expect the auditor to pick a system and trace it end to end: the inventory entry, its risks and ratings, the linked impact assessment, the controls marked applicable in the Statement of Applicability, evidence that those controls operate, and the approval of residual risk. A register and a Statement of Applicability that disagree are among the quickest findings to raise.

Mistakes that weaken AI risk assessment

• Only organisational harm rated. Consequences for individuals and societies are left out, although clause 6.1.2 names them.
• Controls chosen from Annex A first. Working down the control list and then inventing risks to justify it reverses the logic the auditor will follow.
• Residual risk never accepted. The plan exists, but no designated manager has approved it or signed off what remains.
• The register frozen after certification. Models are retrained and suppliers change, yet the ratings stay as they were at the gap analysis.

ISO 42001 risk assessment: questions buyers ask