ISO 42001 Clause 8.2: Repeat AI Risk Assessment When Conditions Change
ISO 42001 clause 8.2 requires AI risk assessments using the process established under clause 6.1.2, at planned intervals or when significant changes are proposed or occur. Results of all assessments are retained as documented information. The practical purpose is to keep decisions aligned with current conditions rather than rely indefinitely on a successful pilot.
What clause 8.2 requires in practice
Clause 8.2 makes AI risk assessment a continuing activity during operation. The organisation performs assessments using the method set up under clause 6.1.2 on two occasions: at planned intervals, and when significant changes are proposed or occur. Both triggers matter. The planned interval gives a baseline rhythm, while the change trigger catches events between those dates. The clause does not say what counts as significant, so the organisation needs a way to judge that consistently.
It also requires the organisation to keep documented information on the outcomes of every AI risk assessment. The wording covers every assessment, not only the most recent or the most favourable one. The practical outputs are a repeatable reassessment process, a way for changes to reach it, and a history of assessment results that explains how the risk picture moved over time.
Recognise change in use as well as technology
A model version change can matter, but it is not the only trigger. A different purpose, user population, data source or business action can alter the consequence of an output. These are original examples of changes to examine, not an exhaustive ISO list.
Determine how potentially significant changes reach the assessment process. Procurement, release management, customer requests and operating feedback can each reveal relevant information. An annual calendar reminder does not replace attention to significant changes that arise between scheduled assessments.
Why clause 8.2 matters to the business
Risk is not a property of a model alone. It depends on who is affected, what decision follows an output and how much people rely on it. A use that was safe as a drafting aid can become hazardous once it triggers an action, even if the technology never changes. Repeating assessment at the right moments keeps management decisions aligned with reality, rather than with the optimism of a pilot. It also gives the business a defensible record: when a customer or regulator asks why a use was permitted at a particular time, retained results show what was known and what was decided. Skipping reassessment saves little and can be costly later.
How to implement clause 8.2
Make reassessment something that happens through normal channels rather than by memory. The steps below show one way Sterling teams do this without prescribing a single format.
- Reuse the clause 6.1.2 method so results stay comparable, and note clearly whenever criteria or assumptions change.
- Write a short working description of what makes a change significant, with examples such as new purpose, new user group or new data source.
- Connect release, procurement and customer-request routines to a prompt that asks whether the change touches an AI use.
- Set planned intervals according to the pace of change in each use rather than one date for everything.
- Involve people who understand affected users and the business action, not only the system owner.
- Retain every assessment with its date, conditions examined and conclusion, and never overwrite an earlier result.
- Send new risks into the treatment process under 6.1.3 and confirm someone owns the follow-up.
Illustrative IT example: a recommendation starts an action
An IT provider uses AI to recommend ticket routing. An experienced coordinator makes the final decision. A team later connects the recommendation to automatic priority changes in the customer system. The model is unchanged, but an incorrect result now directly changes the response workflow.
The provider examines the proposed change using its established risk method. It considers consequences, existing controls and uncertainty before assuming that the earlier assessment remains adequate. The exercise may lead to revised treatment or operating conditions; updating the use description alone does not answer the risk question.
Illustrative construction example: the operating population expands
A construction group evaluates an AI planning assistant on a set of projects with consistent reporting practices. It later introduces the service on projects where subcontractor updates arrive in different formats and at different intervals.
The changed input and operating context may affect the assumptions behind the original assessment. The organisation examines whether forecasts could be misunderstood or relied on beyond their evidence. It records the conclusion even if the final decision is that existing treatment remains suitable, explaining the basis rather than merely copying a prior score.
Use a repeatable method with current evidence
Operational assessment applies the process defined under clause 6.1.2. Preserve comparability where useful, while making changed criteria or assumptions clear. A score can change because conditions changed, because better evidence became available or because the method changed; these explanations should not be confused.
Bring relevant impact-assessment results into the work. New information about affected people can alter consequence analysis even when technical performance looks stable. Obtain suitable contributors rather than ask one system owner to infer every domain or stakeholder perspective.
Retain all results and act on them
The clause requires results of all AI risk assessments to be retained. Do not overwrite an unfavourable assessment with a later favourable one and lose the history. Preserve enough context to understand what was assessed, under which conditions and with what conclusion.
Where assessment identifies new risks requiring treatment, the operational treatment process connects them with clause 6.1.3. Findings should reach people who can decide and act. A reassessment that identifies a significant issue but produces no response is not a useful operating loop.
Common failures and evidence tests
An auditor may select a significant change and ask how it became visible, which assessment was performed and what happened next. Watch for date-only updates, supplier assurances applied to a different use and planned intervals chosen without regard to the activity.
Do not assume that no reported incidents means the earlier assessment remains valid. Reporting may be incomplete, and changes can increase exposure before an adverse event occurs. Reassessment should examine evidence and assumptions proactively.
Frequently asked questions
Is a pre-launch assessment enough?
No. Clause 8.2 includes planned reassessment and significant-change triggers. The organisation needs a continuing process.
Can a change be significant if the model stays the same?
Yes. Purpose, users, inputs or the action taken from an output can change the risk picture without a model update.
Do we retain only the final approved result?
The requirement covers results of all AI risk assessments. Keep the history needed to understand decisions and changes.
Reassess a changed use with a clear decision in view
Discuss a significant AI change with Sterling to scope reassessment, documentation and treatment follow-through. Agreed support can include Effivity ISO & GRC automation software. AI Risk & Impact Assessment strengthens the method behind the work. Return to clause 8 or the library.