7.4 A.5 Assessing Impacts of AI Systems

Key Takeaways

  • A.5 provides four controls: impact assessment process (A.5.2), documentation of assessments (A.5.3), impacts on individuals or groups (A.5.4), and societal impacts (A.5.5).
  • Clause 6.1.4 requires AI system impact assessment as a management-system planning requirement; A.5 supplies reference controls that operationalize assessing and documenting impacts on people and society.
  • Impact assessment focuses on effects on individuals, groups, and society (and related external consequences), which is complementary to—not identical with—enterprise AI risk assessment under Clause 6.1.2.
  • Auditors evaluate process completeness, documentation quality, coverage of individual/group and societal dimensions, and lifecycle timing (before deployment and after material change).
  • Typical NCs: no process; template never completed for high-impact systems; assessments only internal brand risk; one-time go-live assessment never updated after major model or use-context change.
Last updated: August 2026

7.4 A.5 Assessing Impacts of AI Systems

Auditor focus: A.5 is where ISO/IEC 42001 most clearly differs from a pure information-security standard. You are checking whether the organization systematically assesses who can be harmed or affected—individuals, groups, and society—and whether that work is documented and refreshed across the AI life cycle.

Control objective (intent): Identify and assess potential consequences of AI systems for individuals, groups, and society so that impacts can be addressed through the AIMS.


A.5 Control Map

ControlNameAuditor essence
A.5.2AI system impact assessment processDefined, repeatable process for performing assessments
A.5.3Documentation of AI system impact assessmentsResults retained as documented information
A.5.4Assessing impact on individuals or groups of individualsExplicit analysis of effects on people/groups
A.5.5Assessing societal impacts of AI systemsExplicit analysis of broader societal effects

Linkage to Clause 6.1.4

Clause 6.1.4 requires the organization to assess the potential consequences of AI systems for individuals and societies (AI system impact assessment) as part of planning. Annex A.5 provides the detailed control set for process, documentation, and the individual/group vs societal dimensions.

ElementClause 6.1.4 (planning requirement)Annex A.5 (controls)
Mandate to assess impactsManagement system shall perform AISIA as specifiedA.5.2–A.5.5 structure how
Scope of effectsIndividuals and societies (and related consequences per the clause text)A.5.4 people/groups; A.5.5 society
RecordsDocumented information as required by the clauseA.5.3 documentation control
Audit citationUse when planning process missing at AIMS levelUse when control design/implementation of impact assessment fails

In practice, Stage 1/2 findings often cite 6.1.4 and A.5 together when no credible impact assessments exist for in-scope high-impact systems.

Impact assessment vs risk assessment

AI risk assessment (6.1.2 family)AI system impact assessment (6.1.4 / A.5)
Primary focusRisks to organizational objectives (operations, finance, compliance, reputation, security of the org)Effects on external parties—individuals, groups, society
ExampleModel outage causes revenue lossModel bias denies credit to a protected group
ExampleIP leakage of model weightsMass profiling chills free expression
RelationshipInputs treatment and SoAInputs treatment, controls, human oversight, transparency

Trap: A risk register that only lists “regulatory fine” and “brand damage” without analyzing harms to affected persons is not a complete impact assessment—even if enterprise risk scores are sophisticated.


A.5.2 — Impact Assessment Process

Expect a defined process covering at least:

  1. Triggers — new system, new intended use, major model/data/context change, periodic review, incident-driven reassessment
  2. Roles — who drafts, who reviews, who accepts residual impact
  3. Method — steps to identify stakeholders, impacts, severity/likelihood or qualitative scales, mitigations
  4. Inputs — system description, intended use, reasonably foreseeable misuse, data categories, automation level, human oversight design
  5. Outputs — decisions feeding risk treatment, design controls, deployment gates, monitoring
  6. Integration — link to SoA, life-cycle gates (A.6), transparency (A.8), use controls (A.9)

Interview probes:

  • When is an assessment mandatory before production?
  • Who can waive an assessment, and is waiver allowed for high-impact systems?
  • How is “significant change” defined for re-assessment?

Weak process signs: one-page “ethics checklist” with yes/no boxes and no stakeholder analysis; process owned solely by marketing; no deployment gate dependency.


A.5.3 — Documentation

Documented impact assessments should be retrievable, complete enough to reconstruct reasoning, and controlled.

Typical content auditors look for (scaled to risk):

Content elementWhy it matters
System identity & version / dateTraceability to deployed model
Intended purpose & usersBounds analysis
Affected individuals/groupsA.5.4 completeness
Societal considerationsA.5.5 completeness
Positive and adverse impactsBalanced analysis
Foreseeable misuseAbuse cases
Measures to address impactsLink to treatment
Residual concerns & acceptanceAccountability
ApprovalsAuthority

NC example: Process document exists (A.5.2 appears designed) but zero completed assessments for three production high-impact systems → A.5.3 / 6.1.4 implementation failure.


A.5.4 — Individuals or Groups of Individuals

Assess impacts on people, including groups who may be differentially affected:

Impact themeExamples
Rights & dignityPrivacy intrusion, unjust automated decisions, lack of contestability
Discrimination / fairnessDisparate error rates across demographic groups
Safety & wellbeingIncorrect medical triage, unsafe recommendations
EconomicUnfair denial of jobs, credit, insurance
Vulnerable groupsChildren, elderly, disabled users, marginalized communities

Sampling: For a hiring model, expect analysis of candidates as affected individuals, subgroup performance considerations, and human review pathways—not only “improves HR efficiency.”


A.5.5 — Societal Impacts

Societal lens looks beyond single-transaction harm:

ThemeExamples
Labor & economyLarge-scale workforce displacement patterns
Public discourseAmplification of misinformation via generative systems
EnvironmentMaterial energy/water impacts of large-scale training where relevant to context
Public services & trustErosion of trust in institutions from opaque public-sector AI
Collective rightsCommunity-level surveillance effects

Not every system has dramatic societal effects—but the assessment should consider the dimension and document why effects are limited when that is the conclusion. Blank silence on society for a city-wide camera analytics platform is a red flag.


Lifecycle Timing and Completeness Evaluation

Lead auditors test when assessments occur relative to decisions that can harm people:

Lifecycle pointExpectation
Concept / designEarly impact framing informs requirements
Pre-deploymentCompleted assessment before high-impact go-live
Material changeRe-assessment after major model, data, or use-context change
PeriodicPlanned refresh for long-lived high-impact systems
Post-incidentUpdate after harms or near-misses

Completeness scorecard:

  1. Process defined and known (A.5.2)?
  2. Records exist for sampled systems (A.5.3)?
  3. Individual/group analysis substantive (A.5.4)?
  4. Societal analysis considered (A.5.5)?
  5. Timing correct relative to deployment/change?
  6. Outputs visible in treatment, monitoring, and oversight design?
  7. Alignment with Clause 6.1.2 risks without collapsing into pure enterprise risk?

Scenario — InsurTech claims automation

System auto-denies low-value claims with optional human appeal. Impact assessment from two years ago covers “customer satisfaction” only. Model and fraud features changed three times; denial rates rose for a regional language minority. No re-assessment. Findings: A.5.2 trigger failure; A.5.3 stale/incomplete docs; A.5.4 inadequate group analysis; possible 6.1.4 and monitoring (9.1) gaps.

Scenario — Internal code assistant

Low external individual impact if scoped to internal developers with IP controls. Assessment may be lighter but should still exist if the AIMS/SoA applies A.5; document limited external impact with rationale. Do not accept “internal = never assess” if the tool can leak personal data or generate unsafe operational scripts affecting third parties.


Evidence Pack and NC Patterns

Evidence / NC patternNotes
Procedure + completed AISIA reportsA.5.2 design; A.5.3–A.5.5 substance
Deployment gates & change-linked re-assessmentLifecycle timing
Treatment/SoA/management-review linkageProcess effectiveness
No process / no records6.1.4 + A.5.2 / A.5.3
Only enterprise risk languageA.5.4/A.5.5 substance missing
One-time ethics essay; blanket product waiversTiming and integrity failures

Bottom line: A.5 forces the organization to look outward at human and societal consequences, document that look, and repeat it when systems change. With A.2–A.5, governance policy, organization, resources, and impact foundations are in place for the life-cycle and data controls that follow.

Test Your Knowledge

Which statement best distinguishes Clause 6.1.4 AI system impact assessment from typical enterprise AI risk assessment?

A
B
C
D
Test Your Knowledge

Which set lists the four Annex A.5 controls?

A
B
C
D
Test Your Knowledge

A high-impact lending model was impact-assessed at initial launch. Eighteen months later the model architecture, training data mix, and geographic market all changed, but no re-assessment was performed. Which evaluation best fits A.5?

A
B
C
D
Test Your Knowledge

What documentation package best supports A.5.3 for a high-risk public-sector benefits eligibility AI system?

A
B
C
D