A practitioner-grade reference for the ISO/IEC AI standards ecosystem, centred on ISO/IEC 42001:2023 — the world's first certifiable AI management system standard. Dual-lens: executive strategy and implementer depth, kept separate.
ISO/IEC JTC 1/SC 42 — the joint technical subcommittee for artificial intelligence, established in 2017 under secretariat ANSI and chaired by Wael William Diab — is the standards body behind the entire ecosystem mapped on this page. Five working groups divide the work: WG1 foundational standards, WG2 data, WG3 trustworthiness, WG4 use cases and applications, WG5 computational approaches and characteristics of AI systems. At the 17th plenary in Singapore (April 2026, SC 42's first ASEAN plenary), Singapore's IMDA tabled ISO/IEC 42119-8 — the first proposed GenAI testing standard, covering benchmarking and red-teaming.
The AI Management System (AIMS) standard — the certifiable core of the entire ecosystem. Published 18 December 2023.
AI system impact assessment guidance. Published May 2025, ~39 pages. Guidance only — not certifiable.
Requirements for bodies providing audit and certification of AIMS — supplements ISO/IEC 17021-1 for the AI domain.
AI risk management guidance — extends ISO 31000:2018 principles, framework, and process to AI-specific risk.
Governance implications of AI for the governing body — part of the 38500 IT governance family.
| Standard | Scope |
|---|---|
| TR 24028:2020 | Overview of trustworthiness in AI. |
| TR 24027:2021 | Bias in AI systems and AI-aided decision making. |
| 25059:2023 | AI system quality model — SQuaRE extension; companion TS 25058:2024 quality measurement. |
| 5338:2023 | AI system lifecycle processes. |
| 5259 series | ML data quality — Parts 1-4 published 2024, Part 5 2025, Part 6 (TR) due 2026. |
| TS 4213:2022 | Machine learning classification performance — revision flagged October 2025. |
| 24029 series | Neural network robustness — TR-1:2021 overview, -2:2023 formal methods, DIS-3 statistical methods in development. |
| TS 8200:2024 | Controllability of automated AI systems. |
| 12792:2025 | Transparency taxonomy of AI systems. |
| TS 6254:2025 | Objectives and approaches for explainability of ML models and AI systems. |
| TR 5469:2024 | Functional safety and AI systems. |
Two consequential standards are being developed by SC 27 (security), not SC 42: FDIS 27090 AI security (stage 50.20 as of 23 June 2026, publication expected H2 2026 — covers data poisoning, evasion, model extraction, membership inference, and prompt injection) and DIS 27091 AI privacy (DIS ballot closes February 2026, publication expected late 2026 or 2027). Both are guidance documents, not certifiable.
The ecosystem is a stack, not a menu — 42001 is the certifiable management plane; the technical standards supply the measurable substance auditors and regulators increasingly expect underneath it.
This tab is written for the boardroom, not the audit room — strategic rationale, competitive positioning, and investment framing. Implementation detail lives in Tab 03. Keeping the two lenses separate is deliberate: executives need the "why now," implementers need the "how exactly," and mixing them dilutes both audiences.
ISO/IEC 42001 is the first certifiable AI governance standard — following the SOC 2 procurement-gate trajectory. Microsoft SSPA DPR v12, live 30 March 2026, makes ISO 42001 mandatory for "Sensitive Use" AI suppliers — a concrete commercial trigger, not a hypothetical one.
Scarcity is the differentiator today. BCG described itself as "among the first 100 organizations globally certified" (27 Jan 2026). Follow the ISO 27001 trajectory: while the certified population sits in the hundreds it differentiates; once it reaches thousands, it becomes baseline expectation.
ISO/IEC 38507 gives boards an evaluate–direct–monitor framework for AI. The AIMS integrates into existing governance structures, producing one consolidated risk view instead of a parallel AI reporting line.
Audit-ready evidence — risk management, impact assessment, post-market monitoring, incident handling — supports EU AI Act obligations and underpins a rebuttable presumption of reasonable care under Colorado SB 24-205 → SB 189 (effective 1 January 2027) and Texas TRAIGA (January 2026).
Year-one cost ranges from tens of thousands of dollars (SME, narrow scope, existing ISO 27001) to six figures (enterprise scope). Integrated audits with existing ISO management systems cut audit time and cost by 20-30%.
"Certify now while it is a differentiator, not yet an expectation." Watch for the trigger list: a procurement questionnaire that requires it, EU high-risk exposure, investor due diligence, or a Microsoft supply-chain requirement. Any one of these should move certification from "someday" to "this fiscal year."
| Trigger | Why it matters |
|---|---|
| Procurement Questionnaire Requires It | A customer or prospect's RFP now lists ISO/IEC 42001 as a requirement or scored criterion — the commercial case has arrived, not just the strategic one. |
| EU High-Risk Exposure | Any AI system in scope could fall under EU AI Act high-risk classification — certifying early builds the audit trail before the 2 Aug 2026 deadline pressure hits. |
| Investor Due Diligence | AI governance maturity is increasingly a diligence line item for investors and acquirers — a certificate answers the question before it's asked. |
| Microsoft Supply-Chain Requirement | SSPA DPR v12 makes certification mandatory for "Sensitive Use" AI suppliers — not optional if your organisation falls in that category. |
This tab is deliberately kept separate from the Executive Lens (Tab 02) — it is written for the person building and operating the AIMS, not the person approving the budget for it. ISO/IEC 42001 follows the Annex SL Harmonized Structure shared across ISO management-system standards, so Clauses 4-10 will look familiar to anyone who has implemented ISO 27001 or ISO 9001. The AI-specific weight sits inside those familiar clause numbers.
| Clause | What it requires |
|---|---|
| 4 · Context | Internal and external issues, the regulatory landscape, interested parties, AIMS scope, and — distinctively for 42001 — determination of the organisation's role: developer, provider, user, or producer of the AI system. |
| 5 · Leadership | 5.1 top-management commitment · 5.2 AI policy · 5.3 assignment of roles, responsibilities and authorities. |
| 6 · Planning | 6.1 risks and opportunities · 6.1.2 AI risk assessment · 6.1.3 risk treatment plus a mandatory comparison against Annex A · impact assessment · 6.2 AI objectives · 6.3 planning for change. |
| 7 · Support | 7.1 resources · 7.2 competence · 7.3 awareness · 7.4 communication · 7.5 documented information. |
| 8 · Operation | 8.1 operational planning and control · 8.2 AI risk assessment · 8.3 AI risk treatment · 8.4 AI system impact assessment — the full system lifecycle from design through decommissioning, including bias checks, human-in-the-loop design, and incident response. |
| 9 · Performance Evaluation | 9.1 monitoring, measurement, analysis and evaluation · 9.2 internal audit (9.2.2 requires auditor independence from the activity being audited) · 9.3 management review. |
| 10 · Improvement | 10.1 continual improvement · 10.2 nonconformity and corrective action. |
Clause 4 requires the AIMS to record which role the organisation plays in relation to each AI system in scope — developer, provider, user (deployer), or producer. The role determines which Annex A controls are realistically applicable and which can be justifiably excluded in the Statement of Applicability. Get the role wrong at Clause 4 and the SoA built on it in Clause 6.1.3 inherits the error.
Clause 6.1.3 makes the Annex A comparison mandatory — you cannot skip a control your risk assessment finds inconvenient. Treat every Statement of Applicability exclusion as an evidentiary claim you will have to defend in Stage 2, not a paperwork formality you tidy up before the audit.
Annex A is normative — every control must be considered during risk treatment, and any exclusion must be justified in the Statement of Applicability. Unlike ISO/IEC 27001, Annex A here functions as a reference set selected via the Clause 6.1.3 risk-treatment process rather than a fixed baseline everyone adopts wholesale. Annex B supplies the implementation guidance that auditors reference when testing whether a control is actually operating as designed.
| Objective | Controls |
|---|---|
| A.2 · Policies (3) | A.2.2 AI policy · A.2.3 alignment with other organisational policies · A.2.4 policy review. |
| A.3 · Internal Organisation (2) | A.3.2 roles and responsibilities · A.3.3 concern-reporting process (protected channel). |
| A.4 · Resources (6) | AI system inventory · resource documentation · data resources (provenance and bias) · tooling resources · system and computing resources (including environmental impact) · human resources (diverse expertise). |
| A.5 · Impact Assessment (3) | A.5.2 impact-assessment process · A.5.3 conducting the impact assessment per system · A.5.4 assessing AI system functionality and behaviour. |
| A.6 · System Lifecycle (10 — the largest objective) | A.6.1.1 design and development objectives · A.6.1.2 data for development · development documentation · bias in data · robustness · operational concept · A.6.2.2 verification and validation testing · A.6.2.3 human oversight · A.6.2.4 event logging · A.6.2.5 deployment gate. |
| A.7 · Data for AI Systems (4) | A.7.2 data for development and enhancement · A.7.3 acquisition and provenance · A.7.4 data quality · A.7.5 personal information and data preparation. |
| A.8 · Information for Interested Parties | Disclosure of AI system capabilities and limitations. |
| A.9 · Use of AI Systems | Acceptable-use requirements · intended-use verification · responsible-use practices. |
| A.10 · Third-Party and Customer Relationships | Supplier due diligence · responsibility allocation across the AI supply chain. |
1. Human oversight (A.6.2.3) — auditors demand logs, escalation records, and override evidence. "Rubber-stamp" oversight fails.
2. Data governance and bias (A.6.1.4 + A.7) — the most common gap is a missing bias analysis or no data-lineage trail.
3. Supplier agreements (A.10) — auditors look for three specific provisions: audit rights, incident-notification timelines, and exit/data-return clauses.
Implementation order matters more than most teams assume:
Auditors don't grade your policy prose — they sample operational evidence. If A.6.2.3 human oversight can't produce logs, escalation records, and override evidence on request, the certificate documents intent, not control.
None of the standards below certify anything on their own. They supply the methodology and measurable substance that ISO/IEC 42001's management clauses assume already exists — the "how" behind the AIMS "what."
Mirrors ISO 31000's principles, framework, and process, with AI-specific guidance layered on top. This is the "how" of AI risk assessment inside an AIMS. Organisations already aligned to ISO 31000 can adopt it incrementally rather than building a parallel risk process.
A lifecycle impact-assessment framework covering effects on individuals, groups, and society — including foreseeable applications, not just intended ones. Complements Clause 6.1 and Clause 8.4. Functions as a DPIA-analogue that aligns with EU AI Act expectations. It is internal guidance — there is no external audit against 42005 itself.
Guidance for the governing body on effective, efficient, and acceptable use of AI within the organisation. Ties directly to the accountability structures ISO/IEC 42001 requires at the leadership level.
Part of ISO/IEC 42001 itself, not a separate standard. Supplies the underlying catalogue of AI-specific objectives and risk sources that a Clause 6.1.2 / 23894 risk assessment should draw from — the reference list that keeps a risk register from missing AI-specific categories a generic ISO 31000 process wouldn't surface on its own.
The measurable substance behind the management layer: 25059 quality, 5338 lifecycle, 5259 data quality, 24029 robustness, TS 8200 controllability, 12792 transparency, TS 6254 explainability, TR 24027 bias, TR 24028 trustworthiness — plus the forthcoming FDIS 27090 (security) and DIS 27091 (privacy) from SC 27. Full detail in Tab 01.
23894 tells you how to run AI risk inside an AIMS; 42005 tells you who a system affects and how; 38507 tells the board what good oversight looks like. None of the three is certifiable alone — that is the point. Together they supply the substance a 42001 audit tests against.
The path from a readiness assessment to a live certificate typically runs 4-12 months — and it compresses to 4-6 months for organisations extending an existing ISO 27001 ISMS rather than building an AIMS from a blank page.
| Stage | Duration / cost | What happens |
|---|---|---|
| 1 · Readiness / Gap Analysis | 2 weeks – 3 months · $5k–$15k | Determine scope, organisational role, and build the initial AI system inventory. |
| 2 · AIMS Design & Documentation | 1–3 months | Write the policy, risk and impact-assessment methodologies, Statement of Applicability, and data-governance documentation. |
| 3 · Implementation & Training | 1–4 months | The AIMS must operate for roughly 3 months minimum, including a management review and a full internal-audit cycle, before certification can proceed. |
| 4 · Internal Audit + Management Review | ~1 month | The auditor must be independent of the activity being audited (Clause 9.2.2) — internal staff from another function, or a third party. |
| 5 · Stage 1 — Documentation Review | 1–2 days for small organisations | The certification body reviews documentation for completeness. Fix findings here — it is far cheaper than fixing them after Stage 2. |
| 6 · Stage 2 — Implementation & Effectiveness | 4 days (very small org) to ~30 days (large enterprise) | Operational sampling — auditors test whether controls actually run, not just whether they're documented. Harder to falsify than a paper review. |
| 7 · Certificate, Surveillance, Recertification | 3-year certificate | Annual surveillance audits sample Clauses 8-10 plus selected Annex A controls; full recertification in year 3 or 4. |
Extend the existing ISMS — don't build a parallel system. Roughly 50% of controls are reusable, and the risk register, internal-audit programme, and management review can be shared. Integrated audits save 20-30% versus separate audit cycles, and the implementation timeline compresses from 6-12 months to 4-6 months.
"Documentation without operation" is the single most common failure point in the entire certification path. Stage 2 exists specifically to sample for it — fix the gap between what's written and what's running before your certification body finds it for you.
ISO/IEC 42001 sits alongside — not inside — the binding regulatory frameworks below. It operationalises many of the obligations these laws impose, but "operationalises" is not the same as "satisfies." Know exactly where the certificate helps and where it doesn't.
| Framework | Status & relationship to 42001 |
|---|---|
| EU AI Act | ISO/IEC 42001 is not harmonised — it confers no Article 40 presumption of conformity. The EU AI Office stated (May 2024) that 42001 is not fully aligned with the final Act. prEN 18286 (a QMS standard for Article 17) was in public enquiry 30 October 2025 – 22 January 2026 and is expected, via CEN-CENELEC, to fulfil what 42001 doesn't. High-risk obligations apply from 2 August 2026 (the Digital Omnibus may adjust this — plan against the current deadline until it changes). 42001 operationalises many Act obligations — risk management, post-market monitoring, Article 73 incident reporting, technical documentation. Net: a credibility lift, not a legal shield. |
| NIST AI RMF | An official crosswalk exists, mapping the RMF's 4 functions and 72 subcategories to 42001 clauses and Annex A controls. The overlap is substantial; the differences are structural rather than substantive. The RMF itself is voluntary and non-certifiable. |
| US State Laws | Colorado SB 24-205 → SB 189 (effective 1 January 2027) and Texas TRAIGA (January 2026) both offer a rebuttable presumption of reasonable care, or an affirmative defence, for organisations aligned to ISO 42001 or the NIST AI RMF. |
| Global Adoption | Aligned or reference-standard status across Singapore, Canada, the UK, Japan, Brazil, and Colombia — detail by jurisdiction below. |
Model AI Governance Framework 2.0 is aligned with 42001 and, as of January 2026, is the first published agentic-AI governance framework anywhere in the world.
The Artificial Intelligence and Data Act (AIDA) mirrors the EU's high-risk classification approach.
BSI has adopted BS ISO/IEC 42001 and BS ISO/IEC 42006 directly into the national standards catalogue.
A key early adopter of the standard within the Asia-Pacific certification market.
Brazil's LGPD AI guidance and Colombia both reference ISO/IEC 42001 as a benchmark standard for AI governance maturity.
ISO 42001 is a credibility lift, not a legal shield — it operationalises the obligations regulators check for, but only OJEU-cited harmonised standards, like the forthcoming prEN 18286, confer the EU AI Act's presumption of conformity. Certify for governance maturity and procurement leverage; don't market it as compliance.
Every organisation building an AIMS from scratch is doing unnecessary work if it already runs ISO 27001, 27701, or 9001. The Annex SL Harmonized Structure means Clauses 4-10 occupy identical positions across all four standards — the integration opportunity is structural, not just convenient.
Annex SL gives you a shared management plane, but each standard still demands domain depth. A generic risk register that hasn't been extended with AI-specific fields — bias, drift, provenance, human oversight — won't prove AI-specific control to an auditor, no matter how well it serves ISO 27001.
Annex D gives you the mapping — the discipline is doing the roughly 50% integration work with 27001 properly and still building the other half fresh, not stretching one generic risk register across four standards and calling it done.
A practitioner reference that only sells the standard isn't useful in an audit. These are the limitations worth knowing before you commit budget and credibility to certification.
Certification proves your governance process operates — not that your model is safe, accurate, or fair. The academic "CEDAR-42001" framework has quantified this as a documented "conformity-assurance gap."
Documentation can describe controls that don't actually operate. Stage 2 operational sampling mitigates this risk — it doesn't eliminate it. "Certificate-in-two-weeks" vendors are selling documentation, not a running system.
No presumption of conformity means the full evidentiary burden remains yours if a market-surveillance authority challenges your AI system.
Principle-based flexibility is a feature and a limitation — the standard offers little technical specification, in contrast to prEN 18286 and emerging sector-specific rules. Technical depth has to be imported from the supporting standards (Tab 05).
Auditor experience is still building. Unaccredited certificates circulated early in the market's life — including one "first certified" claim that predated the standard's own publication. Pricing is less predictable than the mature ISO 27001 market.
The ~350 certified organisations figure is a lower bound assembled from certification-body and company announcements — no official public register exists. Costs cited throughout this wiki are industry-reported ranges, not vendor quotes. Annex A sub-numbering varies across secondary sources; treat the purchased ISO/IEC 42001:2023 text as authoritative. One claim was deliberately excluded as unverifiable: "83% of Fortune 500 procurement teams will require ISO 42001 by 2027," attributed to Gartner in trade press but unsubstantiated in any primary source. Regulatory timelines — the Digital Omnibus, US state laws — remain in flux; verify before making date-specific commitments to stakeholders.
The conformity-assurance gap is real: 42001 audits whether your governance process runs, not whether your model is safe, accurate, or fair. Buy the technical depth — 24029 robustness, 24027 bias, 25059 quality — to close that gap. Don't expect the certificate to close it for you.
Twenty-three checkpoints across six groups, plus the five-level maturity ladder that tells you honestly where your organisation sits today. Checkbox state is saved locally in your browser.
Informal policies, no clear ownership. AI governance exists as intent, not practice.
The AIMS is built — policies, risk methodology, SoA all exist — but it has not yet been certified by an accredited third party.
An accredited third-party certification body has issued the certificate — Stage 1 and Stage 2 both passed.
The AIMS operates as one system with ISO 27001, 27701, and/or 9001 — shared risk register, shared internal audit, shared management review.
Living controls, mapped once to the EU AI Act, NIST AI RMF, and relevant state laws — ready to pivot the moment a new regulation lands, because the mapping work is already done.
Map controls once to all frameworks — using the NIST crosswalk as the bridge — so that new regulations become mapping exercises, not rebuilds. Watch two triggers that should force a re-plan: an OJEU citation of prEN 18286, or a confirmed change to the 2 August 2026 high-risk deadline.