ISO/IEC 42001 Publication Date and the ISO AI Standards Timeline

Publication timeline and current status

Cite each standard by edition, not by number alone. The edition year is the most reliable anchor when documentation, audit scoping or vendor questionnaires reference these documents. The status information below is as of November 2026 and should be checked against ISO's catalogue before you publish dates in your own materials.

ISO/IEC 42001:2023 is listed in the SC 42 catalogue at stage 60.60, meaning it is published. ISO/IEC 42005:2025 shows the same stage, with a publication date of May 2025. ISO/IEC 23894:2023 is the 2023 edition of the AI risk management guidance. No amendment or corrigendum to any of these three appears in the catalogue information reviewed.

• 2023: ISO/IEC 23894:2023: AI guidance on risk management. It describes processes for the effective implementation and integration of AI risk management.
• 2023: ISO/IEC 42001:2023: AI management system standard. ISO's page carries the date 18 December 2023.
• May 2025: ISO/IEC 42005:2025: Guidance on AI impact assessment, focused on the societal and human impacts of AI.
• In development: ISO/IEC 42003: Guidance on the implementation of ISO/IEC 42001, listed at stage 20.00 (approved work item).

Certifiable requirements versus guidance

The most common misattribution is treating all of these documents as auditable against a single checklist. They are not. ISO/IEC 42001 is a management system standard that specifies requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS). Because it states requirements, an organization can choose certification when it wants independent confirmation that its AIMS meets them. ISO states that certification is optional.

ISO/IEC 23894 and ISO/IEC 42005 are guidance. They inform how an organization carries out risk management and impact assessment, but they are not described as certifiable. A statement such as "certified to ISO/IEC 23894" or "certified to ISO/IEC 42005" has no basis in how ISO describes these documents. If your organization does pursue certification, the scope is the management system defined in 42001.

Scope of applicability is broad. ISO states that 42001 applies to organizations of all sizes and sectors that develop, provide or use AI systems. For a regulated enterprise, that means the standard can apply whether you build models, supply AI-enabled products or consume third-party AI.

How the standards relate

ISO defines an AI management system as the interrelated elements of an organization that establish policies, objectives and processes for the responsible development, provision or use of AI systems. ISO also describes 42001 as an integrated approach to managing AI projects, from risk assessment to the treatment of those risks. It is the organizational frame.

ISO/IEC 23894 supplies guidance for the risk management activity inside that frame. ISO/IEC 42005 supplies a framework for identifying, evaluating and documenting the impacts of AI systems, with a focus on societal and human impacts. ISO says 42005 complements 42001, ISO/IEC 38507 (AI governance) and ISO/IEC 23894. ISO also describes 42001 and 42005 as designed to work hand in hand: 42001 establishes the organization-wide system, and 42005 provides the impact assessment method.

One boundary is worth stating explicitly. 42001 addresses organizational management of AI. Security threats specific to AI systems are the focus of a separate standard, ISO/IEC 27090, which ISO describes as under publication. Do not expect 42001 to serve as a threat catalogue.

Deciding an implementation sequence

ISO does not publish a prescribed order for adopting these documents, and the implementation guidance for 42001 (ISO/IEC 42003) is not yet published. The sequence below is editorial judgment based on how the standards relate, not a requirement from ISO. Adjust it to your existing management systems and regulatory obligations.

• 1. Decide the goal: Choose between certification against 42001 and alignment only. This sets the evidence burden and the audit calendar.
• 2. Scope the management system: Define which AI systems, roles and business units fall inside the AIMS, and record the edition of each standard you reference.
• 3. Establish policies, objectives and ownership: These organizational elements are what 42001 requires, and they give the guidance documents a place to land.
• 4. Adopt risk management guidance: Use 23894 to structure how AI risks are identified, assessed and treated within the system.
• 5. Add impact assessment: Use 42005 to document impacts of individual AI systems and feed the results into risk treatment decisions.

Where runtime enforcement and audit-ready evidence can help

The standards do not map any clause to runtime technology, so what follows is the author's analysis and not a cited requirement. Because ISO defines the AI management system as policies, objectives and processes across an organization, a technical layer can support individual controls but cannot constitute the management system. Leadership commitment, role assignment, impact assessment judgment, internal audit and management review remain organizational work.

Where an organization has decided that certain AI interactions or tool calls must follow defined rules, enforcement in the execution path can apply those rules at runtime rather than reviewing them after the fact. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions that include allow, redact, block, rate limit and escalate for human approval. Its scope is individual interactions and tool calls. Enforcement generates audit-ready evidence of what the AI was allowed to do and what it did, which can supplement the records an AIMS needs. That evidence is currently mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST.

This does not satisfy a 42001 clause on its own, and it does not produce certification. It also does not cover model provenance, lineage or end-to-end tracing of agentic workflows. A useful test for any vendor claim is whether the mapping is cited from the standard or is the vendor's interpretation, and whether the evidence covers organizational processes as well as system-level technical records.