ISO/IEC 23894 is the international guidance on managing the risks that are specific to artificial intelligence. Published in February 2023 by ISO/IEC JTC 1/SC 42, built on ISO 31000 and adopted in Europe as EN ISO/IEC 23894:2024, it is the document most compliance teams reach for the day Article 9 of the EU AI Act, the risk management system for high-risk AI, lands on their desk. That reflex is reasonable and slightly dangerous. The standard and the law use the same words for different things, and the standard will never carry the presumption of conformity that Article 9 needs. This guide explains what ISO/IEC 23894 contains, where it diverges from Article 9, which document will actually be harmonised, and how to use the standard as the method behind an evidence file without mistaking it for the law.
Key takeaways
- ISO/IEC 23894 gives guidance, not requirements: there is nothing to certify against it and no presumption of conformity under the AI Act. ISO/IEC 42001 is the certifiable standard, and its clause 6.1.2 is where an AI risk assessment becomes auditable.
- Its structure mirrors ISO 31000 (principles, framework, process) with AI-specific additions, plus three informative annexes: eleven AI-related objectives, seven families of AI risk sources, and a mapping of the process onto the AI system life cycle.
- “Risk” does not mean the same thing in the standard and in the law: effect of uncertainty on objectives on one side, probability of harm times its severity on the other.
- Article 9 requires what the standard lacks (a residual-risk judgement per hazard, a priority order of measures, testing against predefined metrics, attention to persons under 18) and lacks what the standard has (a stakeholder consultation step).
- The harmonised standard for Article 9 is prEN 18228, in public enquiry until 11 November 2026. Annex III high-risk obligations apply from 2 December 2027.
What is ISO/IEC 23894?
ISO/IEC 23894:2023, “Information technology, Artificial intelligence, Guidance on risk management”, was prepared by ISO/IEC JTC 1/SC 42, the joint committee that also wrote ISO/IEC 22989 (vocabulary) and ISO/IEC 42001 (management system). ISO published it in February 2023, and the catalogue entry describes its scope in one sentence: guidance for organisations that develop, produce, deploy or use products, systems and services that use AI, on how to manage risk specifically related to AI and how to integrate that risk management into their AI-related activities. Two design choices define the document. First, it is explicitly meant to be used together with ISO 31000:2018, the generic risk management guideline: the clause structure mirrors ISO 31000, and wherever the AI text extends the generic text it cites the ISO 31000 clause it builds on. Second, its vocabulary is borrowed, not invented. The normative references are ISO 31000:2018, ISO/IEC 22989:2022 and ISO Guide 73:2009, so when the standard says “risk” it means what ISO 31000 means, a point that matters more than it looks (section 4 below). Europe adopted the text unchanged as EN ISO/IEC 23894:2024, carried in national collections from March 2024 (the German edition is DIN EN ISO/IEC 23894:2023-11, the French one NF EN ISO/IEC 23894). It is a paid document; unlike the vocabulary standard, it is not in ISO’s free list.
Guidance, not a certificate
Every sentence of ISO/IEC 23894 is a recommendation. The text says “should”, never “shall”, so there is no requirement to audit against and no certificate to obtain. Training providers sell personal course certificates on the standard, which is something else entirely. A vendor that claims to be “ISO/IEC 23894 compliant” is claiming something no scheme can verify. The certifiable document is ISO/IEC 42001:2023, the AI management system standard. It requires an AI risk assessment process (clause 6.1.2), AI risk treatment (6.1.3) and an AI system impact assessment (6.1.4), and it repeats the objectives and risk sources of the guidance in its own informative Annex C. For the impact assessment, ISO/IEC 42005:2025, published in May 2025, plays the same supporting role that ISO/IEC 23894 plays for the risk assessment. If you want a certificate, the ISO 42001 certification process is the route; the guidance tells you how to do the risk part well.
What ISO/IEC 23894 contains
The standard takes the three operative clauses of ISO 31000 (principles, framework, process) and adds AI context under each one. The public crosswalk to the NIST AI RMF lists the clauses, which gives a reliable map without opening the paid text. <table header-row=”true”> <tr> <td>Clause</td> <td>What it covers</td> <td>AI-specific addition</td> </tr> <tr> <td>4 Principles</td> <td>The eight ISO 31000 principles (integrated, structured, customised, inclusive, dynamic, evidence-based, human and cultural factors, continual improvement)</td> <td>Considerations on how each principle changes when the object of risk is an AI system</td> </tr> <tr> <td>5 Framework</td> <td>5.2 leadership and commitment, 5.3 integration, 5.4 design (context, commitment, roles and accountabilities, resources, communication and consultation), 5.5 implementation, 5.6 evaluation, 5.7 improvement</td> <td>Governance of the decision to develop, buy or use AI; who is accountable for which AI risk</td> </tr> <tr> <td>6.2 Communication and consultation</td> <td>Dialogue with internal and external stakeholders during the process</td> <td>Engagement with affected people and regulators, including to strengthen human oversight</td> </tr> <tr> <td>6.3 Scope, context and criteria</td> <td>6.3.2 scope, 6.3.3 external and internal context, 6.3.4 risk criteria</td> <td>Criteria that reflect AI objectives such as fairness, transparency and safety</td> </tr> <tr> <td>6.4 Risk assessment</td> <td>Identification of assets, risk sources, events and outcomes, existing controls and consequences; analysis of consequences and likelihood; evaluation</td> <td>AI risk sources (Annex B) and consequences on individuals, groups and society, not only on the organisation</td> </tr> <tr> <td>6.5 Risk treatment</td> <td>Selection of treatment options, treatment plans</td> <td>Options adapted to AI (data, model, monitoring, human intervention)</td> </tr> <tr> <td>6.6 Monitoring and review</td> <td>Keeping the assessment current</td> <td>Continuous validation and re-evaluation as models and data change</td> </tr> <tr> <td>6.7 Recording and reporting</td> <td>The record of the process</td> <td>Traceability of decisions across the AI life cycle</td> </tr> </table> Three informative annexes carry most of the practical value. By our reading of the table of contents, Annex A lists eleven common AI-related objectives: accountability, AI expertise, availability and quality of training and test data, environmental impact, fairness, maintainability, privacy, robustness, safety, security, and transparency and explainability. Annex B lists seven families of AI risk sources: complexity of the environment, lack of transparency and explainability, level of automation, risk sources related to machine learning, system hardware issues, system life cycle issues, and technology readiness. Annex C gives an example mapping between the risk management process and an AI system life cycle, the same life cycle stages that ISO/IEC 22989 defines and that the NIST AI RMF and the OECD use. The same objectives and risk sources reappear in Annex C of ISO/IEC 42001, which is why the two standards are usually read together and why an AI inventory tagged with Annex B sources is a sensible first artefact.
ISO/IEC 23894 vs Article 9 of the AI Act: same words, different rules
Article 9 of the AI Act was written as product-safety law. Its iterative loop of identification, estimation, evaluation and targeted measures follows the tradition of ISO/IEC Guide 51, the safety guide behind machinery and medical-device regulation, as Jonas Schuett observed in his 2022 analysis of Article 9. ISO/IEC 23894 was written inside the ISO 31000 tradition of enterprise risk management. The two traditions share a process shape and disagree on almost everything inside it. <table header-row=”true”> <tr> <td>Point</td> <td>In ISO/IEC 23894</td> <td>In Article 9</td> <td>Consequence</td> </tr> <tr> <td>Definition of risk</td> <td>Effect of uncertainty on objectives, positive or negative (ISO 31000, ISO/IEC 22989)</td> <td>Combination of the probability of an occurrence of harm and the severity of that harm (Article 3(2))</td> <td>A register built on the standard contains opportunities; a register built on the Act contains only harms</td> </tr> <tr> <td>Who is protected</td> <td>The organisation’s objectives, with impacts on external stakeholders taken into account</td> <td>Health, safety and fundamental rights of persons</td> <td>The standard’s “owner” of a risk is the business; the Act’s is the affected person</td> </tr> <tr> <td>Treatment options</td> <td>Avoid, take or increase a risk to pursue an opportunity, remove the source, change likelihood or consequences, share, retain</td> <td>A priority order: eliminate or reduce through design, then mitigation and control, then information to deployers and training (Article 9(5))</td> <td>”Retain” and “increase” are legitimate ISO options that an AI Act file cannot contain</td> </tr> <tr> <td>Acceptability</td> <td>Risk criteria defined by the organisation (clause 6.3.4)</td> <td>The residual risk of each hazard and the overall residual risk must be judged acceptable (Article 9(5))</td> <td>The Act demands a per-hazard judgement the standard never asks for</td> </tr> <tr> <td>Testing</td> <td>Not a step of the risk process</td> <td>Mandatory, against prior defined metrics and probabilistic thresholds, before placing on the market (Article 9(6) to (8))</td> <td>The standard cannot tell you how to prove that a measure works</td> </tr> <tr> <td>Consultation</td> <td>Clause 6.2 communication and consultation, and 5.4.5 in the framework</td> <td>No consultation step; the OECD noted the gap in 2023</td> <td>The standard asks for a record that the law does not, and auditors increasingly want</td> </tr> </table> The expensive confusion is the first row. A risk register written in the standard’s vocabulary will hold organisational risks (reputation, cost overrun, model licensing), opportunities (“increase risk to pursue an opportunity” is a lawful ISO 31000 option), and risks “retained by informed decision”. None of that belongs in an Article 9 file, and the file will still be missing the thing the authority asks for first: for each hazard, the measure chosen in the Article 9(5) order and the explicit judgement that the residual risk is acceptable. The Commission’s consolidated text of Article 9 puts that judgement in paragraph 5 and the testing duty in paragraphs 6 to 8; the standard has no equivalent for either. The scope limits of Article 9 are the second trap. Paragraph 3 confines the system to risks that can reasonably be mitigated or eliminated through development, design or adequate technical information. Paragraph 9 requires providers to consider whether the system is likely to adversely affect persons under 18 and, as appropriate, other vulnerable groups. Paragraph 10 lets providers already bound by risk management rules under other Union law combine the procedures. ISO/IEC 23894 has no equivalent for any of the three, so the standard cannot tell you when you are done, only how to work. The EU AI Act high-risk classification decides whether Article 9 applies at all; the standard decides nothing.
Where ISO/IEC 23894 sits in the standards stack
ISO 31000:2018 is the base; ISO/IEC 23894 is its AI supplement. ISO/IEC 22989 supplies the vocabulary. ISO/IEC 42001 is the certifiable management system that consumes the risk assessment in clause 6.1.2 and repeats the objectives and risk sources in its Annex C. ISO/IEC 42005:2025 covers the impact assessment that clause 6.1.4 requires. Our guide to the standards stack behind the AI Act places each of them. Across the Atlantic, the NIST AI RMF 1.0 is mapped to the standard by a crosswalk. The first version, published in January 2023 against the final draft of the standard, is now marked superseded on the NIST crosswalk page; the revised version, dated 14 August 2025, is maintained by INCITS and hosted by NIST. It maps GOVERN mainly to clauses 5.2 to 5.4 and 5.6, MAP to 5.4.1, 6.3 and 6.4, MEASURE to 6.4.4 and 6.6, and MANAGE to 5.5 to 5.7 and 6.5. Its third note is the interesting one: the standard contains one clause that does not map to the NIST framework at all, 6.2 communication and consultation. The OECD’s November 2023 paper on interoperability in AI risk management compares the leading frameworks and finds that they share four top-level steps: define, assess, treat and govern. It states that ISO/IEC 23894 “supplements ISO 31000 with AI-specific guidance, but operates within the same top-level framework”, that its treatment of impacts on external stakeholders is broader than ISO 31000’s, and that ISO 31000 options such as retaining a risk or increasing it to pursue an opportunity “may sometimes conflict with decreasing risks to people and planet”. It also records that the AI Act, then a proposal, did not seem to include consultation requirements with internal and external stakeholders, and that the Article 17 quality management system came closest to embedding risk management in governance. Article 9 in the adopted text still has no consultation step. European adoption deserves a precise word. EN ISO/IEC 23894:2024 makes the text a national standard in every CEN member country, listed for example by the Estonian standards body as valid from 1 March 2024. A European adoption is not a harmonised standard: only a standard cited in the Official Journal under Article 40 gives presumption of conformity, and according to public trackers no AI Act harmonised standard had been cited by July 2026. The conformity assessment of a high-risk system will therefore rest on the law’s text, not on this standard, for some time yet. Regulators read this family of standards in a way worth noticing. The European Data Protection Supervisor built its guidance for risk management of AI systems of 11 November 2025 on ISO 31000 vocabulary (risk source, event, consequence, control), mapped thirteen risks onto the ISO/IEC 22989 life cycle phases, and explicitly refrained from ranking likelihood and severity, leaving that judgement to each controller. The method is the standard’s; the acceptability decision is yours.
prEN 18228: the harmonised standard that Article 9 will actually use
The standard that will carry the presumption of conformity for Article 9 is not ISO/IEC 23894. It is prEN 18228, “AI Risk Management”, drafted by working group 2 of CEN-CENELEC JTC 21 under the Commission’s standardisation request. CEN-CENELEC’s newsletter of 27 May 2026 states that the draft is intended to support Article 9 and that all high-risk systems placed on the EU market will need to demonstrate conformity with its requirements. The StandICT entry describes the scope: terminology, principles and a risk management process for risks to health, safety and fundamental rights, applied throughout the AI system life cycle; it requires providers to establish objective criteria for risk acceptability but does not set acceptable levels; and it is explicitly not intended for managing the risks faced by the organisation itself, the exact opposite of the ISO 31000 starting point. The timeline is live. A first public enquiry ran until the end of July 2026 (the Dutch national consultation ran from 18 May to 30 June 2026). A revised edition, prEN 18228:2026, was published on 11 September 2026, and its second public enquiry is open until 11 November 2026 through national standards bodies. As a draft it gives no presumption of conformity. The sister document for the Article 17 quality management system, prEN 18286, is out for formal vote after a first vote that did not reach approval. The Commission’s AI Act standardisation page tracks the request. The application dates moved with the Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026: Annex III high-risk obligations apply from 2 December 2027, Annex I product-embedded systems from 2 August 2028, as fixed dates. The Omnibus did not change the text of Article 9. Meanwhile one Article 9-shaped duty is already enforceable: Article 55 requires providers of general-purpose AI models with systemic risk to assess and mitigate those risks, and general-purpose model obligations have applied since 2 August 2025. Three practical consequences follow:
- Build the method on ISO/IEC 23894 now. prEN 18228 inherits the same process shape, and a team that already runs identification, analysis, evaluation, treatment and monitoring per system will have little to redo.
- Write the acceptability criteria and the residual-risk judgement the way Article 9(5) and prEN 18228 phrase them (per hazard, harm to persons, objective criteria), not the way clause 6.3.4 phrases them (organisational risk criteria).
- Date the procedure and plan a revision for the day prEN 18228 is published and cited. A risk appetite statement written for the organisation will not survive that revision; a per-system acceptability rule will.
How to use ISO/IEC 23894 as the method behind an Article 9 file: five steps
- Adopt the standard as the method and Article 9 as the acceptance criteria. Say so in the AI policy, and keep one risk register per AI system, never one for the organisation. The AI risk management guide covers the programme level; Article 9 lives at the system level.
- Run two columns for every risk. One column records the standard’s reading, the effect on objectives; the other records the Act’s reading, harm to persons with its probability and severity. Only the second column decides acceptability. Keeping both avoids the register that confuses an auditor, and it preserves the business view the governance committee still needs.
- Use Annex B as the identification checklist and add what it does not list. Reasonably foreseeable misuse (Article 9(2)), impacts on persons under 18 and vulnerable groups (Article 9(9)), and the risks the other requirements of Articles 10 to 15 leave open, from data governance to human oversight.
- Record, for each hazard, the measure in the Article 9(5) order and the residual-risk judgement. Design first, then control, then information and training, with the reason the earlier option was not feasible. Then record the test that proves the measure works, with the metric and threshold fixed before the test, as Article 9(8) requires. A model drift threshold agreed after the fact is not evidence.
- Link the monitoring and recording clauses to the law’s artefacts. Clause 6.6 monitoring feeds the Article 72 post-market monitoring plan and the incident reporting duty of Article 73; clause 6.7 recording feeds the Annex IV technical documentation. Add a consultation record under clause 6.2 with affected persons, which Article 9 does not require and which authorities increasingly ask about.
An AI governance platform keeps the register, the two risk columns, the measures, the tests and the records in one place per system; AI Sigil does this with the AI Act articles as the acceptance criteria.
FAQ
What is ISO/IEC 23894 in simple terms? It is the ISO guidance on how to run risk management for AI. It takes the generic ISO 31000 process (set the context, identify, analyse, evaluate, treat, monitor, record) and adds what changes when the object is an AI system: new risk sources such as the level of automation or the quality of training data, new objectives such as fairness and explainability, and a mapping of the process onto the AI life cycle. It is a method, written as recommendations, for organisations that build, buy or use AI. Is ISO/IEC 23894 certifiable? No. The text contains recommendations, not requirements, so no certification body can audit an organisation against it and no certificate exists. The certifiable standard in the same family is ISO/IEC 42001, whose clause 6.1.2 requires an AI risk assessment process; the guidance is the natural way to design that process. Course certificates sold by training providers attest that a person attended a course, nothing more. Does ISO/IEC 23894 make a provider compliant with Article 9 of the AI Act? No. Only harmonised standards cited in the Official Journal give presumption of conformity under Article 40, and the candidate for Article 9 is prEN 18228, not this standard. Beyond the legal point, the two documents define risk differently, allow different treatment options and require different records: Article 9 wants a residual-risk judgement per hazard, a priority order of measures and testing against predefined metrics, none of which the standard contains. What is the difference between ISO/IEC 23894 and ISO/IEC 42001? ISO/IEC 42001 is a management system standard: requirements, an audit, a certificate, covering policy, roles, objectives, controls and improvement for AI across an organisation. ISO/IEC 23894 is guidance on one of the things that management system must do, assess and treat AI risk. The management system says a risk assessment is required (clause 6.1.2); the guidance says how to run it. Their lists of AI objectives and risk sources are the same. What is prEN 18228 and when does it apply? prEN 18228 is the draft European standard on AI risk management from CEN-CENELEC JTC 21, written to support Article 9 of the AI Act. Its second public enquiry is open until 11 November 2026. It will only give presumption of conformity once adopted and cited in the Official Journal. The Article 9 obligations it supports apply to Annex III high-risk systems from 2 December 2027 and to Annex I product-embedded systems from 2 August 2028, after the Digital Omnibus on AI. How does ISO/IEC 23894 relate to the NIST AI RMF? A crosswalk, first published by NIST in January 2023 and revised on 14 August 2025 by INCITS, maps the four NIST functions (govern, map, measure, manage) onto the standard’s framework and process clauses. The frameworks cover the same ground with one exception recorded in the crosswalk: the standard’s clause on communication and consultation has no counterpart in the NIST framework. A team can use either as its method; neither replaces the acceptance criteria of a law.
Conclusion
ISO/IEC 23894 is a good method and a bad law. As a method it is hard to beat: a process every risk function already knows, extended with the objectives, risk sources and life cycle that make AI different, and recognised by the NIST crosswalk, the OECD and European regulators. As a compliance scheme it does not exist: it certifies nothing, it presumes nothing, and its definition of risk is not the one Article 9 uses. The working arrangement is simple. Adopt the standard for the process, write the acceptability criteria in the Act’s words, keep the two risk vocabularies in separate columns, test against thresholds fixed in advance, date the procedure, and watch prEN 18228 through its enquiry and into the Official Journal. AI accountability under the AI Act is proven with records, and ISO/IEC 23894 tells you which records to keep.