Skip to content

DPIA and the AI Act FRIA, done as one assessment

GDPR Article 35 and AI Act Article 27, joined at the hip. A worked walkthrough of how to do a Data Protection Impact Assessment and a Fundamental Rights Impact Assessment as a single exercise, with a working tool that drives you through it. Built for the moment an AI system that processes personal data lands on your desk and you have to show both the Data Protection Authority and the market surveillance authority that you've thought it through.

The idea that runs through all of it: one scope, one risk register, one document, two legal lenses. The DPIA looks at the impact on data protection and privacy. The FRIA looks at the broader set of fundamental rights. The overlap is so large that doing them as separate exercises duplicates work and, worse, lets the two risk registers drift out of sync. The legal text agrees: AI Act Article 27(4) says the FRIA "shall complement" the DPIA, not replace it, and EDPB Opinion 28/2024 says the DPIA is the accountability backbone for AI processing of personal data.

The process at a glance

The combined DPIA and AI Act FRIA process An AI system that processes personal data enters the process. Step one scopes the processing once. Step two screens the nine WP248 criteria and the AI Act Article 27(1) deployer test in parallel for one decision. Step three builds the cross-mapped joint record. Step four scores the residual risk against the DPIA and FRIA thresholds together; where risk stays high the assessment loops back to remediate. Step five chooses one set of measures, step six routes to the supervisory authority under Article 36 and notifies the market surveillance authority under Article 27(3), and step seven signs, files, deploys and monitors, with periodic review feeding back to the start on any change. AI system, personal data, going live 1 Scope it once Use case, data subjects, data flows, provider's Article 13 instructions for use. 2 Screen in parallel WP248 nine criteria and the AI Act Art. 27(1) deployer test. Two results, one decision. 3 Build the joint record Description, necessity and proportionality, risk register, using the cross-mapping. 4 Score the residual risk Same risk, two thresholds. DPIA high and FRIA high in parallel, not separately. 5 Choose the measures Technical and organisational controls, human oversight, complaint routes, one set. 6 Route to the authority DPIA high: prior consult under Art. 36 GDPR. Always notify the MSA under Art. 27(3). 7 Sign, file, deploy, monitor One signed document, both regimes satisfied. Review on change (AI Act Art. 27(2)). residual risk high — remediate, step back periodic review, on change The combined DPIA and AI Act FRIA process An AI system that processes personal data enters the process. Step one scopes the processing once. Step two screens the nine WP248 criteria and the AI Act Article 27(1) deployer test in parallel for one decision. Step three builds the cross-mapped joint record. Step four scores the residual risk against the DPIA and FRIA thresholds together; where risk stays high the assessment loops back to remediate. Step five chooses one set of measures, step six routes to the supervisory authority under Article 36 and notifies the market surveillance authority under Article 27(3), and step seven signs, files, deploys and monitors, with periodic review feeding back to the start on any change. AI system, personal data, going live 1 Scope it once Use case, data subjects, data flows, provider's Article 13 instructions for use. 2 Screen in parallel WP248 nine criteria and the AI Act Art. 27(1) deployer test. Two results, one decision. 3 Build the joint record Description, necessity and proportionality, risk register, using the cross-mapping. 4 Score the residual risk Same risk, two thresholds. DPIA high and FRIA high in parallel, not separately. residual risk high, re-assess 5 Choose the measures Technical and organisational controls, human oversight, complaint routes, one set. 6 Route to the authority DPIA high: prior consult under Art. 36 GDPR. Always notify the MSA under Art. 27(3). periodic review, on change 7 Sign, file, deploy, monitor One signed document, both regimes satisfied. Review on change (AI Act Art. 27(2)).

Artefacts

Artefact Type Format
DPIA + FRIA joint assessor Interactive decision wizard and combined assessment workbook Self-contained HTML
DPIA + FRIA process flowchart Joint end-to-end process with notification routes Inline SVG, this page
DPIA + FRIA cross-mapping table Every required element from both regimes, paired and sourced This page

Download and adapt

The assessor is a single self-contained HTML page. No third-party requests, no analytics, no CDN. Open it locally, fill in the wizard, export the combined assessment as HTML or markdown, and paste it into your own template. The tool does not store anything: every input stays in your browser.

The two regimes, side by side

DPIA FRIA
Legal source GDPR Article 35, with methodology in WP248 rev.01 and Annex 2 "acceptable DPIA" criteria AI Act Article 27, with rationale in Recital 96
Who runs it The controller, with the DPO (Art. 35(2)) and the processor assisting (Art. 28(3)(f)) The deployer of a high-risk AI system, in specific contexts
Triggers Processing "likely to result in a high risk to the rights and freedoms of natural persons" (Art. 35(1)). The nine WP248 criteria are the practical test, with "meeting two criteria" usually enough Deploying a high-risk AI system under AI Act Article 6(2) where the deployer is a public body, a private entity providing a public service, or deploying systems listed in Annex III points 5(b) and 5(c) (creditworthiness and insurance pricing)
Minimum content Article 35(7)(a) to (d): systematic description, necessity and proportionality, risks to rights and freedoms, measures to address the risks Article 27(1)(a) to (f): deployer's processes, period and frequency of use, categories of natural persons affected, specific risks of harm, human oversight measures, measures if risks materialise
Authority notification Prior consultation under Article 36 when residual risk remains high Notify the market surveillance authority of the results (Art. 27(3)), unless exempt under Article 46(1)
Penalty for non-compliance Up to €10 million or 2% of worldwide annual turnover (Art. 83(4)(a)) Up to €15 million or 3% of worldwide annual turnover — the Art. 99(4) operator-obligation tier (Art. 99(3) is the €35m/7% prohibited-practices tier). Note: Art. 27 is not itself enumerated in Art. 99, so FRIA-specific exposure is ultimately set by Member State penalty rules under Art. 99(1)

The minimum content lists look similar because they are doing similar work. The FRIA list was written by looking at the DPIA list, then widening the lens from "data subject" to "natural persons or groups of individuals". The mapping below makes the relationship explicit.

Cross-mapping: DPIA and FRIA elements

Every element of one regime has a counterpart in the other. Some are exact pairs, some are supersets, and a few are unique to one side. Use this table to build a single document that satisfies both.

DPIA element (GDPR Art. 35(7)) FRIA counterpart (AI Act Art. 27(1)) Verbatim cite Notes
(a) "a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller" (a) "a description of the deployer's processes in which the high-risk AI system will be used in line with its intended purpose" GDPR Art. 35(7)(a); AI Act Art. 27(1)(a) One paragraph covers both: the use case, the process, the intended purpose, the legal basis. The FRIA adds the "in line with intended purpose" constraint, which mirrors the AI Act provider obligations in Article 16.
(b) "an assessment of the necessity and proportionality of the processing operations in relation to the purposes" No direct element, but covered by the human-oversight element (e) and by the "specific risks of harm" element (d) GDPR Art. 35(7)(b); AI Act Art. 27(1)(d) and (e) The necessity and proportionality test sits underneath the whole FRIA. Document it once, in the introduction to the assessment.
(c) "an assessment of the risks to the rights and freedoms of data subjects" (d) "the specific risks of harm likely to have an impact on the categories of natural persons or groups of persons identified pursuant to point (c) of this paragraph, taking into account the information given by the provider pursuant to Article 13" GDPR Art. 35(7)(c); AI Act Art. 27(1)(d) The FRIA is explicit that the provider's Article 13 instructions-for-use are an input. Use the provider's risk section verbatim where you can.
(d) "the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation" (e) "a description of the implementation of human oversight measures, according to the instructions for use" and (f) "the measures to be taken in the case of the materialisation of those risks, including the arrangements for internal governance and complaint mechanisms" GDPR Art. 35(7)(d); AI Act Art. 27(1)(e) and (f) Split into two FRIA elements on purpose. The DPIA "measures" element covers both the technical and organisational controls, the human oversight, and the complaint route.
(no direct element) (b) "a description of the period of time within which, and the frequency with which, each high-risk AI system is intended to be used" AI Act Art. 27(1)(b) Unique to the FRIA. The DPIA does not ask for it. Pull it from the AI Act notification.
(no direct element) (c) "the categories of natural persons and groups likely to be affected by its use in the specific context" AI Act Art. 27(1)(c) The DPIA asks for "categories of data subjects". The FRIA widens this to "groups" of natural persons, which lets you call out collective-impact risks the DPIA alone would miss.
Views of data subjects (Art. 35(9), "where appropriate") (not explicit, but Recital 96 says deployers "could involve relevant stakeholders, including the representatives of groups of persons likely to be affected by the AI system, independent experts, and civil society organisations") GDPR Art. 35(9); AI Act Recital 96 Use one stakeholder-consultation record. State who you consulted, what you asked, and how the assessment changed as a result.
DPO advice (Art. 35(2)) (no FRIA equivalent) GDPR Art. 35(2) The DPO must be involved in a DPIA. They are not, by name, required for a FRIA, but most organisations will want them in the room. Document the role split.
Outcome communicated to the supervisory authority (Art. 36 prior consultation) Outcome notified to the market surveillance authority (Art. 27(3)) GDPR Art. 36; AI Act Art. 27(3) These are two different authority channels. A combined assessment may trigger both, in parallel, depending on the residual risks.

How the EDPB ties them together

EDPB Opinion 28/2024 (17 December 2024) on the processing of personal data in the context of AI models is explicit: "DPIAs are an important element of accountability, where the processing in the context of AI models is likely to result in a high risk to the rights and freedoms of natural persons." The opinion also notes that the AI Act's EU declaration of conformity under Article 16(g) and Article 47, and Annex V point 5, must include a statement that the AI system complies with EU data protection laws. So the DPIA is upstream evidence for the AI Act conformity statement. The FRIA is downstream evidence that the deployer has thought through the broader rights picture before putting the system in front of real people.

When each one is required

DPIA triggers: the WP248 nine criteria

WP248 rev.01, endorsed by the EDPB as its own guidelines, gives nine criteria. "In most cases, a data controller can consider that a processing meeting two criteria would require a DPIA to be carried out." Run through them in order and count.

  1. Evaluation or scoring, including profiling and predicting, especially from "aspects concerning the data subject's performance at work, economic situation, health, personal preferences or interests, reliability or behaviour, location or movements" (recitals 71 and 91).
  2. Automated decision-making with legal or similar significant effect (Article 35(3)(a), Article 22).
  3. Systematic monitoring, including data collected through networks or "a systematic monitoring of a publicly accessible area" (Article 35(3)(c)).
  4. Sensitive data or data of a highly personal nature, including special categories under Article 9 and criminal-convictions data under Article 10.
  5. Data processed on a large scale, considering the number of data subjects, the volume of data, the duration, and the geographical extent (recital 91).
  6. Matching or combining datasets from two or more processing operations, in a way that exceeds reasonable expectations of the data subject.
  7. Data concerning vulnerable data subjects (recital 75): children, employees, asylum seekers, patients, the elderly, or anyone in an imbalanced relationship with the controller.
  8. Innovative use or applying new technological or organisational solutions (recital 91), where the personal and social consequences may be unknown.
  9. Processing that prevents data subjects from exercising a right or using a service or a contract (Article 22, recital 91).

A national Data Protection Authority may publish its own list of processing operations that always require a DPIA under Article 35(4), and a list of those that never do under Article 35(5). Check the list of the supervisory authority in the Member State where the controller is established.

FRIA triggers: AI Act Article 27(1)

FRIA is required "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", where the deployer is:

  • a body governed by public law, or
  • a private entity providing public services, or
  • a deployer of high-risk AI systems referred to in points 5(b) and 5(c) of Annex III, which are AI systems used to evaluate the creditworthiness of natural persons (except fraud detection) and AI systems used for risk assessment and pricing in life and health insurance.

The "area listed in point 2 of Annex III" exception is the second bucket of high-risk AI systems under Annex III, which covers AI systems used in critical infrastructure (road traffic, water, gas, heating, electricity, digital infrastructure, traffic management, blood and tissue component supply). Public bodies and private entities providing public services in those areas get their own assessment regime elsewhere; everyone else under Article 27(1) is in scope.

A deployer can, in similar cases, "rely on previously conducted fundamental rights impact assessments or existing impact assessments carried out by provider" (Article 27(2)). This is where the joint-assessment tool earns its keep: the same assessment covers both, so the deployer can hand the provider's conformity file straight to the DPO and skip most of the rebuild.

How the triggers line up

WP248 criterion (DPIA) AI Act Annex III category that often matches it
1. Evaluation or scoring 5(b) creditworthiness, 5(c) insurance pricing, 3 education admission and scoring
2. Automated decision-making with legal or significant effect 5(b), 5(c), 4 employment decisions, 3 education admission
3. Systematic monitoring 1(b) biometric categorisation, 1(c) emotion recognition, 4(b) workplace monitoring
4. Sensitive data 1 biometrics, 1(c) emotion recognition
5. Large scale Most Annex III use cases at scale
6. Matching or combining datasets Any system that combines data sources to make a decision
7. Vulnerable data subjects 3 education, 4 employment, 5 access to essential public services
8. Innovative technology Anything that also triggers Article 6(1) (safety component of a regulated product)
9. Prevents exercise of a right or service 5(b) credit, 5(c) insurance, 4 employment

In practice, a high-risk AI system under AI Act Annex III that processes personal data will almost always trigger a DPIA too. The interesting question is what you do with that fact: do you do two separate assessments, or one.

The seven steps in detail

1. Scope it once. Start with a one-page scope statement: the AI system name and version, the use case, the deployer's role under the AI Act (provider, deployer, importer, distributor, or several at once), the data subjects, the categories of personal data, the data flows, the legal basis under GDPR Article 6, and the provider's Article 13 instructions for use. This page becomes the cover of the combined assessment and is referenced from every other section.

2. Screen in parallel. Run the WP248 nine criteria and the AI Act Article 27(1) deployer test at the same time. The criteria look different but they overlap heavily; you do not need a separate decision. The output of this step is one of four verdicts:

Verdict DPIA FRIA Combined action
Neither Out of scope Out of scope Document the screen, file under accountability, move on
DPIA only High risk Not in scope Run the DPIA per WP248, file with the DPO, update the record of processing activities under Article 30
FRIA only Not high risk Article 27(1) triggers Run the FRIA per Article 27, notify the market surveillance authority under Article 27(3)
Both High risk Article 27(1) triggers Run the joint assessment, in the order below

3. Build the joint record. Walk through the cross-mapped elements in the order they appear in the table above. Pull the description, the necessity and proportionality test, the risk register, the measures, and the stakeholder-consultation record from the provider's conformity file where you can. The provider has already done the technical-documentation work under AI Act Article 11; you cite it, you do not redo it.

4. Score the residual risk. The same risk register feeds two thresholds: the DPIA "high risk to the rights and freedoms of natural persons" test under Article 35(1) and the FRIA "specific risks of harm" test under Article 27(1)(d). If either threshold is breached after measures, you have work to do in step five. If the DPIA residual risk remains high, the data controller must consult the supervisory authority under Article 36 before processing. The FRIA does not have a "consult" route; it has a "notify" route (step six).

5. Choose the measures. The measures list is a single set, not two. Technical and organisational controls from Article 32 GDPR line up with the AI Act Article 14 human-oversight requirement and the AI Act Article 15 accuracy, robustness and cybersecurity requirement. The complaint mechanism serves both the GDPR data-subject-rights regime and the AI Act Article 86 right-to-explanation regime.

6. Route to the right authority. Two separate authorities, in parallel where both apply:

  • DPIA prior consultation under GDPR Article 36 is required when the controller has not identified sufficient measures to reduce the residual risk to the rights and freedoms of data subjects to an acceptable level. The full DPIA is provided to the supervisory authority (Article 36(3)(e)).
  • FRIA notification under AI Act Article 27(3) sends the filled-out template (the AI Office template, Article 27(5)) to the market surveillance authority. Article 27(3) exempts a deployer from that notification only "in the case referred to in Article 46(1)" — that is, where a market surveillance authority has authorised the system by derogation from the conformity assessment procedure for exceptional reasons of public security or the protection of life and health of persons, environmental protection, or the protection of key industrial and infrastructural assets. It is not a regulatory-sandbox exemption.

7. Sign, file, deploy, monitor. A single signed document satisfies the Article 35(7) DPIA minimum content and the Article 27(1) FRIA minimum content. It supports the provider's EU declaration of conformity under AI Act Article 16(g) and 47 and Annex V point 5, which includes a statement that the system complies with EU data protection laws. Periodic review and re-trigger feed back into step one on any change of the relevant factors (AI Act Article 27(2)).

A worked example

A municipality wants to use a vendor's AI system to triage social-services applications: deciding which applicants get an in-person interview and which are fast-tracked. The system takes a structured application form plus any free-text the applicant wrote, and returns a recommendation with a confidence score. A caseworker reviews every decision.

Step 1: Scope it once. The use case is social-services triage. The deployer is a public body (so AI Act Article 27(1)(a) is in scope). The data is special-category data under GDPR Article 9(1) (social benefits, health information). The legal basis under GDPR Article 6(1)(c) is a legal obligation; under Article 9(2)(b) it is employment, social security and social protection law. The provider's Article 13 instructions for use give the intended purpose, the data fields, and the known limitations.

Step 2: Screen in parallel. On the WP248 criteria: this is evaluation and scoring (criterion 1), automated decision-making with significant effect (criterion 2), sensitive data (criterion 4), data concerning vulnerable data subjects (criterion 7), and processing that may prevent exercise of a service (criterion 9). Five criteria. DPIA mandatory. On the FRIA test: public body, deploying a high-risk AI system (Annex III point 5 covers access to essential public services). FRIA mandatory.

Step 3: Build the joint record. Use the cross-mapping above. One description section covers use case, legal basis, intended purpose. The necessity and proportionality section asks: can the same triage be done with a simpler rules-based system? The risk register is built from the provider's Article 13 risk section, expanded to include the FRIA "groups of persons" lens (in this case: people who cannot easily use the digital application, people with limited language proficiency, people in crisis).

Step 4: Score the residual risk. After human oversight by a caseworker, the residual DPIA risk is medium: the AI recommends, the caseworker decides, and the decision is reviewable. The residual FRIA risk is also medium: the impact on access to a public service is real, but the human-oversight step and the complaint route reduce it.

Step 5: Choose the measures. A single set: documented human oversight per AI Act Article 14, a complaint mechanism per AI Act Article 86 and GDPR Articles 12 to 22, periodic bias testing, a published transparency notice, a model card per the EDPB Opinion 28/2024 transparency recommendation, and an Article 30 record-of-processing-activities entry.

Step 6: Route to the right authority. The residual DPIA risk is medium, not high, so no Article 36 prior consultation. The FRIA notification under AI Act Article 27(3) goes to the market surveillance authority using the AI Office template (Article 27(5)).

Step 7: Sign, file, deploy, monitor. One document, signed by the data controller's accountable owner, the DPO, and the casework-team lead. Filed in the registry. Published in summary form per the WP248 recommendation. Periodic review at six months, then annually, with re-trigger on any change of the model, the data, or the use case.

Key definitions

Term Verbatim source
Data protection impact assessment "a process designed to describe the processing, assess its necessity and proportionality and help manage the risks to the rights and freedoms of natural persons resulting from the processing of personal data by assessing them and determining the measures to address them" (WP248 rev.01, Section I)
High risk to the rights and freedoms of natural persons "In line with the risk-based approach embodied by the GDPR, carrying out a DPIA is not mandatory for every processing operation. Instead, a DPIA is only required where a type of processing is 'likely to result in a high risk to the rights and freedoms of natural persons' (Article 35(1))" (WP248 rev.01, Section III)
High-risk AI system "AI systems referred to in Annex III shall be considered to be high-risk" (AI Act Article 6(2)). Read with Article 6(3) for the "no significant risk of harm" exception
Fundamental rights impact assessment (FRIA) "an assessment of the impact on fundamental rights that the use of such system may produce", comprising six elements listed in Article 27(1)(a) to (f)
Body governed by public law (not separately defined in the AI Act). Read with the GDPR Article 4(7) notion of "public authority" and with Member State administrative-law definitions
Provider / deployer AI Act Article 3(3) "provider" and Article 3(4) "deployer"

What to do if you have one but not the other

A team that is already doing DPIAs for AI systems under GDPR does not need to start from scratch on the AI Act. The DPIA is upstream evidence for the AI Act conformity statement, and most of the FRIA content can be lifted directly from the DPIA's existing sections with the additions noted in the cross-mapping table above. Reverse it the other way: a team that has run a FRIA for a public-body AI deployment can carry over the description, the necessity and proportionality test, the human-oversight section, and the complaint mechanism into a DPIA, then add the DPIA-only elements (DPO advice, Article 36 prior consultation, the explicit Article 6 legal-basis assessment).

The DPO and the AI governance lead should sign the same document. The DPO is responsible for the DPIA under Article 35(2). The AI governance lead is responsible for the FRIA under Article 27. Both are accountable, and the document should make clear who owns each part.

Verify before you rely on it

This is a practitioner template, not legal advice. Article and standard references are drawn from the primary texts but should be checked against the current version on EUR-Lex before operational use. The AI Office template for the FRIA notification (Article 27(5)) was not yet published at the time of writing. The EDPB Opinion 28/2024 is the most current EDPB position on AI and DPIA; check for newer EDPB output, particularly on generative AI and on AI agents, before relying on it operationally. Member State supervisory authorities may have additional national requirements under Article 35(4) and Article 35(5); check the list for the Member State where the controller is established.

Primary sources

  • GDPR — Regulation (EU) 2016/679 (Article 35 for the DPIA, Article 36 for prior consultation, Article 30 for the record of processing activities, Articles 5 and 24 for accountability)
  • WP248 rev.01 (Article 29 Working Party Guidelines on DPIA, endorsed by the EDPB): the nine criteria, Annex 2 "acceptable DPIA" criteria, the methodology
  • EDPB Opinion 28/2024 (17 December 2024) on certain data protection aspects related to the processing of personal data in the context of AI models: the bridge between DPIA and AI Act
  • AI Act — Regulation (EU) 2024/1689 (Article 6 for high-risk classification, Article 13 for provider instructions for use, Article 16(g), 47 and Annex V point 5 for the GDPR-compliance declaration, Article 27 for the FRIA, Article 99 for penalties)
  • AI Act Recital 96 (rationale for the FRIA)
  • AI Act Annex III (the eight high-risk categories)

More on how this fits with the other EU digital regulations: DORA third-party risk worked example, the toolshop, and the cross-regulation mappings.