ISO/IEC 42001 vs ISO/IEC 5338: Does Certification Cover AI Lifecycle Processes?

What a 42001 certificate shows

ISO describes ISO/IEC 42001 as a management system standard. It specifies requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System (AIMS). An AIMS is a set of interrelated elements of an organization, intended to establish policies, objectives and the processes to achieve them for the responsible development, provision or use of AI systems.

ISO states that certification is voluntary and performed by independent certification bodies. Organizations may choose it for independent confirmation that their AIMS meets the requirements of ISO/IEC 42001:2023. ISO also notes that adopting the standard delivers value in its own right.

The object of certification is therefore the management system. A certificate supports statements such as: this organization has defined AI policies, assigned accountability, and operates processes for managing AI risk and impact. It does not, on ISO's own wording, support the statement that a given model or application was built, tested and released in a specific way. Reading a certificate as proof of engineering practice across the lifecycle goes beyond what ISO says it provides.

How the two standards differ

The standards are listed separately in the ISO/IEC JTC 1/SC 42 catalogue, and they answer different questions. 42001 asks whether the organization manages AI in a structured, accountable way. 5338 describes the processes through which an AI system is defined, controlled, managed, executed and improved.

• Type: 42001: management system standard. 5338: AI system life cycle processes.
• Unit of focus: 42001: the organization and its AIMS. 5338: the AI system across its life cycle stages.
• Certification route: 42001: voluntary certification by independent certification bodies. 5338: ISO's certification statements refer to 42001 and its AIMS requirements.
• What it gives a reader: 42001: requirements for policies, objectives, accountability and processes. 5338: process definitions for lifecycle stages.
• Typical evidence: 42001: AIMS documentation, risk and impact assessments, internal review records. 5338: system-level artifacts and records of processes applied to a specific system.

Where the two standards intersect

The overlap is real but indirect. 42001 applies to organizations that develop, provide or use AI systems, and ISO describes an integrated approach to managing AI projects, from risk assessment to treatment of those risks. Impact assessments are a required part of AI governance under 42001. Annex A sets out controls an organization considers when operating its AIMS. Those requirements and controls create an expectation that the organization has defined how it manages AI systems over their life, which is where lifecycle process guidance becomes relevant.

5338 supplies the process detail that a management system leaves to the organization: how a system is defined, controlled, managed, executed and improved at each stage. A practical reading is that 42001 sets the governance frame and 5338 is a reference for the engineering and operational processes that sit inside it. An organization can choose 5338, or another lifecycle framework, as the way it meets its own AIMS objectives. That choice is the organization's, and a certificate does not record it unless the certified scope says so.

Any mapping between the two should be built from the published clause and Annex A text of 42001 and the process text of 5338, with each link cited. Existing crosswalks published for the NIST AI RMF relate that framework to 42001 or to 5338, not the two standards to each other, and they should be treated as aids rather than proof of coverage. ISO/IEC AWI 42003, intended as guidance on implementing 42001, is under development as of November 2026 and cannot be relied on yet.

The evidence gap in the use phase

Management system documents and design-time artifacts describe intent. They do not show what a deployed AI system was allowed to do on a given day, or what it did. For regulated enterprises, that is the question an auditor or regulator is most likely to put once a system is live, and it is a different kind of evidence from a certificate or a lifecycle process record.

Trussed addresses this use-phase gap. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each interaction or tool call is allowed, redacted, blocked, rate limited or escalated for human approval. Policy is enforced at runtime, not reviewed after the fact, and that enforcement generates continuous audit-ready evidence of what AI was allowed to do and what it did. The evidence is mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST, and deployment is self-managed in the customer cloud with configurable retention and data residency.

The scope is deliberately narrow. Trussed operates on individual interactions and tool calls. It does not cover lifecycle process implementation, model provenance, or the outcome of a 42001 certification. It supplies one category of operational evidence that sits alongside the management system and lifecycle artifacts described above.