Identifying Affected Individuals and Groups in an ISO/IEC 42005 Impact Assessment

Where this step sits in the assessment process

ISO describes ISO/IEC 42005 as a repeatable process for identifying, analyzing and documenting both intended and unintended effects of an AI system on individuals, groups and society. It is positioned as the detailed methodology for assessing individual AI systems, complementing ISO/IEC 42001, which provides the management system around them.

Identifying affected parties is a precondition for the rest of that process. An assessment cannot analyze effects on a group that nobody has named, and it cannot defend an impact conclusion if the group list is thin. Regulated enterprises tend to fail here for a predictable reason: the list is produced in a single workshop, covers users and operators, and is never revisited.

The more reliable approach is to treat the step as an engineering and documentation task. It has defined inputs, a structured register as its output, a named owner, and a review cadence tied to changes in the system and its context. The register then becomes an input to impact analysis, control selection and evidence planning.

Categories of affected parties

The NIST AI RMF draws a distinction that is useful for any impact assessment. End users are the individuals or groups that use the system for specific purposes in a specific context. Affected individuals and communities are all individuals, groups, communities or organizations directly or indirectly affected by the system or by decisions based on its output, and they do not necessarily interact with the deployed system. A register limited to users and operators does not meet that second definition.

A workable category set for the register follows.

• Direct users and operators: People who interact with the system in its deployed context, including staff who review or override its outputs.
• Indirect affected individuals: People who never use the system but are subject to decisions or outputs derived from it.
• Downstream parties: Organizations, teams or communities that receive outputs, or act on decisions informed by them.
• Vulnerable and marginalized groups: Historically marginalized communities, people with disabilities and individuals affected by the digital divide, named explicitly rather than implied.
• Societal groups: Broader communities and society, where the system's effects extend beyond identifiable individuals.
• Sub-groups within each category: Harms can differ across sub-groups, so record the split wherever the context suggests it matters.

Inputs and method for building the register

Start at the earliest stage of system formulation and record the engagement process itself, not only its results. Late identification tends to produce a register shaped by the design that already exists. The sequence below uses inputs that are available before any testing.

• 1. Seed from definitions: Begin with the end user versus directly or indirectly affected party definitions, applied to the system's specific purpose and context.
• 2. Add named communities: Test each named vulnerable community against the use case and record whether it is in scope or excluded.
• 3. Import documented stakeholders: Pull in the internal and external stakeholders already documented when the system's context was mapped.
• 4. Engage and consult: Include perspectives from operators, users and potentially impacted communities, using quantitative, qualitative and mixed methods.
• 5. Classify each entry: Record whether the group is directly or indirectly affected, and whether it interacts with the system.
• 6. Record rationale and assumptions: State why each group is included or excluded and what context-specific assumptions the judgment rests on.

Alignment with ISO/IEC 42001 and the NIST AI RMF

ISO/IEC 42001 and ISO/IEC 42005 are presented as complementary. The management system sets policy, resources and accountability, while the impact assessment examines a specific system. In practice that means the resourcing of impact assessment should be a standing policy decision rather than an ad hoc workshop, and the affected-party register should be a controlled document within the management system.

The NIST AI RMF supports the same practice. It states that harm can fall on individuals, groups, communities, organizations, society and the environment, that contexts matter, and that harmed communities are not always direct users. Its Playbook calls for documented stakeholder engagement and for mechanisms to share feedback from impacted individuals and to give them recourse to contest outcomes. The NIST generative AI profile tags impact assessment actions with AI actor roles, including AI impact assessment and affected individuals and communities, which is a practical model for recording who identifies, who is consulted and who owns each update. NIST also lists a crosswalk between ISO/IEC 42005 and the AI RMF that can help align documentation across the two frameworks.

These are NIST statements about its own framework. Use them to strengthen the register, and map them to your own reading of the standard's requirements.