For groups with many entities and hundreds of models, ISO 42001 starts with a clause 4.3 scoping decision. The stages, durations and what stays outside.
•
•
12 min read time
For a multi-entity enterprise, the ISO/IEC 42001 journey runs from a scoping decision under clause 4.3, through gap analysis, AIMS design, control implementation and internal audit, to a two-stage certification audit and a three-year cycle with annual surveillance. At group scale the sequence takes 12 to 24 months, and the scoping decision determines most of it.
Where does the ISO 42001 journey start for a multi-entity enterprise?
It starts with scope, not with a gap analysis. ISO/IEC 42001:2023, published December 18, 2023, requires the organization to determine the boundary of its AI management system in clause 4.3, "Determining the scope of the AI management system," after considering its context (clause 4.1) and the needs of interested parties (clause 4.2). Everything downstream, from the Statement of Applicability to the audit-day count, is priced off it.
Public certificates show how narrowly the largest AI providers draw it. Anthropic's certificate, announced January 13, 2025, covers "our AI management system." IBM's, announced October 1, 2025, covers "the AI Management System (AIMS) of IBM Granite," one model family. Microsoft's lists nine named services. None certified "the company."
A multi-jurisdiction group has a second boundary to draw. Under IAF MD 1:2023, a multi-site certificate needs "a single management system comprising an identified central function" that "centrally controls the management system." All sites must sit inside the organization's internal audit program and a centralized management review, and where sites are eligible for sampling, the initial audit samples the square root of the number of sites, rounded up. A group that cannot name the central function for its AIMS does not yet have a certifiable scope.
How do you decide what sits inside the AIMS boundary with hundreds of models?
Does the organization decide how the system is built or used, or does it only consume an output? Do the system's outputs reach the interested parties identified under clause 4.2? Can the organization produce evidence for the Annex A controls it will declare applicable? A system that fails the first test is usually a supplier relationship, not an AI system in scope; one that fails the third is in scope but not ready.
The distinction between an AI system in scope and an interested party is the one large estates get wrong most often. A foundation model consumed through a vendor API is not a system the enterprise can audit. The vendor is an interested party and a supplier; the enterprise's application built on it, with its prompts, guardrails and human oversight, is the AI system in scope. The AI inventory has to hold both records and the link between them, because the auditor will ask what changes when the vendor changes the base model.
Population | Illustrative example | First-wave scoping decision | What the auditor will look for |
|---|---|---|---|
Models the group builds and runs in a decision path | Credit, underwriting, claims and pricing models | In scope, system by system | Owner, lifecycle records, risk and impact assessments, monitoring |
Applications built on a vendor foundation model | Internal assistant with retrieval over policy documents | In scope as the enterprise's system; vendor recorded as supplier | Supplier controls, change notification, evaluation against the base model version |
Embedded AI in licensed SaaS | Lead scoring in the CRM, meeting summaries in collaboration tools | In the inventory, outside the certified scope unless it drives a decision about people | Documented exclusion rationale, supplier assessment, acceptable use |
AI the group sells or wraps for customers | Vendor model resold inside a client-facing product | In scope; the group is the provider | Transparency to customers, information for interested parties, incident handling |
Experiments and notebooks not in production | Data science sandboxes | Out of scope, with a lifecycle gate that pulls systems in at deployment | Evidence the gate exists and fires |
Legacy statistical models under model risk management | Capital, liquidity and stress models | Decision point: exclude with a documented boundary to MRM, or include and inherit MRM evidence | A written boundary that matches the model risk management inventory |
Agents with tool access | Agent that reads and writes to a system of record | In scope where it acts on an in-scope system | Permissioning, human oversight triggers, stop mechanism |
Entities in other jurisdictions | A subsidiary with its own AI team | Scope by legal entity and site; first wave takes the entities the central function controls | Central function authority, internal audit coverage of every site |
The table is a starting position, not a rule from the standard. Every exclusion needs a written reason that would survive being read aloud to a regulator, and the inventory must record excluded systems as well as included ones, so the exclusion is visible at each surveillance audit.
What does the journey look like from gap analysis to surveillance, and how long does each stage take?
ISO/IEC 17021-1, the standard accreditation bodies hold certification bodies to, fixes the mechanics. Stage 1 reviews documentation and readiness; Stage 2 evaluates "the implementation, including effectiveness, of the client's management system." Surveillance audits run "at least once a calendar year, except in recertification years," and "the first three-year certification cycle begins with the certification decision."
The durations below are planning ranges for a group with several legal entities and hundreds of models, not figures from the standard; an organization certified to ISO/IEC 27001 will land at the short end of most. Enzai's ISO 42001 implementation guide covers the content of each step; this table covers sequence and elapsed time.
Stage | What happens | Enterprise planning range |
|---|---|---|
Scoping decision | Entities, sites, central function and AI systems named; exclusions written; roles per system recorded | 6 to 12 weeks |
Gap analysis | Clauses 4 to 10 and applicable Annex A controls compared with current practice, per entity | 6 to 10 weeks |
AIMS design | AI policy, risk and impact assessment methods, roles, Statement of Applicability, competence plan | 2 to 4 months |
Control implementation and evidence | Controls operating on every in-scope system; evidence attached to system and version | 4 to 9 months |
Internal audit and management review | Independent audit of every site in scope; nonconformities corrected; top management review | 6 to 10 weeks |
Stage 1 audit | Documentation and readiness review; findings corrected before Stage 2 | 1 to 3 days on site, 4 to 8 weeks to close findings |
Stage 2 audit | Implementation audit across sampled sites; certification decision follows | 1 to 3 weeks of audit days, decision 4 to 8 weeks later |
Surveillance | Annual audit; first within 12 months of the certification decision | Recurring |
Recertification | Full audit before the certificate expires at three years | Year 3 |
The total for a first wave is 12 to 24 months, and the variable that moves it most is not the model count but the number of entities whose evidence must reach the same standard.
Who can certify an AIMS, and does accreditation matter?
ISO/IEC 42006:2025, published July 2025, sets the requirements for bodies auditing and certifying AI management systems, supplementing ISO/IEC 17021-1. ANAB states that it "accredits certification bodies that issue certifications to ISO/IEC 42001" and references 42006 in its program; Anthropic's January 2025 certificate came from an ANAB-accredited body, so ANAB accreditation predates 42006. UKAS granted its first AIMS accreditation to BSI, announced in January 2026; BSI's own release, dated November 17, 2025, also cites accreditation by the Dutch body RvA.
The certificate is only as good as the body that issued it. A buyer, or a customer reviewing the buyer, should ask which accreditation body appears on the certificate, whether that accreditation names ISO/IEC 42001, and what the scope statement covers.
How long before ISO 42001 becomes a market expectation?
There is no authoritative count of certificates; the ISO Survey does not track ISO/IEC 42001. The honest answer comes from four observables that point in different directions.
Public announcements are concentrated on the sell side. Anthropic, IBM and Microsoft certified their own AI products, and a growing number of technology vendors have followed. An enterprise buying AI will be asked to check certificates before it is asked to hold one.
Security questionnaires already carry ISO 42001-shaped questions. The Cloud Security Alliance's AI Controls Matrix, released July 9, 2025, has 243 control objectives mapped to ISO 42001, NIST AI RMF and the EU AI Act, paired with a questionnaire customers can send to vendors. An enterprise selling services with AI inside them should expect these in inbound reviews now.
Government procurement has not mandated it. The UK Department for Science, Innovation and Technology consulted on an AI Management Essentials tool based on ISO/IEC 42001, then stated in its December 2025 response that it "will not be publishing AIME and therefore will not be making it a requirement of the government procurement process."
Regulation does not require it. The EU AI Act does not name ISO 42001, and none of the supervisors covered in Enzai's financial services AI governance glossary entry mandates it. For a regulated deployer, a certified AIMS is one form of evidence against governance expectations, not a requirement.
The useful measure is internal. Count the RFPs, security reviews and regulator requests that ask about ISO 42001 each quarter; when that count is rising, the expectation has arrived.
Does ISO 42001 certification satisfy the EU AI Act?
No. Presumption of conformity under Article 40 of the AI Act attaches to harmonized standards cited in the Official Journal of the European Union, and ISO/IEC 42001 is not one. The work runs through CEN-CENELEC JTC 21 under standardization request M/593 and its amendment M/613; in October 2025 CEN and CENELEC adopted acceleration measures targeting the key standards by the fourth quarter of 2026.
The first deliverable has arrived, and it is not ISO 42001. EN 18286:2026, "Quality Management System for EU AI Act Regulatory Purposes," was published in July 2026 to cover the Article 17 quality management system for high-risk providers. It is a purpose-built European standard, and as of this draft no JTC 21 deliverable has been cited in the Official Journal, so none yet confers presumption. Risk management (prEN 18228), logging (prEN 18229-1) and cybersecurity (prEN 18282) were still in enquiry in July 2026.
The deadlines no longer wait for the standards. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force July 27, 2026; the Commission's AI Act page now gives December 2, 2027, for Annex III high-risk systems and August 2, 2028, for Annex I systems, whether or not harmonized standards are available. Enzai's EU AI Act compliance guide carries the full deadline table. A certified AIMS is evidence of a management system; conformity of a high-risk system is demonstrated obligation by obligation, work the EU AI Act solution page covers separately.
Where does ISO 42001 evidence overlap with the EU AI Act and NIST AI RMF, and where does it not?
The overlap sits at the management-system layer, and NIST's crosswalk from the AI RMF to ISO/IEC 42001 (against the final draft) maps, for example, clause 4.3 scope to MAP 3.3, "targeted application scope is specified and documented." An enterprise using NIST profiles to structure its program can reuse most of its GOVERN evidence for clauses 5 and 7.
Evidence item | ISO/IEC 42001 | EU AI Act | NIST AI RMF |
|---|---|---|---|
AI policy, roles, top management commitment | Clause 5 | Feeds the Article 17 quality management system for providers | GOVERN |
AI risk assessment and treatment | Clauses 6.1.2, 6.1.3, 8.2, 8.3 | Article 9 risk management, per high-risk system | MAP, MEASURE, MANAGE |
AI system impact assessment | Clauses 6.1.4, 8.4 | Article 27 fundamental rights impact assessment, for specified deployers only | MAP |
Supplier and customer controls | Annex A third-party and customer controls | Provider and deployer obligations along the value chain | GOVERN, MANAGE |
Technical documentation to Annex IV, conformity assessment, CE marking, EU database registration | Not covered | Required for high-risk systems | Not covered |
Article 50 transparency, general-purpose AI model obligations | Not covered | Required regardless of AIMS status | Partially, via the Generative AI Profile |
Where it does not overlap is where the cost sits. ISO 42001 asks whether a documented, effective process exists; the AI Act asks for a specific artifact for a specific system, to a specific template, by a specific date. An impact assessment that satisfies an AIMS auditor may not be the Article 27 assessment an Annex III deployer must complete. The mapping that saves work is at the evidence level: a bias evaluation run on a named model version is one artifact that serves clause 8, Article 9 and MEASURE at once. Enzai's compliance frameworks module is built on that principle, with evidence "captured once, used across audits" and a compliance score per system per framework.
What do you need ready before onboarding a governance platform for ISO 42001?
The onboarding question is a scoping question in disguise: a platform can only map what it is given.
The legal entity and site list for the first wave, with the central function named.
An inventory export holding each system's owner, purpose, model or vendor reference, lifecycle stage, jurisdiction and degree of autonomy. Enzai's AI inventory runs five discovery methods (procurement signals, SaaS telemetry, browser signals, network traffic and manual disclosure) and tiers systems by use case, autonomy, data sensitivity and customer exposure, which fills most of these fields for systems nobody declared.
The role the enterprise plays for each system: builder, customer of a vendor system, or provider to its own customers.
The ISO/IEC 27001 artifacts that transfer, the model risk management inventory, and the written MRM boundary.
AI supplier contracts, with the clauses on model change notification and subprocessors located.
An enterprise with these at hand sits at the level of the governance maturity model where certification is a formalization exercise. One without them has its first finding before the gap analysis starts.
What this means operationally
Name the central function and the first-wave entities before commissioning a gap analysis. Record, for every AI system in the inventory, whether it is inside the certified scope, outside with a reason, or a supplier relationship.
Record the enterprise's role per system and link every vendor-model application to the vendor record.
Attach evidence to systems and versions, not to clauses, and map each artifact to every framework it satisfies, so nothing is produced twice for the EU AI Act or NIST AI RMF.
Choose the certification body on accreditation scope and check the certificate wording; customers read the scope statement more carefully than the logo.
Track inbound demand for the certificate quarterly, and run the Annex III EU AI Act work against December 2, 2027, as a separate track the AIMS supports but does not replace.
To see how Enzai structures scoping, evidence and cross-framework mapping for an ISO 42001 program, start with the ISO 42001 solution page or talk to the Enzai team.
Empower your organization to adopt, govern, and monitor AI with enterprise-grade confidence. Built for regulated organizations operating at scale.