WARRANTWhat ISO/IEC 42001 is.
One sentence. The whole of 42001 follows from it. 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 the context of an organization 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.4 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 establishes the AI system impact assessment, which has no direct analogue in 27001. ISO spells that term out; AISIA is this register's abbreviation for it, not the standard's vocabulary — no public ISO text uses the acronym. The impact assessment 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, or both, and societies is deliberate. The aperture is wider than the data protection impact assessment under Article 35 of Regulation (EU) 2016/679, and wider than the fundamental rights impact assessment for high-risk AI systems under Article 27 of Regulation (EU) 2024/1689. A data protection 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 impact-assessment process becomes a standing obligation. § 6.1.4 establishes the process; § 8.4 requires the assessment itself to be performed at planned intervals and when significant changes are proposed or occur, with documented results retained. The Annex A controls in the A.5 group carry it: A.5.2 (AI system impact assessment process), A.5.3 (documentation of AI system impact assessments), A.5.4 (assessing AI system impact on individuals or groups of individuals), A.5.5 (assessing societal impacts of AI systems). The auditor reads them together. A documented process that runs once at system launch and never again does not satisfy § 8.4. The standard frames the impact assessment 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. It has four sub-clauses: § 8.1 operational planning and control, § 8.2 AI risk assessment, § 8.3 AI risk treatment, § 8.4 AI system impact assessment. The last three are the operational counterparts of the three planning processes under § 6.1: § 8.2 runs the risk assessment established under § 6.1.2, § 8.3 binds the organisation to implement the risk-treatment plan it produced under § 6.1.3, and § 8.4 binds it to perform the impact assessment against the process it established under § 6.1.4.
The obligation is mandatory drafting. Shall in ISO style is a requirement, distinct from should (recommendation) and may (permission) — the convention is set out in the ISO/IEC Directives Part 2, not in 42001 itself. 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 recording of event logs. Read together, the three controls describe the per-decision evidence layer the standard expects. An AI agent making decisions in production produces event-log records (A.6.2.8), backed by technical documentation (A.6.2.7), monitored under A.6.2.6, all flowing into the § 8.3 risk-treatment loop and the § 8.4 impact assessment.
The Warrant evidence record is shaped to produce part of this evidence layer, and it is worth being exact about which part. The record identifies the regulatory perimeter — the domain, the jurisdictions, the regimes engaged, a risk tier and the stated reason for that tier. It then carries one row per agent action, naming the actor, the action and the subject under a stable action id. Against each of those actions it carries an authorisation judgement across four conditions — within purpose, preconditions met, human oversight appropriate, reversible — with a written justification, which is the operational expression of § 8.3 risk treatment. Each action is then bound to the specific clauses of 42001 and of every other regime engaged, one row per clause, each carrying a compliance status of satisfied, gap, uncertain or unvalidated. The result is the per-decision record an internal audit under § 9.2 reads to confirm operation against plan. It is not the whole of the A.6.2.8 evidence: determining which of the organisation's events matter, and retaining them, remains the organisation's own work.
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 recording of event logs. Neither is optional once the Statement of Applicability declares it applicable — that is a property of how an SoA works, not a reading of either control. Between them the two titles cover the audit trail the certification body, the supervisor, and any downstream regulator will ask to see.
Read as a title, A.6.2.8 is broader than application 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. What the control normatively requires is a separate question, and this register cannot answer it: the control text and its Annex B implementation guidance sit behind the ISO paywall, are not quoted here, and are not paraphrased here either. The published title — AI system recording of event logs — is the whole of what is publicly checkable. Secondary summaries of the control circulate widely and disagree with each other; none of them is the standard, and none is reproduced here. An organisation that needs to know what the control obliges buys the text.
Control A.6.2.7 is the technical-documentation companion; its normative text and its Annex B implementation guidance are paywalled on the same terms, and are likewise neither quoted nor paraphrased here. What follows is this register's own reading of what a documentation pack has to contain to survive an audit, not a rendering of the control: technical documentation maintained across the lifecycle — requirements, design, verification and validation, deployment, monitoring — that an interested party can read to understand what the AI system does, how it was built, and how it is operated. 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 is one input to A.6.2.8, not a substitute for it. Each action the agent takes produces a row naming the actor, the action and the subject under a stable action id, and against that row an authorisation judgement across four conditions — within purpose, preconditions met, human oversight appropriate, reversible — with a written justification. Each row is bound to specific clauses of the regimes engaged, and the package is independently verifiable without contacting Warrant. What the record does not do is decide which of the organisation's events matter, or set a retention period; those determinations stay with the AIMS owner, wherever the control text lands on them. For a 42001 audit, the per-decision record is the part of the event-log evidence that concerns the agent's own decisions, and no more than that.
The A.6.2.7 contribution is narrower and more precise. The package records the configuration that produced the verdict: the model used at each of the four analysis stages, a digest over those model identifiers and the prompt text behind them, and a digest of the regulation corpus the mapping was made against. All three sit inside the signed bytes, so an auditor can confirm a given decision was produced under a stated configuration rather than an assumed one. Drift between deployed configuration and documented configuration is a common A.6.2.7 finding, and a configuration digest bound into the record makes that drift checkable instead of asserted. The organisation's own technical documentation pack — intended purpose, architecture, data sources, performance characteristics, risks identified, controls applied — is the AIMS owner's to produce; Warrant does not produce it.
The published specimen below is not a 42001 package, and it is worth saying so plainly. Package 7de85ceaeac42a47 was generated from a Frankfurt bank lending trace; the clauses bound in it are EU AI Act Article 12 and Article 13 and FCA Principle 12, and 42001 is not among the regimes it cites. It is linked here because the shape is the point — one row per action, an authorisation judgement against each row, a clause binding per row, a configuration digest inside the signed bytes — not because it evidences anything under this standard. Nor could a package bind A.6.2.7 or A.6.2.8 by id: Warrant's corpus records 42001 at the clause and Annex-A-group level, so the most specific 42001 id the pipeline can emit for these two controls is the group iso_42001.annex_a.A.6.
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 (C(2023)3215) and amended by C(2025)3871 of 23 June 2025, names ten standardisation deliverables 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 are enacted text with obligations set out in the instrument itself, and a management-system standard certifies that an organisation runs a system, not that a given system meets a given article. 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 recording of event logs plus A.6.2.6 operation and monitoring are the conceptual ancestors of EU AI Act Article 12 record-keeping 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 frames the AI system impact assessment around impacts on individuals, groups of individuals, or both, and societies (§ 3.24), 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 clause, what an auditor asks it to show, and the field of the signed evidence package that carries the relevant record. The field names are read from the two published wire-level contracts, warrant-v1-evidence.schema.json (the signed evidence package) and warrant-v1-receipt.schema.json (the response envelope), both v0.2, and are the actual names rather than descriptions of them. The granularity is the clause, because that is the granularity at which Warrant's regulation corpus records 42001 — nineteen clauses from § 4.1 to § 10.2 plus six Annex A groups, not per-control ids like A.6.2.8.
| 42001 clause | What the auditor asks it to show | Field · package unless marked receipt |
|---|---|---|
| § 8.2 · AI risk assessment | A risk assessment performed, with a stated basis. | classification.risk_tier · classification.risk_tier_justification |
| § 8.3 · AI risk treatment | The treatment plan operating, action by action. | authorizations[].within_purpose · preconditions_met · human_oversight_appropriate · reversible · justification |
| Annex A.6 · AI system life cycle | The agent's actions recorded as they occurred. | actions[].action_id · actor · action · subject |
| Annex A.9 · use of AI systems | The system used only for its intended purpose. | authorizations[].within_purpose |
| Any cited clause | Which clauses each action engages, and whether it meets them. | obligations[action_id][].id · compliance · evidence · confidence |
| Clause coverage | Which regimes were considered, and which were not yet in force. | coverage_by_regime · deferred_regimes |
| § 9.2 · internal audit | Which text and which configuration produced the verdict. | trace_metadata.regulations_corpus_sha256 · receipt: pipeline_config_sha256, pipeline_models |
The mapping is reversible. Given an auditor's question on a clause, the organisation reads the row, retrieves the field, and produces the per-decision record. Given a decision under examination, it reads the record and produces the bound clauses. Either direction is one query against the package, and the package is independently verifiable without contacting Warrant.
What the table deliberately does not claim matters as much as what it does. Warrant does not produce an AI system impact assessment, a Statement of Applicability, a resource register under A.4.2, or an incident-communication trail under A.8.4. Those are organisation-level artefacts and they belong to the AIMS owner. The package is per-action evidence about what an agent did and whether it was authorised to do it. It is a component of a 42001 audit file, not the audit file.
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 TR 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 TR 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 42005:2025 · AI system impact assessment
- 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
- Warrant regulator index · the regimes we map evidence against
Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on standards text. Not legal advice. Two passages are quoted: the § 1 Scope sentence and the § 3.24 definition, both from the publicly available text of ISO/IEC 42001:2023 on the ISO Online Browsing Platform, read 2026-08-06. Everything else said here about a clause or an Annex A control is drawn from the standard's published table of contents and control titles — the normative body, Annex A and Annex B are behind the ISO paywall and are neither quoted nor paraphrased. Where this entry describes what a control means in operation, in particular A.6.2.7 and A.6.2.8, that is this register's reading and is marked as such at the point it is made; it is not a rendering of the control text. Package 7de85ceaeac42a47, linked in § 06, is a Frankfurt lending specimen binding EU AI Act Article 12 and Article 13 and FCA Principle 12; it cites no ISO/IEC 42001 clause and is shown for shape only. Corrected 2026-08-06; further corrected 2026-08-07.