How ISO/IEC 42001, 23894, 42005 and 5338 Fit Together

Four standards, four distinct jobs

ISO/IEC 42001:2023 is the only one of the four that specifies requirements for a management system. ISO describes it as the first global standard defining how to establish, implement, maintain and continually improve an AI management system (AIMS). It applies to organizations that provide or use AI-based products or services, and it treats an AIMS as interrelated elements that set policies, objectives and processes for the responsible development, provision or use of AI systems. Certification to 42001 is voluntary and gives independent confirmation that the management system meets the standard.

ISO/IEC 23894:2023 is titled guidance on risk management. It supports the risk side of the management system rather than adding a second certifiable scheme. ISO/IEC 42005:2025 provides guidance on AI system impact assessment, with a focus on societal and human impacts. ISO says it complements 42001, ISO/IEC 38507 on AI governance, and 23894. ISO/IEC 5338:2023 defines processes and associated concepts for describing the life cycle of AI systems based on machine learning and heuristic systems.

As of November 2026, the ISO catalogue lists all four as published. ISO/IEC AWI 42003, which will provide guidance on implementing 42001, is still under development and is not yet a published standard.

Scope and typical artifacts by layer

The scopes below come from the standards' stated purposes. The artifact column is a practical suggestion for avoiding duplicated work, not a list taken from the standards' clauses.

• ISO/IEC 42001: management system: Organization-wide requirements. Typical artifacts: AI policy, objectives, roles and accountability, documented procedures, control records.
• ISO/IEC 23894: risk guidance: Guidance on managing AI risk. Typical artifacts: risk criteria, risk assessments, treatment decisions, residual risk acceptance.
• ISO/IEC 42005: impact assessment: Guidance for one AI system at a time. Typical artifacts: impact assessment records covering human and societal effects.
• ISO/IEC 5338: lifecycle processes: Processes for ML and heuristic AI systems. Typical artifacts: lifecycle process records from design through operation and change.

How outputs from one layer feed the others

ISO describes 42001 and 42005 as designed to work hand in hand. 42001 establishes policies, procedures and accountability across the organization. 42005 offers a method for identifying, analyzing and documenting the effects of an individual AI system. That split is the basis for a useful model: impact assessment sits inside the management system, executed once per system and revisited when the system changes.

A practical flow looks like this. An impact assessment identifies effects on people and society for a specific system. Those findings become inputs to the risk process, where they are evaluated against the organization's risk criteria and either treated or accepted. Treatment decisions then flow in two directions. They shape management-system controls, such as who must approve a use case, what is prohibited, and what oversight applies. They also become requirements on lifecycle processes, such as what must be verified before release and what must be monitored in operation.

The loop closes in operation. What the organization observes in production feeds reassessment of risk and impact, and the management system's continual improvement requirement is the mechanism that carries those changes back into policy and controls. This is a modeling approach that follows the stated scopes of the standards. Teams should confirm the exact clause-level relationships against the standards' text for their own scope.

The layers do not substitute for one another. 42005 addresses societal and human impacts, which differs from the organizational risk process in 23894. Having a risk register does not satisfy an impact assessment, and having lifecycle records does not create a management system.

Which obligations become runtime requirements

Most management-system obligations are organizational: leadership commitment, policy, roles, competence, documentation, internal review. Many lifecycle obligations are design-time or release-time activities. Neither group is enforced by a production control.

A smaller set of obligations describes what a system may or may not do while it is operating. Examples include what data may enter or leave a model, which tools an agent may call, when a person must approve an action, and how much use is permitted. When a risk treatment or impact finding takes this form, it can be written as policy and enforced at runtime rather than left as a procedure people are expected to follow.

The working method is to take each treatment decision and control in scope and classify it as organizational, design-time or runtime. Runtime candidates are those that can be decided from the content and context of a single interaction or tool call. The classification should be made against the primary text of 42001, including its Annex A controls, and the relevant 5338 processes.

There is a tradeoff to keep in view. Runtime enforcement acts on individual interactions. It does not replace impact assessment, risk judgment or lifecycle discipline, and it cannot compensate for a control that was never defined.

Where runtime enforcement and audit-ready evidence fit

Auditors assessing a management system look for evidence that stated controls exist and operate. For runtime controls, a policy document alone shows intent. Evidence of what the policy permitted, redacted or blocked on real traffic shows operation.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Actions are allow, redact, block, rate limit, and escalate for human approval, applied to individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact. That enforcement generates continuous audit-ready evidence, which can support management-system controls and respond to audit requests. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency.

The boundaries matter. Trussed does not deliver ISO/IEC 42001 certification, and no tool does. It does not provide model or dataset provenance, and it does not provide end-to-end tracing of agentic workflows. It addresses the runtime slice of the layered model for regulated enterprises, and the management system, risk process, impact assessments and lifecycle practice remain the organization's own.