ISO/IEC 5338 vs ISO/IEC 42001 vs ISO/IEC 23894: How They Differ and Fit Together

Why these standards get confused

Regulated enterprises often adopt the three standards together and then struggle to say which one governs which activity. The titles are similar, all three come from the same ISO/IEC committee on artificial intelligence, and all three were published as 2023 editions. The result is predictable: overlapping processes in one area, gaps in another, and no clear owner for lifecycle work, management requirements or risk assessment practice.

The simplest way to separate them is to read the document type in each title. ISO/IEC 5338 is titled as AI system life cycle processes. ISO/IEC 42001 is titled as a management system. ISO/IEC 23894 is titled as guidance on risk management. Those three descriptions answer different questions, so they sit at different levels of the organization and belong to different owners.

Side-by-side comparison

The table compares the three standards by what each one is and what it contributes to an AI program. It describes the document type shown in each official title and the practical role that follows from it.

• ISO/IEC 5338: AI system life cycle processes: Document type: process standard. Question answered: what processes apply to an AI system from conception through operation and retirement. Typical owner: engineering and product teams. Contribution: a shared vocabulary of lifecycle activities.
• ISO/IEC 42001: Management system: Document type: management system standard. Question answered: how the organization establishes, runs and improves its AI governance, including policy, roles and controls. Typical owner: AI governance or compliance leadership. Contribution: the organizational framework that other work plugs into.
• ISO/IEC 23894: Guidance on risk management: Document type: guidance. Question answered: how to identify, assess, treat and monitor AI risk. Typical owner: risk management. Contribution: a risk process whose outputs feed both lifecycle decisions and management system controls.

How the three fit together

A practical reading is that each standard supplies something the others lean on. The management system sets the organizational frame: who is accountable, which policies apply, how performance is reviewed. The risk guidance supplies the method for deciding what could go wrong and what to do about it. The lifecycle processes describe where in the life of a system those decisions are applied, such as design, verification, deployment, operation and monitoring.

This means the standards do not compete for the same job. A risk assessment performed without lifecycle context tends to float free of the systems it concerns. Lifecycle processes without a management system can be applied unevenly across teams. A management system without a risk process has policies but no consistent basis for choosing controls. Overlap appears when teams define the same activity, such as post-deployment monitoring, in three places with three owners. The fix is to assign each activity one defining document and have the others reference it.

This page describes the relationship from the standards' titles and document types. Before mapping clauses or controls, check the current texts, because the exact cross-references and normative status are set there.

Which to adopt first

This is editorial judgment, not a requirement of any standard. Start from the question your organization must answer externally. If customers, auditors or regulators will ask how AI is governed across the organization, the management system standard is the natural anchor, because it defines the program everything else supports. If your immediate problem is inconsistent engineering practice, the lifecycle processes give teams a common process baseline. If you lack a repeatable way to assess AI risk, the risk guidance is the quickest gap to close, and it improves whichever other standard you adopt.

Most regulated enterprises end up using all three in combination, with the management system as the container, the risk process feeding it, and lifecycle processes embedded in delivery. Be careful with implementation guidance. ISO/IEC 42003, intended to guide implementation of ISO/IEC 42001, is still under development and is not yet published, so do not plan around it.

On regulation, the EU AI Act is Regulation (EU) 2024/1689. As of November 2026, the Commission's Digital Omnibus on AI proposal of 19 November 2025 would set 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk systems embedded in products. These dates are proposed, not confirmed, so treat the timeline as subject to change. Do not assume that adopting any of the three standards satisfies the Act's obligations.

Where runtime operation creates evidence obligations

Whichever standard you adopt, the operation and monitoring stage is where documentation stops being enough. A reviewer assessing a production AI system will want to know what the system was permitted to do, what it did, and how the organization knew. Policy documents and risk registers describe intent. They do not show what happened on a given interaction or tool call.

That gap is where runtime enforcement applies. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each individual interaction or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval, and that enforcement is applied at runtime, not reviewed after the fact. The enforcement generates continuous, audit-ready evidence, which is mapped to frameworks including the EU AI Act and NIST. This is relevant to the operational controls a management system and a risk treatment plan call for.

The scope is specific. Trussed addresses policy enforcement and evidence at the level of interactions and tool calls. It is not a certification, and it does not provide model lineage, dataset provenance or end-to-end tracing of agentic workflows. Those belong to other parts of your lifecycle and risk program.