ISO/IEC 23894: ISO/IEC 23894 – Tutorial (about 60 minutes)

ISO/IEC 23894 is the international guidance standard for managing the risks that come with artificial intelligence (AI). It takes the general risk management approach of ISO 31000 and explains what changes when the thing you are managing learns from data, behaves probabilistically and may drift after it goes live. It is used by organisations that build AI, buy AI-based products, or put AI into their own services, and by the risk, compliance, data science and product people who work in them. After this tutorial you will be able to explain what the standard covers, walk through its principles, framework and process, identify AI-specific sources of risk, and apply the guidance to a real AI system from idea to retirement.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current and only edition is ISO/IEC 23894:2023, Information technology — Artificial intelligence — Guidance on risk management, Edition 1, published in February 2023 by ISO and the International Electrotechnical Commission (IEC) through their joint technical committee ISO/IEC JTC 1, subcommittee SC 42 (Artificial intelligence). No amendment or revised edition has been published; ISO reviews each standard at least every five years, so the first systematic review falls due around 2028. National standards bodies have adopted the 2023 text unchanged, for example the British Standards Institution (BSI) as BS ISO/IEC 23894:2023, dated 28 February 2023. Verified 2026-10-29. The ISO catalogue entry blocks automated access, so the details were confirmed through the NIST crosswalk of ISO/IEC 23894:2023 to the AI RMF, the OECD.AI policy navigator entry and the BSI adoption record. The standard is guidance: it uses "should" rather than "shall", and there is no certification against it.

Who it is for: risk managers and compliance officers who now have AI in their portfolio; data scientists, machine learning engineers and product owners who need to show that their system's risks are understood; security, privacy and quality professionals; and managers who must decide whether an AI use case is acceptable. No background in AI or in ISO standards is needed. If you have met risk registers, likelihood and impact before, you will move faster, but every term is explained here.

Prerequisites: none. A rough idea of what a machine learning model is (software that learns patterns from example data and then makes predictions) is helpful and is explained in Lesson 2.

Learning objectives. After this tutorial:

You will be able to explain why AI needs tailored risk management and how ISO/IEC 23894 relates to ISO 31000.
You will be able to use the core vocabulary: risk, risk source, event, consequence, likelihood, control, risk criteria and AI system life cycle.
You will be able to describe the three building blocks of the standard (principles, framework and process) and what its three annexes add.
You will be able to run an AI risk assessment, from setting scope and criteria through identification, analysis and evaluation to treatment.
You will be able to connect risk activities to each stage of an AI system's life cycle, including monitoring after deployment.
You will be able to explain what "using" or "aligning with" the standard can and cannot mean, given that it is not certifiable.
You will be able to position ISO/IEC 23894 next to ISO/IEC 42001, ISO/IEC 22989, the NIST AI Risk Management Framework and the EU AI Act.

Lesson 1 – Origins, purpose and scope

Why AI risk needed its own guidance

Organisations have managed risk for a long time. Banks manage credit risk, factories manage safety risk, IT departments manage information security risk. Since 2009 many of them have used ISO 31000, the international guideline for risk management, which gives a general set of principles, a framework for embedding risk management in the organisation, and a process for assessing and treating risks. ISO 31000 deliberately does not say anything specific about any one technology or industry.

AI systems stretch that general approach in several ways. A traditional program does what its code says; a machine learning model does what its training data taught it, and nobody wrote down the rules it follows. The same input can produce slightly different outputs, and performance that looked excellent in testing can quietly decline once the world changes. The people affected by an AI decision, such as a job applicant or a patient, are often not the people who built or bought the system. AI also brings new attack types, such as poisoning the training data, and new kinds of harm, such as unfair treatment of groups of people. Risk managers needed help translating familiar ideas into this new setting, and AI teams needed a shared language to talk to risk managers.

ISO/IEC JTC 1/SC 42, the international committee that writes AI standards, answered with ISO/IEC 23894. Rather than inventing a separate method, it follows ISO 31000 clause by clause and adds AI-specific explanation wherever the general guidance needs it. An organisation that already runs ISO 31000-style risk management can therefore extend what it has, instead of building a parallel process for AI.

Purpose

The purpose of the standard is to help organisations integrate risk management into their AI-related activities and functions, and to describe how to do that effectively. It frames risk management, as ISO 31000 does, as something that creates and protects value: it is not only about avoiding harm, but also about pursuing the benefits of AI with eyes open. A team that understands its risks can often move faster, because it knows which safeguards matter and where it can safely experiment.

Scope

The scope is broad. The guidance applies to any organisation that develops, produces, deploys or uses products, systems and services that rely on AI, whatever its size, sector or type. That covers a start-up training its own models, a software vendor embedding a third-party language model, a hospital buying a diagnostic tool, and a government agency using AI to prioritise inspections. The guidance is meant to be tailored: a small firm with one chatbot will apply it very differently from a multinational with hundreds of models.

Three points about scope often surprise newcomers:

It is about organisational risk management. It explains how an organisation should manage AI risk, not how to build a specific model or which algorithm to choose.
It does not set acceptable risk levels. The organisation decides what is tolerable, within the law and the expectations of its stakeholders.
It is meant to be read together with ISO 31000:2018, which is a normative reference. Where 23894 says nothing new about a clause, the ISO 31000 guidance simply applies.

Lesson 2 – Key concepts and vocabulary

ISO/IEC 23894 takes most of its vocabulary from three places: ISO 31000 and ISO Guide 73 for risk terms, and ISO/IEC 22989 for AI concepts and terminology. The definitions below are explanations in plain words, not the official definitions.

Artificial intelligence (AI) system – a system built to generate outputs such as forecasts, recommendations, content or decisions, working towards objectives that people define. In practice it is the whole system: model, data pipelines, user interface and the people operating it.
Machine learning (ML) – the family of AI techniques in which a model's behaviour is derived from example data during training, instead of being written as explicit rules. Most AI risk discussions today concern ML systems.
Risk – the effect of uncertainty on objectives. The effect can be negative, positive or both. This is broader than the everyday meaning of "something bad might happen".
Objective – a result the organisation wants to achieve, for example "approve good loans quickly" or "keep patient data private". Risk is always measured against objectives, which is why Annex A of the standard lists common AI-related objectives.
Risk source – anything that can lead to risk, on its own or together with other factors. Poor-quality training data, an opaque model or a high level of automation are typical AI risk sources (Annex B).
Event – something that happens, or a change in circumstances, such as "the model's accuracy drops for applicants from one region" or "an attacker extracts training data through the chat interface".
Consequence – the outcome of an event that affects objectives, for example a wrongful rejection, a fine, reputational damage or physical injury.
Likelihood – the chance of something happening, expressed in words, numbers or probabilities.
Control – any measure that keeps a risk where it is or changes it, such as human review of decisions, input validation, bias testing or a contractual clause with a model supplier.
Risk criteria – the yardsticks an organisation uses to decide how significant a risk is. They reflect the organisation's values, objectives, resources, and legal and stakeholder expectations.
Risk owner – the person with the accountability and authority to manage a particular risk, including deciding whether residual risk is acceptable.
Residual risk – the risk that remains after treatment. It is never zero and must be consciously accepted or treated further.
Stakeholder – anyone, whether a person or an organisation, who can influence a decision or activity, is affected by it, or believes they are affected. For AI this includes end users and people subject to automated decisions, not only customers and regulators.
AI system life cycle – the stages an AI system passes through, as described in ISO/IEC 22989: inception; design and development; verification and validation; deployment; operation and monitoring; continuous validation; re-evaluation; and retirement.
Drift – a change over time in the data a model sees, or in the relationship between inputs and the correct output, that makes a once-good model less accurate. Drift is the main reason AI risk must be monitored after go-live.
Explainability – how well people can be shown which factors mattered most in producing an AI system's output. Related to transparency, which is about making appropriate information about the system available to stakeholders.
Robustness – the ability of a system to keep its level of performance under varied conditions, including unusual inputs, noise and deliberate manipulation.

Risk as uncertainty about objectives

The single most useful idea to take from this lesson is that risk is tied to objectives. If you do not know what an AI system is supposed to achieve, for whom, and within which limits, you cannot say what its risks are. A fraud model that flags too many genuine transactions creates customer-experience risk; the same model flagging too few creates financial-loss risk. Both are risks against different objectives of the same system. ISO/IEC 23894 therefore asks you to make AI objectives explicit before you assess anything.

Because the definition includes positive effects, an AI risk assessment can also uncover opportunities: for instance, a model that is fairer than the human process it replaces, or a monitoring capability that detects problems earlier than before. Recording these helps decision-makers weigh benefits against harms instead of seeing only the downside.

Risk sources, events and consequences

The vocabulary forms a chain. A risk source (training data under-represents older customers) can lead to an event (the model systematically scores older applicants lower), which has consequences (unfair rejections, complaints, a regulatory investigation). Controls can act at any point in the chain: better data reduces the source, fairness testing catches the event before release, and human review limits the consequences. Likelihood and the size of the consequences together give the level of risk, which is compared with the risk criteria.

Lesson 3 – Structure of the standard

ISO/IEC 23894 mirrors the structure of ISO 31000:2018. Clauses 1 to 3 are the usual introductory clauses: scope, normative references (ISO 31000:2018 and ISO/IEC 22989:2022) and terms and definitions. The guidance itself sits in three main clauses, followed by three informative annexes.

Figure 1 – ISO/IEC 23894 follows the three building blocks of ISO 31000 and adds three informative annexes that support the process.

Clause 4 – Principles

ISO 31000 lists eight principles that describe effective risk management: it should be integrated into all activities, structured and comprehensive, customised to the organisation, inclusive of stakeholders, dynamic, based on the best available information, attentive to human and cultural factors, and continually improved. ISO/IEC 23894 keeps these principles and adds AI-specific considerations where they matter. In plain terms:

Inclusive means involving people who are affected by AI outputs, and people with relevant expertise such as data scientists, ethicists and domain experts, early enough to influence decisions.
Dynamic takes on extra weight because AI systems, their data and their environment change; risks identified at launch can shift or new ones can appear.
Best available information raises questions about data: where it came from, how representative it is, and how much the organisation actually knows about a third-party model.
Human and cultural factors include how people interact with AI, such as over-trusting automated outputs or ignoring them, and differing cultural expectations about fairness and privacy.

Clause 5 – Framework

The framework is the organisational arrangement that makes risk management happen consistently. It follows ISO 31000's structure: leadership and commitment at the centre (5.2), surrounded by integration (5.3), design (5.4), implementation (5.5), evaluation (5.6) and improvement (5.7). The design sub-clause covers understanding the organisation and its context, articulating risk management commitment, assigning roles, authorities, responsibilities and accountabilities, allocating resources, and establishing communication and consultation. Improvement covers adapting the framework and continually improving it. The AI-specific guidance explains, for example, that top management should set policy on AI use, that roles need to cover AI-specific tasks such as data stewardship and model validation, and that the organisation's context includes AI regulation, societal expectations and its dependence on AI suppliers.

Figure 2 – The framework cycle: leadership drives the integration, design, implementation, evaluation and improvement of AI risk management.

Clause 6 – Process

The process is what risk practitioners actually do, and it is where most of the AI-specific detail sits. Its sub-clauses are: general (6.1); communication and consultation (6.2); scope, context and criteria (6.3); risk assessment (6.4), which splits into risk identification, risk analysis and risk evaluation; risk treatment (6.5); monitoring and review (6.6); and recording and reporting (6.7). Risk identification is broken down further into identifying assets and their value, risk sources, potential events and outcomes, existing controls, and consequences. Risk analysis covers assessing consequences and assessing likelihood. Lesson 4 walks through the process step by step.

Figure 3 – The AI risk management process: context and criteria feed the assessment, treatment follows, and monitoring loops back while results are recorded and reported.

The annexes

The three annexes are informative, which means they offer help rather than additional guidance you are expected to follow. They are among the most practical parts of the standard.

Annex A – Objectives. A list of common AI-related objectives that risks can affect: accountability, AI expertise, availability and quality of training and test data, environmental impact, fairness, maintainability, privacy, robustness, safety, security, and transparency and explainability. It helps an organisation check that its objectives, and therefore its risk identification, are not too narrow.
Annex B – Risk sources. Common sources of AI risk: complexity of the environment, lack of transparency and explainability, level of automation, risk sources related to machine learning (for example data quality and how data is collected), system hardware issues, system life cycle issues, and technology readiness.
Annex C – Risk management and AI system life cycle. An example mapping that shows which risk management activities are relevant at each life cycle stage, so risk work is spread across the system's whole life instead of happening once before launch.

A useful way to remember the annexes: A tells you what you care about, B tells you where trouble tends to come from, and C tells you when to look.

Lesson 4 – How it works in practice

This lesson follows the process in clause 6 as a practitioner would, adding the framework pieces that must be in place first. Remember throughout that the steps are iterative: you revisit them whenever the system, its data or its context changes.

Step 0 – Put the framework in place

Before assessing a single model, the organisation needs a few basics. Top management should state its position on AI: which uses it supports, which it forbids, and how much AI risk it is willing to take. Roles must be clear. Typical arrangements name a business owner for each AI system who is also its risk owner, a technical owner for the model, a data owner, and an independent function (risk, compliance or an AI governance committee) that challenges assessments. Resources are needed too: people with both AI expertise and risk expertise are scarce, and the standard treats AI expertise as an objective in its own right. Finally, AI risk should be integrated into existing processes, such as product approval, procurement, change management and enterprise risk reporting, rather than run as a side activity.

Step 1 – Communicate and consult

Communication and consultation run through every step. For AI, the people to involve go beyond the project team: affected users or their representatives, legal and privacy specialists, domain experts who know what a wrong answer would mean in practice, and suppliers of models or data. Early consultation helps surface risks that technical teams cannot see from the inside, such as how a frontline employee will really use a recommendation, or which groups of customers are likely to be under-represented in the data.

Step 2 – Set scope, context and criteria

Define what is being assessed: one model, one AI-enabled product, or a portfolio. Describe the AI system's purpose, intended users, the decisions it influences, the degree of human involvement and the life cycle stage it is in. Then capture the context. External context includes laws and regulations (such as AI, privacy, consumer protection and sector rules), societal expectations, the competitive landscape and the supplier ecosystem. Internal context includes the organisation's values, policies, data assets, skills and existing controls.

Next, define risk criteria: how consequences and likelihood will be rated, how they combine into a risk level, and which levels are acceptable, need treatment or need escalation. AI criteria often need extra dimensions that a classic financial scale misses, such as harm to individuals' rights, unfair impact on a group, loss of trust, or environmental cost. Agreeing criteria before the assessment avoids the temptation to set the bar wherever the results happen to land.

Step 3 – Identify risks

Risk identification asks what could happen, why and how. ISO/IEC 23894 suggests looking at several things in turn:

Assets and their value – the data, models, algorithms, infrastructure and also intangible assets such as reputation and trust, plus value to stakeholders outside the organisation, such as individuals' privacy.
Risk sources – use Annex B as a prompt list: is the environment complex or unpredictable? Is the model opaque? How automated is the decision? Is the training data representative, current and lawfully obtained? Is the technology mature?
Potential events and outcomes – concrete scenarios, such as performance decline after a change in customer behaviour, an adversarial input that fools a vision model, or a generative model producing confident but false statements.
Existing controls – what is already in place, and whether it actually works for AI. A general code review process, for example, will not catch a biased training set.
Consequences – for the organisation, for individuals and groups, and for society. Annex A helps check every relevant objective: fairness, privacy, safety, security, transparency and so on.

Techniques include workshops, checklists, scenario analysis, threat modelling, reviewing incidents from similar systems, and red-team exercises in which testers try to make the system fail.

Step 4 – Analyse risks

Analysis builds understanding of each risk: its causes, how effective existing controls are, how severe the consequences could be and how likely they are. AI makes both halves harder. Consequences can be widespread because one model makes thousands of decisions a day, so a small error rate can still harm many people. Consequences can also be hard to observe: a person wrongly refused a service may never find out why. Likelihood is difficult to estimate when there is little history and when performance depends on data the system has not yet seen. Practitioners combine quantitative evidence (test metrics, error rates by subgroup, robustness test results) with expert judgement, and they record the uncertainty in their estimates rather than hiding it.

Step 5 – Evaluate risks

Evaluation compares the analysed risk levels with the criteria from Step 2 to decide what needs action and in what order. Possible outcomes include: do nothing further, consider treatment options, undertake further analysis, keep existing controls, or reconsider objectives altogether. That last option is important for AI. Sometimes the right conclusion is that a use case should not proceed, or should proceed only with a narrower purpose or with a person making the final decision.

Step 6 – Treat risks

Risk treatment selects and implements options to address risk. The ISO 31000 options apply: avoid the risk by not starting the activity; take or increase risk to pursue an opportunity; remove the risk source; change the likelihood; change the consequences; share the risk, for example through contracts or insurance; or retain the risk by informed decision. Typical AI treatments include improving or rebalancing training data, choosing a more interpretable model, adding human review for high-impact decisions, limiting the system to a narrower purpose, rate-limiting and filtering inputs, testing robustness against adversarial examples, adding explanations for users, setting performance thresholds that trigger rollback, and negotiating transparency and incident-notification clauses with suppliers.

A risk treatment plan records what will be done, by whom, by when, with what resources, how success will be measured, and what residual risk is expected. The risk owner then decides whether that residual risk is acceptable. Treatments can introduce new risks of their own: a human reviewer may simply approve everything the model suggests, so the treatment itself needs checking.

Step 7 – Monitor and review

Monitoring is where AI differs most from many traditional systems. Models can drift, users find new ways to use a tool, attackers adapt, and laws change. Monitoring should therefore cover model performance (overall and for relevant subgroups), data quality and distribution, incidents and complaints, the effectiveness of controls, and changes in context. Reviews should be planned, for example on a schedule and whenever significant changes are made to the model, its data or its use, and their results should feed back into the assessment.

Step 8 – Record and report

Recording and reporting make risk management visible and accountable. Typical records include an AI system inventory, a risk register entry per system, assessment reports, treatment plans, acceptance decisions and monitoring results. Reporting tailors this information to its audience: engineers need technical detail; executives and boards need a view of the main AI risks, trends and decisions required; external stakeholders may need transparency information about how a system works and how to challenge its outputs.

Following the life cycle (Annex C)

Annex C ties the process to the AI system life cycle. The key message is that risk management is not a gate passed once before launch. Each stage raises different questions, and the process runs again whenever the system moves forward or changes.

Figure 4 – Risk management activities follow the AI system life cycle, with operation, re-evaluation and redesign forming a loop until retirement.

At inception, the focus is whether the use case is appropriate at all, its objectives and its stakeholders. During design and development, data sourcing, labelling, model choice and security of the pipeline dominate. Verification and validation checks performance, fairness and robustness against the criteria. At deployment, controls are switched on, users are trained and residual risk is formally accepted. In operation and monitoring, the organisation watches for drift and incidents; continuous validation and re-evaluation decide whether to retrain, redesign or stop. Retirement has risks too: deleting or archiving data and models correctly, informing users, and removing hidden dependencies on the old system.

Lesson 5 – Assessment, certification and compliance

No certification against ISO/IEC 23894

ISO/IEC 23894 is a guidance document. It contains recommendations ("should") and explanations, not requirements ("shall"). As a result, there is no certification scheme for it, no accredited certificate an organisation can obtain, and no formal maturity levels or ratings. An organisation can truthfully say that it uses the standard as guidance or that its AI risk process is aligned with it, but a claim to be "ISO/IEC 23894 certified" would be misleading. Some training providers issue personal course certificates mentioning the standard; these show that a person attended training, not that an organisation conforms.

Where formal assessment does happen

The certifiable standard in this area is ISO/IEC 42001, which specifies requirements for an AI management system. ISO/IEC 42001 requires an organisation to define and apply an AI risk assessment process and an AI risk treatment process, among many other things. Certification bodies audit those requirements; ISO/IEC 42006:2025 sets requirements for the bodies that audit and certify AI management systems. ISO/IEC 23894 is the natural guidance to use when designing the risk parts of such a system, so in a 42001 audit an organisation will often show 23894-style records as evidence. The auditor, however, is checking conformity to 42001, not to 23894.

Ways to check your own use of the standard

Even without certification, organisations regularly assess how well they apply the guidance:

Gap analysis – compare current practice clause by clause with the guidance in clauses 4 to 6 and list the differences, for example "no defined criteria for fairness harms" or "no monitoring of deployed models".
Internal audit – the internal audit function tests whether AI risk assessments are actually performed, documented and acted upon for a sample of systems.
Second-line review – a risk or compliance function independently challenges the assessments made by product teams.
Independent assurance – an external firm reviews the AI risk process against the guidance and reports its opinion, which is useful for boards, customers or investors. This is an assurance report, not a certificate.
Customer and regulator reviews – buyers of AI products and supervisory authorities increasingly ask suppliers how they manage AI risk; mapping your process to a recognised international standard makes those conversations easier.

Regulation

Using ISO/IEC 23894 does not by itself make an organisation compliant with any law. Laws such as the EU AI Act (Regulation (EU) 2024/1689) require a risk management system for high-risk AI systems, among other obligations. Organisations often use 23894 as a structured method to meet such obligations, but compliance is judged against the legal text and any harmonised standards adopted for it, not against this guidance. Always check the specific legal requirements with qualified advisers.

Signs that the guidance is working

Useful indicators include: every AI system in the inventory has a named risk owner and a current assessment; risk criteria explicitly cover harms to people, not only to the organisation; assessments are updated after significant model or data changes; monitoring covers subgroup performance and drift; residual risk acceptance is documented at the right level; and lessons from AI incidents lead to changes in the framework itself.

Lesson 6 – Worked example: a lender applies ISO/IEC 23894 to a loan pre-screening model

Harbourline Finance is a fictional mid-sized consumer lender in Europe with about 900 employees. Its data science team has built a machine learning model that pre-screens online personal loan applications. The model scores each application, and the business plans to approve strong applications automatically, send borderline ones to underwriters and decline the weakest. Harbourline already uses ISO 31000 for enterprise risk management and decides to extend it to AI using ISO/IEC 23894.

1. Framework

The board approves an AI policy that permits AI for credit decisions only with human oversight of declines, and states a low appetite for unfair outcomes. The head of consumer lending becomes the risk owner for the model. The chief risk officer sets up a small AI risk committee with members from data science, compliance, privacy, information security and customer service. An AI system inventory is created; the pre-screening model is its first entry. The committee notes a skills gap: the risk team does not yet understand model validation, so two risk analysts attend training and a validation specialist is hired.

2. Scope, context and criteria

The assessment scope is the pre-screening model, its data pipeline and the decision workflow around it, at the verification and validation stage. External context includes consumer credit law, data protection law, and the EU AI Act, under which AI used to evaluate the creditworthiness of individuals is classified as high-risk. Internal context includes the existing credit policy, the data warehouse and the underwriting team's capacity.

The committee agrees criteria with a five-point scale for consequences, covering financial loss, harm to applicants, regulatory exposure and reputation, and a five-point likelihood scale. Any risk with a "major" consequence for applicants needs treatment regardless of likelihood. Fairness is made measurable: approval rates and error rates for protected groups must stay within an agreed tolerance of the overall rate.

3. Identification

A workshop uses Annex A and Annex B as prompt lists. Key findings:

Data – the training data comes from past decisions made by underwriters, so it may contain historical bias. Applicants who were declined have no repayment history, so the model learned only from approved loans.
Transparency – the model is a gradient-boosted ensemble; applicants who are declined have a legal right to meaningful information, and underwriters need to understand scores.
Level of automation – automatic approval and decline at volume means errors spread quickly.
Life cycle – economic conditions change; a model trained on low-interest-rate years may perform poorly in a downturn.
Security – fraudsters could probe the online form to learn which inputs push a score over the approval line.
Opportunity – consistent scoring could reduce the variation between individual underwriters and speed up decisions for good applicants.

4. Analysis and evaluation

The validation specialist runs the model on a held-out test set and breaks results down by age band, gender and region. Overall performance is good, but applicants under 25 are declined noticeably more often than their later repayment behaviour justifies. This "unfair declines of young applicants" risk is rated major consequence, possible likelihood: above the acceptance line. Drift in a downturn is rated major and likely over a three-year horizon. Probing by fraudsters is rated moderate and possible. Lack of explanations is rated major for regulatory exposure, because the lender must be able to explain declines.

5. Treatment

The committee chooses treatments and records them in a treatment plan:

Change consequences: no automatic declines. Every application the model would decline goes to an underwriter, who sees the score, the main contributing factors and a checklist. Automatic approvals stay.
Change likelihood: the data team reweights the training data and adds alternative data on rental payment history (with a lawful basis confirmed by the privacy officer), then re-tests subgroup performance.
Transparency: an explanation component produces the top factors for each score in plain language for underwriters and for decline letters.
Drift: monthly monitoring of input distributions and approval rates, plus quarterly back-testing against actual repayments; agreed thresholds trigger a review or a rollback to the manual process.
Security: rate limits on the application form, anomaly detection for repeated near-identical applications, and keeping exact score thresholds confidential.
Pitfall check: to avoid underwriters simply approving whatever the model suggests, a sample of their decisions is reviewed monthly and override rates are tracked.

After re-testing, the under-25 gap falls within tolerance. The risk owner accepts the residual risks in writing, and the committee approves deployment.

6. Monitoring, recording and reporting

Six months after launch, monitoring shows a rise in applications from a new partner website whose customers differ from the training population. The input distribution alert fires, the committee re-opens the assessment, and the model is retrained with data that includes these customers. Each step is recorded in the risk register. The board receives a quarterly AI risk report with the status of each AI system, top risks, incidents and open actions. Harbourline also adds the model's documentation and risk records to the evidence it is building for a future ISO/IEC 42001 certification and for its EU AI Act obligations.

The example shows the full cycle of the standard: principles (inclusive, dynamic, best available information), framework (policy, roles, resources, integration), process (context, assessment, treatment, monitoring, records), and the annexes used as practical tools.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 23894 sits in a growing family of AI and risk documents. Knowing who does what avoids duplicated effort and helps you answer the common question "which one should we use?" The usual answer is that they complement one another.

Figure 5 – ISO/IEC 23894 builds on ISO 31000 and ISO/IEC 22989 and supports the risk processes required by ISO/IEC 42001.

Standard or framework	Owner	What it is	Relationship to ISO/IEC 23894
ISO 31000:2018	ISO	Generic risk management guidelines for any organisation and any risk.	The parent. 23894 follows its structure clause by clause and adds AI-specific guidance; it is a normative reference.
ISO/IEC 22989:2022	ISO/IEC JTC 1/SC 42	AI concepts and terminology, including the AI system life cycle.	Provides the AI vocabulary and the life cycle stages used in Annex C; also a normative reference.
ISO/IEC 42001:2023	ISO/IEC JTC 1/SC 42	Requirements for an AI management system; certifiable.	Requires AI risk assessment and treatment; 23894 gives detailed guidance on how to do them well.
ISO/IEC 42005:2025	ISO/IEC JTC 1/SC 42	Guidance on assessing the impacts of AI systems on individuals, groups and society.	Complements 23894: impact assessment focuses on effects on people and society, which feed into risk identification and criteria.
NIST AI Risk Management Framework (AI RMF 1.0)	US National Institute of Standards and Technology	Voluntary framework organised into four functions: Govern, Map, Measure and Manage.	Similar aims; NIST publishes a crosswalk that maps each of the four functions to the 23894 subclauses that support it. Many organisations use both.
EU AI Act (Regulation (EU) 2024/1689)	European Union	Law with obligations by risk category, including a risk management system for high-risk AI.	Legal requirements; 23894 can serve as a method for building the required risk process, but does not itself grant compliance.
ISO/IEC 27001 and ISO/IEC 27005	ISO/IEC JTC 1/SC 27	Information security management system requirements and information security risk guidance.	Security of AI data and models is one AI objective; many organisations combine their security and AI risk processes.

Choosing a combination

A typical mature set-up looks like this: ISO 31000 provides the enterprise risk approach; ISO/IEC 23894 tailors it to AI; ISO/IEC 22989 gives everyone the same vocabulary; ISO/IEC 42001 provides the management system and, optionally, certification; impact assessments inform which harms to people matter most; the NIST AI RMF helps in conversations with US customers and partners; and legal teams map all of this to the specific regulations that apply. ISO/IEC 23894 is the piece that answers the practical question "how do we actually assess and treat the risks of this AI system?"

A smaller organisation does not need all of this at once. Starting with an inventory of AI systems, a simple set of criteria, and a 23894-style assessment of the highest-impact system is a sensible first step that can grow into a management system later.

Common pitfalls and best practices

Common pitfalls

Treating AI risk as a one-off launch gate. Assessing a model once before release and never again ignores drift, new uses and changing context, which is exactly what the life cycle guidance warns against.
Only considering risks to the organisation. Rating risks purely by financial or reputational impact misses harms to individuals, groups and society that the standard asks you to consider.
Claiming certification. Telling customers the company is "ISO/IEC 23894 certified" is inaccurate, because the standard is guidance and has no certification scheme.
Leaving it all to the data scientists. Technical teams see technical risks; without consultation with affected users, legal, domain experts and risk professionals, important risks stay hidden.
Assuming bought-in AI is the supplier's problem. Organisations that deploy a third-party model still carry the risk of how it is used; they need information, contractual safeguards and their own testing.
Trusting human review blindly. Adding a person to approve AI outputs is not an effective control if that person lacks time, information or authority to disagree.
Setting criteria after the results. Defining "acceptable" once the numbers are known turns the assessment into a justification exercise.

Best practices

Start with an inventory. Know which AI systems you build, buy and use, who owns each one and which decisions it affects.
Use the annexes as checklists. Walk through Annex A objectives and Annex B risk sources in every assessment so that fairness, transparency, robustness and the rest are not forgotten.
Integrate, don't duplicate. Build AI risk into existing enterprise risk, product approval, procurement and change processes.
Measure what matters after go-live. Monitor performance by subgroup, data drift, incidents, complaints and override rates, with thresholds that trigger review.
Document decisions, including acceptance. Record who accepted which residual risk and why; this is the core of accountability.
Revisit the framework itself. Use incidents and audit findings to improve policies, roles and criteria, not just individual models.
Align with 42001 and regulation from the start. If certification or legal obligations are likely, structure records so they serve as evidence later.

Summary and key takeaways

ISO/IEC 23894:2023 (Edition 1, ISO/IEC JTC 1/SC 42) is guidance on managing AI-related risk; it is current, unamended and not certifiable.
It mirrors ISO 31000:2018, adding AI-specific advice to the principles (clause 4), framework (clause 5) and process (clause 6).
Risk means the effect of uncertainty on objectives, so clear AI objectives come first; Annex A lists common ones.
Annex B lists typical AI risk sources such as opaque models, high automation, machine learning data issues and immature technology.
The process runs from communication, scope, context and criteria through identification, analysis, evaluation and treatment to monitoring, recording and reporting.
Annex C links risk activities to every stage of the AI system life cycle; monitoring after deployment is essential because models drift.
Formal certification happens under ISO/IEC 42001; 23894 helps design the risk parts of that management system and supports regulatory duties such as those in the EU AI Act.
Good practice means an AI inventory, criteria that include harm to people, real human oversight, documented risk acceptance and continual improvement.

Reflection questions

Pick one AI system your organisation uses or plans to use. What are its objectives, and which Annex A objectives are most at risk?
Which three Annex B risk sources apply most strongly to that system, and what events could each one lead to?
How would you write risk criteria that capture harm to people affected by the system, not only financial loss to your organisation?
If your system were provided by a third-party supplier, what information and contractual safeguards would you need to manage its risks?
What would you monitor after deployment, which thresholds would trigger a review, and who would decide whether to retrain, restrict or retire the system?