How ISO/IEC 23894 Feeds Into an ISO 42001 Management System

Buyers regularly ask whether they should adopt ISO/IEC 23894 or ISO/IEC 42001, as though it were a choice. It is not. One tells you what an AI management system must contain; the other tells you how to do the risk part of it. Only one of them can be certified against, and the reason is in the grammar of the documents.

Requirements versus guidance

ISO documents divide into those that state requirements and those that give guidance, and the split is visible in the verbs. A requirements standard uses “shall”: the organisation shall determine, the organisation shall document. A guidance standard uses “should”. You can be audited against “shall” because there is a fact of the matter about whether you did it. You cannot be audited against “should” in the same way, because departing from it is permitted.

ISO/IEC 42001:2023 is a management system standard with requirements. ISO/IEC 23894:2023, “Information technology — Artificial intelligence — Guidance on risk management”, is guidance. That is why certification bodies certify against the first and nobody certifies against the second, and why a vendor claiming to be “23894 certified” is telling you something about their understanding rather than about their risk process. The same relationship holds one level up: ISO 31000, the general risk management standard 23894 is built on, is also guidance and also not certifiable.

What is actually in 23894

23894 follows the structure of ISO 31000:2018 — principles, framework, process — and then adds the AI content that the general standard cannot have. Its main body walks the risk management process: establishing scope and context, risk identification, analysis, evaluation, treatment, and the surrounding activities of communication, consultation, monitoring, review and recording.

The annexes are the part worth reading first. One sets out objectives an organisation may hold in relation to AI — fairness, transparency and explainability, robustness, privacy, safety, security, accountability, maintainability, availability — because a risk is only definable against an objective. Another catalogues sources of risk specific to AI systems: the level of automation, the opacity of the system, machine learning characteristics such as data quality and drift, hardware issues, the complexity of the system life cycle, and technology readiness. A third maps the risk management process onto the AI system life cycle so that you can see which activity belongs at which stage.

The risk-source catalogue is the single most practically useful thing in the document, and it is what most homegrown AI risk registers are missing. Registers written from scratch tend to contain the harms people have read about and omit the boring structural sources — drift, life-cycle complexity, the maturity of the components — that actually generate incidents.

The 42001 clauses it feeds

42001 requires a risk process but is deliberately thin on how to run one. Three of its clauses are where 23894 lands.

• Clause 6.1.2, AI risk assessment. 42001 requires the organisation to define and apply a process that establishes risk criteria, identifies risks, analyses and evaluates them, and produces comparable, valid and reproducible results. It does not tell you what the criteria are or where to look for risks. 23894’s process clause and its risk-source annex are a direct answer to both.
• Clause 6.1.3, AI risk treatment. 42001 requires treatment options to be selected, controls determined, those compared against Annex A, and a Statement of Applicability produced. 23894’s treatment guidance supplies the reasoning that gets recorded in that document — and the Statement of Applicability is the artefact an auditor reads first.
• Clause 6.1.4, AI system impact assessment. This is the requirement with no counterpart in older management system standards: an assessment of consequences for individuals and society, not only for the organisation. 23894 informs it, but the dedicated document is ISO/IEC 42005 on AI system impact assessment.

The distinction between 6.1.2 and 6.1.4 is the one to internalise. Risk assessment asks what could go wrong for you; impact assessment asks what could go wrong for everyone else. An implementation that answers the first twice and the second never is the most common way to fail this part of the standard, and it is the same conceptual gap that the AI Act’s fundamental rights impact assessment exists to close in the regulatory setting.

Where the rest of the family fits

SC 42 has produced a set of documents that fit together, and knowing the shape saves buying the wrong one.

• ISO/IEC 22989 — concepts and terminology. The vocabulary the others use.
• ISO/IEC 23053 — a framework for AI systems using machine learning. Descriptive rather than normative.
• ISO/IEC 23894 — risk management guidance.
• ISO/IEC 42001 — the certifiable management system.
• ISO/IEC 42005 — AI system impact assessment.
• ISO/IEC 42006 — requirements for bodies auditing and certifying AI management systems. Not for you; for your auditor’s auditor.

Only 42001 produces a certificate. Everything else in that list produces competence, and competence is what the certificate is supposed to be evidence of.

What this means when you implement

Practically, the sequence that works is: use 23894 to build the risk process and populate the register, use 42005 to structure the impact assessments the register triggers, and use 42001 to hold the whole thing together as a management system with a policy, objectives, internal audit, management review and improvement. Starting from 42001 alone produces a management system wrapped around a risk process nobody designed, which passes a documentary review and falls over the first time somebody asks how a specific risk was scored.

It is also worth being clear about what none of these standards do. They do not tell you whether your model is accurate enough, they do not supply thresholds, and they do not confer any presumption of conformity with the EU AI Act, whose Article 40 presumption attaches only to European harmonised standards cited in the Official Journal. If you want a second framework for the measurement side specifically, the NIST AI RMF’s Measure function is more concrete about what to produce than either ISO document is, and the two vocabularies map onto each other without much friction.