ISO/IEC 5338 vs ISO/IEC 42001: How the Standards Fit Together

Two Standards Operating at Different Layers

ISO/IEC 42001:2023 is described by ISO as the first international standard specifying requirements for an Artificial Intelligence Management System (AIMS). It follows the Annex SL high-level structure shared with standards like ISO/IEC 27001, which means it operates through a policy, risk assessment, objective-setting, and continual improvement cycle. Because it uses this common structure, organizations can integrate AIMS audits into existing management system audits rather than building a separate audit track from scratch. ISO/IEC 42001 is structured to support third-party conformity assessment and certification by accredited bodies, making it the standard most enterprises point to when demonstrating formal AI governance to customers, regulators, or partners.

ISO/IEC 5338:2023 sits at a different layer. It defines AI system life cycle processes by extending the general software life cycle processes established in ISO/IEC/IEEE 12207, adding AI-specific process areas such as data engineering and model-related considerations that do not exist in the base software standard. It covers stages including concept and inception, development, verification and validation, deployment, operation and monitoring, and retirement. Unlike 42001, ISO/IEC 5338 is published as a process-reference standard rather than a certifiable management system. Organizations do not get certified against it; they use it to structure how AI systems are actually engineered.

ISO/IEC 5338 vs ISO/IEC 42001 at a Glance

The table below summarizes the core distinctions covered above, side by side.

Where the Two Standards Overlap

The overlap between ISO/IEC 5338 and ISO/IEC 42001 concentrates on three areas: risk identification, data quality, and monitoring. In ISO/IEC 42001, these appear as governance requirements, expressed through risk assessment and treatment obligations tied to the AIMS policy cycle. In ISO/IEC 5338, the same concerns appear as process activities embedded in specific life cycle stages, such as data engineering during development or performance checks during operation. This is a natural consequence of the two standards being developed under the same technical committee, ISO/IEC JTC 1/SC 42, but it also means the same underlying activity, such as a model risk review, can generate different documentation depending on which standard's requirements are being satisfied.

Organizations that treat this overlap as duplication rather than as two views of the same activity tend to end up with parallel, disconnected artifacts: a risk register maintained by governance teams for 42001 audits, and separate validation logs maintained by engineering teams for internal process discipline. Aligning these into shared artifacts, such as a single risk register referenced by both functions, reduces redundant work without weakening either standard's requirements.

Where Independent Implementation Creates Gaps

Implementing ISO/IEC 42001 without adopting 5338-aligned engineering processes leaves a common gap: the management system has policies and risk categories, but lacks the granular technical evidence, such as data lineage, validation results, or model versioning records, that certification auditors typically expect to see tied to those risk categories. The organization may pass a paper audit but struggle to produce evidence quickly when asked.

The reverse gap is just as common. Organizations that implement ISO/IEC 5338 well often have strong engineering process discipline, clear life cycle stage gates, and good technical documentation, but lack the policy structure, defined accountability, and continual-improvement mechanism that auditors and regulators expect from a management system. Because ISO/IEC 5338 is not independently certifiable, this level of engineering maturity does not by itself satisfy external governance expectations that reference a certifiable standard like ISO/IEC 42001.

The underlying issue in both cases is ownership. Unclear division of responsibility between engineering functions running 5338-aligned processes and governance functions running the 42001 management system creates audit gaps when nobody is explicitly assigned to generate and retain the required evidence.

Building a Joint Implementation Approach

A joint approach starts by assigning explicit ownership: engineering functions remain responsible for the life cycle activities defined under ISO/IEC 5338, while governance functions remain responsible for the policy, risk, and continual-improvement obligations defined under ISO/IEC 42001. Between them, the two functions agree on shared artifacts, such as a common risk register and a common evidence trail, so a single activity like a model risk review satisfies both the engineering process record and the management system audit requirement. Runtime monitoring of AI systems in operation becomes the connective layer that ties ongoing engineering activity to the conformance evidence a management system audit expects, rather than leaving that link to be reconstructed manually after the fact.

Common Questions on ISO/IEC 5338 and ISO/IEC 42001