Running AI Impact Assessments at Planned Intervals: Clause 8.4 of ISO 42001

Why Clause 8.4 Exists and What It Is Actually Asking

ISO 42001 introduced something that no other mainstream management system standard has ever required in quite the same way: a formal, repeating assessment of the impact your AI systems have on people, society, and your organisation. Clause 8.4 is where that requirement lives, and it catches a lot of organisations off guard because it goes beyond risk management. It asks you to look outward, not just inward.

Most organisations implementing ISO 42001 are reasonably comfortable with risk assessment. They have done it for ISO 9001 or ISO 27001 and they understand the mechanics. But Clause 8.4 is not simply a risk assessment with a different label. It is asking you to evaluate the actual and potential impacts of your AI systems on individuals and groups who may be affected by what those systems do. That includes your customers, your workers, third parties, and in some cases broader society.

If you have already worked through the AI system impact assessment concept in ISO 42001, you will know that the standard uses this mechanism as one of its most distinctive features. Clause 8.4 is where the rubber meets the road: it tells you that the assessment must be conducted at planned intervals, not just once at implementation.

What Clause 8.4 Actually Requires

The clause requires that the organisation conduct AI system impact assessments at planned intervals and when significant changes occur. It does not specify a fixed frequency. That is intentional. The standard recognises that the appropriate interval depends on the nature of the AI system, the context in which it operates, and the level of risk and impact involved.

What this means in practice is that you need to make a documented decision about how often you will reassess each AI system, justify that decision based on the risk and impact profile of the system, and then actually follow through at those intervals. An auditor will want to see all three elements: the planned interval, the rationale for it, and evidence that the assessment happened on schedule.

The Scope of an AI Impact Assessment

An AI impact assessment under Clause 8.4 is broader than a technical risk review. It should address questions such as:

• What decisions is this AI system influencing or making, and who is affected by those decisions?
• Are there groups of people who may be disproportionately affected, positively or negatively?
• Has the AI system's behaviour changed since the last assessment, either due to retraining, new data, or changes in deployment context?
• Are the controls put in place after the previous assessment still effective?
• Have the external circumstances changed in ways that alter the impact profile of the system?

The assessment needs to be documented. Clause 7.5 of ISO 42001 applies, which means you need documented information that demonstrates the assessment was carried out, what was considered, what was found, and what decisions or actions resulted from it.

Setting Planned Intervals: The Decisions You Need to Make

The phrase planned intervals is used deliberately. It mirrors language in Clause 9.2 for internal audits and Clause 9.3 for management review. The intent is the same: the organisation must plan the activity in advance, not wait until something goes wrong to trigger a review.

Setting the right interval requires you to think carefully about the nature of each AI system in scope. A low risk, stable system with limited human impact might reasonably be assessed annually. A high risk system that makes consequential decisions about individuals, operates on live data, or has a history of producing unexpected outputs might need quarterly or even more frequent assessment.

Factors That Should Influence Your Interval Decision

When deciding how often to assess a particular AI system, consider the following factors:

• Consequence severity: If the system influences decisions that significantly affect people, such as credit scoring, recruitment screening, or medical triage support, the interval should be shorter.
• Rate of change: AI systems that are frequently retrained, updated, or exposed to shifting data distributions can drift in their behaviour. More frequent assessment catches drift earlier.
• Regulatory environment: In sectors with specific AI governance requirements, such as financial services or healthcare, regulatory expectations may effectively set a minimum frequency.
• Volume of interactions: A system processing millions of transactions per month accumulates impact at a faster rate than one used occasionally. Higher volume often justifies shorter intervals.
• Previous findings: If earlier assessments found significant issues, a shorter interval for the next cycle is appropriate until the situation stabilises.

Document your reasoning. When an auditor asks why you chose a 12 month interval for one system and a 6 month interval for another, you need a clear, defensible answer grounded in the factors above.

Triggering Assessments Outside the Planned Schedule

Clause 8.4 also requires that assessments be conducted when significant changes occur. This is a trigger based requirement that sits alongside the planned interval requirement. The two are complementary, not alternatives.

Significant changes that should trigger an unscheduled impact assessment include:

• Retraining the AI model on new or expanded data sets
• Deploying the system in a new business context or to a new population of users
• Changing the decisions or processes the system feeds into
• Receiving complaints or evidence of unexpected outputs
• Changes in the legal or regulatory environment affecting AI use
• Integrating the system with new data sources or third party platforms

The challenge here is that organisations often make incremental changes to AI systems without formally classifying them as significant. This is where your change management process, addressed under Clause 6.3 of ISO 42001, connects directly to Clause 8.4. If your change management process does not include a step that asks whether an AI system change is significant enough to trigger a reassessment, you have a gap that an auditor will find.

What the Assessment Should Produce

An AI impact assessment under Clause 8.4 is not a checkbox exercise. It should produce outputs that are genuinely useful for managing the system and protecting affected parties. At a minimum, the assessment should result in:

• A documented record of what was assessed, when, and by whom
• A clear statement of the findings, including any impacts identified that were not previously recognised
• An evaluation of whether existing controls are still adequate
• Decisions about whether additional controls, modifications, or in extreme cases discontinuation of the system are required
• Actions assigned to responsible persons with timeframes

The outputs feed back into your AI risk treatment process under Clauses 8.2 and 8.3, and they should be considered as inputs to your management review under Clause 9.3. This is how the system is supposed to work: impact assessments generate findings, findings drive treatment decisions, and the overall picture is reviewed at management level on a regular basis.

Common Weaknesses Auditors Find in Clause 8.4 Implementation

Having audited AI management systems and trained auditors to assess them, the patterns of weakness that emerge in Clause 8.4 are fairly predictable. Knowing them in advance gives you a chance to address them before an external auditor does.

Assessments Conducted Once and Never Repeated

This is the most common finding. An organisation conducted a thorough impact assessment when implementing ISO 42001, documented it well, and then treated it as a one time exercise. When the auditor asks for evidence of the assessment at planned intervals, there is nothing to show beyond the original document. The clause is explicit: the assessment must be repeated. A single initial assessment does not satisfy Clause 8.4.

No Documented Rationale for the Chosen Interval

Organisations sometimes set an interval, such as annually, without documenting why that interval is appropriate for each system. The auditor will ask. If the answer is simply that annual seemed reasonable, that is not sufficient. The interval needs to be justified based on the risk and impact profile of the system.

Change Management Not Connected to Impact Assessment

As noted above, if your change management process does not include a mechanism for deciding whether a change to an AI system triggers a reassessment, you will miss assessments that should have been conducted. This is a systemic gap, not just a procedural one, and auditors will trace it back through your documented processes.

Assessments Conducted by the Wrong People

An AI impact assessment requires input from people who understand the technical behaviour of the system, the operational context in which it is used, and the population of people affected by it. Assessments conducted solely by IT staff without input from operational areas, or solely by compliance staff without technical input, tend to miss important dimensions. The assessment team should be cross functional.

Findings Not Actioned

An assessment that identifies issues but does not result in documented decisions and actions is worse than useless from a management system perspective. It demonstrates awareness of a problem without any response. Auditors look for the connection between assessment findings and subsequent actions. If that connection is not documented, the assessment has not served its purpose.

How Auditors Will Test Clause 8.4 Compliance

When an auditor examines your compliance with Clause 8.4, they are likely to follow a sequence something like this:

1. Ask to see the list of AI systems in scope for the AIMS and confirm which ones are subject to impact assessment requirements.
2. For each system, ask to see the documented planned interval and the rationale for that interval.
3. Request evidence that assessments have been conducted at those intervals, including dates, participants, and documented outputs.
4. Select one or two assessments and review them in detail to confirm they addressed the required scope, including impacts on individuals and groups.
5. Check whether any significant changes to the AI systems have occurred since the last assessment and whether those changes triggered a reassessment where required.
6. Trace the findings from recent assessments to see whether actions were assigned, completed, and verified as effective.

If you are preparing for a certification audit or a surveillance visit, running through this sequence yourself is a useful way to identify gaps before the auditor does. The article on auditing operational controls and impact assessments under Clause 8 covers the auditor perspective in more detail.

Connecting Clause 8.4 to the Rest of Your AIMS

Clause 8.4 does not operate in isolation. It connects to several other parts of ISO 42001 in ways that matter for both implementation and audit.

The AI risk assessment and treatment processes under Clauses 8.2 and 8.3 are the upstream inputs to impact assessment. The findings from your risk treatment process should inform what you look for in an impact assessment, and the findings from the impact assessment should feed back into risk treatment decisions. These processes should be designed to interact, not run in parallel without connection.

Your documented information requirements under Clause 7.5 apply to impact assessment records. Those records need to be controlled, retained for an appropriate period, and accessible to the people who need them, including auditors.

The Annex A controls, particularly those in A.5 relating to impact assessment, provide additional guidance on what an assessment should consider. While Annex A controls are not automatically mandatory, if your Statement of Applicability has included A.5 controls as applicable, your impact assessments should reflect the guidance those controls provide.

Finally, the results of impact assessments should be reported to top management as part of the management review process. If your management review inputs do not include a summary of AI impact assessment findings, you are missing an important feedback loop. For a detailed look at what the management review under ISO 42001 Clause 9.3 covers, that article walks through the inputs and outputs in detail.

Practical Steps to Build a Repeating Assessment Process

If you are building or improving your Clause 8.4 process, here is a practical sequence to work through:

1. Inventory your AI systems. You cannot assess what you have not identified. Make sure your AIMS scope document and your Annex A.4 resource documentation accurately reflect all AI systems in use.
2. Classify each system by risk and impact level. Use a simple framework that considers consequence severity, affected population size, and rate of change. This classification drives your interval decisions.
3. Set and document planned intervals for each system. Record the rationale alongside the interval. This becomes the evidence base for your interval decisions during an audit.
4. Build the assessment into your operational calendar. Add it to your internal audit schedule or a separate AI governance calendar. It needs to be a scheduled event with a responsible owner, not a task that gets done when someone remembers.
5. Design an assessment template that covers the required scope. Include sections for affected parties, decision impacts, control effectiveness, and findings. A consistent template makes it easier to compare assessments over time and demonstrate trend analysis.
6. Connect your change management process to the assessment trigger. Add a step to your change management procedure that requires a significance assessment for any change to an AI system. If the change is significant, initiate an impact assessment before or shortly after deployment.
7. Assign actions and track them to closure. Findings from impact assessments should enter your corrective action or improvement tracking system. They should not sit in a separate document that no one reviews.

A Note on Proportionality

ISO 42001 is built on the principle of proportionality. The effort you put into impact assessment should be proportionate to the risk and impact of the AI system being assessed. A simple rules based system with limited human impact does not require the same depth of assessment as a machine learning model making consequential decisions about individuals.

This means you do not need to apply the same template or the same level of rigour to every system. What you do need is a documented, defensible basis for the level of effort you applied. Auditors understand proportionality and will not penalise you for a lighter assessment of a genuinely low risk system, provided the classification of that system as low risk is itself documented and justified.

Building Auditor Competence in ISO 42001

Clause 8.4 is one of the areas where auditors without specific ISO 42001 training tend to struggle. The concepts involved, including impact on affected parties, societal implications, and the interaction between technical system behaviour and human outcomes, are not covered in standard quality or safety auditor training. Auditors approaching ISO 42001 for the first time need to develop a working understanding of how AI systems behave and what kinds of impacts they can produce before they can audit this clause effectively.

If you are working towards ISO 42001 auditor credentials or looking to add AI management system auditing to your existing scope, Audit Workshop offers ISO 42001 training at Foundation, Internal Auditor, and Lead Auditor levels. The courses are built around practical audit application, not just clause reading, and they cover the specific challenges of auditing AI impact assessments in operational contexts. You can explore the available courses at auditworkshop.com.