Skip to content
UNTIL 31 DECWhich kind of AI user are you?
Take the two-minute check
AIAC AI ASSURANCE COUNCIL™

ISO/IEC 42001

Clauses 8.2 and 8.3 — AI risk assessment; AI risk treatment

Clauses 8.2 and 8.3 are not a second copy of clauses 6.1.2 and 6.1.3. Planning establishes the processes; Operation runs them — assessments performed at the intervals the organisation set and whenever something significant changes, the treatment plan actually implemented, and the results of both retained. Evidence of a process is not evidence that it ran.

§ 1Who it binds

Which systems, and for how long

Audited organisation

Every AI system inside the scope of the management system, for as long as it is in service. Clauses 8.2 and 8.3 bind the organisation operating the AIMS and run continuously rather than at a milestone: they attach to the interval the organisation set for itself and to the changes it defined as significant. A system acquired rather than built is not outside them, since the organisation still decides what to assess and what to accept.

§ 2In practice

Six establishes, eight executes

Clause 6 and clause 8 mirror one another, and the mirror is the standard’s most misread feature. Clause 6.1.2 requires the organisation to establish an AI risk assessment process — criteria, a repeatable method, the steps by which risks are identified, analysed and evaluated. Clause 8.2 requires that process to be performed: at the intervals planned for it, and when something significant changes. Clause 6.1.3 establishes the treatment process and yields a plan; clause 8.3 requires the plan to be implemented and the results kept. Organisations reliably evidence the planning half, are then asked for the operational half, and discover that a documented process and a process that ran leave entirely different traces.

The standard does not define significant change, and the omission is deliberate — what counts differs between a credit model and a document classifier. It also means an organisation that has not defined it has a gap findable in one question. The definition has to be per system and it has to be capable of firing: a retrain, a change of training data source, a new deployment population, a threshold moved, a supplier replacing the model behind a hosted endpoint the organisation does not control. Union law arrives at the same problem from the other direction, since Article 9 treats risk management as a continuous, iterative process running across the whole lifecycle rather than as an exercise completed before launch.

Systems that learn in service break the change trigger rather than fail it. A model updating on production data alters its behaviour with no change event at all — no release, no ticket, no approval anybody could route into a change-management workflow. The standard’s own introduction draws attention to this property of AI systems, and the practical consequence is that the trigger has to come from a measurement instead of from a workflow: a drift detector, a subgroup performance monitor, a referral rate that moves. Post-market monitoring under Article 72 rests on the same observation, that a system in service has to be watched rather than cleared once.

Clause 8.3 is about implementation, and implementation is where treatment plans quietly become intentions. Two records carry it: proof that each treatment named in the plan was put in place, and acceptance of whatever risk remains, given by somebody with the authority to accept it. Unowned residual risk is the commonest gap here and it usually follows from a plan naming a function instead of a person. The assessment side has to join up with the impact side as well: what an AI system impact assessment finds is an input to a treatment decision, and where the two run as separate exercises the impact findings reach nothing.

§ 3When it applies

Which edition applies

  1. 31 December 2023

    BSI published its adoption of the first edition, BS ISO/IEC 42001:2023, on this date. It identifies the edition and imposes no deadline: conformity with ISO/IEC 42001 is voluntary and no duty commences here.

  2. 31 March 2026

    BS EN ISO/IEC 42001:2026, the European and UK adoption, was published on this date; BSI states it carries no technical differences from the 2023 adoption. An edition date, not a date anything falls due.

§ 4What discharges it

What the operating record must show

The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.

  1. 01

    A written definition of significant change, per AI system

    Approved, dated, and specific enough that whoever raises a change can answer it yes or no. One definition covering every system at once is usually a sentence nobody can apply to any of them.

  2. 02

    A reassessment log separating interval from trigger

    Two columns, because they fail differently. The scheduled entries show the planned cadence was kept; the triggered entries show the definition actually fired. A year of changes with no triggered entry is itself the finding.

  3. 03

    Implementation proof for each treatment in the plan

    Per treatment, what was put in place and when — distinct from the decision to put it in place. A tracker item marked complete records the closing of a task, not the existence of a working control.

  4. 04

    Residual risk acceptances naming the accepting individual

    What remains after treatment, who accepted it, and on what date. Acceptance attributed to a function or a forum leaves nobody who can be asked why, which is the question that arrives after an incident.

  5. 05

    The change signal for systems that learn in service

    For any model updating on live data, the monitor supplying the reassessment trigger, its thresholds, and what it has raised. Without one the organisation holds a trigger it has no means of detecting.

§ 5Worked example

Worked example — two changes and one annual assessment

A bank runs a transaction-monitoring model inside its AIMS. The risk assessment process is documented and was approved last year; the register lists eleven AI risks with owners and treatments. The annual reassessment was performed in March. In June the vendor shipped a new model version to the hosted endpoint; in July the bank extended the model to a new customer segment. Both were raised as change requests and approved. The register has not been touched since March.

Which clause has been breached, and by what exactly?

Clause 8.2, twice — and the change process is the reason rather than the excuse. Two events in the period meet any reasonable definition of significant: a model version the bank did not build, and a population it had never assessed. Both passed a gate with no step routing them to a reassessment. The annual exercise is not the defect; the missing link between the gate and the trigger is. The bank also cannot show which definition of significant change it was working to, so the gap from March to July reads as a decision nobody took rather than a judgement someone made. What closes it is small: a written definition per system, a mandatory field on the change record asking whether the definition is met, and a log recording the answer either way. The July extension raises a separate question under 8.3, because the treatments approved for the original population were never tested against the new one.

§ 6What a weak answer looks like

A procedure answering a question about practice

The procedure produced in answer to a question about practice. Asked how AI risks are assessed, the organisation supplies a well-drafted document: criteria, matrix, roles, review cycle, all approved. Asked when it last ran and what changed as a result, it supplies the same document. The gap is not documentation quality — the procedure is frequently better than the practice it describes — it is that clause 8.2 is answered by dated records of the thing operating, and a procedure answers a different clause. The tell is a register in which every entry carries the same review date.

§ 7Elsewhere

The same problem in Union law

Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.

  • EU AI Act

    Article 9 requires a risk management system for a high-risk AI system to be established, implemented and maintained as a continuous iterative process across the lifecycle, with regular systematic review.

  • EU AI Act

    Article 72 obliges a provider to collect and analyse performance data from systems in service. It is the statutory analogue of a reassessment trigger driven by measurement rather than by a change record.

A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.

§ 8provenance

The provision itself

This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.

§ 9Also read

Also read

Certification

Assessed on the same standard of evidence

Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The Certified Applied AI Associate, the Council’s flagship, is open to any adult today, its fee waived by a coupon code from the AI-Readiness Check, and the register lists what is open for enrolment.

Flagship · AIAC-CAAACertified Applied AI Associate30 minutes · 18 or over · on the register
Open now →The credentials open for enrolmentThe register →