DPIA vs FRIA
Last reviewed: · By Victor Humenhuk (AIGP certified)
A DPIA is a GDPR Article 35 assessment carried out by the controller where processing is likely to result in a high risk to the rights and freedoms of natural persons. A FRIA is an EU AI Act Article 27 fundamental rights impact assessment carried out before first use by certain deployers of Annex III high-risk systems: public bodies and private entities providing public services, plus any deployer using an Annex III system for creditworthiness or for life and health insurance risk assessment and pricing. They ask different questions from different vantage points, since a DPIA examines personal data processing risk while a FRIA examines the impact of one specific deployment on the fundamental rights of the people and groups affected. Where a deployer has already covered a point in its DPIA, Article 27(4) allows the FRIA to complement it rather than repeat it.
DPIA vs FRIA vs conformity assessment
| DPIA | FRIA | Conformity assessment | |
|---|---|---|---|
| Legal basis | GDPR Article 35 | AI Act Article 27 | AI Act Article 43 |
| Who carries it out | The controller | Certain deployers | The provider, alone or with a notified body |
| Trigger | Processing likely to result in a high risk to individuals | Deployer type plus use of a qualifying Annex III high-risk system | Placing a high-risk system on the market |
| Focus | Personal data processing, necessity and proportionality | Impact of this deployment on the fundamental rights of affected people and groups | Whether the system meets the Chapter III requirements |
| Timing | Prior to the processing | Before first use | Before placing on the market, repeated after substantial modification |
| Who sees the result | Internal, and the supervisory authority on prior consultation under Article 36 | Notified to the market surveillance authority, using the template the AI Office is to develop | Declaration of conformity, CE marking and EU database registration |
A fourth cousin is the Algorithmic Impact Assessment, which is not an EU instrument at all, Canada's Directive on Automated Decision-Making being the best-known example. ISO/IEC 42005 provides a voluntary AI system impact assessment method alongside it. See AI impact assessments and ISO 42005.
When is a DPIA required?
Article 35(1) requires a DPIA where processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons. Article 35(3) names three cases where one is always required:
- Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions producing legal or similarly significant effects are based.
- Processing of special categories of data, or of personal data relating to criminal convictions and offences, on a large scale.
- Systematic monitoring of a publicly accessible area on a large scale.
Supervisory authorities also publish mandatory lists under Article 35(4), most of which include AI, profiling and biometric processing. The content is set by Article 35(7): a systematic description of the processing and purposes, an assessment of necessity and proportionality, an assessment of the risks to data subjects, and the measures envisaged to address them. The controller must seek the advice of the data protection officer where one is designated, and must consult the supervisory authority under Article 36 where high residual risk remains. Article 26(9) of the AI Act tells deployers to use the information the provider supplies under Article 13 when preparing the DPIA.
When is a FRIA required, and what goes in it?
Article 27 applies to deployers of the high-risk systems referred to in Article 6(2), that is the Annex III systems, with an express exception for systems intended to be used in the critical infrastructure area at Annex III point 2. Within that scope it catches deployers that are bodies governed by public law, private entities providing public services, and any deployer of the Annex III point 5(b) and 5(c) systems: creditworthiness evaluation and credit scoring, and risk assessment and pricing in life and health insurance. It is a deployer duty rather than a provider duty, and it bites before the system's first use.
The assessment must describe:
- the deployer's processes in which the high-risk system will be used, in line with its intended purpose;
- 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 that specific context;
- the specific risks of harm likely to affect those categories, taking account of the provider's Article 13 information;
- how the human oversight measures in the instructions for use will be implemented; and
- the measures to be taken if those risks materialise, including internal governance arrangements and complaint mechanisms.
The deployer notifies the market surveillance authority of the results, using the questionnaire template the AI Office is to develop. Where similar assessments have already been done, by the deployer previously or by the provider, the deployer may rely on them and update where needed.
How do the two fit together on a real deployment?
Take a bank deploying a bought-in credit scoring model. The vendor is the provider and completes the conformity assessment, technical documentation, CE marking and registration. The bank is the deployer and must:
- run a DPIA, because automated evaluation of personal aspects with significant effects is squarely within Article 35(3)(a);
- run a FRIA, because credit scoring is Annex III point 5(b);
- satisfy Article 26 on instructions for use, competent human oversight, appropriate input data, monitoring, at least six months of logs, and informing individuals subject to the decisions;
- have an Article 22 analysis under the GDPR if the decision is solely automated with legal or similarly significant effects, and be able to give meaningful information about the logic involved.
Sequence them so the DPIA runs first and feeds the FRIA. Article 27(4) is explicit that where any of the FRIA obligations are already met through the DPIA, the FRIA complements it. Duplicating the analysis in two documents that then diverge is a governance failure waiting to be found in an audit.
What about providers, and what about systems outside Annex III?
Two boundary questions come up constantly.
Providers do not do FRIAs. The provider's equivalent discipline is the Article 9 risk management system, which runs across the lifecycle and considers reasonably foreseeable misuse, and the Article 43 conformity assessment, which tests the system against the Chapter III requirements. The provider feeds the deployer through the Article 13 instructions for use, and a deployer that cannot get usable Article 13 information cannot complete a defensible FRIA. That is a procurement problem, so put it in the contract rather than discovering it at go-live.
Annex I systems are outside Article 27. A high-risk system that qualifies through Article 6(1), because it is a safety component of a regulated product, does not trigger the FRIA duty at all, even though it carries the full Chapter III load. The same is true of Annex III point 2 critical infrastructure systems. Those deployments still need Article 26 compliance and, wherever personal data is involved, a DPIA. Many organisations run a voluntary fundamental rights analysis anyway, because it is the cleanest way to evidence that the Article 26 monitoring and oversight duties are actually being discharged.
Related study notes
- Impact Assessments in the Design Phase
- Conformity assessments, registration and notification
- Obligations on Data Controllers
- AI impact assessments and ISO 42005
Frequently asked questions
Does a FRIA replace a DPIA?
No. They rest on different legal bases and have different scopes and audiences. A FRIA complements a DPIA where the ground is already covered, but it cannot discharge the GDPR Article 35 obligation, and a DPIA cannot discharge Article 27.
Do providers have to carry out a FRIA?
No. Article 27 is a deployer obligation. Providers carry out the conformity assessment under Article 43 and operate the risk management system under Article 9. Providers do, however, have to give deployers the Article 13 information that the FRIA depends on.
Is a FRIA published?
Not by default. The deployer notifies the market surveillance authority of the results by submitting the completed template. It is a regulatory filing rather than a public transparency document, although public bodies may face separate disclosure obligations under national law.
What if my organisation is not a public body and not in credit or insurance?
Then Article 27 does not apply to you, even if you deploy a high-risk system. You still owe the full Article 26 deployer duties, and a DPIA under the GDPR wherever the processing is likely to result in a high risk to individuals.
Test yourself
Try the free AIGP practice questions, or read the full AIGP study guide - free.