Welcome back to the series, and to the post I have been quietly putting off since Clause 6. The AI System Impact Assessment — known affectionately, by no one, as the AISIA — is the requirement most likely to be unfamiliar, the requirement most likely to be misunderstood as something else, and the requirement most likely to send your implementation team to a whiteboard for several hours and then to lunch. We did Annex A at survey altitude last time. Today we descend.
The reason this deserves its own treatment is straightforward: it is the part of ISO/IEC 42001:2023 that does not, structurally, exist in any other management system standard. Not ISO 27001. Not ISO 9001. Not ISO 14001. Each of those is, fundamentally, about protecting the organisation and the integrity of its outputs. The AI System Impact Assessment is about the individuals, groups, and societies on the receiving end of what the organisation produces. ISO has, after a fashion, written outward-facing obligations into a management standard. This is unusual. Please appreciate it.
Where the Requirement Actually Lives
The AISIA is referenced in three places, and each matters in a slightly different way.
Clause 6.1.4 — the requirement itself. The organisation shall assess potential consequences for individuals, groups of individuals, and society arising from the development, provision, or use of AI systems. The assessment shall be performed, documented, and updated when significant changes occur. The text is short and almost shrug-like on the page. Do not be misled by the brevity; it is doing a great deal of work.
Annex A.5 — the controls that operationalise it. A.5.2 covers the impact assessment process; A.5.3 covers documentation; A.5.4 covers impacts on individuals and groups of individuals; A.5.5 covers societal impacts. These are the controls that, in your Statement of Applicability, you will mark as applicable and then have to actually do something about. (If you skipped to this post, the SoA was foreshadowed in the Annex A overview. It is the spreadsheet that proves the deliverables.)
Annex B.5 — informative implementation guidance for A.5. It is not a normative requirement. The auditor will, however, assume you have read it, and your life will be easier if that assumption is correct.
What Makes It Genuinely Different
I have, over the course of explaining this clause to clients, watched several intelligent people nod and say, “ah, like a DPIA.” It is not, quite, like a DPIA. Allow me to enumerate the differences, because the differences are the entire point.
It is broader than a privacy impact assessment
A DPIA asks: what happens to personal data? The AISIA asks: what happens to people, regardless of whether personal data is involved. A recommender system that subtly homogenises cultural consumption may not, on most readings, process personal data in a way that triggers a DPIA. It is, however, well within the scope of an AISIA. Personal data is one possible vector of harm; it is not the only one, and the standard is admirably clear on this.
It is outward-facing where risk assessment is inward-facing
Clause 6.1.2 (AI risk assessment) is concerned with risks to the AIMS — risks to the organisation’s ability to achieve its AI objectives. Clause 6.1.4 (AISIA) is concerned with risks to others — to the individuals, groups, and societies the AI system touches. These are not the same exercise, and they should not be the same document. Yes, they can — and should — cross-reference one another. They remain distinct artefacts, and auditors will check.
It covers groups and societies, not just individuals
This is the part organisations most consistently underestimate. A.5.4 covers individuals and groups. A.5.5 covers society at large. The standard is asking you to consider — and document — effects such as algorithmic discrimination against demographic categories, erosion of public trust in information ecosystems, and cumulative impacts that no single user would experience individually but that aggregate into something material. You do not need a complete answer to these questions. You do, however, need to demonstrate that you asked them.
It covers misuse, not just intended use
Annex B.5 expects you to consider reasonably foreseeable misuse of the system, not merely the use case in the product brief. If your system is a content classifier and one can foresee it being re-purposed for moderation in jurisdictions where the consequences of misclassification are severe, the AISIA should say so. “We didn’t intend that” is not, here, a defence.
What an Actual AISIA Looks Like
The standard, true to ISO form, does not prescribe a template. Annex B.5, however, describes the shape of a defensible process. Distilled:
1. Define the system in scope. Purpose, capabilities, deployment context, affected population. Be specific. “The model” is not a scope. “The credit-decisioning model deployed in the UK retail banking flow as of [date]” is.
2. Identify the affected parties. Users, subjects of decisions, indirect third parties, society. Not every category will be material for every system, but you must consider all of them.
3. Characterise potential impacts. By category — fairness, autonomy, safety, dignity, economic effect, environmental effect, broader societal effect. By severity, likelihood, and reversibility. Include both intended use and reasonably foreseeable misuse.
4. Identify mitigations. Technical (bias testing, human-in-the-loop review, output filtering). Procedural (usage policies, customer instructions per A.10). Informational (disclosures to users and affected parties per A.8). The mitigations are where the AISIA reaches out and touches the rest of Annex A.
5. Document everything; review on cadence and on change. The standard is explicit that AISIAs are not one-off artefacts. Material changes to deployment context, training data, or affected population trigger an update. A.5.3 exists precisely to ensure that you can produce the record.
Annex B.5 also gestures, helpfully, towards adjacent frameworks — the NIST AI Risk Management Framework, the OECD AI Principles, sector-specific guidance — where they help structure the assessment. These are not normative references. They are useful intellectual scaffolding, and your auditor will not penalise you for having read them.
What Changed, What’s Novel, What’s Quietly Radical
Three things deserve calling out, since this post is, after all, about what makes the AISIA different.
It is a first-of-its-kind requirement in management system standards. No other ISO management standard imposes a structured obligation to assess third-party impact at this level of granularity. The closest analogues are regulatory — GDPR DPIAs, EU AI Act conformity assessments — rather than voluntary-framework obligations. ISO 42001 has imported a regulator-style instinct into a voluntary scheme. This is, depending on your disposition, either bold or annoying. Possibly both.
It is iterative, not one-off. Unlike CE marking or many regulatory conformity assessments, the AISIA is not something you complete once and file. It is part of the management system’s continual improvement loop — which is why A.5.2 frames the process as the control, not any particular assessment artefact produced by it.
It is the bridge between the AIMS and the world outside it. Most of ISO 42001 is, by structural inheritance from Annex SL, about how the organisation runs itself. Clause 6.1.4 and Annex A.5 are the parts where the standard concedes that AI systems exist in a context broader than the organisation that built them. It is a small concession in word count. It is a very large concession in intent.
An Editorial Aside
I find the AISIA quietly remarkable. ISO has, in its careful, slightly tortured, fluorescently-lit way, written into a voluntary management framework a requirement that organisations producing AI must think — formally, on the record, with retained evidence — about people they will never meet. It is the sort of thing one wishes had been required of several earlier technologies, ideally before they were deployed at population scale. It is, in any case, here now, and your job is to do it well enough that the auditor signs the page and, ideally, that the people downstream of your model are measurably better off for the exercise.
Closing
So the AISIA: not a privacy impact assessment, not a risk register, not a press release. Its own creature, with its own process, its own documented evidence, and its own review cadence. Next time in the series, we begin the proper descent into Annex A — grouped, mercifully, into a small number of thematic posts so that none of us expire of the pace. First up: the governance core — Policies (A.2), Internal Organization (A.3), and Resources (A.4) — the three sections that, together, determine whether anyone in your organisation actually has the authority to do any of this. Until then.