ISO/IEC 42001:2023: the AI management system (AIMS) standard, explained

ISO/IEC 42001 uses ISO's Harmonized Structure — the same template behind ISO/IEC 27001:2022 and ISO 9001 — with normative requirements running through Clauses 4 to 10 as a Plan-Do-Check-Act cycle: Context of the Organization (4), Leadership (5), Planning (6), Support (7), Operation (8), Performance Evaluation (9) and Improvement (10). Clause 6 is where the AI-specific work concentrates: an AI risk assessment and risk treatment process, AI objectives, and the establishment of an AI system impact assessment process. Clause 8 then requires operating and controlling the AI lifecycle against that planning, and Clause 9 requires internal audits and management review producing evidence an external auditor can sample. Because the skeleton is shared with ISO/IEC 27001, an organization already running an ISMS typically reuses its document-control, internal-audit and management-review machinery rather than building a second parallel system from scratch — the new work is almost entirely in the AI-specific content, not the management-system scaffolding.

Annex A is the standard's normative control catalogue. Corroborated secondary reporting (not independently verified against the paywalled standard text — see the sourcing note above) describes 38 controls organized under nine control objectives, A.2 through A.10: AI policies, internal organization, resources for AI systems, assessing impacts of AI systems, the AI system life cycle, data for AI systems, information for interested parties of AI systems, use of AI systems, and third-party and customer relationships. As with ISO/IEC 27001's own Annex A, the standard does not require implementing all 38 controls by default — an organization runs its Clause 6 risk assessment and AI system impact assessment first, then selects applicable controls into a Statement of Applicability and documents a justification for any it excludes. Annex B gives implementation guidance control-by-control, Annex C catalogues AI-specific risk sources (bias, explainability gaps, model drift, safety) that feed the risk assessment, and Annex D addresses sector-specific applicability.

This is the clause that most clearly separates ISO/IEC 42001 from a conventional information-security management system, and it is the piece an ISO/IEC 27001-certified organization cannot simply reuse. Centered on Annex A.5 and required by Clause 8.4, it is not a risk assessment in the security sense — it evaluates organizational impact, impact on individuals or groups, and societal impact, including whether an AI system's selection or scoring criteria could produce biased outcomes against a particular community, and it has to be performed and documented at planned intervals and whenever a system changes materially. For a vendor that embeds an on-device model — object detection in a camera, anomaly scoring in an industrial sensor, voice processing in an appliance — this is the clause asking a different question than a firmware security assessment does: not just "can this model be attacked or does it leak data," covered by work like an AI-BOM for embedded AI devices or threat-modeled against MITRE ATLAS, but "who could this model's decisions affect, and was that assessed before and after shipping."

Certification is voluntary and performed by accredited certification bodies under ISO/IEC 17021-1, supplemented by ISO/IEC 42006:2025's AI-specific requirements for the certifiers themselves; national accreditation bodies such as ANAB (US) and UKAS (UK) accredit those certifiers, with ANAB reported to have accredited multiple US certification bodies and UKAS confirming its first accredited body by November 2025. The process follows the same two-stage pattern as other management-system certifications — a Stage 1 documentation review, then a Stage 2 operational audit sampling real evidence that the AIMS runs as documented — leading to a three-year certificate with annual surveillance audits and a full recertification audit at the end of the cycle.

Certification does not, by itself, satisfy the EU AI Act. Multiple legal analyses of the Act's Article 40 mechanism agree that ISO/IEC 42001 has not been cited in the EU Official Journal and therefore does not create a rebuttable legal presumption of conformity; that presumption is reserved for harmonized standards CEN-CENELEC's JTC 21 publishes, with a dedicated standard (EN 18286) specifically targeting the Article 17 quality-management-system duties the Act imposes on high-risk AI providers. Where the two overlap, ISO/IEC 42001 certification is widely treated as strong due-diligence evidence of a working governance program — not a substitute for the Act's own conformity-assessment route. Against the non-certifiable NIST AI Risk Management Framework, the standards are complementary rather than competing: a community-submitted crosswalk on NIST's own Trustworthy and Responsible AI Resource Center maps AI RMF's GOVERN/MAP/MEASURE/MANAGE subcategories to specific 42001 clauses and Annex B controls, and ISO/IEC 42001's own risk-assessment clause draws on the separate guidance-only ISO/IEC 23894:2023 (published 6 February 2023), which is explicitly not designed for standalone certification.

A device or firmware maker that builds or ships its own AI models — not just one that consumes a third-party model API — sits at the intersection of several of these frameworks at once: a Cyber Resilience Act security baseline for the firmware itself, an AI-BOM for the embedded model's provenance, a threat model against adversarial AI attack techniques, and now a management-system layer asking whether the organization actually governs that model's risk and impact on an ongoing basis rather than once at ship time. ISO/IEC 42001 is the standard that formalizes the last piece — it does not replace firmware or product security work, it sits above it as the accountability and audit-trail layer. SoftWSP does not issue ISO/IEC 42001 certificates — that requires an accredited certification body under ISO/IEC 17021-1 and ISO/IEC 42006 — but where a device or firmware vendor is building out an AIMS, mapping its AI governance controls against an existing device and firmware security program is a practical way to avoid running two disconnected efforts for the same embedded model.

This guide cross-checks ISO's own publicly indexed standard-page language for ISO/IEC 42001:2023 and ISO/IEC 23894:2023 against the ANSI/ANAB accreditation-body blog and several independent secondary analyses, since iso.org's standard and insights pages returned HTTP 403 to this guide's fetch tooling and could not be rendered directly. The Annex A control count (38 controls, nine objectives) and clause-level detail in particular are drawn from secondary sources rather than the purchased standard text and should be verified against ISO's own PDF before being relied on for a certification decision. This guide is not a substitute for the standard itself, for ISO/IEC 42006's certification-body requirements, or for legal advice on EU AI Act conformity.