As soon as an organisation wants to deploy an AI system that affects people, the same question comes up within weeks: do we do a DPIA, a FRIA, or both? The short answer is that these are not competitors. A DPIA (Article 35 GDPR) assesses risks to the protection of personal data. A FRIA (Article 27 AI Act) looks wider, at the fundamental rights of the people the system affects: non-discrimination, social protection, access to a service, human dignity. They overlap in part, but that is not double work if you connect them properly.
What a DPIA assesses
A data protection impact assessment is mandatory whenever a processing operation is likely to result in a high risk to the rights and freedoms of natural persons.2 The Dutch data protection authority translates this into a list of processing operations for which a DPIA is mandatory by default, plus nine criteria for other cases: meeting two or more criteria generally means you need a DPIA.56 Think of large-scale processing of special category data, systematic and extensive profiling with effects on people, or large-scale monitoring of a public area. The EDPB guidelines, building on the earlier WP248 guidance, set out the method: describe the processing, assess necessity and proportionality, map the risks to data subjects, and identify the measures that address them.4
A DPIA is therefore mainly an instrumental exercise: it tests whether the processing of personal data is lawful, necessary and proportionate, and whether security is adequate. Responsibility sits with the controller, with a mandatory advisory role for the data protection officer where one has been appointed.
What a FRIA assesses
A FRIA goes a step beyond data protection. Article 27 of the AI Act requires certain deployers of high-risk AI systems to assess the effect the system's use has on the fundamental rights of the people and groups it affects.1 That reaches further than privacy: think of equal treatment, access to social benefits, fair process, human dignity. In practice you describe the process the system is used for, how often and for how long, which groups of people are likely to be affected, what specific harm could occur, how human oversight is arranged, and what measures are in place if a risk actually materialises.
It is worth being honest here: the form of a FRIA is not legally prescribed. Article 27 lists the elements it must contain, but no mandatory template. Useful models exist, such as the European Commission's ALTAI self-assessment tool and the template developed by human rights organisations, but none of them is a legal standard.7
Who must do which, and when
The target groups differ. A DPIA applies to any controller whenever the processing of personal data is likely to result in a high risk, regardless of sector or whether AI is involved at all. A FRIA applies only to a specific group of deployers of high-risk AI systems: bodies governed by public law, private entities providing public services, and deployers using the system for creditworthiness assessment (with an exception for fraud detection) or for risk assessment and pricing in relation to life and health insurance.1 Other high-risk categories under Annex III, such as critical infrastructure, fall outside the FRIA obligation. If you use a high-risk system without belonging to one of those groups, you do not need a FRIA, even though a DPIA is often still required.
| | DPIA (Article 35 GDPR) | FRIA (Article 27 AI Act) | |---|---|---| | Assesses | Risks to the protection of personal data | Risks to the fundamental rights of affected persons and groups | | Mandatory for | Any controller where high risk is likely | Public law bodies, private providers of public services, and deployers of creditworthiness or life/health insurance systems | | In force since | Already mandatory under the GDPR (2018) | Follows the Annex III calendar: 2 December 2027 | | Legally prescribed form | No, but a method is set out in EDPB guidelines | No, no mandatory template | | Who typically drafts it | The DPO or privacy officer, together with the process owner | A compliance or AI governance role at the deployer, with the DPO involved for the data protection part |
The timing distinction is sharp. You must already do a DPIA today if your processing falls under it; that obligation has existed since 2018 and is independent of the AI Act. The FRIA obligation becomes enforceable once the Annex III obligations apply, on 2 December 2027, following the postponement the Digital Omnibus introduced into the AI Act.3 That is not a licence to wait: an organisation that is already building or procuring a high-risk system that falls within one of the FRIA target groups does well to factor the FRIA elements into its procurement and implementation process now, rather than starting in 2027.
Where the overlap sits, and how to reuse it legally
The two assessments share part of their analysis. Both call for a description of the system and the process it is used in, a risk assessment for the people it affects, and measures to mitigate those risks. Where a DPIA stops at data protection, a FRIA continues into broader fundamental rights: not a duplicate exercise, but a wider one.
The amending regulation makes that reuse explicit: where an obligation under Article 27 is already covered by a DPIA you carried out under the GDPR, you may refer to or reuse the relevant parts instead of repeating the work.3 In practice a well-executed DPIA becomes the foundation of your FRIA: the system description, the data categories involved, and part of the risk analysis carry over directly. What you add is the wider fundamental rights lens: which groups are affected beyond the data protection question, and what oversight and remedy measures belong with that.
Who writes it in practice
A DPIA is usually drafted by the process owner, with the DPO in an advisory and reviewing role; where a DPO has been appointed, that involvement is mandatory. A FRIA sits, by law, with the deployer, not the provider of the AI system. In practice that is often a compliance or AI governance function, which brings in the DPO for the part that overlaps with personal data and the process owner for the operational details. At a municipality or other public law body, coordination often sits with the data protection officer together with the responsible policy department; at an insurer, with the compliance or risk function together with the actuarial team that manages the model.
Two examples from practice
A municipality procures a signalling system. Say a municipality wants to deploy a system that flags households at elevated risk of poverty or debt at an early stage, so that support can be offered sooner. As soon as the system processes personal data to build profiles, a DPIA is needed: the processing is systematic, often large scale, and affects vulnerable groups, which quickly meets several of the criteria the Dutch authority applies.5 Because the municipality is a public law body, and depending on the exact use the system may qualify as high risk under Annex III, the FRIA obligation is added once that obligation takes effect: which groups are affected, what risk of a false flag exists, and what human oversight prevents the system from deciding alone.
An insurer uses an underwriting model. An insurer deploys a model to determine the risk and premium for a life or health insurance policy. That use is explicitly named as FRIA-relevant under Annex III, so the insurer cannot avoid it once the obligation applies.1 At the same time, such a model almost always processes health data at scale, which already makes a DPIA mandatory today, independent of the AI Act.6 This is where the reuse is clearest: the DPIA already maps the health data risks, and the FRIA adds the question of whether the model systematically disadvantages certain groups in acceptance or pricing.
What to do today, what to plan for 2027
Today: take stock of which AI systems process personal data and carry out the DPIA the GDPR already requires, including a clear risk assessment and mitigating measures. Map whether your organisation falls into one of the FRIA target groups: a public law body, a private provider of a public service, or a user of creditworthiness or life/health insurance models. If it does, build the DPIA now so the system description and risk analysis can be reused for a later FRIA.
For 2027: plan the formal FRIA for every in-scope system well before 2 December 2027, not in the final month. Use the DPIA as the foundation, add the fundamental rights analysis, and record who signs off internally before the system goes into use. Do not wait for the deadline to discover your system description is outdated or that no one owns the fundamental rights analysis.
Frequently asked questions
Do I always need both a DPIA and a FRIA?
No. A DPIA depends on the risk of the data processing, a FRIA on your role and the type of system. Many organisations only do a DPIA, some will only do a FRIA later if no personal data is involved, and the FRIA target group usually does both because their processing involves personal data anyway.
Is a FRIA mandatory for every high-risk system?
No. The FRIA obligation only applies to public law bodies, private providers of public services, and deployers of creditworthiness or life/health insurance systems.1 Other users of high-risk systems, for example in critical infrastructure, fall outside this specific obligation.
Can I just copy my existing DPIA as a FRIA?
Not simply copy it, but you can reuse it. The amending regulation allows you to refer to or reuse the relevant parts of your DPIA for the data protection part of the FRIA.3 You still need to add the wider fundamental rights analysis, the groups affected, and the human oversight arrangements yourself.
Is there a mandatory template for a FRIA?
No. Article 27 describes the elements it must contain, but does not prescribe a fixed form.1 Useful models such as ALTAI exist, but they are tools, not a legal requirement.7
When does the FRIA obligation become enforceable?
The FRIA follows the calendar of the high-risk obligations under Annex III, which become enforceable on 2 December 2027 following the Digital Omnibus.3 The DPIA obligation under the GDPR has applied since 2018 and is unaffected by that.
Who is responsible if the FRIA is missing or incomplete?
The deployer, not the provider of the AI system, carries the FRIA obligation.1 In case of a shortcoming, the competent supervisory authority can take enforcement action; the exact consequences depend on the nature and severity of the failure.
