AI Impact Assessment Template

Most AI risk reviews ask what could go wrong for the organisation and never record what the system could do to the people it scores, ranks, monitors or answers. An AI impact assessment fills that gap: it documents who an AI system affects, how it could harm their rights, safety or opportunities, what reduces that harm and who accepted what remains. This fill-in template follows the elements of ISO/IEC 42005:2025, the content of an EU AI Act Article 27 fundamental rights impact assessment (FRIA) and the NIST AI RMF MAP function. It is for AI governance leads, product owners and privacy and risk teams assessing AI they build or deploy.

How to use this template

• Replace text in square brackets, such as [Organisation], [AI system] and [AI governance group]. Example entries describe a fictional CV screening assistant; delete them once answered.
• Complete section 2 at the idea stage and sections 3 to 13 before the system is used on real people. Canada's Algorithmic Impact Assessment tool sets the same rhythm: complete it "at the beginning of the design phase", again before production, and update it when functionality or scope changes.
• One assessment covers one system in one deployment context.
• This template covers impacts on people and society. Risks to [Organisation] belong in the AI Risk Assessment Guide process and the Risk Register Template; personal data processing belongs in the DPIA Template. Cross-reference rather than copy.
• ISO/IEC 42005:2025 is paywalled. Its clause numbers here come from the NIST-hosted crosswalk to the AI RMF, which was based on the draft (DIS) text; check them against your licensed copy.

1. Purpose

This assessment identifies and evaluates the actual and reasonably foreseeable impacts of [AI system] on individuals, groups and society when used by [Organisation] for [purpose], the measures that reduce them and the decision of the accountable owner. It is evidence for [Organisation]'s AI management system (ISO/IEC 42001:2023 clause 6.1.4, AI system impact assessment, and Annex A area A.5, Assessing impacts of AI systems) and, where required, the FRIA under Article 27 of Regulation (EU) 2024/1689 (the EU AI Act).

2. Screening and assessment level

Any "Yes" in rows 1 to 4 requires a full assessment (sections 3 to 14). Otherwise complete a short form (sections 3, 4, 11 and 12) and record why.

Article 27 check: a FRIA is required before deploying a high-risk system under Article 6(2) if [Organisation] is a body governed by public law, a private entity providing public services, or a deployer of an Annex III point 5(b) system (creditworthiness and credit scoring, except fraud detection) or point 5(c) system (risk assessment and pricing for life and health insurance). Annex III point 2, critical infrastructure, is excluded. Required: [Yes / No]. Reason: [ ].

Dates: under Article 113 as amended by the Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026), high-risk obligations, including Articles 26 and 27, apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product systems. See the EU AI Act Compliance Guide.

Screening decision: [Full / Short form / Not required]. Reason: [ ]. Screened by: [name, role, date].

3. Assessment details and roles

4. System description and intended use

ISO/IEC 42005 asks for the system description, functionalities, purpose, intended use and unintended uses (clauses 6.3.1 to 6.3.5); NIST AI RMF MAP 1.1 asks for intended purposes and the context of use to be understood and documented.

• Purpose and benefit: the problem solved, for whom, and how benefit is measured. [Cut time to shortlist from 10 days to 3.]
• How it works: inputs, model type, outputs, and a plain data flow to the point where an output affects a person.
• Decision role: [Fully automated / Recommends to a human / Supports an independent human decision]. Can a person see, question and overrule each output?
• Process, period and frequency (Article 27(1)(a) and (b)): [All graduate roles, continuous, about 4,000 applications a month.]
• Environment: countries, languages, channels and integrations (clauses 6.6.1 and 6.6.2).
• Unintended uses and foreseeable misuse: [Using scores for promotion decisions; inferring age from graduation dates.]
• Alternatives considered: non-AI or less intrusive options, and why they were rejected.

5. Affected people and consultation

Article 27(1)(c) requires "the categories of natural persons and groups likely to be affected by its use in the specific context". Include people who never use the system.

Record what consultees said and what changed as a result (NIST AI RMF MAP 5.2): [ ]. Article 26(7) requires deployers who are employers to inform workers' representatives and affected workers before putting a high-risk system into service at work.

6. Data and model information

• Training data: sources, period, population covered, known gaps and labelling. For a third-party model, record what the provider does and does not disclose.
• Input data: fields used and proxies for protected characteristics, such as postcode, name, graduation year or career gaps. Article 26(4) requires deployers that control input data to ensure it is "relevant and sufficiently representative" for the intended purpose.
• Performance and limits: accuracy measures, test data, error rates by affected group where lawful, and known limits (MAP 2.2).
• Third-party components: models, APIs, datasets and terms, including any training on [Organisation]'s data (MAP 4.1). Article 27(2) lets a deployer rely on a provider's assessment for similar cases, but its own context must still be assessed. See the Third-Party AI Risk Guide.

7. Bias and fairness review

The ICO's AI guidance distinguishes allocative harms, where decisions distribute opportunities or resources unevenly, from representational harms, such as stereotyping or demeaning labels. NIST AI 600-1 lists "Harmful Bias or Homogenization" as a generative AI risk.

Set thresholds before testing; Article 9(8) likewise requires providers to test high-risk systems "against prior defined metrics and probabilistic thresholds". Record trade-offs, such as accuracy against data minimisation, with the reasoning and who decided. Confirm in the DPIA the lawful basis for any protected-characteristic data used in testing. See the AI Red Teaming Guide for adversarial testing of generated content.

8. Rights, safety and societal impacts

For each area, record actual and reasonably foreseeable impacts, including from failures and misuse (ISO/IEC 42005 clauses 6.8.2 and 6.8.3; Article 27(1)(d)). NIST AI RMF MAP 3.1 and 3.2 also ask for benefits and costs to be documented: record benefits here too.

9. Human oversight, transparency and redress

• Oversight (Article 27(1)(e)): who reviews outputs, when and with what authority. Article 26(2) requires people with "the necessary competence, training and authority". [Recruiters review every rejected CV within 10 points of the cut-off and can override.]
• Automation bias: how overseers avoid "over-relying on the output" (Article 14(4)(b)), for example by showing reasons, not just a score, and auditing a sample.
• Stop and fallback: who can suspend the system and which manual process takes over. Article 26(5) requires deployers to suspend use and inform the provider when they consider the system presents a risk.
• Notice and explanation: Article 26(11) requires deployers of Annex III systems that make or assist decisions about people to inform them, and Article 86 gives people affected by such decisions with legal or similarly significant effects a right to "clear and meaningful explanations of the role of the AI system".
• Complaints (Article 27(1)(f)): how people complain and obtain human review: [ ].
• Logs: Article 26(6) requires deployers to keep automatically generated logs for at least six months unless other law provides otherwise. Retention: [ ].

10. System access and agent identities

Complete this where the system connects to other systems or acts on its own. Impact on people often comes through what the system's identity can reach: the McHire default password flaw exposed job applicants' data through an AI hiring platform's administrative access.

• Identities: service accounts, API keys, OAuth grants or agent identities used; owner, storage and rotation.
• Reach: data stores, APIs and tools it can read or change; scoped per request or standing.
• Unapproved actions: actions affecting people with no human step, such as rejection emails, and the approval gates on the rest. See the AI Agent Authorisation Guide.

11. Impact scoring

Score each impact before mitigation. Likelihood is the chance of harm within [12 months] at planned scale; severity is the harm to the most affected person, weighted for numbers affected and reversibility. NIST AI RMF MAP 5.1 asks for the likelihood and magnitude of each impact to be documented. Align these scales with your enterprise matrix.

Rating = likelihood × severity: 1 to 3 Low; 4 to 6 Medium; 8 to 9 High; 12 to 16 Very high. Any severity 4 is at least High.

Overall impact level is the highest residual rating in section 12 and sets the approver in section 13. For comparison, Canada's Algorithmic Impact Assessment scores 65 risk and 41 mitigation questions and assigns Levels I to IV (0 to 25, 26 to 50, 51 to 75 and 76 to 100 per cent of the maximum), which determine the requirements of its Directive on Automated Decision-Making.

12. Mitigations and residual impact

Every Medium or higher impact needs a measure, owner and date. Article 27(1)(f) requires "the measures to be taken in the case of the materialisation of those risks", including governance and complaint mechanisms, so record response measures as well as preventive ones.

If a High or Very high impact cannot be reduced, redesign, narrow the use, add human decision-making or do not deploy.

13. Decision and sign-off

Approver by overall level: Low, [business owner]; Medium, [business owner and AI governance group]; High, [AI governance group and executive sponsor]; Very high, [executive committee] or do not deploy.

Record why any reviewer or DPO advice was not followed: [ ]. This matches OMB Memorandum M-25-21 for US federal agencies, which requires independent review of high-impact AI assessments and a signature from the individual accepting the risk.

14. Notification, records and reassessment

• FRIA notification: where Article 27 applies, notify the market surveillance authority of the results using the template under Article 27(3), unless the Article 46(1) exemption applies. Article 27(5) requires the AI Office to develop a questionnaire template, including an automated tool; the Commission's AI Act Service Desk did not say it had been published when checked in October 2026. Notified: [date, authority, reference].
• Publication: Canada requires federal institutions to publish completed assessments on its Open Government Portal. [Publish summary / Internal only, reason].
• Retention: keep each version, the evidence for sections 6 and 7, and the sign-off for [life of the system plus 6 years].
• Triggers: new purpose, user group, country or data source; model or provider change; drift or group gaps beyond threshold; complaint patterns or a serious incident; a change in law. Article 27(2) requires an update when an element has changed or is out of date.
• Scheduled review: High and Very high every [6 months], others every [12 months]. Next: [date].

15. Related documents and references

Related [Organisation] documents: [AI Policy] · [AI System Inventory] · [AI Risk Assessment Procedure] · [DPIA] · [Supplier AI Assessment] · [AI Incident Response Procedure].

1. ISO: ISO/IEC 42005:2025, AI system impact assessment
2. ISO: ISO/IEC 42001:2023, AI management system
3. European Commission AI Act Service Desk: Article 27, Fundamental rights impact assessment for high-risk AI systems
4. EU AI Act: Article 26, Obligations of deployers of high-risk AI systems
5. NIST: AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
6. NIST AI Resource Center: Crosswalk ISO/IEC 42005 and NIST AI RMF
7. Government of Canada: Algorithmic Impact Assessment tool
8. ICO: What are the accountability and governance implications of AI?

Implementation guidance

Which assessment applies. Run overlapping assessments from one set of system facts.

Framework mapping.

Rolling it out:

1. Screen the inventory with section 2 so you know how many full assessments are due. See the AI Governance Guide.
2. Pilot on one built and one bought system, and cut prompts nobody can answer.
3. Calibrate scoring: two assessors score the pilot impacts independently; large gaps mean the severity scale needs local examples.
4. Gate production: make sign-off a condition of go-live in change and procurement, and revert to the section 9 fallback if a section 13 condition misses its date.
5. Connect monitoring: feed section 7 metrics and section 14 triggers into model monitoring and complaint handling.

Small and large organisations: a small organisation that only buys AI can use the short form for most tools and run full assessments only for systems that decide about people. A large one should hold assessments in a governance platform linked to the inventory and risk register and a standing review panel. See the AI Governance Platform Buyer's Guide.

Common failure patterns: assessing the model rather than the deployment; completing the template after go-live; listing users but not the people decided about; testing bias without thresholds set in advance; calling it oversight when reviewers accept almost every output; and not reassessing when the provider changes the model.

Measures: share of inventoried systems screened and assessed before production; median days from screening to sign-off; High impacts open past due; override and appeal-upheld rates; group performance gaps against thresholds; and reassessments completed on time after triggers.

This template is provided for guidance, must be adapted to your organisation and is not legal advice. Related NHI Mgmt Group resources: AI Risk Assessment Guide · DPIA Template · ISO/IEC 42001 Guide · NIST AI RMF Guide · AI Acceptable Use Policy Template