4.2 Clause 6.1.4 AI System Impact Assessment

4.2 Clause 6.1.4 AI System Impact Assessment

Auditor focus: Has the organization assessed how in-scope AI systems can affect people and society—not only how AI failures hurt the business? Are assessments timed in the lifecycle, scoped to real systems, and fed back into risk treatment and Annex A.5 controls? A GDPR DPIA alone is usually insufficient.

Clause 6.1.4 is one of the most distinctive planning requirements in ISO/IEC 42001. While many management-system standards concentrate on organizational risk, 42001 explicitly requires the organization to assess the impacts of AI systems on individuals, groups of individuals, and societies. Lead auditors who miss this distinction will under-audit AI ethics, fundamental rights, and external harm pathways.

---

What 6.1.4 Requires (Substance)

The organization shall assess the potential consequences of AI systems for individuals and societies throughout the AI system lifecycle as appropriate to its role and the systems in scope. In practice, a defensible AI system impact assessment (AISIA) process typically defines:

• When assessments are required (new system, significant change, new population, new deployment context, third-party model introduction).
• What is assessed (intended use, foreseeable misuse, affected populations, decision stakes, automation level, human oversight, data sensitivity, environmental effects where relevant).
• Who participates (product owners, ML engineers, legal/privacy, ethics, domain experts, and where appropriate, representatives of affected groups).
• How results are documented, approved, and linked to risk treatment and controls.
• How often reassessments occur and what triggers them.

Templates vary; auditors test completeness, application, and feedback into the AIMS, not a branded form name.

---

Distinction: Organizational Risk Assessment vs Impact Assessment

Feedback loop: Impact findings shall inform AI risk assessment and treatment. Example: a credit-scoring model’s disparate impact on a protected group is both an external impact (6.1.4) and an organizational risk (regulatory, reputational, ethical failure under 6.1.2). Treatment may include data remediation, model redesign, human review, restricted use cases, or non-deployment—then reflected in the SoA and Annex A.5 controls.

  Context (4) + Policy (5)
           |
           v
   +-------------------+
   | 6.1.4 Impact      |-----> affected people/society analysis
   | Assessment        |
   +---------+---------+
             |
             v feeds
   +-------------------+
   | 6.1.2 AI Risk     |
   | Assessment        |
   +---------+---------+
             |
             v
   +-------------------+
   | 6.1.3 Treatment   |-----> Annex A controls + SoA
   | + residual accept |
   +-------------------+

---

Relationship to Annex A.5 (Assessing Impacts of AI Systems)

Annex A.5 provides control objectives and controls that operationalize impact assessment—for example, establishing processes for impact assessment, documenting assessments, and ensuring results are considered in the AI system lifecycle. Auditors should:

1. Confirm whether A.5 controls are applicable in the SoA (exclusions need strong justification for organizations that develop, provide, or use AI systems with people impact).
2. Sample implemented A.5 controls against actual impact assessment reports.
3. Trace high-impact systems from inventory → 6.1.4 report → risk treatment → A.5 evidence → monitoring after deployment.

A.5 is not a substitute for Clause 6.1.4; it is the control set that often implements the planning requirement.

---

What Auditors Sample

1. Impact assessment reports

Look for structured analysis of:

• System purpose and decision type (assistive vs automated; reversible vs irreversible).
• Affected individuals and groups (customers, employees, patients, applicants, bystanders, vulnerable populations).
• Potential adverse impacts (rights, safety, fairness, dignity, economic opportunity, environment where relevant).
• Positive impacts and intended benefits (balanced analysis; not only harms).
• Mitigations and residual concerns (including human oversight and redress).
• Approval and version (who signed, for which model version / deployment).

2. Scope of systems assessed

Compare the AI system inventory (from Clause 4 scope and operational control) with completed assessments. High-stakes systems (HR screening, credit, healthcare triage, content moderation affecting speech, biometric identification) should not be “planned for later” without risk-based justification.

3. Timing in the lifecycle

Impact assessment is weak if performed only as a pre-certification paper exercise after production deployment. Auditors expect assessments before high-impact deployment and reassessment after significant changes (new training data distribution, architecture change, new geography, new user population, material prompt/system-instruction change for generative systems).

---

Traps and Nonconformity Patterns

Trap 1: Checkbox privacy DPIA only

A privacy impact assessment focused on personal data processing is valuable and may overlap, but privacy ≠ full AI impact. Fairness, safety, human agency, labor displacement, large-scale content harms, and group-level stereotyping may fall outside a narrow DPIA. Auditors should record whether the organization’s procedure claims “DPIA = 6.1.4 compliance” without broader criteria.

Trap 2: Enterprise risk double-counting without external lens

Some auditees rename their 6.1.2 register as “impact assessment.” If every row still measures only financial/regulatory impact to the company, 6.1.4 is not met.

Trap 3: Template with empty “society” fields

Reports that list “N/A — B2B tool” without analysing how B2B AI decisions affect end customers or workers often fail sampling. B2B does not erase societal impact.

Trap 4: No feedback into treatment

Beautiful impact PDFs that never change residual risk, model gates, or SoA controls are ineffective. Auditors test the loop, not just document existence.

Scenario for exam practice

An insurer uses a machine-learning model to set premiums. The privacy team completed a DPIA. The risk register lists “model error → financial loss.” There is no analysis of demographic disparate impact, no assessment of explainability for adverse decisions, and no process for customer challenge of automated outcomes. Annex A.5 is marked “implemented” because the DPIA template exists.

Likely findings: Nonconformity or major observation against 6.1.4 (inadequate AI system impact assessment for individuals/groups), potential 6.1.2/6.1.3 issues (AI risks incomplete; treatments not driven by external impact), and A.5 implementation gaps if SoA claims full impact-assessment control maturity.

Document objective evidence: report IDs, system versions, dates, affected-group analysis, and whether impact findings re-enter risk treatment.