AI System Impact Assessment Under ISO 42001

What ISO 42001 requires

Clause 8.4 requires the organisation to assess the impacts of AI systems on individuals, groups of individuals, and societies in accordance with the documented process required by Annex A.5. Annex A.5 expands this into four controls covering process, documentation, specific assessment, and review.

When to do an AISIA

• Before deploying a new AI system in scope.
• When the system's intended purpose changes.
• When the operational context changes materially (new geography, new user population).
• On a scheduled review cycle (commonly annual) regardless of changes.
• After a substantive incident that revealed unanticipated impact.

Seven dimensions to cover

1. Intended purpose — what the system is for, and what it explicitly is not for.
2. Affected individuals and groups — direct users, decision subjects, and indirectly affected parties.
3. Fairness — disparate impact across protected groups, including the worst-case sub-population.
4. Safety — physical and material harms that could result from system errors.
5. Privacy — personal data flows, sensitive attributes, re-identification risk.
6. Security — adversarial inputs, model theft, data leakage.
7. Foreseeable misuse — uses the system was not designed for but that users will attempt anyway.

Many organisations add environment (energy and water consumption) and human oversight (how a human can override, monitor or shut down the system) as standing dimensions.

Method

A practical AISIA follows four steps:

1. Describe. Document the system, intended purpose, data, model, deployment context and users.
2. Identify. Brainstorm impacts across the seven (or more) dimensions with the cross-functional team.
3. Rate. Score each impact for severity and likelihood, both inherent and residual after mitigations.
4. Decide. Document the decision (proceed, modify, escalate, defer), the residual risk owner, and the review schedule.

Evidence auditors expect

• A documented AISIA methodology approved at AI governance level.
• A completed AISIA for every AI system in scope, with named owner and approver.
• Traceable links from the AI inventory to each assessment.
• Refresh dates and review records demonstrating the assessment is current.
• For systems with significant residual risk: documented mitigations and the residual risk acceptance decision.

AISIA vs the EU AI Act FRIA

The EU AI Act Article 27 introduces a Fundamental Rights Impact Assessment (FRIA) for certain deployers of high-risk AI systems. AISIA and FRIA are not the same — the FRIA has a statutory minimum content set defined by the Act — but a well-built AISIA covers most FRIA requirements. Most organisations operate one integrated impact assessment that flags the FRIA-specific sections when applicable. See our high-risk AI systems guide for the FRIA detail.

Common pitfalls

• Templating away the substance. Auditors recognise boilerplate. Each assessment must reflect the specific system.
• Single-author assessments. Multi-perspective input (product, ML, legal, domain expert) catches impacts a single author misses.
• Missing foreseeable misuse. The most frequently raised gap in 2026 audits.
• No refresh schedule. An assessment frozen at deployment fails the "kept current" requirement.
• No link to the AI inventory. Auditors trace inventory → assessment → evidence; broken traceability is a finding.