ISO/IEC 42001
Clause 6.1.2 — AI risk assessment
What 6.1.2 establishes is a process, not a register. Criteria first, then a method that identifies, analyses and evaluates AI risks and can be run twice by two people without producing two different answers. Clause 8.2 is where that method is actually operated, and evidence of the one is not evidence of the other.
§ 1 — Who it binds
Who owes the process, and when
Every organisation operating an AI management system, before any assessment is performed. Clause 6.1.2 sits in Planning: it binds the organisation to define the criteria, the method and the process, and it is discharged by a documented method rather than by a completed assessment. It applies whatever the size of the AI estate, including where the organisation builds nothing at all and only uses systems supplied by others.
§ 2 — In practice
Six establishes it, eight runs it
The standard mirrors itself. Clause 6 establishes processes and clause 8 runs them, and the pairing is exact enough that 6.1.2 and 8.2 carry the same title. The NIST-hosted crosswalk written against the FDIS, attributed to Microsoft, reflects the split independently: it maps GOVERN 1.3 and GOVERN 1.4 of the NIST AI Risk Management Framework onto the planning clauses and GOVERN 1.5 onto the operational ones. In an assessment this becomes ordinary and awkward. An organisation asked for its risk assessment process hands over a register of risks, which is an output; an organisation asked for its assessments hands over a methodology document, which is a design. Both are usually present somewhere in the building and neither is filed where the clause expects it.
Criteria come first and have to be capable of producing results that are consistent, comparable and valid. That is the sentence with consequences, because a colour-coded matrix meets none of the three. Red, amber and green are labels; what makes them criteria is a stated threshold behind each, and for a probabilistic system a threshold is a number attached to a population and a window — which subgroup, measured how, over what period, and at what level the organisation stops accepting the result. Almost nobody has written this down, and the profession has a name for the consequence: an audit function meeting the same absence has a duty to go and get criteria settled rather than report that none existed, which is what evaluation criteria for an AI audit sets out.
Repeatability is the property the clause quietly demands and the one nobody tests. If two competent assessors, given the same system and the same criteria, reach materially different evaluations, the divergence is not a disagreement about the system — it is proof that the criteria do not determine an answer. The check costs an afternoon: hand one system to a second assessor, compare, and record the result. Where a lifecycle risk process is required in law, as Article 9 requires of a high-risk system, the same weakness surfaces later and more expensively, because a process that cannot be reproduced cannot be shown to have been followed.
AI risk is not information security risk with a new label, and a register carried over from another management system is the failure this clause meets most often. The borrowed frame is mature and well understood, which is exactly why it gets reused, but it is built around an adversary exploiting a weakness. The characteristic AI harm has no adversary: a system works precisely as built, on a population it was not fitted to, while every control around it operates correctly. There is a standard for the method — ISO/IEC 23894:2023, Information technology — Artificial intelligence — Guidance on risk management — and the point of naming it here is not that it must be adopted but that a dedicated treatment exists, so reaching for the security methodology is a choice rather than a necessity.
Risk and impact are different assessments with different subjects, and 6.1.2 sits next to a clause that makes the distinction concrete. A risk assessment asks what threatens the organisation’s ability to achieve its objectives. An impact assessment asks what the system does to individuals, to groups and to society, whether or not that troubles the objectives at all. The two overlap heavily and are not substitutes: a harm falling entirely on people outside the organisation can be severe and register as nothing on a risk matrix calibrated to revenue, reputation and regulatory exposure. Organisations that run only one of the two almost always run the risk assessment, because it is the one their existing committee already knows how to read.
§ 3 — When it applies
The editions, and why neither is a deadline
31 December 2023
Publication date of the BSI adoption of the first edition; an edition date, not a compliance deadline.
31 March 2026
European and UK adoption, BS EN ISO/IEC 42001:2026 — BSI states no technical differences in the requirements or guidance.
§ 4 — What discharges it
What the process must produce before it runs
The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.
01
The documented risk assessment process, with its criteria
Method, inputs, who performs it, and the criteria it applies — held as one document rather than reconstructed from a completed register. This is the artefact the clause asks for, and it is separate from anything the process has produced.
02
Threshold statements for each measurable AI risk
A figure, the population it is measured over, the observation window, and the level at which the result stops being acceptable. Without the figure a grading is a preference, and two people applying it will not land in the same place.
03
A repeatability check performed by a second assessor
One system handed independently to somebody who did not do the original work, with the two evaluations compared and the difference explained. Almost no organisation runs this, and it is the only direct test of whether the criteria decide anything.
04
The AI risk register keeping identification, analysis and evaluation apart
Three recorded steps rather than one column of ratings. Where identification and evaluation are collapsed, a category such as bias or drift gets scored as though it were a risk and the specific failure mode is never named.
05
The consistency argument against enterprise risk criteria
How the AI criteria relate to the thresholds the organisation already uses elsewhere, and where they deliberately differ. An AI scale calibrated in isolation produces gradings the board cannot compare with anything else it reads.
06
Ownership and last-evaluated date per register entry
A named owner with authority over the treatment, and the date the entry was last worked on rather than the date it was created. Entries with neither are the ones nobody revisits between certification visits.
§ 5 — Worked example
Worked example — amber, red, and no threshold
A bank’s model risk function is asked to produce the AI risk assessment for its ISO/IEC 42001 programme. It adapts the information security methodology already in use: assets, threats, vulnerabilities, likelihood and impact on a five-by-five grid, appetite expressed as red, amber and green. Applied to the retail credit model the output reads "model bias — amber" and "model drift — amber". Two analysts asked to score the same system independently returned amber and red.
Where does this fall short of the process 6.1.2 establishes?
At the criteria, which the clause asks for first and which is the only element here that was inherited rather than set. Nothing states what makes a bias finding amber instead of red, so the two analysts did not disagree about the model — they had nothing to disagree against, and their divergence is the direct evidence of it. A workable criterion for this system would name a subgroup, a measure, a window and the level at which the bank stops accepting the result. The second shortfall is the borrowed frame. Assets, threats and vulnerabilities describe an intrusion well and a credit model badly, because the harm does not arrive through an attacker; it arrives through the model doing exactly what it was fitted to do on applicants it was not fitted for. The third is that "model bias" is a category rather than a risk, which means the identification step has not really been performed — what survives is the grid, and the exercise then spends its time filling it in.
§ 6 — What a weak answer looks like
The security register, relabelled
The security register with the word "model" inserted. Confidentiality, integrity and availability carry over, a handful of AI-flavoured entries go in at the bottom, and the organisation reports that AI risk is assessed. It is not laziness — the borrowed methodology is mature, already audited, and understood by the committee that will read the output. What it cannot express is a system degrading quietly on one subpopulation while every surrounding control operates correctly, because the frame has nowhere to put a harm with nobody behind it.
§ 7 — Elsewhere
The same process, demanded elsewhere
Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.
Article 9 requires a risk management system to be established, documented and maintained across the lifecycle of a high-risk system. Both instruments ask for a defined process rather than a completed register, and each fixes its own population.
IIA Standard 13.4 obliges an auditor to assess whether management’s criteria are adequate and, where they are not, to identify appropriate ones with the board. The criteria 6.1.2 asks an organisation to set are the ones that audit then tests against.
A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.
§ 8 — provenance
The provision itself
This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.
- ISO/IEC 42001:2023 free document preview — official contents page, listing 6.1.2 AI risk assessment under 6.1 Actions to address risks and opportunities, with 6.1.3, 6.1.4 and the mirrored 8.2 and 8.3.
- BSI Knowledge product record for BS ISO/IEC 42001:2023, published 31 December 2023.
- BSI Knowledge product record for BS EN ISO/IEC 42001:2026, published 31 March 2026.
- BSI Knowledge product record for BS ISO/IEC 23894:2023, Information technology — Artificial intelligence — Guidance on risk management, confirming the standard’s existence and official title.
- NIST-hosted crosswalk attributed to Microsoft and written against ISO/IEC FDIS 42001, mapping GOVERN 1.3 and GOVERN 1.4 to the planning clauses and GOVERN 1.5 to the operational ones.
§ 9 — Also read
Also read
AI system impact assessment — clause 8.4
Certification
Assessed on the same standard of evidence
Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The Certified Applied AI Associate, the Council’s flagship, is open to any adult today, its fee waived by a coupon code from the AI-Readiness Check, and the register lists what is open for enrolment.