Key takeaways
- ISO/IEC 42001:2023 is the first international, certifiable standard for an AI Management System (AIMS), published jointly by ISO and IEC in December 2023.
- It targets organizations, not individual AI systems. A certificate says the company runs AI under a managed system; it does not bless any specific model.
- The standard pairs a familiar management-system spine (Clauses 4 to 10) with an AI-specific control set in Annex A spanning policies, lifecycle, data, transparency, and third-party relationships.
- Certification follows a two-stage audit and a three-year cycle with annual surveillance. Realistic preparation runs 6 to 12 months for organizations starting from a low or moderate baseline.
- ISO 42001 is a governance scaffold, not an EU AI Act compliance answer. It does not deliver conformity assessment, prohibited-practice screening, end-user transparency, or serious-incident reporting on its own.
What ISO/IEC 42001 actually is
ISO/IEC 42001:2023 is an international standard that specifies requirements for “establishing, implementing, maintaining and continually improving an AI management system within organizations”. The official scope statement is published on the ISO catalogue page. It was developed by the joint ISO/IEC technical subcommittee SC 42, the same body that produces the broader family of AI standards on bias, robustness, life cycle, and risk management. ISO 42001 is the first of its family that any organization can be certified against by an accredited third party.
The thing being certified is the AI Management System (AIMS), not the AI itself. An AIMS is the body of policies, roles, processes, controls, and records that govern how an organization develops, procures, deploys, and decommissions AI systems. The phrasing matches the way ISO 9001 governs quality and ISO 27001 governs information security: the standard certifies the company’s discipline, not the product.
ISO 42001 inherits the Plan-Do-Check-Act cycle that runs through every Harmonised Structure ISO management standard, and adapts each phase to AI’s specifics. “Do” expands to model training, deployment, and monitoring with drift checks. “Check” includes performance against fairness, robustness, and explainability objectives, not only ISO-style nonconformities. “Act” includes retraining triggers and recall paths for systems already in the field.
Two practical consequences flow from the way the standard is written. First, the certificate is awarded to an organization at a defined scope (one business unit, one product line, the whole legal entity), so an “AIMS-of-1” is a valid certification scope when a small company runs a single AI system. Second, the standard is voluntary. No regulator requires it. It earns its weight through procurement, investor due diligence, and the audit-trail value it offers as evidence under regimes like the EU AI Act.
Who the standard is for
ISO 42001 is jurisdiction-neutral, but it speaks naturally to the role taxonomy used by EU AI Act Articles 3(3) and 3(4). Providers develop or commission an AI system and place it on the market under their own name. Deployers operate an AI system under their own authority. The same AIMS clauses cover both, but the operational evidence differs: providers spend more time on training-data lineage and model documentation; deployers spend more time on intended-purpose statements, instructions-for-use, and operator training.
General-purpose AI (GPAI) model providers, including those building large foundation models, can certify against ISO 42001 too. The standard does not have a dedicated GPAI annex, but the Annex A control families on data, lifecycle, third-party relationships, and policies map cleanly to the obligations that downstream Acts impose on GPAI providers.
Internal-use AI follows the same rules as market-facing AI. A bank using a credit-scoring model only for its own customers is still in scope, because the AIMS covers any AI system the organization develops, uses, or relies on. The certificate is silent on whether the AI is sold externally; it speaks only about how it is governed.
A useful corollary is the “AIMS-of-1”: a small organization with one productionized AI system. Many of the ISO 42001 controls scale down naturally (a one-person AI policy, a single Statement of Applicability, a single risk assessment). The Annex A controls remain the same, but the audit evidence shrinks accordingly. Auditors are used to reading scope statements that limit certification to a named system; they will not penalize lean.
The clause structure: how ISO 42001 is built
Clauses 4 to 10
The body of the standard follows the High-Level Structure (HLS) shared by ISO 9001, ISO 27001, and the rest of the Harmonised Structure family. Clauses 1 to 3 set the scope, normative references, and terms; the operative requirements live in Clauses 4 to 10.
Clause 4 (Context) asks the organization to map its internal and external context for AI, identify interested parties (regulators, customers, workers, affected populations), and define the AIMS scope. Clause 5 (Leadership) requires a designated AI accountability owner, an AI policy approved at the top, and demonstrable commitment from leadership. Clause 6 (Planning) is where the AI risk assessment and the AI impact assessment live, alongside the Statement of Applicability that ties everything to the Annex A controls. Clause 7 (Support) covers resources, competencies, awareness, communication, and documented information. Clause 8 (Operation) extends operational planning to the full AI lifecycle (design, data, training, evaluation, deployment, monitoring, retirement). Clause 9 (Performance evaluation) requires monitoring, internal audit, and management review. Clause 10 (Improvement) closes the loop with nonconformity, corrective action, and continual improvement.
Annex A: the nine control domains, briefly
Annex A is the AI-specific control set. It is shaped like ISO 27001 Annex A but lives at a higher abstraction level: control objectives, not prescribed implementations. Nine domains, A.2 through A.10:
A.2Policies for AIA.3Internal organizationA.4Resources for AI systemsA.5Assessing impacts of AI systemsA.6AI system life cycleA.7Data for AI systemsA.8Information for interested parties of AI systemsA.9Use of AI systemsA.10Third-party and customer relationships
Each domain holds a handful of control objectives. The standard does not say how to satisfy them; the organization chooses controls during planning and justifies its choices in the Statement of Applicability.
Annex B, Annex C, Annex D
Annex B is informative implementation guidance that maps each Annex A control objective to suggested practices. Annex C lists AI-specific risk sources: training data bias, automation bias, opacity, robustness gaps, security exposures, environmental impact. Annex D walks through cross-sector use-case considerations (healthcare, public sector, employment, defence). These three annexes are not requirements, but auditors read them; deviations from Annex B should be justified in writing.
Annex A in operating terms
The most common trap with ISO 42001 is treating Annex A like a policy checklist. Auditors want artefacts that show the controls live in the day-to-day, not binders. Here is each domain as an operating rhythm, with one concrete example of the artefact that earns the tick.
A.2 Policies for AI
The AI policy and any sub-policies (acceptable use, model development, third-party AI) are reviewed at a defined cadence. Operating artefact: the dated policy register with version history and a board minute approving the current version.
A.3 Internal organization
Roles and responsibilities for AI are documented and unambiguous. Operating artefact: a RACI matrix that names the AI accountability owner, the model owners per system, the data steward, and the second-line risk function, signed off by HR or organizational design.
A.4 Resources for AI systems
The organization knows what data, tooling, compute, and human resources its AI systems consume. Operating artefact: a monthly inventory review of the feature store, prompt registry, model registry, and compute spend, with deltas flagged to the AI accountability owner.
A.5 Assessing impacts of AI systems
For each AI system, an impact assessment captures effects on individuals, groups, and society. Operating artefact: a completed AI impact assessment per system, refreshed when the system is materially changed or every 12 months, whichever comes first.
A.6 AI system life cycle
The life cycle from concept to retirement is governed: design review, data review, model review, deployment approval, monitoring, retirement. Operating artefact: model-lifecycle gate records showing who approved each transition and on what evidence.
A.7 Data for AI systems
Data used for training and inference is documented, fit for purpose, and quality-managed. Operating artefact: a dataset card per training dataset, listing provenance, lawful basis, representativeness checks, and known gaps.
A.8 Information for interested parties
Users, operators, and affected parties receive appropriate information about the AI system. Operating artefact: the system’s transparency notice or model card, plus any in-product disclosures shown to end users, with screenshot evidence.
A.9 Use of AI systems
The intended purpose, operational limits, and human oversight are defined and enforced. Operating artefact: an “intended use” document per system, paired with an operator briefing or training attestation log.
A.10 Third-party and customer relationships
Suppliers (foundation-model providers, data vendors, MLOps platforms) and customers (where the organization operates as a provider) are governed through contracts and assurance. Operating artefact: an AI supplier register with each supplier’s role, the contractual AI clauses in force, and the most recent assurance evidence (audit report, attestation, SBOM, or model card).
A useful self-test: walk into a Tuesday morning and ask “which artefact have I touched today for which Annex A control?” If the answer is “none for weeks”, the AIMS exists on paper only.
Risk assessment, impact assessment, and the Statement of Applicability
AI risk assessment vs AI impact assessment
ISO 42001 separates two activities that share vocabulary in everyday speech. AI risk assessment (Clause 6.1.2) is the organization-facing view: what could go wrong with this AI system, for the organization, and how likely and serious is it? AI impact assessment (Clause 6.1.4) is the outward-facing view: what effects does this AI system have on individuals, groups of individuals, or society, including their fundamental rights?
Treating them as one document misses the point. Risk assessment drives the selection of Annex A controls. Impact assessment drives transparency obligations, redress mechanisms, and the decision to deploy at all. The AWS Security Blog walks through the AI lifecycle risk management approach and shows how both feed the Statement of Applicability.
How the Statement of Applicability differs from ISO 27001
A Statement of Applicability (SoA) in ISO 27001 lists each Annex A control and says whether it is applicable or not, with justification. In ISO 42001 the same logic applies, but the SoA gains a second axis: AI use cases. A control may be applicable in general, but its concrete implementation may differ per AI use case (a chatbot, a fraud-detection model, an HR resume screener). The cleanest SoAs ship as a matrix: rows are controls, columns are AI use cases, cells reference the concrete control implementation.
What evidence auditors accept
Auditors discount policy PDFs that have no traffic. They accept records that show the policy was used: review minutes, approval signatures, ticket comments, training attendance logs, screenshots of in-product transparency notices, dataset cards, model cards, drift dashboards, and incident retrospectives. A useful rule of thumb: for each Annex A control, identify one artefact that auditors can sample, one cadence at which it is refreshed, and one named owner. Three items per control across nine domains is a tractable preparation backlog.
The certification process from kickoff to surveillance
Gap analysis and AIMS scoping (months 1 to 2)
The first six to eight weeks set the scope of certification (which legal entity, which business unit, which AI systems), run a gap analysis against Clauses 4 to 10 and Annex A, and produce the initial backlog of policies, procedures, and artefacts to build. Most organizations also use this phase to choose an accredited certification body. Lead times for first-time audits ranged from two to six months across 2025, so booking early matters.
Stage 1 audit
Stage 1 is the documentation and readiness audit. The certification body reviews the AIMS scope, the AI policy, the risk and impact assessments, the SoA, and the management-review records. According to the Cloud Security Alliance’s certification-process walkthrough, Stage 1 typically runs one to two on-site or remote days for a small organization. Any major nonconformities must be remediated before Stage 2.
Stage 2 audit
Stage 2 is the operational-effectiveness audit. Auditors sample evidence per Annex A control, interview the AI accountability owner and model owners, and verify that the AIMS is running as documented. Duration scales with size and complexity, typically one to three weeks for a mid-sized organization with multiple AI systems. The output is the certificate (if successful) plus a list of minor nonconformities and observations.
Surveillance audits and three-year recertification
The certificate is valid for three years with annual surveillance audits at roughly one third of the initial audit duration. Year four triggers a full recertification audit. CSA’s auditing lessons notes that the most common surveillance findings concern stale impact assessments and unenforced model-retirement procedures.
Realistic timelines
Cloud Security Alliance and most certification bodies converge on 6 to 12 months of preparation for an organization with a low-to-moderate baseline, longer if the AIMS scope is broad or if existing management systems (ISO 27001, ISO 9001) are absent. Organizations that already hold ISO 27001 typically halve the policy-writing effort because policies, internal-audit programmes, and management-review cadences are reusable.
ISO 42001 in the regulatory map: what it does and does not cover
Where ISO 42001 maps onto the EU AI Act
There is significant overlap between ISO 42001’s clauses and the EU AI Act’s provider and deployer duties, particularly on risk management, data governance, technical documentation, post-market monitoring, and human oversight. Independent crosswalks place the overlap at roughly 40 to 50 percent of the Act’s substantive requirements. The harmonised European standards being prepared under mandate M/593 (the prEN 18228 family from CEN-CENELEC) are the formal bridge between the AI Act’s essential requirements and a presumption of conformity; once published, conforming to those harmonised ENs will be the cleanest way to demonstrate Act compliance. Until then, ISO 42001 is the closest mature scaffold.
The five gaps that matter
A certified AIMS does not, on its own, deliver:
- Conformity assessment for high-risk AI systems under Article 43 (internal control or notified-body assessment depending on the use case).
- Prohibited-practice screening under Article 5 (social scoring, untargeted facial-image scraping, certain emotion-recognition uses).
- End-user transparency under Article 50 (disclosure when a person interacts with an AI system or sees AI-generated content).
- Serious-incident reporting under Article 73 to the relevant market-surveillance authority within the prescribed deadlines.
- Fundamental-rights impact assessment for deployers of high-risk AI systems under Article 27, when the deployer is a public body or a private actor providing services of general interest.
An organization can hold a valid ISO 42001 certificate and still be in breach of the Act on any of these axes. The certificate’s value is that it makes the rest of the Act easier to demonstrate; it is not a defence.
NIST AI RMF crosswalk
The NIST AI Risk Management Framework 1.0 and ISO 42001 are designed to interoperate. NIST’s four core functions cross-map cleanly: Govern aligns with Clause 5 and parts of Clause 6; Map aligns with Clauses 4 and 6.1; Measure aligns with Clauses 8 and 9; Manage aligns with Clauses 8 and 10. An organization that has done serious work against the AI RMF can reuse most of the artefacts; the gap is usually the formal AIMS scope statement, the SoA, and the auditable management-review cadence.
Why a certificate is not a defence
Market surveillance authorities under the EU AI Act will not accept “we are ISO 42001 certified” as a substitute for the Act’s specific obligations. They may use the certificate as evidence of a mature governance posture, which softens enforcement when minor noncompliance is found, but the legal duties under the Act remain individually testable. The frame to keep in mind: ISO 42001 is a governance scaffold that makes everything else easier; it is not a finish line.
FAQ
Is ISO 42001 mandatory? No. ISO 42001 is a voluntary international standard. No jurisdiction currently mandates certification. Demand is driven by procurement (large enterprises asking suppliers for it), investor due diligence, and the audit-trail value it offers under regulations like the EU AI Act. Some industries (financial services, healthcare) may add it to vendor questionnaires over the next 18 months, which will turn it into a de-facto requirement for vendors.
How long does ISO 42001 certification take? A realistic preparation timeline is 6 to 12 months for an organization with a low-to-moderate baseline, less if you already hold ISO 27001 and can reuse policies, internal-audit programmes, and management-review cadences. The audit itself runs Stage 1 (one to two days) plus Stage 2 (one to three weeks depending on size). Total elapsed time from kickoff to certificate is therefore typically 8 to 14 months.
Can ISO 27001 certified organizations extend their AIMS scope? Yes, and that is the most common starting path. The two standards share the High-Level Structure, so policies, document control, internal audit, and management review carry over directly. The work to add is the AI-specific risk and impact assessment, the Annex A control set (especially A.5, A.6, A.7), and the model lifecycle gates. Organizations regularly run a single integrated management system covering ISO 27001 and ISO 42001 with a shared management review.
Does ISO 42001 cover generative AI specifically? The standard is technology-neutral, but Annex C explicitly lists risks that apply to generative AI (hallucination, prompt injection vulnerabilities, training-data provenance, intellectual-property concerns). Annex D’s use cases include generative scenarios. Organizations that build or deploy generative AI should expect auditors to pay particular attention to A.7 (data for AI systems) and A.8 (information for interested parties), where generative AI’s transparency obligations bite hardest.
Is ISO 42001 enough for the EU AI Act? No. ISO 42001 covers roughly 40 to 50 percent of the Act’s substantive requirements and provides a strong governance scaffold, but it does not deliver conformity assessment, prohibited-practice screening, end-user transparency, serious-incident reporting, or fundamental-rights impact assessment. The harmonised European standards being prepared under mandate M/593 will be the formal bridge to Act conformity. For now, treat ISO 42001 as the foundation, the Act as the binding obligation, and the harmonised ENs as the future-state alignment.
Who can audit and certify an AIMS? Only certification bodies accredited for ISO 42001 by a recognised national accreditation body (UKAS in the UK, ANAB in the US, COFRAC in France, DAkkS in Germany, ACCREDIA in Italy, ENAC in Spain, IPAC in Portugal). The list of accredited bodies grew rapidly through 2025. Verify that the certification body’s accreditation explicitly covers ISO/IEC 42001, not only ISO/IEC 27001; not every body has extended its scope yet.
Conclusion
ISO 42001 is the first piece of AI governance infrastructure that organizations can actually be certified against, and it is rapidly becoming the lingua franca of AI assurance. Treated as a scaffold, it organises every other AI obligation: it gives the EU AI Act a place to land, it absorbs the NIST AI RMF without conflict, and it forces the company to put names against the AI it owns. Treated as a finish line, it disappoints, because the certificate cannot stand in for the binding-law work that still has to happen in parallel.
At AI Sigil, we treat the AIMS as the operating object: a live system that the platform helps run, not a binder that auditors visit once a year. If you are mapping where ISO 42001 sits next to the EU AI Act in your stack, the companion piece ISO 42001 Won’t Make You EU AI Act Compliant. Here’s the Standards Stack That Will. walks through the bridge in detail. To see how the AI Sigil platform operationalises the AIMS day-to-day, the platform tour is the next stop.