ISO/IEC 23894: A Plain-English Guide to the AI Risk Management Standard

ISO/IEC 23894:2023 is the international standard that tells organizations how to manage the risks that come with artificial intelligence. Its full title is Information technology - Artificial intelligence - Guidance on risk management, and it was published in early 2023 by ISO under ISO/IEC 23894:2023, developed by ISO/IEC JTC 1/SC 42, the joint committee responsible for AI standards. Start with the one thing most people get wrong. ISO/IEC 23894 is guidance, not a certifiable management system. You align with it and you audit against it; you don't get certified to it. The certifiable AI management system is ISO/IEC 42001, and it can use 23894 as its risk engine.

Think of ISO/IEC 23894 as the ISO counterpart to the NIST AI Risk Management Framework (AI RMF). Both are voluntary, both are lifecycle-based, both are risk-focused, and both build on established risk-management thinking. This guide walks through what the standard covers, who it is for, how it is structured across six clauses and three annexes, the AI-specific risks it addresses, whether it is certifiable, how it compares to the NIST AI RMF, ISO/IEC 42001, and the EU AI Act, and how to actually operationalize its oversight and control requirements for autonomous, agentic AI.

What is ISO/IEC 23894?

ISO/IEC 23894 is the international standard that provides guidance on managing risk related to artificial intelligence. Published as ISO/IEC 23894:2023 under the official title Information technology - Artificial intelligence - Guidance on risk management, it is the first dedicated international AI risk management standard. It sets out how an organization should identify, analyze, evaluate, treat, and monitor AI-specific risk throughout the AI lifecycle.

The standard is developed and maintained by ISO/IEC JTC 1/SC 42, the joint ISO and IEC subcommittee responsible for artificial intelligence standardization (the same committee behind ISO/IEC 42001). It was published in February 2023, which makes it the ISO-world companion to NIST's AI RMF 1.0, released in the United States a month earlier in January 2023. Together they marked the moment AI risk management moved from ad hoc practice to codified, internationally recognized guidance.

In plain terms, ISO/IEC 23894 is iso 23894 risk management guidance: a repeatable process for treating AI risk with the same rigor you already apply to security, financial, or operational risk. It does not prescribe specific controls or tools. Instead, it tells you how to run AI risk management as a disciplined, documented, ongoing activity.

Who ISO/IEC 23894 is for (scope)

ISO/IEC 23894 is deliberately sector-agnostic. It applies to any organization that develops, provides, deploys, or uses AI systems, regardless of industry, size, or whether AI is built in-house or procured from a vendor. A bank deploying a credit-scoring model, a health provider using diagnostic AI, a SaaS company shipping an AI feature, and an enterprise rolling out agentic AI assistants are all in scope.

If you own governance, that breadth is the whole point. When you lead AI governance, GRC, security, or compliance, ISO/IEC 23894 gives you a common process and vocabulary to apply consistently across every AI use case in your organization, instead of reinventing a risk approach per team or per model. For architects and product or engineering leaders, it defines the risk activities that need to be built into the AI lifecycle rather than bolted on afterward.

How ISO/IEC 23894 is structured (clauses and three annexes)

The iso 23894 structure follows the familiar ISO management-guidance shape: a set of main clauses that describe the risk-management framework and process, followed by informative annexes that adapt that process specifically to AI. The iso 23894 annexes are where the AI-specific value lives, so it is worth enumerating all three precisely.

Part of the standard	What it contains
ISO 31000 basis	The principles, framework, and process from ISO 31000:2018, adapted to AI. This is the risk-management backbone the whole standard rests on.
Main clauses (six)	Scope, normative references, terms and definitions, and the core guidance on the risk-management framework and the risk-management process applied to AI.
Annex A - risk-management objectives	Illustrative objectives an organization may pursue when managing AI risk (for example, safety, security, fairness, transparency, accountability).
Annex B - AI-specific risk sources	A catalog of the sources of risk that are particular to AI systems, used as input to risk identification.
Annex C - process-to-AI-lifecycle mapping	Maps the risk-management process onto the stages of the AI system lifecycle, showing where each risk activity applies.

Built on ISO 31000

ISO/IEC 23894 does not invent a new risk methodology. It adopts the principles, framework, and process triad from ISO 31000:2018, the general international guideline for risk management, and adapts it to the realities of AI. That is the essence of iso 31000 vs iso 23894. ISO 31000 is the parent, general-purpose risk-management guidance for any kind of risk. ISO/IEC 23894 is the AI-specialized child that keeps the same structure but adds AI-specific risk sources and a lifecycle mapping. If your enterprise-risk team already works to ISO 31000, adopting 23894 extends a model they know rather than replacing it.

The six main clauses

The main body of the standard covers scope, normative references, and terms and definitions. It then sets out guidance on the risk-management framework (how risk management is governed, resourced, and integrated into the organization) and the risk-management process (the operational steps of identifying, analyzing, evaluating, and treating risk). The intent is clear: AI risk management is not a separate silo but part of how the organization already governs risk.

Annex A: risk-management objectives

Annex A offers a set of illustrative objectives you might set when you manage AI risk, such as safety, security, privacy, fairness, transparency, and accountability. It helps teams frame why they are managing a given risk and what a good outcome looks like, rather than treating risk work as a compliance checkbox.

Annex B: AI-specific risk sources

Annex B is the catalog of risk sources unique to AI. It is the input to risk identification, and it is the reason a generic ISO 31000 process is not enough on its own. We break the risk sources out in detail in the risk-sources section below.

Annex C: mapping the process to the AI lifecycle

Annex C is arguably the most practical part of the standard. It maps the risk-management process onto the AI system lifecycle so that risk activities land at the right stage, from inception and design through data collection, model building, verification, deployment, operation, and eventual retirement. This is what turns risk management from a one-time review into a continuous activity that follows the system.

How the ISO/IEC 23894 risk-management process works

Because it inherits the ISO 31000 process, the iso 23894 risk management guidance follows a recognizable cycle. The difference is that each step is applied to AI systems and repeated across the lifecycle rather than run once at launch.

• Communication and consultation - engage stakeholders (data science, security, legal, affected users) throughout, so risk decisions reflect real context.
• Scope, context, and criteria - define what AI system is in scope, the environment it operates in, and how risk will be measured and accepted.
• Risk identification - find where AI risk arises, using Annex B risk sources as a prompt.
• Risk analysis - understand each risk's likelihood, consequences, and drivers.
• Risk evaluation - compare analyzed risk against your criteria to decide what needs treatment.
• Risk treatment - select and implement controls to modify the risk (mitigate, transfer, avoid, or accept).
• Monitoring and review - track risk continuously, because AI systems and their data drift over time.
• Recording and reporting - document decisions and evidence, which is what makes alignment demonstrable.

The following table shows how the process maps onto the AI lifecycle, mirroring the intent of Annex C. This is the difference between a static risk register and a living program.

AI lifecycle stage	Primary risk-management activity
Inception and design	Establish scope, context, and criteria; identify foreseeable risks and intended use and misuse.
Data collection and preparation	Identify and analyze data-quality, bias, and privacy risks; set data controls as treatment.
Model building and training	Analyze model-limitation, robustness, and security risks; evaluate against acceptance criteria.
Verification and validation	Test for performance, fairness, explainability, and adversarial resilience before release.
Deployment and operation	Implement human-oversight, access-control, and monitoring treatments; watch for drift and misuse.
Retirement	Manage decommissioning risk, including data handling and downstream dependencies.

What AI risks ISO/IEC 23894 covers (risk sources)

Annex B is where ISO/IEC 23894 earns its place as a dedicated AI standard rather than a copy of general risk guidance. It enumerates categories of risk that are specific to, or amplified by, AI systems. Most explainers list these generically. The value is in tying each one to what it means in practice.

• Data quality and bias - training data that is incomplete, unrepresentative, or skewed, producing unreliable or discriminatory outputs.
• Model limitations and failures - models that are brittle, overfit, drift over time, or fail silently outside their training distribution.
• Security and adversarial attacks - threats such as data poisoning, model extraction, evasion, and prompt injection against AI systems.
• Privacy - exposure or inference of personal data through training data, model memorization, or outputs.
• Safety and malfunction - physical or operational harm when an AI system behaves unexpectedly in the real world.
• Fairness and discrimination - outcomes that disadvantage individuals or groups, whether from data, design, or deployment context.
• Transparency and explainability - systems whose decisions cannot be understood, contested, or audited.
• Human oversight and control - insufficient ability for people to monitor, intervene in, or override AI behavior.
• Environmental, societal, and ethical impacts - broader effects such as energy use and downstream social consequences.

For enterprises, several of these overlap with the risk of unsanctioned or ungoverned AI adoption inside the organization. That is the shadow AI problem, and it is worth reading alongside the risk-source categories here.

Is ISO/IEC 23894 certifiable? (the biggest misconception)

No. ISO/IEC 23894 is not certifiable. This is the single most common mistake in the market, and getting it right is the whole point of understanding the standard. You cannot "get certified to ISO 23894," and any offer of iso 23894 certification misunderstands what the document is. ISO/IEC 23894 is guidance. You can align your program with it and you can audit yourself against it, but there is no accredited certification scheme for it.

The confusion comes from conflating two different documents, which is exactly the iso 23894 vs iso 42001 question. ISO/IEC 42001:2023 is the certifiable AI management system (AIMS) standard, written with the "shall" requirements and the auditable structure a certification body needs. Here is the clean way to think about it. ISO/IEC 42001 is the certifiable management system, and ISO/IEC 23894 is the risk engine it can run on. If your organization pursues ISO/IEC 42001 certification, using ISO/IEC 23894 to structure the risk-management part of that system is a natural fit.

Guidance tells you how to run a process. A certifiable management system defines auditable requirements an accredited body can assess you against. ISO/IEC 23894 is the former. ISO/IEC 42001 is the latter.

ISO/IEC 23894 vs the NIST AI RMF, ISO 42001, and the EU AI Act

Want the fastest way to place ISO/IEC 23894 correctly? Compare it to the other frameworks it is regularly confused with. The table below is the cleanest four-way comparison of the major AI risk-management references, and the subsections that follow explain each relationship.

Dimension	ISO/IEC 23894	NIST AI RMF	ISO/IEC 42001	EU AI Act (Article 9)
Nature	Guidance on AI risk management	Voluntary risk-management framework	Certifiable AI management system (AIMS)	Binding legal requirement
Voluntary or legal	Voluntary	Voluntary	Voluntary (but certifiable)	Legally required for high-risk AI in the EU
Certifiable?	No	No	Yes (accredited certification)	Not a certification; a conformity obligation
Structure	ISO 31000 process adapted to AI; 6 clauses + 3 annexes	Four core functions: Govern, Map, Measure, Manage	Management-system clauses (like ISO 27001) with Annex A controls	Article requiring a documented, continuous risk-management system
When to use it	To run a disciplined AI risk process; as the risk engine inside a 42001 program	To assess and govern AI risk, especially in a US context	When you need certifiable proof of AI governance	When you place high-risk AI on the EU market

ISO/IEC 23894 vs NIST AI RMF

ISO/IEC 23894 and the NIST AI Risk Management Framework are close cousins. Both are voluntary, both operate across the AI lifecycle, both are risk-based, and neither is certifiable. The difference is mostly one of origin and shape. 23894 is the ISO international standard built on the ISO 31000 process, while the NIST AI RMF organizes the same work into four core functions, Govern, Map, Measure, and Manage. That framework was published as NIST AI 100-1 (AI RMF 1.0) in January 2023. This is the heart of the iso 23894 vs nist ai rmf question: they are two vocabularies for the same discipline, and an organization aligned to one is most of the way to the other. Many multinational teams map their controls to both, so they can speak to European and US stakeholders with one program.

ISO/IEC 23894 vs ISO/IEC 42001

As covered above, this is the guidance-versus-certifiable distinction. ISO/IEC 23894 tells you how to run AI risk management. ISO/IEC 42001 is the certifiable management system that surrounds and governs that work. They are complementary, not alternatives. If you already run ISO/IEC 42001, ISO/IEC 23894 gives you a ready-made way to fulfil its risk-management expectations.

ISO/IEC 23894 and the EU AI Act (Article 9)

The EU AI Act sits in a different category: it is law, not voluntary guidance. Article 9 requires providers of high-risk AI systems to establish, document, and maintain a continuous risk-management system across the system's lifecycle. The Act says that you must manage risk; it does not hand you a detailed method. ISO/IEC 23894 (and a certifiable ISO/IEC 42001 program) is one credible way to supply the how that regulators expect. In practice, aligning to 23894 is a defensible route toward demonstrating the kind of disciplined, lifecycle risk management Article 9 demands.

Operationalizing ISO/IEC 23894 for agentic AI

Here is the gap no standard closes on its own. ISO/IEC 23894 repeatedly calls for human oversight, control, and accountability, but by design it stays silent on mechanism. It tells you the outcome to achieve and leaves the enforcement to you. For traditional models, that gap is manageable. For autonomous, agentic AI, which can take actions, call tools, and chain steps without a human in the loop, the standard's oversight and accountability guidance only becomes real when concrete access controls enforce it.

For agentic AI, the standard's human-oversight, control, and accountability requirements collapse into four operational primitives. Frontegg, as the authority on authentication and authorization, frames these as the building blocks of agentic AI governance:

• Agent identity - every AI agent is a first-class, authenticated identity (a non-human identity), not an anonymous process sharing a human's credentials. Frontegg treats agent identity as a distinct identity-management problem with its own credentials and lifecycle.
• Scoped authorization - each agent is granted only the specific, least-privilege permissions its task requires, so a compromised or misbehaving agent cannot reach beyond its scope. Frontegg positions granular, scoped authorization as core to governing agents.
• Human-in-the-loop for high-impact actions - high-risk actions require a human to approve before the agent proceeds, turning "human oversight" from a policy statement into an enforced control.
• Tamper-proof audit trails - every agent action is logged in an accountable, reviewable record, which is what makes the standard's accountability and recording expectations demonstrable.

This is also where the enterprise data-risk angle meets the standard. Agents that reach across tools and data sources are a leading vector for AI-driven data loss, so scoped authorization and audit trails are as much a data-protection control as a governance one. For the connector-level version of that risk, see our coverage of data exfiltration through AI connectors. And because ungoverned agent adoption is itself a form of shadow AI, treating agent identity and access as a first-class control is how you keep autonomous AI inside the risk program rather than outside it.

If your organization is moving from governing static models to governing autonomous agents, this is where a standard-defined "what" needs an operational "how." agen.co, built on Frontegg's identity and access platform, provides that enforcement layer: agent identity, scoped authorization, human-in-the-loop approvals, and audit trails that make ISO/IEC 23894's oversight and accountability guidance enforceable in production.

How to implement and align with ISO/IEC 23894 (checklist)

Because ISO/IEC 23894 is guidance rather than a checklist of controls, "implementation" means building a repeatable, documented AI risk-management program and generating evidence that it runs. Use the steps below as a practical alignment path.

• Inventory your AI systems - catalog every model, AI feature, and autonomous agent in development, in production, and procured from vendors.
• Establish scope, context, and criteria - define risk acceptance criteria and integrate AI risk into your existing enterprise risk framework (ideally the ISO 31000 one you already run).
• Run documented risk assessments per lifecycle stage - use Annex B risk sources to identify risk and Annex C to place each activity at the right lifecycle stage.
• Implement and track treatments - select controls, assign owners, and monitor continuously for drift, misuse, and new risk.
• Produce alignment evidence - keep records of assessments, decisions, and treatments; this is what demonstrates alignment and supports an ISO/IEC 42001 program or an EU AI Act Article 9 obligation.
• Enforce oversight for agents - layer agent identity, scoped authorization, human-in-the-loop approvals, and audit trails so the standard's control requirements are enforced, not just documented.

ISO/IEC 23894 is one standard-specific piece of a broader discipline. For the wider view of how AI risk is governed end to end, including the generic framework, assessment, and mitigation practices this standard slots into, read our guide to AI risk management as a whole. Use 23894 as the ISO-anchored method within that broader program.

Frequently asked questions

What is ISO/IEC 23894?

ISO/IEC 23894:2023 is the international standard that provides guidance on managing risk in AI systems. Its official title is Information technology - Artificial intelligence - Guidance on risk management, it was published in 2023 by ISO/IEC JTC 1/SC 42, and it is built on the ISO 31000 risk-management process adapted to the AI lifecycle.

Is ISO/IEC 23894 certifiable?

No. ISO/IEC 23894 is guidance, not a certifiable management system, so there is no accredited certification scheme for it. You can align with it and audit against it, but you cannot be certified to it. The certifiable AI standard is ISO/IEC 42001.

What is the difference between ISO/IEC 23894 and ISO/IEC 42001?

ISO/IEC 23894 is guidance on how to run AI risk management. ISO/IEC 42001 is a certifiable AI management system (AIMS) with auditable requirements. They are complementary: a 42001 program can use 23894 as its risk-management engine.

How does ISO/IEC 23894 compare to the NIST AI RMF?

They are counterparts. Both are voluntary, lifecycle-based, risk-focused, and non-certifiable. ISO/IEC 23894 is the ISO standard built on ISO 31000, while the NIST AI RMF organizes the same work into four functions: Govern, Map, Measure, and Manage. An organization aligned to one is well positioned for the other.

What are the annexes of ISO/IEC 23894?

There are three. Annex A lists risk-management objectives, Annex B catalogs AI-specific risk sources, and Annex C maps the risk-management process onto the stages of the AI lifecycle.

How does ISO/IEC 23894 relate to ISO 31000?

ISO/IEC 23894 is built directly on ISO 31000:2018. It adopts ISO 31000's principles, framework, and process and adapts them to AI, adding AI-specific risk sources and a lifecycle mapping. ISO 31000 is the general parent standard; 23894 is the AI-specialized application of it.

How does ISO/IEC 23894 relate to the EU AI Act?

The EU AI Act's Article 9 legally requires providers of high-risk AI to run a documented, continuous risk-management system across the lifecycle. The Act mandates that you manage risk but does not prescribe the method. ISO/IEC 23894 is a credible way to supply that method and help demonstrate the discipline regulators expect.

Where can I get ISO/IEC 23894?

The standard is published by ISO and can be purchased through official ISO channels. Buy it from the ISO website or an authorized national standards body rather than an unofficial PDF copy, so you receive the current, licensed version.

Operationalize your AI risk program

ISO/IEC 23894 gives you the international, ISO-anchored method for AI risk management, the counterpart to the NIST AI RMF, and the risk engine that can sit inside an ISO/IEC 42001 program or help satisfy the EU AI Act. What it cannot do is enforce its own oversight and accountability requirements once your AI starts acting autonomously. That last mile is an identity and access problem.

agen.co, built on Frontegg, supplies the enforcement layer the standard leaves open: agent identity, scoped authorization, human-in-the-loop approvals for high-impact actions, and tamper-proof audit trails. It is how you turn 23894's "what" into an operational "how" for agentic AI. See how agen.co operationalizes AI oversight and control for autonomous agents.