Most organisations certified to ISO\/IEC 42001:2023 performed their AI impact assessment once. It sits in the AIMS document register dated to initial deployment, version-controlled, approved, and untouched. The AI system it describes has retrained twice, ingested new data sources, and expanded to a user population the original assessment never contemplated. The assessment describes a system that no longer exists.<\/p>\n\n\n\n

Clause 8.2 of ISO\/IEC 42001:2023 requires AI risk assessments and impact assessments to be performed “at planned intervals or when significant changes are proposed or occur.” The phrase “significant changes” carries the full weight of the reassessment obligation \u2014 and the standard does not define it.<\/p>\n\n\n\n

That undefined threshold is where most AIMS implementations quietly fail.<\/p>\n\n\n\n

What ISO 42001 Clause 6.1.2 and 6.1.4 Actually Require<\/h2>\n\n\n\n

ISO\/IEC 42001:2023 splits AI risk governance across two parallel assessment obligations that must operate as a linked cycle.<\/p>\n\n\n\n

Clause 6.1.2 requires a formal AI risk assessment process \u2014 identification, analysis, evaluation, and prioritisation of AI-related risks. The process must produce consistent, comparable results across assessment cycles. Clause 8.2 operationalises this by mandating reassessment at planned intervals and when significant changes occur. Documented results must be retained for each cycle, not just the first.<\/p>\n\n\n\n

Clause 6.1.4 requires a separate AI system impact assessment \u2014 an evaluation of consequences for individuals, groups, and societies. This covers ground that technical risk assessment misses: bias effects on specific populations, accessibility failures, consequences that shift when the system deploys into a new jurisdiction. Annex A control A.5.2 specifies the trigger conditions more concretely than the core clauses: major system updates, data source shifts, business function expansion, regulatory changes, and incidents all mandate reassessment.<\/p>\n\n\n\n

The two assessments feed each other. Impact assessment outputs inform risk treatment decisions under Clause 6.1.3. Risk assessment findings shape the scope of the next impact assessment cycle. Neither functions as a standalone document \u2014 they are linked processes that must move together when the AI system changes.<\/p>\n\n\n\n

Clause 6.1.3 reference reflects mapped standard requirement. Verify against current edition before audit use.<\/p>\n\n\n\n

<\/figure>\n\n\n\n

Where AI Impact Assessment Implementations Fail<\/h2>\n\n\n\n

The dominant failure pattern is classification inaction. Organisations understand that significant changes require reassessment. They accept the principle during implementation. Then they never formally define what constitutes a significant change in their AIMS documentation.<\/p>\n\n\n\n

Without that definition, every model retrain passes without a documented classification decision. Every data refresh, every scope extension, every prompt-engineering change that alters decision logic \u2014 none of these events trigger a formal review because the mechanism to classify them does not exist. The AI impact assessment remains permanently dated to initial deployment.<\/p>\n\n\n\n

Auditors encountering this pattern find a single assessment record with no subsequent versions and no documented rationale explaining why reassessment was not required. GloCert International flags this as a major nonconformity candidate: impact assessments not conducted for all in-scope AI systems, or assessments that do not address impacts on affected individuals after system changes. No version history, no defence.<\/p>\n\n\n\n

A secondary failure compounds the first. Clause 9.1 monitoring often detects model drift or performance degradation \u2014 the data exists in dashboards and logs. But no documented escalation path connects monitoring outputs to the Clause 6.1.2\/6.1.4 reassessment cycle. The two processes run in separate silos. Drift data that should trigger a “significant change” classification review sits in an operational dashboard and goes nowhere near the risk governance function.<\/p>\n\n\n\n

Why August 2026 Makes This Urgent<\/h2>\n\n\n\n

Organisations using ISO 42001 certification as their EU AI Act governance framework face a specific problem. EU AI Act Article 9 requires a risk management system for high-risk AI systems that operates as a continuous iterative process planned and run throughout the entire lifecycle, with regular systematic review and updating. Article 9 explicitly links risk reassessment to post-market monitoring data collected under Article 72 \u2014 creating a near-continuous trigger, not an interval-based one.<\/p>\n\n\n\n

ISO\/IEC 42001:2023 Clause 8.2 permits a static schedule if no significant changes are defined. Article 9 does not. The two frameworks are compatible only if the organisation actively bridges the gap \u2014 calibrating its AIMS reassessment intervals to post-market monitoring cycles so that Article 9’s continuous-iterative obligation is satisfied through the AIMS rather than through a parallel process.<\/p>\n\n\n\n

The enforcement date for high-risk AI system obligations under Articles 9\u201317 is 2 August 2026. Penalties for non-compliance range up to \u20ac35 million or 7% of global annual turnover for the most serious violations. An ISO 42001 certificate that demonstrates a static, single-point assessment cycle will not satisfy Article 9 for Annex III high-risk systems.<\/p>\n\n\n\n

No CB or accreditation body has published specific guidance defining trigger conditions or minimum frequency for AI impact assessment refresh when underlying models change. Auditors default to their own interpretation of Clause 8.2. Organisations that define the threshold themselves and produce evidence of consistent application are better positioned than those waiting for CB guidance that does not yet exist.<\/p>\n\n\n\n

<\/figure>\n\n\n\n

Three Steps to Close the Reassessment Gap Before Surveillance<\/h2>\n\n\n\n

1. Define “significant change” in your AIMS documentation.<\/strong> Create an AI Model Change Classification Policy that specifies threshold categories: retraining on new or updated data, fine-tuning or prompt changes altering decision logic, deployment scope expansion, new data source integration, monitoring outputs exceeding defined drift thresholds, and regulatory or legal changes affecting operating context. Assign a classification owner accountable for each determination. Annex A.5.2 already lists the trigger categories. Build your policy around them.<\/p>\n\n\n\n

2. Retrofit a change register for existing AI systems.<\/strong> For each in-scope system, document the date of the original impact assessment, every model or deployment change since that date, and a recorded determination for each change event \u2014 either triggering reassessment, or documenting \u2014 with classification owner sign-off \u2014 why reassessment was not required. Where changes occurred without documented rationale, conduct a retrospective assessment before the surveillance audit and log it as a corrective action under Clause 10.<\/p>\n\n\n\n

3. Connect Clause 9.1 monitoring to the reassessment cycle.<\/strong> Modify your monitoring framework to include a documented escalation path: when metrics exceed defined drift or performance thresholds, a formal “significant change” classification review is initiated. The output either triggers a Clause 6.1.2\/6.1.4 reassessment or produces a documented “no reassessment required” determination with rationale. For EU AI Act high-risk systems, align this cycle with Article 72 post-market monitoring intervals.<\/p>\n\n\n\n

The Single Thing to Remember<\/h2>\n\n\n\n

An AI impact assessment is not a deployment gate. It is a lifecycle document. If your AIMS cannot answer the question “what changed since the last assessment, and who decided it didn’t require reassessment?” \u2014 you have a structural nonconformity that will surface at surveillance. Define the threshold. Build the register. Connect the monitoring. The standard requires it. The EU AI Act demands it. And your auditor will ask for it.<\/p>\n\n\n\n

<\/figure>\n\n\n\n

About AEC International<\/h4>\n\n\n\n

AEC International provides ISO certification, training, and consultancy services at the intersection of AI governance, information security, and management system implementation. We support organisations across industries in achieving and maintaining ISO certification \u2014 from gap analysis and implementation through audit preparation and continual improvement.<\/p>\n\n\n\n

Learn more: www.aec.llc<\/p>\n","protected":false},"excerpt":{"rendered":"

Most ISO 42001 AI impact assessments are performed once and never updated. Clause 8.2 requires reassessment when significant changes occur \u2014 but most organisations never define that threshold. Here’s how to close the gap before surveillance. <\/p>\n","protected":false},"author":1,"featured_media":49,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[13,24,12],"class_list":["post-48","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-audit-preparation","tag-internal-audit","tag-iso-42001","tag-risk-management"],"reading_time":"5 min read","_links":{"self":[{"href":"https:\/\/aec.llc\/blog\/wp-json\/wp\/v2\/posts\/48","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/aec.llc\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/aec.llc\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/aec.llc\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/aec.llc\/blog\/wp-json\/wp\/v2\/comments?post=48"}],"version-history":[{"count":1,"href":"https:\/\/aec.llc\/blog\/wp-json\/wp\/v2\/posts\/48\/revisions"}],"predecessor-version":[{"id":53,"href":"https:\/\/aec.llc\/blog\/wp-json\/wp\/v2\/posts\/48\/revisions\/53"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/aec.llc\/blog\/wp-json\/wp\/v2\/media\/49"}],"wp:attachment":[{"href":"https:\/\/aec.llc\/blog\/wp-json\/wp\/v2\/media?parent=48"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/aec.llc\/blog\/wp-json\/wp\/v2\/categories?post=48"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/aec.llc\/blog\/wp-json\/wp\/v2\/tags?post=48"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}