FRIA step by step: how to conduct a Fundamental Rights Impact Assessment

Updated: June 2026

Introduction: the FRIA as a governance exercise

The Fundamental Rights Impact Assessmentfundamental rights impact assessmentAn assessment that certain deployers of high-risk AI must perform to identify and mitigate the system's risks to people's fundamental rights.Open full entry → (FRIAFRIAFundamental Rights Impact Assessment — required of public bodies and certain private deployers before using some high-risk AI systems under the EU AI Act.Open full entry →) required by Art. 27 of the EU AI Act is designed to answer one fundamental question: what happens to the fundamental rights of real people when this AI systemAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs — predictions, content, recommendations or decisions — that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → is deployed? It is not a documentation exercise, it is a structured inquiry that should genuinely change how an organization approaches AI deployment.

This guide provides a detailed, practical walkthrough of the six-step FRIA process, with specific guidance for Dutch public sector and regulated organizations.

Before you begin: who needs a FRIA?

Art. 27.1 requires a FRIA from public authorities and bodies deploying high-riskriskIn the EU AI Act's terms, the combination of the probability that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → AI. This includes: central and local government, public hospitals and healthcare institutions, public universities, social housing corporations, and certain regulated private sector organizations providing public services.

The FRIA must be completed before deployment begins, not after. Retrospective FRIAs have no legal standing under Art. 27.

Step 1: system scoping (week 1)

Document the AI system precisely:

• System name, vendor, version
• Intended purpose and specific use case
• How the system works (at a conceptual level, you do not need the source code)
• Which decisions the system informs or makes
• The categories of individuals it processes data about or affects
• The scale of deployment (how many people affected per year?)
• Whether similar systems have been used before and what happened

Output: A 1–2 page system description that the rest of the FRIA builds on.

Step 2: stakeholder mapping (week 1–2)

Identify every group whose rights could be affected by the AI system:

• Direct subjects: individuals whose data is processed and who receive AI-influenced decisions
• Indirect stakeholders: family members, employees, communities who may be affected by decisions made about direct subjects
• Vulnerable groups: children, elderly, people with disabilities, people in economic hardship, who may face heightened risks
• Protected characteristics: ethnic minority groups, LGBTQ+ individuals, religious minorities, who may face discrimination risk

Output: A stakeholder map with a narrative explanation of how each group is connected to the AI system.

Step 3: rights mapping (week 2–3)

For each stakeholder group, identify which fundamental rights are at risk. Work through the EU Charter systematically:

Charter article	Right	Relevance to this AI system
Art. 1	Human dignity	[High/Medium/Low/None]
Art. 7–8	Privacy and data protection	[Assessment]
Art. 21	Non-discrimination	[Assessment]
Art. 24	Children's rights	[Assessment]
Art. 47	Right to a fair hearing	[Assessment]

Output: A completed rights mapping table with brief justification for each assessment.

Step 4: risk assessment (week 3)

For each rights risk identified as High or Medium:

• Probability: How likely is this harmharmThe concrete damage an AI system can do that a responsible-AI principle exists to prevent: in the EU AI Act's terms, harm to a person's health, safety, or fundamental rights. Harm is the bridge between an abstract principle and a governable risk; governance becomes operational the moment an organization names the specific harms it wants to prevent. For fairness, a harm is a group receiving systematically worse outcomes because of a characteristic that should not have counted. See principle, risk.Open full entry → to occur? (1–5 scale)
• Severity: How serious is the harm if it occurs? (1–5 scale)
• Breadth: How many people could be affected? (1–5 scale)
• Risk score: Probability × Severity × Breadth
• Priority: High (score 27–125), Medium (8–26), Low (1–7)

Output: A risk matrix prioritizing the top rights risks for mitigation.

Step 5: mitigation measures (week 3–4)

For each High and Medium priority risk: design specific, verifiable mitigation measures. Examples:

• Non-discrimination risk: Regular algorithmic auditing for demographic parity; independent bias testing before deployment
• Right to fair hearing: Mandatory written explanation of AI-influenced decisions; appeals process documented in procedure manual
• Privacy risk: Data minimizationdata minimizationProcessing only data that is adequate, relevant and necessary — in ML, implemented through pseudonymisation, feature selection, synthetic data and privacy-enhancing techniques.Open full entry → review; GDPR DPIADPIAData Protection Impact Assessment — required before likely-high-risk processing (systematic profiling with significant effects, large-scale special categories, public monitoring); AI development triggers it constantly.Open full entry → with DPO sign-off
• Dignity risk: Human override mandatory for all negative decisions affecting individuals

Each measure must have: a responsible owner, an implementation deadline, and a verification method.

Step 6: residual risk assessment and sign-off (week 4)

After applying mitigation measures, re-assess residual risks. For each risk: what is the residual probability and severity after mitigation? If any residual riskresidual riskThe risk that remains after controls have reduced it. No control reduces a risk to zero, and not every control is worth its cost, so a deliberate judgment is made: whether the cost of further control is justified by the reduction it would buy, and whether the remaining risk is acceptable against the organization's risk appetite. This is a design-level judgment, where execution reports back up and governance accepts the residual risk, calls for more control, or declines the use case. EU AI Act Art. 9(5) requires it to be judged acceptable per hazard and overall. See risk, control, risk appetite.Open full entry → remains High, consider whether deployment should proceed, and under what additional conditions.

Sign-off required from: the AI Officer, the DPO (for data-related risks), legal counsel, and the relevant management level (typically the Management Team member responsible for the affected function).

Compliance checklist

1. Has the FRIA been completed before deployment?
2. Does the FRIA cover all six steps?
3. Has the stakeholder mappingstakeholder mappingSystematically identifying who is affected by a system — users, affected non-users, vulnerable groups, organization, society — and what each stands to gain or lose.Open full entry → identified vulnerable groups?
4. Have all Charter rights been assessed (not just privacy)?
5. Are mitigation measures specific, verifiable, and assigned to named owners?
6. Has residual risk been assessed and documented?
7. Has sign-off been obtained from AI Officer, DPO, and management?
8. Is the FRIA filed and available for supervisory review?