AI risk assessment: how to assess one AI use case for ISO 42001, the EU AI Act and UK GDPR

The enterprise customer's due-diligence questionnaire has a new line: "Has this AI feature been risk-assessed?" Your ISO/IEC 42001 project has reached clause 6.1.4, and a lender you sell to wants inputs for its own impact assessment. An AI risk assessment answers all three, if you run it once per use case.

This guide is for heads of security, compliance leads and CTOs at UK tech firms of 25 to 250 people selling into regulated customers. It sets out a step-by-step method for one AI use case, shows where a DPIA and the EU AI Act's fundamental rights impact assessment fit, and works through an example.

What is an AI risk assessment?

An AI risk assessment looks at one AI system or use case and asks two questions: what could go wrong for the organisation (risk), and what could happen to the people and groups the system affects (impact). Scoped per use case, one assessment record can serve ISO/IEC 42001, a DPIA and a customer's EU AI Act assessment.

Four assessments tend to get confused, because each asks a slightly different question of the same system. For what ISO/IEC 42001 is and how an AI management system works, start with our ISO/IEC 42001 overview. The table shows how the four relate.

The trick is to stop treating these as four documents. They share most of their inputs: the intended purpose, the data, the people affected and the controls in place. Write those once, then let each assessment draw from the same record.

Why does an AI management system need both a risk and an impact assessment?

ISO/IEC 42001:2023 separates the two. Clause 6.1.2 asks for an AI risk assessment, set against the organisation's AI objectives. Clause 6.1.4 asks for an AI system impact assessment, focused on the consequences for individuals, groups and society. Annex A control objective A.5 covers assessing those impacts. An AI management system needs both.

The two answer different questions, so they can disagree. A recommendation feature might carry low risk to the business and a real impact on the people it ranks. A chatbot with no personal data might carry high reputational risk and almost no impact on anyone's rights. The risk assessment can still weigh consequences for people; the impact assessment gives them a separate, deeper look.

A risk register that only scores harm to the company has not assessed the AI.

ISO/IEC 42005:2025 is the guidance standard for AI system impact assessment, first published in May 2025. It describes how and when to assess impacts across the AI lifecycle and how to document them, and how that work fits into AI risk management and an AI management system. Treat ISO/IEC 42005 as the method for the impact half of the record, not as a separate project.

How do you run an AI risk assessment for one use case?

Run an AI risk assessment in eight steps: define the use case and its intended purpose, name the people affected, list the harms, rate likelihood and severity, record the existing controls, judge the residual risk, take a decision with a named owner, and set the review triggers. Each step adds one section to a single record.

The rating mechanics are the same ones you already use for information security. Our guide to cyber security risk assessment covers scales, criteria and treatment; this method only adds what is specific to AI.

1. Scope the use case and its intended purpose. Take the entry from your AI inventory: what the system does, who uses it, on which data, and what decisions it informs. Write the intended purpose in one sentence. Everything after this step is judged against it.
2. Name the people affected. List the users, the people whose data goes in, and the people the output is about. Note any group that could be affected differently, such as applicants with thin credit files or customers writing in a second language.
3. List the harms, in both directions. For the organisation: contractual, regulatory, financial and reputational harm. For people: the ICO's guidance points to allocative harms, such as a lost financial opportunity, and representational harms, such as stereotyping. Keep attack and misuse scenarios in your security work; our piece on AI security risks covers those.
4. Rate likelihood and severity. Use your existing scales, and rate the impact on people separately from the risk to the business. A low business score must not cancel a high score for the people affected.
5. Record the existing controls. Data quality checks, testing results, access limits, logging, and above all the human oversight in place: who reviews the output, when, and whether they can override it.
6. Judge the residual risk and impact. Re-rate both after controls, and say in a sentence why the remaining level is acceptable or not.
7. Decide, and name an owner. Approve, approve with conditions, or stop. The owner is a person with authority over the feature, not the person who filled in the form.
8. Set the review triggers. Write down the specific events that reopen the record (see the reassessment section below).

The steps are short on purpose. Most of the effort sits in steps 2 and 3, because that is where an engineering team's view of the feature meets the view of the people on the receiving end.

When does an AI use case need a DPIA?

Under UK GDPR Article 35, a DPIA is required before processing that is likely to result in a high risk to people's rights and freedoms, particularly when new technologies are used. The ICO's view is that, in the vast majority of cases, using AI will involve that kind of processing. Where personal data is involved, assume a DPIA is needed.

Article 35(3) names cases where a DPIA is always required, including a systematic and extensive evaluation of personal aspects based on automated processing, such as profiling, that leads to decisions with legal or similarly significant effects. AI features that score or screen people for decisions such as lending or hiring can fall into that case.

The ICO also says that where you conclude a particular AI use is not high risk, you still need to document how you reached that view. That conclusion belongs in the AI risk assessment record too.

Do not write the DPIA twice. Keep the DPIA as the data protection document, written with your DPO's advice, and cross-reference it from the AI risk assessment: the processing description, the lawful basis, the data minimisation measures and the residual data protection risk. The AI record then adds what a DPIA does not ask for, such as risk to the business and impacts on people who are not data subjects.

One caution: the ICO marks its AI guidance as under review following the Data (Use and Access) Act. Check the current version before you rely on any specific wording.

Who has to do a fundamental rights impact assessment under the EU AI Act?

Article 27 of the EU AI Act applies to three kinds of deployer of an Annex III high-risk AI system: bodies governed by public law, private entities providing public services, and deployers of creditworthiness and credit-scoring systems or of life and health insurance pricing systems. Critical infrastructure systems are excluded. The assessment is done before first use.

Read the scope precisely. Article 27 does not apply to every deployer of a high-risk system. A private deployer of, say, an Annex III recruitment tool has other duties under the Act, but not a fundamental rights impact assessment.

The assessment itself has six elements:

• a description of the deployer's processes in which the system will be used;
• the period and frequency of use;
• the categories of people and groups likely to be affected;
• the specific risks of harm to them, taking into account the information the provider gives under Article 13;
• the human oversight measures, according to the instructions for use;
• the measures if those risks materialise, including internal governance and complaint mechanisms.

Once the assessment is done, the deployer notifies the market surveillance authority of its results. Article 27(4), as amended by Regulation (EU) 2026/1744, lets the deployer cross-reference the relevant sections of its DPIA, or include parts of it, rather than repeat them.

The timing changed in 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, sets 2 December 2027 as the date from which Chapter III, Sections 1 to 3, apply to Annex III high-risk systems. Article 27 sits in Section 3, so the fundamental rights impact assessment applies from 2 December 2027, not August 2026. Our EU AI Act overview covers the rest of the Act's timeline.

What does a UK supplier owe a customer's impact assessment?

A UK tech supplier that builds an AI feature and sells it under its own name is usually the provider under the EU AI Act, and the Act reaches providers placing systems on the EU market wherever they are based. The provider's job is to give deployers the Article 13 information their own impact assessments depend on.

Article 13 requires high-risk systems to come with instructions for use that are concise, complete, correct and clear. At a minimum they cover the intended purpose, the expected level of accuracy, robustness and cybersecurity, known circumstances that could lead to risks to health, safety or fundamental rights, performance for specific groups where appropriate, and the human oversight measures.

Those items map almost one-for-one onto what your customer needs. Article 27 tells the deployer to take the provider's Article 13 information into account when it assesses risks of harm, and Article 26(9) tells deployers to use that same information for their DPIA. Article 27(2) also lets a deployer, in similar cases, rely on existing impact assessments carried out by the provider.

Your customer's fundamental rights impact assessment is only as good as your instructions for use.

In practice, build a provider pack from your own AI risk assessment record: intended purpose, known limitations, test results by group where you have them, oversight design and change history. When a financial services or insurance customer asks for inputs, you send the pack instead of answering a fresh questionnaire.

When should you reassess an AI risk assessment?

Reassess an AI risk assessment when something that shaped its conclusions changes: a material change to the model or feature, new training or input data, a new customer segment or purpose, an incident or complaint, or monitoring results that drift outside the limits you set. A calendar review catches what the triggers miss.

Both regimes expect this. The ICO describes the DPIA as a live document to be reviewed regularly and reassessed where appropriate, for example when the nature, scope, context or purpose of the processing changes. Article 27(2) requires a deployer to update its assessment when any element has changed or is no longer up to date.

Write the triggers into step 8 of the record as concrete events, such as "model version change", "new customer in lending" or "complaint rate above the agreed threshold". "Review annually" on its own is a date, not a trigger.

Worked example: an AI risk assessment for one SaaS feature

Take a 60-person UK SaaS firm selling loan-origination software to lenders in the UK and the EU. It adds a feature that reads applicants' bank statements and suggests an affordability score to underwriters, who make the final decision. The table shows the record.

One record, four uses. The ISO/IEC 42001 risk and impact assessments come from the rows on harms, impacts and decision. The DPIA is referenced, not rewritten. The EU lender's fundamental rights impact assessment draws its provider inputs from the same rows.

A UK lender using the same feature owes no Article 27 assessment, because that duty is EU law. It still needs its own UK GDPR DPIA, and it will ask the supplier for much the same evidence.

What are the most common AI risk assessment mistakes?

The most common AI risk assessment mistakes are assessing the model instead of the use case, scoring only the risk to the business, writing a separate document for every regime, and treating the assessment as finished on approval. Each one costs time later, usually when a customer asks a question the record cannot answer.

1. Assessing the model, not the use case. The same model can be harmless in one feature and high risk in another. Scope each record to one intended purpose.
2. Scoring only the business risk. Clause 6.1.4 asks for a separate assessment of the consequences for people, and the two ratings can disagree.
3. Duplicating the DPIA. Two documents describing the same processing will drift apart. Cross-reference instead.
4. Assuming every high-risk deployer needs a fundamental rights impact assessment. Article 27 names specific deployers; check whether your customers are among them before promising inputs on a deadline.
5. Treating approval as the end. Without review triggers, the record describes a feature that no longer exists.

An assessment nobody can update is a snapshot, not a control.

If the next question is certification, our piece on ISO 42001 certification covers what the audit involves and costs.

Frequently asked questions