Combining ISO/IEC 42001, 23894, 5338 and 42005 into One AI Governance Program

What each standard is for

The four standards are easy to conflate because they all touch AI risk. Their scopes differ, and the program design depends on keeping them apart.

ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS). It applies to organizations that provide or use AI-based products or services, and it follows the Plan-Do-Check-Act method. It is the only one of the four that sets requirements an organization can be assessed against. The other three are guidance or process standards.

ISO/IEC 23894:2023 is guidance on AI risk management. It describes processes for implementing and integrating AI risk management, including alongside wider enterprise risk practice.

ISO/IEC 5338:2023 defines processes and concepts for the life cycle of AI systems based on machine learning and heuristic systems. It gives you the per-system stages that work moves through.

ISO/IEC 42005:2025 provides guidance for identifying, evaluating and managing potential societal and human impacts across the AI system lifecycle. ISO describes 42001 and 42005 as designed to work together: 42001 sets organization-wide policies, procedures and accountability, and 42005 supplies a method for identifying, analyzing and documenting the effects of individual systems inside that framework.

As of November 2026, all four are listed as published in the ISO/IEC JTC 1/SC 42 catalogue. Guidance on implementing 42001 (ISO/IEC 42003) is still a work item under development, so a program plan should not wait for it.

Where the standards overlap and how to remove duplication

The overlap is mainly in outputs. A 23894 risk assessment and a 42005 impact assessment both identify what could go wrong and for whom, and both lead to treatment decisions. Run separately, they produce two registers with different vocabulary, different owners and conflicting ratings for the same system.

Use one assessment record structure with a single risk register. Each entry should state the system, lifecycle stage, the risk or impact, who is affected, the rating against shared criteria, the selected treatment, the control that implements it and the owner. Impact findings from 42005 become entries in the same register, flagged by type. Community crosswalks to the NIST AI RMF can help reconcile terminology across 23894, 42005 and 5338, but they are community-submitted and should not be treated as authoritative ISO mappings.

Ownership needs the same split as the structure. Organization-level owners hold policy, risk criteria and the control set. System-level owners hold the lifecycle record, the assessments and the operational evidence for their system. Connect AI risk records to the existing enterprise risk governance rather than building a separate AI risk function that reports nowhere.

A phased implementation sequence

ISO positions 42001 as the foundation, so the sequence starts there. The phases below follow the Plan-Do-Check-Act cycle, and the boundaries are yours to adjust.

• 1. Scope and accountability (Plan): Inventory AI systems, define AIMS scope, assign organization-level and system-level owners, and approve the AI policy and objectives.
• 2. Shared assessment method (Plan): Set risk criteria, the common register and one record template covering 23894 risk and 42005 impact assessment.
• 3. Lifecycle mapping (Plan): Map 5338 stages to your existing development and operations processes. Define the gates where assessments are required and the records each stage produces.
• 4. Control selection (Do): Assess a pilot set of systems, select treatments, and build one control set. Mark each control as procedural, technical, or enforced at runtime.
• 5. Operate and collect evidence (Do): Run systems under the controls and retain the records each control produces.
• 6. Review and improve (Check, Act): Review evidence against policy, reassess when systems or uses change, and feed findings back into criteria and controls.

Where documented requirements depend on runtime enforcement

A policy approved at the organization level and a risk treatment recorded at design time are intentions. Whether an AI system conforms to them depends on what happens during operation. This is the usual gap between documented policy and system behavior.

For each control in the shared set, ask whether it can be satisfied by a decision made once, such as an approval, a documented assessment or a defined role, or whether it must hold on every interaction. Controls in the second group need enforcement in the execution path. Typical examples are limits on what data may reach a model, restrictions on which tools an agent may call, limits on request volume, and human approval before a consequential action. A review process cannot guarantee any of these after the fact.

Evidence follows the same split. Procedural controls produce documents: approved policies, assessment records, lifecycle gate sign-offs. Runtime controls produce a record of each decision: what was requested, which policy applied, and whether it was allowed, redacted, blocked or escalated. An auditor assessing the AIMS will want both, linked to the same risk register entry so the chain from risk to control to operational record can be followed.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval. Enforcement operates on individual interactions and tool calls and generates audit-ready evidence. It addresses the runtime portion of a control set. It does not replace the management system, the assessments or the lifecycle process, and it does not itself confer certification.