WARRANTWhat ISO/IEC 42001 is.
Twenty-one words. The whole of 42001 follows from that one sentence. The standard is not a checklist of AI safety properties; it is a management-system standard, in the same sense that ISO 27001 is a management-system standard for information security and ISO 9001 is a management-system standard for quality. The thing being certified is not the AI; it is the organisation's ability to manage the AI, continuously, across its lifecycle, with documented evidence at every stage.
The choice of the word establishing is operative. Before the AIMS exists at all, the organisation has to have set its boundaries (clause 4), assigned the leadership (clause 5), planned the risk treatment (clause 6), and built the support infrastructure (clause 7). The choice of continually improving is equally operative. The AIMS is not a one-time deliverable; it is a Plan-Do-Check-Act loop the organisation runs forever, with the supervisor or the certification body re-entering on a fixed surveillance cadence to confirm the loop is still running.
The phrase within organizations matters. 42001 binds an organisation, not a model. A frontier-lab provider that trains a model and ships it to a deployer cannot certify the model under 42001; it certifies the organisation that produces the model, on the scope statement that names which AI systems and which lifecycle stages are inside the certified perimeter. A deployer that consumes the model and operates an agent on top of it certifies the organisation that operates the agent, on its own scope. The certificate names an organisation, a scope, and a date. It does not name a model.
The pattern is familiar to anyone who has read ISO 27001. The high-level structure ISO uses across all management-system standards (Annex SL HLS) is the same. Clause numbers map: clause 4 in 42001 reads almost identically in shape to clause 4 in 27001. The auditor's questions follow the same arc. The thing that is new in 42001 is what fills the AI-specific clauses (§ 6.1.4 AI risk and impact assessment, § 8.3 AI system impact assessment in operation) and what fills Annex A (the 38 controls covering the AI lifecycle).
The seven clauses any management system has.
The Annex SL high-level structure organises every modern ISO management-system standard into seven operative clauses. Reading the structure once is reading every standard once. The clause numbers and names in 42001 are identical to those in 27001, 9001, 14001, 22301, and 50001; what changes is the AI-specific text inside each clause. For an AI deployer, naming what evidence each clause demands is the difference between a defensible AIMS and a paper one.
The seven clauses are not isolated. The auditor reads them as a loop. Context (4) drives leadership (5). Leadership (5) authorises planning (6). Planning (6) becomes operation (8) backed by support (7). Operation (8) produces data that performance evaluation (9) reviews. Performance evaluation (9) feeds improvement (10), which loops back into planning (6). An AIMS that documents each clause but cannot show the loop is documentation, not a system. The certification body looks for the loop.
The AI system impact assessment obligation.
Clause 6 is where 42001 starts to depart materially from 27001. § 6.1.2 sets the AI risk assessment process; § 6.1.3 sets the AI risk treatment process; § 6.1.4 introduces the AI System Impact Assessment, AISIA, which has no direct analogue in 27001. The AISIA is the AI-specific obligation that distinguishes a 42001 audit from a 27001 audit on the same organisation.
The drafting choice in individuals, groups of individuals, and societies is deliberate. The AISIA is broader than a privacy impact assessment under GDPR Article 35, broader than a data protection impact assessment under the UK GDPR equivalent, and broader than the fundamental-rights impact assessment under EU AI Act Article 27. A privacy impact assessment looks at data subjects; the AISIA looks at affected populations whether or not they are data subjects. A society-level impact (labour-market displacement, democratic-process effects, environmental cost) is in scope where it can reasonably be anticipated.
The AISIA process becomes a standing obligation. § 6.1.4 is paired with the operational equivalent in § 8.3 and with the Annex A controls A.5.2 (process), A.5.3 (documentation), and A.5.4 (ongoing impact assessment). The auditor reads the four together. A documented AISIA process that runs once at system launch and never again does not satisfy A.5.4. The standard frames AISIA as a continuing obligation, not a launch deliverable.
What goes into a defensible AISIA. The standard does not prescribe a template, but the audit-ready shape includes a description of the AI system and its intended use, the categories of affected individuals and the categories of affected populations, the impact dimensions considered (safety, fairness, transparency, controllability, environmental cost, societal implication), the methodology used to assess each dimension, the residual impact accepted by the organisation, and the trigger conditions that would cause the AISIA to be re-run. The organisation that can hand the auditor an AISIA in this shape, signed by a named owner, with version history, has the cleanest path to certification.
The AISIA also matters outside 42001. The EU AI Act Annex IV technical documentation will, on the harmonisation roadmap, accept a 42001-aligned AISIA as a meaningful component of the conformity assessment. A high-risk AI system provider that runs an AISIA under § 6.1.4 in 2026 is producing documentation that will travel into 2027 EU AI Act audits with minimal rework. The same artefact carries weight in FCA Consumer Duty supervision, in MAS AI risk management examinations, and in Singapore IMDA model AI governance reviews. Building the AISIA once, in the 42001 shape, is one of the highest-return decisions a deployer makes.
The per-decision evidence layer.
Clause 8 is where the planning artefacts under clause 6 meet the AI agent in production. § 8.2 sets the AI risk treatment obligation in operation; § 8.3 sets the AI system impact assessment in operation. The two clauses are paired: § 8.2 binds the organisation to run the risk-treatment plan it produced under § 6.1.3; § 8.3 binds the organisation to run the AISIA it produced under § 6.1.4.
Three words of obligation. Shall implement is mandatory drafting in ISO style, distinct from should (recommended) and may (permitted). The auditor reads shall as a finding-or-pass test. Where the organisation has a risk treatment plan and cannot show the controls are operating in production, the audit produces a major nonconformity. Where the controls are operating but undocumented, the audit produces a minor nonconformity. Either result blocks first-time certification until remediated.
The Annex A controls in A.6.2 are how clause 8 binds to the operational layer. A.6.2.6 covers operation and monitoring; A.6.2.7 covers technical documentation; A.6.2.8 covers AI system records of events. Read together, the three controls describe the per-decision evidence layer the standard expects. An AI agent making decisions in production produces records of events (A.6.2.8), backed by technical documentation (A.6.2.7), monitored under A.6.2.6, all flowing into the § 8.2 risk-treatment loop and the § 8.3 ongoing AISIA.
The Warrant evidence record is shaped to produce exactly this evidence layer. It identifies the AI system and the regulatory perimeter (which lifecycle stage, which jurisdictions, which interested parties); captures the per-action subject, inputs, outputs, and timestamps (the records of events under A.6.2.8); carries a per-action authorisation envelope (within purpose, preconditions met, human oversight appropriate, reversible, justification) · the operational expression of § 8.2 risk treatment; and binds each action to the specific 42001 controls and any other regimes engaged. The result is the per-decision evidence record an internal audit under § 9.2 reads to confirm operation against plan.
The operational backbone, nine categories.
Annex A of ISO/IEC 42001 holds 38 controls organised across nine categories (A.2 through A.10). Each control is named, scoped, and accompanied by an implementation guidance entry in the companion Annex B. Annex A is normative when applied; the organisation declares which controls are applicable in its Statement of Applicability and the auditor inspects against that statement. Excluded controls require justification.
Reading Annex A as a whole, the standard treats AI as a lifecycle that produces and consumes evidence at every stage. Policy (A.2) authorises roles (A.3) which deploy resources (A.4) into impact assessment (A.5) and lifecycle execution (A.6) on data (A.7) with information out to interested parties (A.8) and use-context constraints (A.9) and supplier-customer responsibility allocation (A.10). The auditor's trace through Annex A is in that order. Skip a category and the trace breaks.
The Statement of Applicability is the artefact that pulls Annex A together. It names every control, declares applicable or not applicable, justifies exclusions, and records the implementation status (planned, in place, fully implemented). The SoA is the primary document the certification body inspects on Stage 1; a thin or hand-waved SoA is the most common reason organisations fail Stage 1 readiness review.
The two controls that build the audit trail.
Among the 38 controls, two carry disproportionate weight for organisations deploying AI agents. Control A.6.2.7 covers technical documentation; control A.6.2.8 covers AI system records of events. Both are mandatory once applied (almost every deployer applies them). The two controls together describe the audit trail the certification body, the supervisor, and any downstream regulator will inspect.
The drafting choice in records of events is broader than logging. Application logs are events; so are model-version changes, prompt-template revisions, dataset refresh actions, deployment promotions, incident notifications, customer escalations, and human-oversight interventions. A.6.2.8 binds the organisation to determine which events matter (the determination is itself documented), to ensure the AI system generates the records, and to retain them for a duration suitable to the system's risk class. The auditor inspects the determination, the generation, and the retention; deficiency in any of the three is a finding.
Control A.6.2.7 is the technical-documentation companion. The organisation produces and maintains technical documentation across the lifecycle (requirements, design, V&V, deployment, monitoring) that an interested party can read to understand what the AI system does, how it was built, and how it is operated. The Annex B implementation guidance suggests technical documentation include the intended purpose, the architecture, the data sources, the performance characteristics, the risks identified, and the controls applied. A.6.2.7 is the EU AI Act Annex IV cousin; the same artefact will satisfy both regimes if drafted once for the more demanding of the two.
Warrant's per-decision evidence record maps directly to A.6.2.8 records of events. Each decision the agent makes produces a record covering actor, action, subject, inputs, outputs, timestamps, and the human-oversight conditions that fired or should have fired. Each record is mapped to a specific EU AI Act obligation and is independently verifiable without contacting Warrant. The retention obligation is satisfied independently of the organisation's standard observability stack: the record stays verifiable across every rotation of the underlying log infrastructure. For a 42001 audit, the per-decision record is the A.6.2.8 evidence the organisation hands the auditor.
The pointer to A.6.2.7 technical documentation lives in the same artefact. Each per-decision record references the technical-documentation set in force at the moment of the decision (model version, prompt template, system architecture). The auditor reads the pointer, retrieves the technical documentation pack, and confirms the decision was made under the documented configuration. Drift between deployed configuration and documented configuration is the most common A.6.2.7 finding; binding the pointer into the per-decision record makes the drift auditable instead of theoretical.
Why 42001 is the harmonisation backbone.
The European Commission and CEN-CENELEC JTC 21 are working on harmonised European standards (hENs) for the EU AI Act. The standardisation request from the Commission to CEN-CENELEC, dated 22 May 2023 and revised in 2024, names ten standardisation topics including risk management, data governance, transparency, human oversight, accuracy, robustness, cybersecurity, quality management, conformity assessment, and post-market monitoring. ISO/IEC 42001 was published while the JTC 21 work was already in flight; the alignment is structural, not coincidental.
The expected mechanism is presumption of conformity. Under EU New Legislative Framework practice, a manufacturer that complies with a harmonised standard is presumed to comply with the corresponding regulation. For the EU AI Act, a high-risk AI system provider that holds a 42001 certificate, with a scope statement that covers the AI system in question, will be able to point at the certificate to discharge a portion of the Article 9 (risk management), Article 10 (data and data governance), Article 11 (technical documentation), Article 12 (record-keeping), Article 13 (transparency), and Article 17 (quality management system) obligations. Not the whole of any one article; the AI Act articles each carry obligations the standard does not fully cover (Article 12 logging is more prescriptive than A.6.2.8, for example). But a defensible portion.
The shape of the convergence matters for organisations building evidence in 2026. An AISIA (§ 6.1.4) drafted in the 42001 shape is closer in form to the EU AI Act Article 27 fundamental rights impact assessment than any other available template. A.6.2.7 technical documentation is closer in form to EU AI Act Annex IV than any other available checklist. A.6.2.8 records of events plus A.6.2.6 operation and monitoring are the conceptual ancestors of EU AI Act Article 12 logging plus Article 72 post-market monitoring. The organisation that builds the 42001-aligned evidence in 2026 inherits a head start on the EU AI Act regulator-evidence in 2027.
The remaining gap is the conformity assessment route. The EU AI Act requires conformity assessment for high-risk systems, with notified bodies for some classes and self-assessment for others. 42001 certification is third-party certification under the IAF MLA, not EU notified-body assessment under the AI Act. A 42001 certificate from an IAF-MLA accredited body is not, on its own, an AI Act conformity assessment certificate. Once the harmonised standards land and the European Commission publishes the corresponding Official Journal references, the route may collapse to a single audit; until then, organisations need both.
Where the two regimes diverge.
42001 and the EU AI Act share a great deal of conceptual surface, but they are not the same instrument and neither substitutes for the other. The differences land in four places: legal status, scope, risk framing, and certification route.
The risk framing diverges at the AISIA. ISO/IEC 42001 § 6.1.4 frames AI system impact assessment around individuals, groups of individuals, and societies, which captures a wide societal aperture (labour displacement, environmental cost, democratic process). EU AI Act Article 9 risk management is narrower, focused on health, safety, and fundamental rights, with Article 27 fundamental rights impact assessment as the dedicated rights-focused instrument. The 42001 AISIA is broader; the AI Act risk management is more legally crisp. An organisation running both can use the AISIA as the upstream artefact and refine the AI Act-specific instruments downstream.
The certification route diverges fully. 42001 is third-party certification under accredited bodies. EU AI Act conformity assessment runs through notified bodies designated by EU member-state authorities, with conformity assessment procedures defined per Annex III category. A 42001 certificate from BSI, DNV, TÜV, or another accredited body is not, in 2026, a substitute for an AI Act conformity assessment notified-body certificate. The two will likely co-exist for years; treating them as interchangeable is a category error.
The practical consequence for an organisation deploying AI agents into the EU market in 2026: the 42001 certificate is the demonstration of organisational AIMS maturity, useful to procurement, supervisors, and harmonisation tooling. The AI Act conformity assessment is the gate to placing a high-risk AI system on the EU market. Skipping 42001 is a procurement risk; skipping the AI Act conformity assessment is a market-access blocker. The two are complementary, sequenced, and both required for a serious enterprise rollout.
The control-to-field map.
The table below names the 42001 control, the evidence the AI agent must produce per action, and the Warrant evidence field that carries the record into the per-decision evidence package. The mapping is the shape an organisation hands to the certification body without further engineering.
| 42001 control | What evidence must show | Warrant evidence field |
|---|---|---|
| A.5.2 · AISIA process | Impact-assessment trail per system class. | metadata.aisia_reference |
| A.5.4 · ongoing impact | Per-decision residual-risk record. | trace.actions[].residual_risk_check |
| A.6.2.7 · technical docs | Provider-deployer interpretive layer. | regulator_evidence.tech_documentation_pointer |
| A.6.2.8 · records of events | Per-decision audit trail. | trace.actions[].decision_rationale |
| A.8.4 · incident comm | Post-incident regulator notice trail. | metadata.incident_disclosure_chain |
| A.9.2 · responsible use | Use-context check per decision. | assess.use_context_in_scope |
| § 6.1.4 · AISIA | System-level impact assessment. | classification.aisia_summary |
| § 8.2 · risk treatment | Authorisation envelope per action. | assess.authorization_envelope |
| § 9.1 · monitoring | Cohort outcomes review trail. | regulator_evidence.cohort_monitoring_report |
| A.10.2 · responsibility | Provider-deployer responsibility split. | classification.party_responsibility_map |
The mapping is reversible. Given an auditor's question on a specific control, the organisation reads the column, retrieves the field, and produces the per-decision record. Given a specific decision under examination, the organisation reads the per-decision record and produces the bound controls. Either direction is one query against the evidence package. The record is mapped to a specific EU AI Act obligation, and it is independently verifiable without contacting Warrant.
Three audit stages, three-year cycle.
Certification against ISO/IEC 42001 runs through accredited certification bodies operating under the International Accreditation Forum Multilateral Recognition Arrangement (IAF MLA). The bodies hold accreditation from a national accreditation body (UKAS, ANAB, DAkkS, JAB, ENAC, and equivalents). The IAF MLA is what lets a certificate issued in one jurisdiction carry weight in another; without it, a UK certificate would not satisfy a US procurement gate, and vice versa.
The certification timeline runs longer than most organisations expect. From a cold start (no AIMS in place) to a stage-2 pass typically runs nine to fifteen months. The three big consumers of time are the AISIA, the Annex A control implementation (especially A.6.2.7 technical documentation across multiple AI systems), and the internal-audit cycle under § 9.2 (which requires at least one full internal-audit pass before the external auditor will run stage 2). Organisations starting in May 2026 with a procurement gate at end of 2026 are tight; organisations starting now with a procurement gate at mid 2027 are comfortable.
The buyer-facing weight of the certificate is changing fast. In 2024 a 42001 certificate was a differentiator in enterprise procurement. In 2025 it became table stakes for AI vendors selling into financial services, healthcare, and public sector. In 2026 it is appearing as a procurement gate in the standard contractual templates of major enterprise buyers, alongside ISO 27001 and SOC 2. For SaaS providers selling into regulated buyers, the 42001 certificate is becoming a procurement gate. The cost of the audit (typically £40,000 to £200,000 depending on organisation size and AIMS scope) is small relative to the opportunity cost of failing a procurement gate.
The companion standards that travel with 42001.
ISO/IEC 42001 sits inside a wider family of AI standards published or in development under ISO/IEC JTC 1 Subcommittee 42 (Artificial Intelligence). Reading 42001 in isolation gives the audit map; reading it against the family gives the conceptual map. The companion standards are largely informative or guidance-oriented, not certifiable, but the auditor will read 42001 against them when the implementation guidance in Annex B leaves a question open.
- ISO/IEC 23894:2023 · AI risk management. Guidance standard that sits alongside § 6.1 of 42001. Names risk identification, analysis, evaluation, and treatment processes for AI systems. Most organisations adopt 23894 as the methodology backing the § 6.1.2 risk assessment.
- ISO/IEC 24028:2020 · Overview of trustworthiness in artificial intelligence. Informative standard naming the trustworthiness properties (transparency, explainability, controllability, robustness, safety, privacy, fairness). The conceptual ancestor of the AISIA dimensions in § 6.1.4.
- ISO/IEC 23053:2022 · Framework for AI systems using machine learning. Informative standard that names the components of a machine learning system. Useful when the AIMS scope includes ML-based systems and the auditor wants a shared vocabulary.
- ISO/IEC 5338:2023 · AI system life cycle processes. Specifies processes across the AI system lifecycle. The lifecycle stages in 5338 align with the lifecycle controls in 42001 Annex A.6, and many organisations adopt 5338 as the lifecycle-process backbone behind A.6 implementation.
- ISO/IEC 42005:2025 · AI system impact assessment guidance. Recently published guidance on conducting the AISIA introduced in 42001 § 6.1.4. The practical complement to the obligation, with worked methodology.
- ISO/IEC 25059:2023 · Quality model for AI systems. Defines the quality characteristics for AI systems (functional adequacy, user controllability, transparency, robustness, intervenability, accountability, societal and ethical risk mitigation). Useful for the verification and validation control under A.6.2.4.
The relationship between the standards is not symmetric. 42001 is the only certifiable instrument; the others are guidance. An organisation that wants a certificate certifies against 42001, with the others sitting alongside as the methodology backing each clause. An auditor who finds an organisation has implemented 42001 without reading 23894, 24028, or 5338 will not raise a finding for that alone, but will be sceptical of the depth of the implementation; the AI-specific clauses are too thin in 42001 itself to defend without the family.
For Warrant readers, the family map matters because the per-decision evidence shape the standards converge on is the same. 23894 risk treatment plus 24028 trustworthiness properties plus 5338 lifecycle processes plus 42001 management system clauses all reach the same conclusion: a defensible AI deployment produces per-decision evidence that names the action, the inputs, the rationale, the controls in operation, the human oversight in place, and the residual risk accepted. The per-decision record is the artefact that carries that evidence across all of them, each one mapped to a specific obligation and independently verifiable without contacting Warrant.
Questions a CISO and an AIMS owner ask first.
Read the source directly.
- ISO/IEC 42001:2023 · Information technology · Artificial intelligence · Management system (ISO Store)
- ISO/IEC 23894:2023 · AI risk management guidance
- ISO/IEC 24028:2020 · Overview of trustworthiness in AI
- ISO/IEC 23053:2022 · Framework for AI systems using machine learning
- ISO/IEC 5338:2023 · AI system life cycle processes
- ISO/IEC JTC 1/SC 42 · Artificial Intelligence subcommittee
- Regulation (EU) 2024/1689 · the EU AI Act
- CEN-CENELEC JTC 21 · harmonised European standards for the AI Act
- International Accreditation Forum · IAF MLA registry
- Per-control Warrant evidence field mapping
Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on standards text. Not legal advice. The verbatim quotations of ISO/IEC 42001:2023 § 1, § 6.1.4, § 8.2, A.6.2.8 reflect the standard text in force on 9 May 2026.