Most organisations already have an enterprise risk process, but it was not designed for systems that learn from data, change behaviour after deployment and act through software identities. ISO/IEC 23894:2023, Information technology, Artificial intelligence, Guidance on risk management, adapts the ISO 31000:2018 risk management guidelines to AI rather than replacing them. This guide explains what the standard covers, how its structure mirrors ISO 31000, how it relates to ISO/IEC 42001, ISO/IEC 42005 and the NIST AI RMF, and how to put it into practice. It is for risk managers, security and AI platform teams, and executives deciding how AI risk should sit inside their existing governance. It is based on the publicly available descriptions of the standard; buy the standard itself before building controls on its clause text.
Key takeaways
- It extends ISO 31000, it does not stand alone. ISO/IEC 23894 is intended to be used in connection with ISO 31000:2018, cites its clauses and adds AI-specific guidance on top.
- Same three pillars: principles (clause 4), framework (clause 5) and process (clause 6), mirroring ISO 31000, plus annexes on AI objectives, AI risk sources and a mapping to the AI system life cycle.
- Guidance, not certification. Like ISO 31000 it gives guidelines, not certifiable requirements. Certification for AI management happens under ISO/IEC 42001, which can use 23894 as its risk method.
- It plugs into the NIST AI RMF. NIST publishes a crosswalk mapping 23894 clauses to Govern, Map, Measure and Manage, so one risk process can serve both.
- Agents make risk sources concrete. When AI systems hold credentials and call tools, risk identification must include the non-human identities they use and what those identities can reach.
Scope: who and what is covered
ISO published ISO/IEC 23894:2023 in February 2023 (edition 1, 26 pages), developed by ISO/IEC JTC 1/SC 42, the joint committee for artificial intelligence. According to the ISO summary it gives guidance on how organisations that develop, produce, deploy or use products, systems and services that use AI can manage risk specifically related to AI, how to integrate risk management into AI-related activities and functions, and processes for implementing it. ISO states the guidance can be customised to any organisation and its context.
That scope covers the whole value chain, from model developers to an organisation that only buys an AI-enabled SaaS product. The normative references, as summarised by the OECD AI Policy Navigator, are ISO 31000:2018, ISO/IEC 22989:2022 (AI concepts and terminology) and ISO Guide 73:2009 (risk management vocabulary), which is where its terms come from.
How it relates to ISO 31000
ISO 31000:2018, Risk management, Guidelines, gives principles, a framework and a process that any organisation can use regardless of size, activity or sector. It is not certifiable. ISO lists it as confirmed in 2023 and marked for revision.
ISO/IEC 23894 keeps that architecture. Where it extends ISO 31000:2018 it cites the relevant clause and then adds AI-specific guidance, and its clause structure mirrors and amends ISO 31000 with added sub-clauses to make the link clear. In practice this means you do not build a second risk process for AI: you specialise the one you already run.
| ISO 31000:2018 | ISO/IEC 23894:2023 addition | What changes in practice |
|---|---|---|
| Clause 4: Principles | Notes where AI use needs specific consideration under each principle | Principles such as integration and continual improvement are read against AI behaviour that changes after release |
| Clause 5: Framework | AI-specific aspects of leadership, integration, design, implementation, evaluation and improvement | AI roles, accountability and resources appear in the risk governance structure |
| Clause 6: Process | Specialises communication and consultation, context, assessment, treatment, monitoring and review, recording and reporting for AI | Risk assessments cover AI objectives, AI risk sources and the AI life cycle |
| No equivalent | Annex A: common AI-related objectives; Annex B: AI risk sources; Annex C: example mapping of risk processes to the AI system life cycle | Ready-made starting lists for workshops and risk registers |
Key obligations
ISO/IEC 23894 is a guidance standard, so it contains recommendations rather than "shall" requirements, and there is nothing to certify against. The "obligations" are the practices an organisation commits to when it declares that its AI risk management follows the standard. The clause headings below are taken from NIST's published crosswalk; the content descriptions are ours, based on ISO 31000 and the public summaries, not on the clause text.
| Clause | Heading | What an organisation is expected to do |
|---|---|---|
| 5.2 | Leadership and commitment | Top management owns AI risk, sets policy and provides resources |
| 5.3 | Integration | AI risk management runs inside existing governance, not beside it |
| 5.4 | Design (5.4.1 to 5.4.5) | Understand context, articulate commitment, assign roles, allocate resources, set up communication |
| 5.5 to 5.7 | Implementation, Evaluation, Improvement | Put the framework to work, check it is effective, adapt and continually improve |
| 6.2 | Communication and consultation | Involve stakeholders, including affected users, throughout |
| 6.3 | Scope, context and criteria | Define scope (6.3.2), external and internal context (6.3.3) and risk criteria (6.3.4) for each AI system |
| 6.4 | Risk assessment | Identify (6.4.2, including assets, risk sources, events, controls and consequences), analyse (6.4.3, consequences and likelihood) and evaluate (6.4.4) |
| 6.5 | Risk treatment | Select treatment options (6.5.2) and prepare and implement treatment plans (6.5.3) |
| 6.6 and 6.7 | Monitoring and review; Recording and reporting | Monitor AI systems in operation, keep records, report to decision makers |
Applying the process to AI: what to add
- Context (6.3): record the AI system's purpose, intended and foreseeable misuse, data sources, model supplier, deployment environment and the identities and permissions it runs with.
- Identification (6.4.2): use Annex B risk sources as a prompt list, and add security sources such as prompt injection (OWASP LLM01:2025), data and model poisoning (LLM04:2025), supply chain (LLM03:2025) and excessive agency (LLM06:2025).
- Analysis (6.4.3): rate consequences for the organisation and for affected people; likelihood should reflect exposure, for example whether the model reads untrusted content.
- Treatment (6.5): combine technical controls (scoped credentials, output filtering, human approval) with organisational ones (supplier contracts, training).
- Monitoring (6.6): AI risk changes with model updates, new data and new tools, so review triggers should include every model or prompt version change, not only an annual cycle.
Timeline and current status
| Date | Standard | Relevance |
|---|---|---|
| February 2018 | ISO 31000:2018, edition 2 | Base guidelines; confirmed 2023, marked for revision |
| July 2022 | ISO/IEC 22989:2022 | AI concepts and terminology used by 23894 |
| February 2023 | ISO/IEC 23894:2023, edition 1 | Current, stage 60.60 (published) |
| December 2023 | ISO/IEC 42001:2023 | Certifiable AI management system requirements |
| May 2025 | ISO/IEC 42005:2025 | AI system impact assessment, which ISO says complements 23894 |
At the time of writing, the ISO page shows no amendment or revision of 23894 in progress. Because ISO 31000 itself is marked for revision, a future 23894 update to realign with it is plausible, but we have no date. Check the ISO page before citing an edition in a contract.
Enforcement and penalties
No body enforces ISO/IEC 23894 and there is no certification against it, so there are no penalties. It matters because others rely on it:
- ISO/IEC 42001 audits: an AI management system needs a defined AI risk assessment and treatment process. 23894 is a natural method to show auditors, although ISO does not state that 42001 requires it. See the ISO/IEC 42001 Guide.
- Regulation: laws such as the EU AI Act expect risk management for some AI systems. Following 23894 can produce useful evidence, but it does not by itself show legal compliance. See the EU AI Act Compliance Guide.
- Customers and procurement: buyers increasingly ask how AI risk is managed. Pointing to a documented ISO 31000 and 23894 based process is a familiar answer for risk and audit teams.
Choosing between frameworks
| Need | Best fit | Why |
|---|---|---|
| You run ISO 31000 enterprise risk management | ISO/IEC 23894 | Extends the process you already have with AI content |
| You need a certificate for AI governance | ISO/IEC 42001, with 23894 as the risk method | Only 42001 is a requirements standard |
| You need detailed generative AI actions | NIST AI RMF with NIST AI 600-1 | Named GAI risks and suggested actions by ID |
| You must assess impact on people and society | ISO/IEC 42005 | Focuses on impacts on individuals, groups and society |
| Small organisation buying AI services | A light 23894 process inside existing risk management | Proportionate, no new governance body needed |
Large organisations typically keep one AI risk register built on 23894 and map it to the NIST AI RMF via the crosswalk. Smaller ones can apply clause 6 to their few AI systems and skip framework redesign beyond naming an owner.
Crosswalk to the NIST AI RMF
| NIST AI RMF function | ISO/IEC 23894 clauses (per NIST crosswalk) |
|---|---|
| GOVERN | 5.2, 5.3, 5.4 (all sub-clauses), 5.6, 6.1 |
| MAP | 5.4.1, 6.3.2, 6.3.3, 6.3.4, selected 6.4.2 sub-clauses, 6.4.3, 6.7 |
| MEASURE | 5.7.1, 5.7.2, 6.3.4, 6.4.2.5, 6.4.3.2, 6.4.3.3, 6.4.4, 6.6, 6.7 |
| MANAGE | 5.5, 5.6, 5.7, 6.5.2, 6.5.3, 6.6, 6.7 |
The crosswalk notes that clause 6.2, Communication and consultation, has no AI RMF counterpart. See the NIST AI RMF Guide and the NIST AI 600-1 Generative AI Profile Guide.
What it means for AI agents and non-human identities
The standard predates the spread of tool-using agents, but its process handles them well if identities are treated as assets and risk sources.
- Assets (6.4.2): list the service accounts, API keys, OAuth grants and workload identities each AI system uses, and what data and systems they reach.
- Risk sources: prompt injection (MITRE ATLAS AML.T0051 LLM Prompt Injection) turns into misuse of those credentials; supply chain compromise (AML.T0010 AI Supply Chain Compromise) can leak them. The LLMjacking incidents show stolen cloud credentials and API keys being used to run AI at the victim's expense.
- Controls (6.4.2.5) and treatment (6.5): least privilege, short-lived tokens, per-agent identities rather than shared keys, and human approval for high-impact actions. See the AI Agent Authorisation Guide.
- Monitoring (6.6): log which agent identity made each tool call, and alert on new scopes, unusual volumes or access outside the agent's purpose.
- Ownership: every agent identity needs a human owner who also owns the AI risk entry. See the Identity Governance for AI Agents Guide.
Compliance steps
- Buy and read the standard: obtain ISO/IEC 23894 and ISO 31000; do not build on summaries alone.
- Gap-assess your current risk process: compare your ISO 31000 based (or equivalent) method against clauses 4 to 6 and note where AI content is missing. See the ISO 31000 Risk Management Guide.
- Set AI risk criteria (6.3.4): agree with leadership what level of AI risk is acceptable, including harm to people, not only to the organisation.
- Inventory AI systems: record purpose, life cycle stage, supplier, data and the non-human identities each uses.
- Pilot the process on two systems: one internal assistant and one customer-facing or agentic system. Use Annex B as the workshop prompt list and Annex C to line up activities with the life cycle. Use the AI Risk Assessment Guide for the method.
- Treat and record: agree treatment plans with owners and deadlines; record residual risk acceptance by the right authority.
- Integrate: add AI review gates to change management, procurement and release, and AI scenarios to incident response. If the new gates block delivery, fall back to a lighter review for low-risk systems rather than dropping the gate.
- Review and improve: report metrics to the risk committee, re-assess on every material model or tool change, and map results to 42001 or the NIST AI RMF if required.
Detection and measurement
- Coverage: percentage of inventoried AI systems with a current risk assessment under the 23894 process.
- Timeliness: percentage of model, prompt or tool changes re-assessed before release.
- Treatment progress: percentage of AI risk treatment actions closed by their due date.
- Identity hygiene: percentage of AI agents with a dedicated, owned, least-privilege identity.
- Residual risk: number of AI risks above appetite with documented acceptance.
Framework mapping
| ISO/IEC 23894 area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Framework, leadership, risk criteria | GV.RM Risk Management Strategy | PM-9 Risk Management Strategy |
| Risk assessment (6.4) | ID.RA Risk Assessment | RA-3 Risk Assessment, RA-9 Criticality Analysis |
| Supplier and model sourcing risk | GV.SC Cybersecurity Supply Chain Risk Management | SR-3 Supply Chain Controls and Processes |
| Testing as a control | ID.RA | SA-11 Developer Testing and Evaluation |
| Recording and reporting incidents (6.7) | GV.RM | IR-6 Incident Reporting |
This mapping is ours, not part of ISO/IEC 23894.
Common failure patterns
- Running AI risk as a separate silo: a parallel AI register nobody in enterprise risk reads, the opposite of the integration the standard is built on.
- Claiming certification: 23894 cannot be certified; claims of "23894 certified" mislead customers.
- Building from summaries: writing controls from blog posts instead of the purchased text.
- Annual-only reviews: AI systems change with every model update; a yearly assessment misses most of the risk.
- Leaving identities out of context and assets: the assessment covers bias and accuracy but not the keys the system holds, as LLMjacking victims found.
- Ignoring affected people: only rating impact on the organisation; pair 23894 with an impact assessment. See the AI Impact Assessment Template.
Practitioner checklist
- Obtain ISO/IEC 23894:2023 and ISO 31000:2018 and confirm current editions on iso.org.
- Extend your existing risk process with AI content rather than creating a new one.
- Define AI-specific risk criteria approved by leadership.
- Inventory AI systems with life cycle stage, supplier, data and the non-human identities they use.
- Use Annex B risk sources plus the OWASP LLM Top 10 as identification prompts.
- Trigger re-assessment on every material model, prompt or tool change.
- Give every agent its own owned, least-privilege identity and log its actions.
- Map results to ISO/IEC 42001 and the NIST AI RMF crosswalk where needed.
- Never describe the organisation as certified to 23894.
Standards and references
- ISO: ISO/IEC 23894:2023 Information technology, Artificial intelligence, Guidance on risk management
- ISO: ISO 31000:2018 Risk management, Guidelines
- ISO: ISO/IEC 42001:2023 Artificial intelligence, Management system
- ISO: ISO/IEC 42005:2025 AI system impact assessment
- ISO: ISO/IEC 22989:2022 Artificial intelligence concepts and terminology
- NIST: ISO/IEC 23894 Crosswalk to the NIST AI RMF
- OECD.AI: Policy Navigator entry for ISO/IEC 23894
- OWASP: Top 10 for LLM Applications 2025
Related NHI Mgmt Group resources: AI Risk Assessment Guide · NIST AI RMF Guide · LLM Security Guide · ISO/IEC 42001 Guide · ISO 31000 Risk Management Guide. This guide summarises ISO/IEC 23894 and is not legal advice.