Every control in an ISO management system has an owner, a calendar, and a body of evidence. When ISO/IEC 42001 arrives, the question is not whether to build those things for AI but whether anyone will do the clause-by-clause work of showing where they already exist.
The standard was built to attach to systems you already operate
ISO describes ISO/IEC 42001 as “the world’s first AI management system standard” and positions it alongside ISO 9001 for quality, ISO 14001 for environment, and ISO/IEC 27001 for information security. The same ISO overview says the standard is “built around a ‘Plan-Do-Check-Act’ process” and describes an integrated approach that runs from risk assessment through to the treatment of those risks. None of that language is new to a bank, an insurer, or a hospital system. It is the operating grammar of every management system those organizations have already been audited against.
The clause skeleton is familiar too. KPMG’s certification overview, published in July 2026, walks it in the order any ISO/IEC 27001 owner will recognize: Clause 4 for understanding the organization and scope, Clause 5 for leadership, policies and responsibilities, Clauses 6 and 8 for operational risk management, and Clause 10 for continual improvement. The same overview states that ISO/IEC 27001 “can be integrated with AIMS to strengthen security controls” — AIMS being the artificial intelligence management system the standard defines — and that the standard’s security control objectives are “designed to work in harmony with existing ISMS programs,” the information security management system most regulated enterprises already certify.
The standard says so itself. In a February 2025 briefing on complementing ISO/IEC 42001, BSI points to Annex D of the standard as its own integration guidance, naming ISO/IEC 27001 for information security, ISO/IEC 27701 for privacy, and ISO 9001 for quality as the management systems it expects to join. A standard that ships with an annex on how to integrate with your existing systems is not asking you to stand up a parallel one.
The maps already exist, and most programs never open them
The mapping exercise is not novel work. NIST’s AI Resource Center publishes crosswalks between the NIST AI Risk Management Framework (AI RMF) and the ISO AI standards, and they show how little of the territory is new. The revised crosswalk to ISO/IEC 23894, the AI risk management guidance, notes that ISO/IEC 23894 is built on ISO 31000’s general risk management guidance. ISO 31000 is the document most enterprise risk functions already describe themselves against. The crosswalk then maps the AI RMF’s GOVERN function to leadership, integration, and design clauses; MAP to scope, context, risk criteria, and risk analysis; and MANAGE to treatment selection, treatment plans, and monitoring and review. Read as a risk officer rather than a technologist, that is a description of the risk cycle you already run, with AI-specific content poured into each step.
The crosswalk is also honest about where the mapping fails. Its notes single out one ISO/IEC 23894 clause — 6.2, communication and consultation — as having no NIST counterpart. That is the whole point of a crosswalk. The value is not in the clauses that line up; it is in the specific clauses that do not, because those are the only places where a new control is required rather than an existing one re-labeled.
The same resource center carries a crosswalk for ISO/IEC 42005, the AI system impact assessment standard, mapped while it was still a draft international standard (DIS). It is a two-column table: each AI RMF function and outcome on the left, the corresponding 42005 clauses on the right, with a dash wherever no clause matches. That format — outcome, matching clause, or an explicit gap — is exactly what an enterprise should produce for its own control library against ISO/IEC 42001, and in our experience few do. The standard gets read, a gap assessment gets commissioned, and the output is a list of findings rather than a mapping that names, for every requirement, the existing control, its owner, and the evidence that it operates.
The standard does not ask for a new function. It asks which existing controls already satisfy it, and which do not.
The standard does not ask for a new function. It asks which existing controls already satisfy it, and which do not.
What the mapping produces, and who should own each piece
A mapping done properly produces three artifacts, and each has an obvious home in a function that already exists.
The first is the Statement of Applicability (SoA). KPMG calls the SoA “a critical component of certification” and describes the expected chain: identified AI risks linked to control objectives and recorded in the SoA. Any enterprise with an ISMS has produced an SoA before; the AI version is the same document with AI risks and AI control objectives in the rows. It belongs to whoever owns the ISO/IEC 27001 SoA today, with the AI risk owners contributing their rows.
The second is the AI impact assessment, which KPMG summarizes as the “evaluation of the impact of AI on individuals and society.” This is the one genuinely new artifact, because enterprise risk assessment has historically asked what a system does to the firm, not what it does to the people on the other end of it. The NIST crosswalk for ISO/IEC 42005 shows that even this artifact maps onto outcomes the AI RMF already names; what is new is the obligation to write it down per system and keep it current. It belongs with whichever per-system assessment the firm already runs — model risk or privacy impact — rather than with a project-stage review that closes when the project does.
The third is the scope statement and the evidence that the system operates. KPMG’s description of the certification path makes the audit mechanics plain: a Stage I documentation audit, then a Stage II implementation audit in which auditors interview stakeholders, validate controls in the technical environment, and review internal audits and management reviews. A certificate is valid for three years, with annual surveillance audits and recertification in the third year. Every one of those checkpoints — internal audit, management review, surveillance — is a ritual an ISO-certified enterprise already runs on a calendar. The mapping decision is whether AI gets its own calendar or joins the existing one. Our assessment is that it should join the existing one, with a named AI control owner reporting into the same management review.
The practical sequence is short. Within a quarter, the risk function takes the existing control library — ISMS, model risk, third-party risk — and maps each ISO/IEC 42001 clause and control objective to it in the NIST crosswalk format: requirement, matching control, or a dash. The dashes become the project; everything else becomes an evidence-collection task for an owner who already exists. The impact assessment template is built once and attached to the inventory of AI systems, so each new entry triggers its own. Then the organization decides, on evidence rather than instinct, whether certification is worth the audit cost or whether demonstrable conformance is enough.
The expensive version of ISO/IEC 42001 is the one that treats it as a new discipline and staffs it accordingly. The defensible version is a mapping: the standard’s clauses on one side, your control library on the other, and a dash wherever nothing matches. The standards bodies have already published their half of that table. The half that remains — your controls, your owners, your evidence — is the governance work itself, and no one outside the organization can do it for you.