ISO/IEC 42001, 23894, 42005 and 5338: How the ISO AI Standards Fit Together

What each standard is for

ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system within an organization. It is written for entities that develop, provide or use AI-based products or services. It is the only one of the four that organizations can be certified against, and certification is voluntary. ISO describes it as an integrated approach to managing AI projects, from risk assessment through to treatment of those risks.

ISO/IEC 23894 is titled Guidance on risk management. It describes processes for implementing and integrating AI risk management. It is guidance, not a set of certifiable requirements.

ISO/IEC 42005 is guidance on AI system impact assessment. ISO positions it as complementary to ISO/IEC 42001, ISO/IEC 23894 and ISO/IEC 38507 (AI governance), with a specific focus on societal and human impacts. ISO/IEC 5338 defines processes and associated concepts for describing the life cycle of AI systems based on machine learning and heuristic systems.

Editions matter when you cite them: 42001, 23894 and 5338 are 2023 editions, and 42005 is a 2025 edition. As of November 2026, ISO/IEC AWI 42003, intended as guidance on implementing 42001, is still under development and is not a published implementation guide.

The four documents compared

The differences in kind and scope explain why they cannot substitute for one another.

• ISO/IEC 42001:2023: Kind: management system requirements, certifiable. Level: organization. Answers: what policies, accountabilities and processes does the organization operate around AI?
• ISO/IEC 23894:2023: Kind: guidance. Level: risk management process. Answers: how are AI risks identified, analyzed, treated and integrated into management?
• ISO/IEC 42005:2025: Kind: guidance. Level: individual AI system. Answers: what are the effects of this system on people and society, and how are they documented?
• ISO/IEC 5338:2023: Kind: life cycle processes. Level: AI system. Answers: which processes describe the system from conception through operation and retirement?

How outputs move between the standards

ISO describes 42001 and 42005 as designed to work hand in hand. 42001 establishes the organization-wide system of policies, procedures and accountability. 42005 supplies a methodology for identifying, analyzing and documenting the effects of individual AI systems. The management system is the standing structure, and each impact assessment is a system-specific input to it.

A practical reading of the relationships follows. Treat it as an interpretation to check against the standards' text rather than a clause-level mapping. Risk management under 23894 produces risk analyses and treatment decisions. Impact assessment under 42005 produces documented effects on people and society for a given system. Both should inform what the management system requires of that system: which controls apply, who approves it, and what must be monitored. Lifecycle processes under 5338 are where those decisions land in engineering work, such as requirements, verification, deployment, operation and monitoring.

The overlap is real. Impact findings often become risk entries, and risk treatments often become lifecycle requirements. Because 42005 is described as complementing 23894, scope impact assessment alongside the risk process instead of running it as a standalone exercise. A shared register for risks, impacts and treatment decisions avoids duplicated work and keeps the links visible.

Documented policy versus operational evidence

Most of the work in steps 1 through 4 is design-time: policies, methods, assessments and procedures written down and approved. That documentation is necessary, but an auditor eventually asks a different question. Given what your assessments concluded, what was this system actually allowed to do on a given day, and what did it do?

That question lands on step 5. A risk treatment that says sensitive data must not leave a boundary, or that high-impact actions need human approval, is a statement of intent until something enforces it and keeps a record. The distinction is between a control that is described and a control that operates. Operating controls need records generated at the time of operation, not reconstructed afterward from memory or from general-purpose logs.

The tradeoff is practical. Per-interaction evidence costs effort to design, store and retain. But the standards connect assessment to treatment to operation, and a gap at the operational end undermines the credibility of everything upstream. Decide early which treatments depend on runtime behavior, and name the evidence each should produce. Confirm the exact records expected with your certification body and the standard text.

Where runtime enforcement produces evidence

This section is the author's interpretation, not a statement from the standards. Where a risk treatment or impact mitigation depends on what an AI system does at runtime, policy enforcement in the execution path can both apply the control and generate the record. Trussed enforces policy on individual AI interactions and tool calls across models, agents, tools, MCP servers, AI sites and coding assistants. Each request can be allowed, redacted, blocked, rate limited or escalated for human approval, and the enforcement produces continuous audit-ready evidence of the decision.

That evidence supports the operational controls these standards expect, such as showing that a treatment was enforced at runtime and not only written down. It does not replace the management system, the risk process, impact assessments or lifecycle documentation, and it does not by itself establish certification or compliance. It also does not address model or dataset provenance, lifecycle tracing or transaction-level governance. Those remain design-time and process questions for your program.