How to put the impact of AI on people and society into a formal document
What ISO/IEC 23894 treats as one element of risk management — impact on individuals and society — ISO/IEC 42005:2025 treats as a standalone, formal assessment procedure. Where ISO/IEC 42001, Clause 6.1.4, makes "carry out an AI system impact assessment" a requirement, ISO/IEC 42005 provides the concrete guidance for designing that assessment and documenting it formally. This page explains how ISO/IEC 42005 defines an impact assessment, the process for running it, and what you document and from what perspective.
Like ISO/IEC 23894, ISO/IEC 42005 is not itself certifiable. It is the guidance an organization preparing for or operating ISO/IEC 42001 draws on when it implements impact assessment — the "how" to ISO/IEC 42001's "what."
Scope note
This overview is based on the published text of ISO/IEC 42005:2025 (first edition, May 2025), read alongside ISO/IEC 42001:2023. Where a term could be ambiguous, the standard's wording is used. For formal citation or document submission, refer to the official standard text.
What is ISO/IEC 42005?
ISO/IEC 42005:2025 is the international standard (first edition) for AI system impact assessment guidance, published by ISO/IEC JTC 1/SC 42 in May 2025. It applies to any organization that develops, provides, or uses AI, of any size, type, or nature. It takes ISO/IEC 22989 and ISO/IEC 23053 as normative references, building on the concepts and terms covered earlier in this series.
Its subject matter is the direct international counterpart to the Fundamental Rights Impact Assessment (FRIA) the EU AI Act requires for certain high-risk AI systems, and to the "Measure" work of the NIST AI Risk Management Framework. An organization that designs one impact-assessment procedure to ISO/IEC 42005 has a structure it can map onto those regulatory obligations rather than building each separately.
The standard has two main clauses and five informative annexes:
- Clause 5 (process) — how to establish and implement the impact-assessment process: when, by whom, and at what thresholds the organization assesses, approves, and reviews.
- Clause 6 (documentation) — what goes into an individual impact assessment. It reads almost like a table of contents for one assessment report.
- Annex A — using it with ISO/IEC 42001: maps which ISO/IEC 42001 clause connects to where in ISO/IEC 42005.
- Annex B — using it with ISO/IEC 23894: the relationship between risk management and impact assessment.
- Annex C — a benefits-and-harms taxonomy, with example benefits and harms per objective, in tables.
- Annex D — aligning with other impact assessments: reducing overlap with existing privacy, human-rights, and security impact assessments.
- Annex E — example impact-assessment templates, ready to use as forms.
Key point 1 — An impact assessment is a "formal, documented process"
ISO/IEC 42005 defines an AI system impact assessment as a formal, documented process by which an organization that develops, provides, or uses AI-enabled products or services considers the impacts on individuals, groups of individuals, and society (3.1). The phrase carrying the most weight in that definition is "formal and documented." It is not a reviewer's subjective judgment or a one-off check, but an activity fixed as a procedure and preserved as an output.
So how does it differ from a risk assessment? ISO/IEC 42005 explains the difference and the relationship in Annex B. Risk management is a higher-level activity covering the whole organization — business strategy, compliance, finance, and technology strategy. Impact assessment has a narrower target: the reasonably foreseeable impacts on individuals, groups of individuals, society, and the environment. It takes a more product- and service-oriented view — focused on the concrete, potential uses of an AI system rather than governance- or management-level issues — and is designed to be carried out by the teams that develop, provide, and technically manage the system.
The crucial point is that the impact assessment does not replace risk management. ISO/IEC 42005 describes it as a key input to a successful risk assessment and an important part of the overall risk management lifecycle. That input relationship comes back below, under the ISO/IEC 42001 connection.
Key point 2 — Separate the process (Clause 5) from the document (Clause 6)
On first reading, the items in Clause 5 and Clause 6 look similar, which is easy to confuse. Telling the two apart is the first step to understanding the standard.
Clause 5 is about how the organization runs the activity of impact assessment: documenting the process (5.2), integrating it with other management processes (5.3), when to perform it (5.4), how to set scope and responsibility (5.5, 5.6), how to set thresholds for sensitive and restricted use (5.7), and how to perform, analyze, record, approve, and monitor (5.8–5.12).
Clause 6 is about what goes into a single impact assessment report: scope (6.2), AI system information (6.3), data (6.4), algorithms and models (6.5), the deployment environment (6.6), interested parties (6.7), actual and foreseeable impacts (6.8), and measures (6.9).
In short, Clause 5 is the process framework for running impact assessment; Clause 6 is the documentation set for an individual report. For an organization preparing for certification, it is natural to split the work — stand up the process with Clause 5, and write each assessment with Clause 6.
Key point 3 — When to perform it, and what triggers a redo (5.4)
A part that is easy to leave out of impact assessment is timing. ISO/IEC 42005 advises deciding in advance at which lifecycle stage, how often, and when to update the assessment (5.4).
In particular, 5.4.2 lists the changes that should prompt a re-assessment: a change in intended use or in users; a change in customer expectations; a change in the AI system itself (its data, complexity, or performance); a change in the operating environment; and a change in context (applicable law, contractual obligations, internal policy, interested parties, operating region). The standard recommends performing the risk assessment and impact assessment before applying such changes.
For cases where assessing every system in full is impractical, ISO/IEC 42005 also proposes a triage procedure (5.4.4): document in the process what counts as a "high-risk" AI system and the conditions that call for a full impact assessment, and use a lightweight assessment to decide first whether a full one is needed.
This timing-and-trigger design makes the impact assessment a recurring activity across the lifecycle rather than a static, one-off output — the "dynamic" principle from ISO/IEC 23894 operating here too.
Key point 4 — Sensitive use, restricted use, and thresholds (5.7)
Another core ISO/IEC 42005 emphasis is documenting thresholds, particularly thresholds tied to how the AI system is used.
Two terms appear here. Sensitive use is use that can have a significant adverse impact on individuals, groups of individuals, or society. Restricted use is use constrained by law, organizational policy, or contract. Factors to weigh when defining thresholds include applicable law, interested-party expectations, the state of the art, the AI system's benefits, cultural/labor/social norms, and the organization's AI ethics framework.
Once a use is classified as sensitive or restricted, the organization has to define the next steps — further review, approval, escalation — in the process. The standard gives an AI system that automates loan decisions as an example of sensitive use, because it can have a significant financial impact on individuals. It also gives an example of escalating all the way to senior management to decide whether to reconsider development itself — for instance where children's rights are significantly affected and the harm is hard to mitigate technically.
Thresholds are not only a sensitive/restricted binary. ISO/IEC 42005 also advises setting an impact scale: a use that is not sensitive but affects a large number of users should have that scale reflected and connected to the next steps.
Key point 5 — What you document, and from what perspective (Clause 6)
Clause 6 lays out, in order, what a single impact assessment report should contain.
Scope, system, data, model
Scope (6.2) identifies the AI system in question, the individuals, groups, and society that could be affected, the intended use and use-case types, and reasonably foreseeable misuse. AI system information (6.3) describes the basic description, functions and capabilities, purpose, intended use, and unintended use.
Data information and quality (6.4) covers the data's source and acquisition path, quantity, provenance, risk of unwanted bias, labeling, quality processes, and access control — and, where PII is involved, whether a data protection impact assessment is needed. Algorithm and model information (6.5) examines the appropriateness, source, and validation of the algorithm, and the model's training method, feature selection, performance metrics, generalization, bias, data drift, retraining, continuous learning, and environmental impact. Where an externally sourced pre-trained model is used, the standard advises re-examining these items against the new data and scenarios.
Deployment environment, interested parties
Deployment environment (6.6) documents both the geographic and linguistic context (discriminated-against, vulnerable, or marginalized groups; the languages an NLP system supports) and the technical deployment environment (cloud, open source, hardware, security considerations). Interested parties (6.7) identifies, separately, the directly affected interested parties (users, vulnerable groups, workers, data subjects) and other interested parties (AI producers, regulators, professional associations). It recommends documenting the results of consultation with affected groups and ensuring individuals have an opportunity to contest, or seek redress for, automated decisions.
Impacts and measures
Actual and foreseeable impacts (6.8) are the heart of Clause 6. Benefits and harms are analyzed for each interested party from the perspective of several objectives: accountability, transparency, fairness and non-discrimination, privacy, reliability, safety, explainability, and environmental impact — a starting point, not an exhaustive list. Annex C provides example benefits and harms per objective in tables. Then 6.8.3 requires documenting separately the impact on interested parties of AI system failure and reasonably foreseeable misuse.
Finally, measures (6.9) documents the technical and managerial actions to realize and manage benefits and mitigate harms. Technical proposals feed the per-system approval procedure; management-level recommendations feed policy setting and the risk treatment plan. This is the link that turns an impact assessment from analysis into actual decisions and risk treatment.
How it connects to ISO/IEC 42001
In the context of this series, ISO/IEC 42005 is most useful as the guide for implementing ISO/IEC 42001, Clause 6.1.4 (AI system impact assessment). ISO/IEC 42005 provides the mapping to ISO/IEC 42001 clauses directly, in its informative Annex A:
- ISO/IEC 42001 6.1.4 corresponds to ISO/IEC 42005 as a whole — where 6.1.4 requires establishing an impact-assessment process, Clause 5 guides the process and Clause 6 the documentation.
- ISO/IEC 42001 8.4 (performing the impact assessment) corresponds to ISO/IEC 42005 5.4 — 8.4 requires performing the assessment on a planned cadence or on significant change, which 5.4's timing-and-trigger design supports.
- ISO/IEC 42001's Annex B guidance also maps across: B.5.2 (process) to Clause 5, B.5.3 (documentation) to Clause 6, and B.5.4/B.5.5 (impact on individuals/groups and society) to 6.7. B.2.2 (AI policy), B.3.2 (roles and responsibilities), and B.4.2 (resources) connect to the corresponding ISO/IEC 42005 clauses too.
A note on ordering: in the body of ISO/IEC 42001, impact assessment (6.1.4) sits after risk assessment (6.1.2), but a NOTE in 6.1.2 says the impact-assessment output can be used as an input to the risk assessment, and ISO/IEC 42005's Annex B likewise describes the impact assessment as a key input to risk assessment. So the clause numbering and the actual order of work need not match. In practice it is natural to perform the impact assessment first or in parallel, and design its output to feed the 6.1.2 AI risk assessment. (See our overview of ISO/IEC 23894 for the risk side.)
From an audit perspective — points to watch
Impact assessment is a requirement handled separately from risk assessment in the ISO/IEC 42001 framework, and in practice the two activities are easily confused. The gaps that can surface include the following. (These are situations that can arise in practice, not assertions of frequency.)
- Substituting a risk assessment — only a loss-focused risk assessment exists, with no separate output addressing impact on individuals and society, so the link to ISO/IEC 42001 B.5.4/B.5.5 is broken.
- Outputs without a process — one or two assessment reports exist, but Clause 5's process (timing, triggers, thresholds, approval) is undefined, so a change does not actually set off a re-assessment.
- Missing threshold and sensitive-use definitions — no documented criteria for what counts as sensitive or restricted use, or what triggers escalation.
- No trace of stakeholder consultation — affected groups are identified, but the consultation and its documented results are easy to leave out.
- A broken link between impact and risk — the impact-assessment output does not flow into the 6.1.2 risk assessment as an input.
In an audit, you would typically be asked to show not just the impact-assessment procedure but the completed impact-assessment outputs and records that the re-assessment trigger has actually fired.
Putting it into practice — where to start
- An organization adopting this for the first time — use the Annex E example templates as a starting point and treat the Clause 6 contents as the items each report must cover. Start with the highest-priority (sensitive or high-risk) systems first.
- An organization preparing for ISO/IEC 42001 certification — implement 6.1.4 with the ISO/IEC 42005 Clause 5 process, map 8.4 to 5.4 and B.5.2/B.5.3/B.5.4/B.5.5 to Clauses 5/6/6.7, and pass the impact-assessment output into the 6.1.2 risk assessment as an input.
- An organization already running other impact assessments — use the Annex D alignment and mapping guidance to reduce overlap with existing privacy (PIA), human-rights (HRIA), and security (SIA) impact assessments, and reuse their outputs as inputs to the AI system impact assessment.
To see where this sits in the wider portfolio, the ISO/IEC AI Standards Map lays out the SC 42 standards by category on a single page.
Key terms at a glance
| Term | Meaning |
|---|---|
| AI system impact assessment | A formal, documented process to identify, assess, and address the impact on individuals, groups, and society (3.1). |
| intended / unintended use | The use an AI system was designed for / a use it was not designed for. |
| reasonably foreseeable misuse | Use that is unintended but can arise from a user's predictable behavior. |
| sensitive use | Use that can have a significant adverse impact on individuals, groups, or society. |
| restricted use | Use constrained by law, organizational policy, or contract. |
| benefits and harms | The positive and negative impacts analyzed per interested party, from the perspective of each objective. |
The bottom line
ISO/IEC 42005:2025 does not invent new impact-assessment principles. It develops the individual-and-society impact that ISO/IEC 23894 treats as one element of risk into a standalone, formal procedure and document, structuring "who is affected, by what, and how to record it." Two things matter most. First, the impact assessment does not replace the AI risk assessment — it complements it and serves as a key input to the risk management process. Second, it is a process repeated across the lifecycle, not a single output. For organizations facing the EU AI Act's FRIA or the NIST AI RMF, it is also the structure that lets one procedure answer to several regimes.
The standard that defines that "lifecycle" itself is the subject of the next article: ISO/IEC 5338:2023 — AI System Lifecycle Processes.
📚 SC 42 AI Standards Series
← Previous: ISO/IEC 23894:2023 — Guidance on AI Risk Management
📍 Current: ISO/IEC 42005:2025 — AI System Impact Assessment
→ Next: ISO/IEC 5338:2023 — AI System Lifecycle Processes (forthcoming)