Governance practice
AI impact assessment: what it is, when the law requires one, and how it differs from a DPIA
Standfirst: "Run an impact assessment" can mean three different documents. A data protection impact assessment (DPIA) under GDPR Article 35 is owed by a controller when processing is likely to create high risk to people's rights. A fundamental rights impact assessment (FRIA) under AI Act Article 27 is owed by a narrow class of deployers of high-risk AI systems, and ISO/IEC 42005:2025 describes a third, voluntary practice that is neither of them.
Why the phrase is ambiguous
The same two words cover three instruments with different owners, different triggers, and different legal weight. Two are binding EU law. One is guidance from a standards body. If a manager tells you to "do the impact assessment" for an AI project, your first job is to work out which regime applies, because the answer changes who signs it, what goes in it, and whether a regulator ever sees it.
The quickest sorting question is this: are you the controller of personal data, the deployer of a high-risk AI system under the AI Act, or an organization following a management system standard? Each role points to a different document. You can hold all three roles at once, which is why Article 27(4) of the AI Act exists. More on that below.
The DPIA: GDPR Article 35
The DPIA is the oldest of the three and the one most people mean by default. It belongs to the controller, the party that decides why and how personal data is processed. The trigger is a risk threshold, not a technology list:
Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data.
Article 35(3) then names cases where a DPIA is required "in particular":
- a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects concerning the person or similarly significantly affect the person
- large-scale processing of special categories of data under Article 9(1), or of data relating to criminal convictions and offences under Article 10
- systematic monitoring of a publicly accessible area on a large scale
Supervisory authorities add to this. Under Article 35(4) each authority must publish a list of processing operations that require a DPIA, and under Article 35(5) it may publish a list of operations that do not. So the trigger analysis has two layers: the general high-risk test, and the local lists.
Article 35(7) sets the minimum contents. The assessment must contain a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks to data subjects' rights and freedoms, and the measures envisaged to address those risks, including safeguards and security measures. The controller must seek the advice of the data protection officer where one is designated (Article 35(2)), and where appropriate must seek the views of data subjects or their representatives (Article 35(9)). Article 35(11) requires a review at least when the risk represented by the processing changes.
One useful detail for exam purposes: a single DPIA may cover a set of similar processing operations that present similar high risks. You do not need one document per operation.
The FRIA: AI Act Article 27
The FRIA is newer and narrower. It belongs to the deployer, not the provider, and it attaches to high-risk AI systems referred to in Article 6(2). But not every deployer of a high-risk system owes one. Read Article 27(1) closely, because the scope is where questions get missed:
Prior to deploying a high-risk AI system referred to in Article 6(2), with the exception of high-risk AI systems intended to be used in the area listed in point 2 of Annex III, deployers that are bodies governed by public law, or are private entities providing public services, and deployers of high-risk AI systems referred to in points 5 (b) and (c) of Annex III, shall perform an assessment of the impact on fundamental rights that the use of such system may produce.
Unpack that. The obligation falls on:
- deployers that are bodies governed by public law
- deployers that are private entities providing public services
- any deployer of a high-risk AI system referred to in Annex III points 5(b) and 5(c), regardless of whether it is public or private
And there is a carve-out: high-risk systems intended for use in the area listed in point 2 of Annex III are excepted. A purely private deployer using a high-risk system outside points 5(b) and 5(c), and not providing public services, owes no FRIA at all. That asymmetry is deliberate and it is exactly the kind of distinction a certification exam tests. Learn what Annex III points 2, 5(b) and 5(c) actually cover from the Annex itself; the article text turns entirely on those references.
Article 27(1) also fixes the contents. The assessment must consist of:
- a description of the deployer's processes in which the system will be used, in line with its intended purpose
- a description of the period of time within which, and the frequency with which, the system is intended to be used
- the categories of natural persons and groups likely to be affected in the specific context
- the specific risks of harm likely to have an impact on those categories, taking into account the information the provider gives under Article 13
- a description of the implementation of human oversight measures, according to the instructions for use
- the measures to be taken if those risks materialize, including arrangements for internal governance and complaint mechanisms
Timing and lifecycle matter. Under Article 27(2) the obligation applies to the first use of the system. In similar cases the deployer may rely on previously conducted FRIAs, or on existing impact assessments carried out by the provider. If any element changes or goes stale during use, the deployer must update the information.
Two procedural points distinguish the FRIA from a DPIA. Under Article 27(3) the deployer must notify the market surveillance authority of the results, submitting a filled-out template, with a possible exemption in the case referred to in Article 46(1). And under Article 27(5) the AI Office must develop a template questionnaire, including through an automated tool, to simplify compliance. A DPIA, by contrast, stays with the controller unless other GDPR mechanisms bring the authority in.
ISO/IEC 42005: the voluntary practice
ISO/IEC 42005:2025, "AI system impact assessment," provides guidance for organizations performing AI system impact assessments for individuals and societies. It is a standard, not a law. Nothing in it triggers a legal obligation and no regulator receives its output. It sits in a family with ISO/IEC 42001 (edition 1.0, published 2023-12-18), which specifies requirements for establishing, implementing, maintaining and continually improving an AI management system, and ISO/IEC 42006:2025, which sets requirements for bodies that audit and certify an AI management system against ISO/IEC 42001. ISO/IEC 22989:2022 supplies the concepts and terminology underneath all of them.
The practical point: an organization can follow 42005 as good governance even where neither Article 35 nor Article 27 applies. Following it does not discharge either legal duty by itself, though a well-run assessment can feed both documents.
The three side by side
| GDPR Article 35 DPIA | AI Act Article 27 FRIA | ISO/IEC 42005:2025 | |
|---|---|---|---|
| Who owes it | The controller | Certain deployers of high-risk AI systems only | Any organization choosing to follow the guidance |
| Trigger | Processing likely to result in a high risk to rights and freedoms of natural persons; Article 35(3) cases and authority lists | First use of a high-risk system under Article 6(2), within the Article 27(1) deployer categories, minus the Annex III point 2 exception | Voluntary |
| Core contents | Description of processing and purposes; necessity and proportionality; risks; mitigating measures | Processes, period and frequency of use, affected categories, specific risks of harm, human oversight, measures on materialization | Guidance for assessing impacts on individuals and societies |
| Goes to a regulator? | Not by default | Yes, results notified to the market surveillance authority via template | No |
| Legal status | Binding EU regulation | Binding EU regulation | Voluntary standard |
Where the two legal duties meet
Article 27(4) handles the overlap directly. If any Article 27 obligation is already met through a DPIA conducted under GDPR Article 35, or under Article 27 of Directive (EU) 2016/680, the FRIA shall complement that DPIA. Note the verb. The FRIA does not replace the DPIA and the DPIA does not absorb the FRIA. A deployer that is also a controller may end up with one combined body of analysis, but both legal duties remain distinct and both must be satisfied.
On an exam, this material rewards precision over familiarity. You should be able to name which party owes each assessment, state the Article 35(1) trigger in its own terms, list who falls inside and outside Article 27(1) including the Annex III point 2 exception, recall that the FRIA attaches to first use and gets notified to the market surveillance authority, and place ISO/IEC 42005 as voluntary guidance rather than law. Anyone who has skimmed the topic knows there are "impact assessments for AI." The candidate who passes knows which instrument, which owner, and which trigger, and can tell them apart under time pressure.
Common questions
Is a DPIA the same as a fundamental rights impact assessment?
No. A DPIA under GDPR Article 35 is about risk to the rights and freedoms of data subjects from processing personal data. A fundamental rights impact assessment under EU AI Act Article 27 is owed by specific deployers of specific high-risk AI systems and covers the use of the system. They can both apply to the same deployment.
Who has to do a fundamental rights impact assessment?
Article 27(1) narrows it to deployers that are bodies governed by public law, deployers that are private entities providing public services, and deployers of the high-risk systems at points 5(b) and 5(c) of Annex III. It also carves out systems used in the area at point 2 of Annex III.
Sources
Every figure, date and quotation above was read from the document itself, not from a summary of it.
- Regulation (EU) 2024/1689, Official Journal L, 12 July 2024, Article 27
- Regulation (EU) 2016/679, General Data Protection Regulation, Article 35
- IEC Webstore, ISO/IEC 42005:2025, AI system impact assessment
Credential Press is not affiliated with, endorsed by or authorized by the IAPP, ISO, the IEC, NIST or any other body. This is not legal advice.
We are writing the book on this. The AIGP Exam Guide covers all 4 domains and all 13 competencies, in proportion to the published item weights. Join the first-reader list and you get it free before it goes on sale.