Assess and Document AI Impacts on Individuals and Groups
The organisation must assess and document how its artificial intelligence (AI) systems could affect individuals or groups of people across the whole life of each system.
Plain language
This control is about working out, in advance and on an ongoing basis, how your artificial intelligence (AI) systems could affect real people. An AI system might influence someone's job application, a loan decision, the price they are offered, or how they are treated by a service. Some of those effects can be harmful, such as unfair treatment of a particular group, loss of privacy, or a decision that disadvantages someone with no easy way to challenge it. This control requires you to deliberately look for those possible impacts, write them down, and keep that assessment current throughout the system's life cycle, meaning from the first idea, through building and launching it, while it runs day to day, and right up to when you retire it. The point is that you understand the human consequences of your AI before they cause harm, and that you have a written record showing you thought it through. As part of your AI management system (AIMS), this documented assessment becomes evidence that you take responsibility for how your AI affects people, not just whether it works technically.
Framework
ISO/IEC 42001:2023
Control effect
Proactive
Classifications
N/A
Official last update
01 Dec 2023
Control Stack last updated
18 June 2026
Maturity levels
N/A
Official control statement
The organisation shall assess and document the potential impacts of AI systems to individuals or groups of individuals throughout the system's life cycle.
Why it matters
If you never assess how an AI system affects people, it can quietly harm individuals or unfairly disadvantage whole groups before anyone notices.
Operational notes
Refresh each impact assessment whenever a system materially changes or is retrained, and review all of them on a regular schedule, such as annually.
Implementation tips
- The AI lead should keep a register of every AI system in use or under development and, for each one, record which individuals or groups it could affect, such as customers, employees, job applicants, or vulnerable people.
- The risk owner should run a structured impact assessment at the start of each AI project that asks how the system could harm people through unfair treatment, privacy loss, exclusion, financial detriment, or safety, and document the findings before the system goes live.
- The project team should repeat or review each impact assessment at defined points in the life cycle, for example after a major change, after retraining the model, or at least annually, and date-stamp each version so changes over time are visible.
- The product owner should pay particular attention to impacts on groups rather than just individuals, checking whether any outcome falls more heavily on people sharing a characteristic such as age, gender, disability, or location, and record that analysis.
- The compliance manager should store all completed impact assessments in one accessible place and link each one to the decision it informed, so the organisation can show that documented impacts actually shaped how the AI system was designed, used, or restricted.
Audit / evidence tips
- Aska list of the organisation's AI systems and the documented impact assessment for each one, then check that every live system has an assessment rather than only the flagship products
- Look ata sample of impact assessments and confirm they actually name the individuals or groups affected and describe specific potential harms, not just generic statements that the system is safe
- Askhow impacts on groups of people were considered, and look for evidence that the organisation checked whether outcomes disadvantage a particular group, since good practice covers both individuals and groups
- Look atthe dates and version history of the assessments to confirm they are reviewed across the life cycle, for example updated after major changes or retraining, rather than written once and forgotten
- Gooda current, dated impact assessment for each AI system that names affected people, lists realistic harms, and is clearly linked to design or operating decisions the organisation took as a result
Cross-framework mappings
How Annex A 5.4 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| sync_alt Partially overlaps (1) expand_less | ||
| Annex A 5.34 | ISO/IEC 42001:2023 Annex A 5.4 requires the organisation to assess and document potential impacts of AI systems on individuals or groups ... | |
ASD ISM
| Control | Notes | Details |
|---|---|---|
| sync_alt Partially overlaps (1) expand_less | ||
| ISM-1203 | ISO/IEC 42001:2023 Annex A 5.4 requires the organisation to assess and document potential impacts of AI systems on individuals or groups ... | |
| handshake Supports (4) expand_less | ||
| ISM-0009 | ISO/IEC 42001:2023 Annex A 5.4 requires the organisation to assess and document potential AI impacts on people across the AI system life ... | |
| ISM-0041 | ISO/IEC 42001:2023 Annex A 5.4 requires documented assessment of AI impacts on individuals and groups throughout the AI system life cycle | |
| ISM-0888 | Annex A 5.4 requires continuous life-cycle assessment and documentation of AI impacts on individuals or groups | |
| ISM-2120 | ISM-2120 necessitates a secure software development policy to define secure design and development practices | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Want to implement this AI control?
Mindset Cyber runs PECB-accredited ISO/IEC 42001 training that maps directly to the AI controls in this library.