How to run an AI impact assessment (ISO 42005 and the EU AI Act FRIA)

An AI impact assessment answers one question before your AI goes live: who could this harm, and how badly? It is a structured look at how an AI system could affect people, groups and society, their rights, their safety, their access to services, their treatment by an automated decision, done before deployment and revisited when the system changes. The defining feature, and the thing most organisations get wrong, is that it looks outward at the impact on people, not inward at the risk to your business.

It is not an optional nicety. It is required in principle by ISO 42001, detailed by a dedicated standard, ISO 42005, and for some organisations it is made law by the EU AI Act as a Fundamental Rights Impact Assessment (FRIA). This post is what it is, how it differs from the DPIA you may already know, and, above all, how to actually run one.

First, three things people confuse

Half the confusion around impact assessments comes from mixing up three different exercises. They overlap, but they answer different questions.

	AI impact assessment	AI risk assessment	DPIA
Looks at	Impact on people, groups, society	Risk to your organisation and the system	Risk to people from personal-data processing
Asks	”Who could this harm, and how badly?"	"What could go wrong for us, and how do we manage it?"	"Does this data processing create high risk?”
Anchor	ISO 42005; ISO 42001 clause 6.1.4 and Annex A.5; EU AI Act Article 27	ISO 23894; NIST AI RMF	UK/EU GDPR Article 35
Status	Guidance, and legally required for some EU deployers	Guidance	Legally required where processing is high-risk

The two that get conflated most are the impact assessment and the DPIA. A DPIA is narrower (personal data only) but it is the one that is legally forced in the UK. An AI impact assessment is broader: it covers harms a DPIA never touches, a safety failure, a discriminatory outcome, an environmental or societal effect, and it considers people affected even when no personal data of theirs is processed. A single high-risk AI system that decides something about people can trigger all three. Doing a DPIA and calling it an impact assessment is the single most common mistake, and we will come back to it.

The two anchors: the standard, and the law

An AI impact assessment shows up in two places that matter.

The standards route: ISO 42001 and ISO 42005

If you run, or are building, an AI Management System to ISO 42001, the impact assessment is not optional. Clause 6.1.4 of the standard requires you to assess the potential consequences of your AI systems to individuals, groups of individuals, and society, to document the results, and to feed them back into your AI risk assessment and treatment. Annex A then gives the reference controls, the A.5 group, “Assessing impacts of AI systems”:

Control	What it requires
A.5.2	A defined, repeatable impact assessment process: when it is triggered, what it covers, who is responsible
A.5.3	Documentation of each assessment: intended use, foreseeable misuse, positive and negative impacts, mitigations, affected people, oversight
A.5.4	Assessing impact on individuals or groups, including their rights, wellbeing and life opportunities, with attention to vulnerable groups
A.5.5	Assessing societal impacts: environmental, economic, health and safety, and effects on social norms

ISO 42001 tells you that you must do this, but describes it only at a high level. ISO/IEC 42005:2025 is the dedicated guidance standard that tells you how. Published in 2025, it sets out when to perform an assessment and when to re-perform it, how it fits across the AI system lifecycle, and what a documented assessment should contain. It is guidance, so you do not certify against it directly; it is the practical companion to the certifiable management-system standard. If you take impact assessment seriously, 42005 is the blueprint.

The legal route: the EU AI Act FRIA (Article 27)

For some organisations the impact assessment stops being good practice and becomes law. Article 27 of the EU AI Act requires a Fundamental Rights Impact Assessment from certain deployers of high-risk AI.

Who has to do one is narrower than “everyone using high-risk AI”:

• Deployers that are public bodies, or private entities providing public services, when they use an Annex III high-risk system; plus
• Any deployer, public or private, using AI for creditworthiness and credit scoring (excluding fraud detection), or for risk assessment and pricing in life and health insurance.

Critical-infrastructure high-risk systems are specifically carved out. So a bank scoring credit, or a life insurer pricing risk, is in scope regardless of who they are; a company using high-risk AI for something else may not be. Work out your tier first, our method for that is in how to classify your AI systems by risk.

What the FRIA must contain is set out in Article 27 and maps almost exactly onto a good impact assessment:

• (a) the processes in which the system will be used;
• (b) the period and frequency of use;
• (c) the categories of people and groups likely to be affected;
• (d) the specific risks of harm to them, using the provider’s instructions for use;
• (e) the human oversight measures in place;
• (f) the measures if risks materialise, including internal governance and complaint mechanisms.

You do it before first use, update it when any of those factors change, and notify the market surveillance authority of the result. The FRIA complements a DPIA: where your DPIA already covers some of this, the FRIA builds on it rather than repeating it. (One practical note: the AI Office is due to publish a template for the FRIA, and as things stand in 2026 it has not appeared yet, so in the meantime you build your own against the Article 27 list.)

When does it apply? The FRIA rides with the high-risk obligations, which were set to apply from 2 August 2026. The EU’s Digital Omnibus package, adopted in 2026, has deferred the Annex III high-risk regime to 2 December 2027, so the FRIA duty moves with it. Treat the current dates as the plan and watch for movement, we track the full timeline in the EU AI Act deadlines. Getting the FRIA wrong sits under the deployer-obligation penalty tier, fines up to the higher of a set amount or a percentage of global turnover, so it is not a paperwork afterthought.

Neither route replaces the other. The FRIA is the legal floor for those it applies to; ISO 42005 is the method that makes any impact assessment, FRIA or not, actually rigorous. If you are building governance properly, you run one process that satisfies both.

How to actually run one

Here is a defensible sequence that satisfies ISO 42005, the ISO 42001 controls and the Article 27 FRIA at once. It is a process, not a form.

1. Trigger and scope it. Decide whether a full assessment is needed. The triggers: a new AI system, a significant change to its purpose, users, data or context, a new high-risk use, or a change in the law. Set threshold criteria up front so this is consistent, not ad hoc.
2. Describe the system. Its purpose, intended use, reasonably foreseeable misuse, how it works, the data and model behind it, the deployment context, and who operates it. The happy path is not enough; the misuse is where harm lives.
3. Map who is affected. Individuals, groups, vulnerable groups, people affected indirectly who never touch the system, and society. Where you can, involve or consult the people actually affected.
4. Identify the potential impacts and harms, intended and unintended, across rights, safety, fairness and discrimination, privacy, autonomy, transparency, access to services, economic effect, societal effect and environment. A harms checklist keeps this honest.
5. Assess severity and likelihood for each. It does not need a heavy scoring model, but it does need documented reasoning, not a gut feel.
6. Define mitigations, controls and human oversight. For each material impact, what reduces it, and specifically how a human stays in control of the decisions that carry weight.
7. Determine the residual risk, and decide. State what is left after mitigation and make an explicit call: proceed, proceed with conditions, or do not deploy. That decision is the point of the whole exercise.
8. Plan for when it goes wrong. Incident response, internal escalation, and a complaint and redress route for affected people, exactly what Article 27(f) demands.
9. Document it, and notify if required. Write it up (see below), and if you are an in-scope EU deployer, notify the market surveillance authority.
10. Assign an owner and sign it off. A named accountable owner and a documented approver, with a date. An unsigned assessment is a draft.
11. Review and re-run on change. Schedule a review, and re-run whenever the system, its use or the rules change materially. Impact assessment is a lifecycle habit, not a launch gate you pass once.

If you have read our other governance pieces, the shape is familiar. This is the same discipline as classifying systems by risk and writing an AI policy: a defined process, a named owner, real analysis, and a durable record.

What good documentation contains

The assessment is only worth as much as the record it leaves. A defensible one captures: the system description and foreseeable misuse; the data and model summary; the deployment context; the stakeholder map including vulnerable groups; the enumerated impacts with severity and likelihood; the mitigations and human-oversight design; the residual risk; the go / no-go decision and its reasoning; the incident and complaint arrangements; the named owner and approver with a date; a review schedule and change log; and links to the related DPIA and AI risk assessment. That is what an auditor, a regulator, or a customer will ask to see, and it is the part that has to already exist, not be assembled in a hurry.

Common mistakes

• Doing a DPIA and calling it done. The DPIA covers data-protection risk; it does not cover the safety, fairness, societal and rights harms an impact assessment exists to catch. The Act says the FRIA complements the DPIA, not replaces it.
• Only assessing your own risk. Running an organisation-risk assessment and labelling it an impact assessment. The test is outward: impact on people and society, not loss to you.
• Box-ticking. A document with no severity reasoning, no real mitigations and no decision is not an assessment, it is a filing.
• Doing it after launch. The assessment must precede first use. Afterwards is incident response, not impact assessment.
• One and done. Never revisiting it after a significant change breaches both the ISO 42005 lifecycle expectation and the Article 27 duty to update.
• Ignoring foreseeable misuse and vulnerable groups. The people most likely to be harmed are often the ones a happy-path assessment skips.
• No named owner. With no accountable person and no sign-off, nothing is actually governed.

The UK position

There is no UK law that mandates a fundamental-rights impact assessment for AI; the UK’s approach is principles-based and regulator-led. But two things still bind you. First, a DPIA is legally required under UK GDPR where AI processing of personal data is likely to result in high risk, and the ICO’s own guidance is that the nature of AI means it will usually trigger that requirement, so for most AI touching personal data, the DPIA is not optional. Second, the EU AI Act reaches across borders: if you are a UK organisation deploying in-scope high-risk AI that affects people in the EU, the FRIA can apply to you regardless of where you sit.

So the practical UK message: the DPIA is your legal floor at home; if you touch the EU with high-risk AI, the FRIA discipline becomes directly relevant; and if you are building to ISO 42001 either way, the impact assessment is part of the system. Most organisations serious about AI end up running one process that answers all three.

The minimum viable impact assessment

If the full method looks heavy, the smallest version that genuinely protects people, and stands up to scrutiny, is: a clear description of the system and its foreseeable misuse, a map of who it affects (including the vulnerable), the material harms with a severity judgement, the mitigations and human oversight, an explicit go / no-go decision, and a named owner who signed it, before launch. That closes the gap most organisations have, no structured look at impact on people, and gives you something defensible to build on. Depth is what you add as the stakes rise.

The short version

An AI impact assessment asks who your AI could harm and how badly, and answers it before the system goes live. It is broader than a DPIA, required in principle by ISO 42001, detailed by ISO 42005, and mandatory as a FRIA under EU AI Act Article 27 for public-service and credit and insurance deployers of high-risk AI. Run it as a real process: scope it, describe the system and its misuse, map who is affected, weigh the harms, design the mitigations and oversight, make an explicit decision, document it, own it, and revisit it on change. Do that and you catch the harm on paper, where it is cheap to fix, instead of in production, where it is not.

Want to know where you stand? The free AI governance readiness assessment gives you a quick, no-email read on your impact-assessment and governance maturity in about ten minutes. When you want to build the process and stand it up properly, talk to us.

For the full picture, see the AI governance guide.