AI System Impact Assessment: [AI system name]
Impact assessment of an AI system on individuals, groups of people and
society, covering benefits as well as harms, across the system's life
cycle. Structure aligned with ISO/IEC 42005:2025, Information
technology, Artificial intelligence, AI system impact assessment
(edition 1, published May 2025), and usable as the impact assessment
record an ISO/IEC 42001 AI management system expects. It is not a GDPR
data protection impact assessment (DPIA) nor an EU AI Act fundamental
rights impact assessment (FRIA); see section 1.4. Replace every
[bracketed] value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [AIIA-001] |
| AI system and version | [Name] [version] |
| Life cycle stage | [Inception / Design and development / Verification and validation / Deployment / Operation and monitoring / Retirement] |
| Assessment type | [Initial / Stage update / Change-triggered / Periodic / Post-incident] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Assessment owner | [@owner] |
| Assessment team | [@product], [@ml-lead], [@legal], [@domain-expert], [@ethics-reviewer] |
| Last updated | YYYY-MM-DD |
| Next review due | YYYY-MM-DD |
| Related records | [AI risk assessment], [DPIA], [FRIA], [Model card], [AI system card], [AIMS impact assessment procedure] |
Approvals
| Role | Name | Decision | Date |
|---|
| System owner | [@name] | [Proceed / Proceed with conditions / Do not proceed] | YYYY-MM-DD |
| AI governance lead | [@name] | [Decision] | YYYY-MM-DD |
| Independent reviewer | [@name] | [Decision] | YYYY-MM-DD |
| Accountable executive (if high residual impact) | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial assessment at design stage |
| 1.0 | YYYY-MM-DD | [@name] | Example: Updated before deployment with validation results |
| 1.1 | YYYY-MM-DD | [@name] | Example: Reassessed after extension to a new country |
Contents
1. Scope and context of the assessment
1.1 Purpose and trigger
[Why this assessment is being done now.] Example: Initial assessment
for a new AI system that ranks applicants for a municipal social housing
waiting list, at the design stage, before data collection.
1.2 Boundaries
| In scope | Out of scope |
|---|
| Example: The ranking model, its inputs, the case-worker interface, the appeal process | The housing allocation policy itself (set by the council) |
| Example: Effects on applicants, case workers, landlords and the local community | Internal IT infrastructure risks (covered by security risk assessment) |
1.3 Organisational context and criteria
| Item | Value |
|---|
| Organisation role | [Developer / Provider / Deployer / Developer and deployer] |
| AI policy and objectives | [Link to AI policy] |
| Impact criteria and scales | [Section 6 scales, approved by AI governance on YYYY-MM-DD] |
| Acceptance thresholds | Example: No residual impact rated "High" without executive approval; no "Critical" accepted |
| Applicable laws and standards | Example: National housing law, GDPR, EU AI Act (likely high-risk: access to essential public services) |
1.4 Relationship to other assessments
| Assessment | Purpose | Relationship to this one |
|---|
| AI risk assessment ([NIST AI RMF] or ISO/IEC 23894 based) | Risks to the organisation and its objectives | Impacts rated High feed its risk register |
| GDPR DPIA (Article 35) | Risks to rights and freedoms from personal data processing | Shares data flow description; this assessment covers non-data impacts too |
| EU AI Act FRIA (Article 27) | Deployer's legal duty for certain high-risk systems | This assessment can supply evidence; the FRIA has its own required content and notification |
| ISO/IEC 42001 AIMS | Management system requiring an impact assessment process | This document is the record of that process for this system |
2. AI system description
| Attribute | Description |
|---|
| Purpose | Example: Prioritise applications by assessed housing need |
| Functions | Example: Scores each application 0 to 100 and explains the top three factors |
| AI techniques | Example: Gradient-boosted model plus rule-based eligibility checks |
| Inputs | Example: Household size, income, current housing condition, medical priority flags, time on list |
| Outputs | Example: Priority score and band (A to D) shown to case workers |
| Decision role | Example: Decision support; case worker makes the final ranking decision |
| Data sources | Example: Application form, council records, health assessments with consent |
| Deployment environment | Example: Council case management system; 25 case workers |
| Scale | Example: About 9,000 applications per year |
| Third-party components | Example: None; model trained in-house |
3. Intended uses and reasonably foreseeable misuse
| ID | Use | Type | Users | Notes |
|---|
| U-01 | Example: Prioritise applications for case-worker review | Intended | Case workers | Core use |
| U-02 | Example: Report waiting list statistics to council | Intended | Analysts | Aggregated only |
| MU-01 | Example: Case workers accept scores without review because of workload | Foreseeable misuse | Case workers | Automation bias |
| MU-02 | Example: Scores reused to screen tenants for private landlords | Foreseeable misuse | Third parties | Purpose creep |
| MU-03 | Example: Applicants gaming inputs once factors are known | Foreseeable misuse | Applicants | Integrity |
4. Stakeholders and affected parties
4.1 Affected parties
| ID | Party | Relationship | Vulnerability factors |
|---|
| SP-01 | Example: Applicants | Subject of the output | Low income, possible disability, language barriers |
| SP-02 | Example: Children in applicant households | Indirectly affected | Cannot represent themselves |
| SP-03 | Example: Case workers | Users | Workload pressure |
| SP-04 | Example: Current tenants and neighbourhoods | Indirectly affected | Community composition |
| SP-05 | Example: Society / public trust in public services | Indirect | n/a |
4.2 Consultation
| Who was consulted | Method | Date | Key input |
|---|
| Example: Tenant advocacy organisation | Workshop | YYYY-MM-DD | Concern about applicants with irregular income |
| Example: Case workers (6) | Interviews | YYYY-MM-DD | Need to see why a score is high or low |
| Example: Disability rights adviser | Review of draft | YYYY-MM-DD | Medical flags must be optional and explained |
5. Impact identification
5.1 Benefits
| ID | Benefit | Parties | Level | Evidence or assumption |
|---|
| B-01 | Example: More consistent prioritisation across case workers | SP-01 | Group | Pilot showed 30% less variation between workers |
| B-02 | Example: Faster processing, shorter wait for a decision | SP-01, SP-03 | Individual | Assumed 2 weeks saved per application |
| B-03 | Example: Better data on unmet housing need for planning | SP-05 | Society | Aggregated reporting |
5.2 Harms
| ID | Potential harm | Parties | Level | Impact area | Cause |
|---|
| H-01 | Example: Lower scores for applicants with irregular income patterns | SP-01, SP-02 | Group | Fairness, access to services | Training data reflects past decisions |
| H-02 | Example: Applicants unable to understand or challenge their ranking | SP-01 | Individual | Accountability, autonomy | Opaque scores |
| H-03 | Example: Exposure of sensitive health information | SP-01 | Individual | Privacy | Medical flags in inputs |
| H-04 | Example: Case workers deskilled or over-reliant | SP-03 | Group | Autonomy, quality of service | Automation bias |
| H-05 | Example: Reduced public trust if errors become public | SP-05 | Society | Trust | Errors without explanation |
| H-06 | Example: Scores reused outside purpose | SP-01 | Individual | Privacy, discrimination | MU-02 |
6. Evaluation of severity and likelihood
6.1 Scales
| Score | Severity | Likelihood |
|---|
| 1 | Minimal: minor inconvenience, easily reversed | Rare: not expected in the system's life |
| 2 | Moderate: noticeable effect, reversible with effort | Unlikely |
| 3 | Significant: material effect on rights, access or wellbeing | Possible |
| 4 | Severe: serious, hard to reverse, many people | Likely |
| 5 | Critical: irreversible or affecting fundamental rights at scale | Almost certain |
Impact rating I=S×L, banded as Low (1 to 4), Medium (5 to 9),
High (10 to 15) and Critical (16 to 25).
6.2 Inherent rating
| Harm | Severity | Likelihood | Rating | Band | Rationale |
|---|
| H-01 | 4 | 4 | 16 | Critical | Example: Historic data shows lower allocation for self-employed applicants |
| H-02 | 3 | 4 | 12 | High | No explanation in current design |
| H-03 | 4 | 2 | 8 | Medium | Access controls exist but data is sensitive |
| H-04 | 3 | 3 | 9 | Medium | Workload is high |
| H-05 | 3 | 2 | 6 | Medium | |
| H-06 | 4 | 2 | 8 | Medium | No technical barrier to export |
7. Mitigation measures
| ID | Harm | Measure | Type | Owner | Due | Effectiveness check |
|---|
| MT-01 | H-01 | Example: Remove income volatility feature; fairness constraint on selection rate by employment type | Design | @ml-lead | YYYY-MM-DD | Selection rate ratio >= 0.9 on validation |
| MT-02 | H-02 | Example: Plain-language factor explanations in notices; appeal route | Design, process | @product | YYYY-MM-DD | Usability test with 10 applicants |
| MT-03 | H-03 | Example: Medical flags as yes/no category only; role-based access | Technical | @security | YYYY-MM-DD | Access review |
| MT-04 | H-04 | Example: Mandatory written reason when accepting band A or D; training | Process | @ops-lead | YYYY-MM-DD | Override and reason audit |
| MT-05 | H-06 | Example: Purpose limitation in data sharing agreements; no export function | Organisational | @legal | YYYY-MM-DD | Annual audit |
8. Residual impacts
| Harm | Residual severity | Residual likelihood | Rating | Band | Acceptable? | Justification |
|---|
| H-01 | 3 | 2 | 6 | Medium | Yes | Fairness tests pass; monitored monthly |
| H-02 | 2 | 2 | 4 | Low | Yes | |
| H-03 | 4 | 1 | 4 | Low | Yes | |
| H-04 | 3 | 2 | 6 | Medium | Yes, with monitoring | Override audit |
| H-05 | 2 | 2 | 4 | Low | Yes | |
| H-06 | 4 | 1 | 4 | Low | Yes | |
Net assessment of benefits against residual harms: [Example: benefits
B-01 and B-02 are material for about 9,000 households a year; residual
harms are Medium or below with active monitoring. The team recommends
proceeding with conditions in section 11.]
9. Documentation, communication and reporting
| Audience | What is shared | Channel | When |
|---|
| AI governance board | Full assessment | Governance meeting | Each version |
| Case workers | Summary, limitations, override duties | Training | Before go-live |
| Applicants | How the system is used, how to ask for review | Notice and website | At application |
| Public | Summary of the assessment | Council transparency register | At deployment |
| Regulators | On request, plus FRIA where required | Formal submission | As required |
Records are retained for [the system's life plus 10 years] in [document
management system], with version history.
10. Monitoring and review triggers
10.1 Indicators
| Indicator | Target | Frequency | Owner |
|---|
| Example: Selection rate ratio by employment type | >= 0.9 | Monthly | @ml-lead |
| Example: Case-worker override rate | 5% to 25% (outside range investigated) | Monthly | @ops-lead |
| Example: Appeals upheld | < 10% | Quarterly | @product |
| Example: Complaints mentioning the system | Trend | Quarterly | @complaints-lead |
10.2 Reassessment triggers
| Trigger | Stage |
|---|
| New model version or retraining with new data | Development, operation |
| New input feature or data source | Development |
| Use in a new population, region or purpose | Deployment |
| Indicator outside target for two consecutive periods | Operation |
| Serious incident or upheld complaint about discrimination | Operation |
| Change in applicable law | Any |
| Decision to retire the system | Retirement: assess effects of withdrawal and data disposal |
11. Conclusion and decision
| Item | Value |
|---|
| Overall residual impact | [Low / Medium / High] |
| Recommendation | [Proceed / Proceed with conditions / Redesign / Do not proceed] |
| Conditions | Example: MT-01 to MT-04 complete before go-live; monthly fairness report for the first 6 months |
| Decision by | [@accountable-person] on YYYY-MM-DD |
| Dissenting views recorded | [Summary or "none"] |
12. Glossary and references
| Term | Meaning in this document |
|---|
| Affected party | A person or group whose interests may be changed by the AI system, whether or not they use it |
| Impact | An effect, positive or negative, of the AI system on individuals, groups or society |
| Foreseeable misuse | Use other than intended that can be predicted from human behaviour or incentives |
| Residual impact | Impact remaining after mitigation measures |
| Selection rate ratio | Rate of favourable outcomes for a group divided by that of the most favoured group |
References: ISO/IEC 42005:2025; ISO/IEC 42001:2023; ISO/IEC 23894:2023;
[organisation AI policy]; [DPIA]; [FRIA].
Standard and licence note
Structure aligned with ISO/IEC 42005:2025, AI system impact assessment
(edition 1, May 2025), for the topics an impact assessment record covers:
scope, system description, uses and misuse, affected parties, benefits
and harms, evaluation, mitigation, residual impact, documentation and
life cycle review. This template is original text written for this
collection and reproduces no text from the standard; obtain the standard
for its full guidance. It does not replace a GDPR DPIA or an EU AI Act
FRIA. Template licence: MIT.