Data Protection Impact Assessment: GDPR Guide

A data protection impact assessment (DPIA) is a structured process that identifies and mitigates privacy risks before a processing activity begins. Required by Article 35 of the GDPR, DPIAs are not optional for high-risk processing. They are binding legal obligations, and failing to conduct one when required can result in fines of up to EUR 10 million or 2% of worldwide annual turnover under Article 83(4)(a).

In recent years, supervisory authorities across the EEA have issued dozens of enforcement actions citing the absence of a DPIA or deficiencies in its execution, according to data compiled by the EDPB enforcement tracker. These cases underscore a practical reality: supervisory authorities treat the DPIA as a core accountability instrument, not a paper exercise.

This guide explains when a data protection impact assessment is required, what it must contain, how to carry it out methodically, and where common mistakes occur.

Definition and Legal Basis

A data protection impact assessment is a documented risk analysis that controllers must perform whenever a type of processing is “likely to result in a high risk to the rights and freedoms of natural persons” (Article 35(1)). The assessment evaluates the necessity and proportionality of the processing, assesses risks to data subjects, and identifies measures to address those risks.

The concept is rooted in the broader accountability principle, which requires controllers not merely to comply with GDPR principles but to demonstrate that compliance through documented evidence. A DPIA is one of the primary tools for discharging that obligation.

DPIAs and Privacy by Design

DPIAs are closely connected to privacy by design obligations under Article 25. While privacy by design requires data protection to be embedded into processing from the outset, the DPIA provides the structured methodology for assessing whether those design choices are adequate. In practice, conducting a DPIA early in a project lifecycle ensures that data privacy principles are integrated before systems go live, rather than retrofitted after deployment.

The Role of the Data Protection Officer

Article 35(2) requires the controller to seek the advice of the Data Protection Officer (DPO) when carrying out a DPIA. The DPO does not conduct the DPIA — that responsibility lies with the controller — but the DPO reviews the methodology, validates the risk assessment, and advises on mitigation measures. Organisations without an appointed DPO may lack the internal expertise to perform thorough assessments, which is one reason the DPO role is critical to effective compliance programmes.

When Is a DPIA Required?

Article 35(3) lists three situations where a DPIA is mandatory:

• Systematic and extensive profiling with significant effects on individuals, including automated decision-making that produces legal or similarly significant outcomes.
• Large-scale processing of special categories of data (Article 9) or data relating to criminal convictions (Article 10).
• Systematic monitoring of publicly accessible areas on a large scale, such as CCTV surveillance or location tracking.

Beyond these explicit triggers, Article 35(1) applies the general threshold of processing that is “likely to result in a high risk.” The EDPB’s Guidelines on DPIAs (WP 248 rev.01) identify nine criteria to help controllers assess whether this threshold is met. If a processing activity meets two or more of these criteria, a DPIA is generally required. These criteria include evaluation or scoring, automated decision-making with legal effect, systematic monitoring, processing of sensitive data, large-scale processing, matching or combining data sets, data concerning vulnerable subjects, innovative use of technology, and processing that prevents data subjects from exercising a right.

National supervisory authority lists. Each EU member state supervisory authority publishes a list of processing operations that require a DPIA (Article 35(4)). For example, the French CNIL publishes its DPIA required list identifying specific categories of processing, and the UK ICO maintains a similar inventory. Controllers must check the list published by the relevant authority in their jurisdiction, as these lists supplement — and sometimes expand — the criteria above.

How to Conduct a Data Protection Impact Assessment

A DPIA is not a single document; it is a process that produces documented outputs. Article 35(7) specifies four minimum elements that every DPIA must contain. The following methodology walks through each element in turn.

Describe the Processing Operations

The DPIA must include a systematic description of the envisaged processing operations and their purposes, including the legitimate interest pursued where applicable. This description should cover the nature, scope, context, and purposes of the processing; the categories of personal data involved; the recipients and any data processors engaged; data flows, storage locations, and retention periods (see storage limitation); and the legal basis under Article 6.

Assess Necessity, Proportionality, and Risks

The DPIA must evaluate whether the processing is necessary and proportionate in relation to its purpose. This involves asking whether the stated objective could be achieved with less data, less intrusive methods, or shorter retention periods. Controllers should document why alternatives were considered and rejected.

The core of any data protection impact assessment is then a risk analysis that evaluates threats to the rights and freedoms of data subjects. Risks should be assessed on two dimensions: likelihood and severity. Common risk categories include unauthorised access or disclosure (see handling data breaches), inaccurate or excessive data leading to unfair decisions, loss of control over personal data, discrimination or reputational damage, and financial harm or identity theft.

An IAPP survey found that 73% of organisations conducting DPIAs identified at least one significant risk that required mitigation measures, demonstrating that the exercise has practical value beyond compliance documentation.

Define Mitigation Measures and Residual Risk

For each identified risk, the DPIA must describe the measures envisaged to address it. These include safeguards, security measures, and mechanisms to ensure protection of personal data and demonstrate compliance. Examples include pseudonymisation, encryption, access controls, data minimisation techniques, and contractual safeguards with processors.

The controller must then assess residual risk — the risk remaining after mitigation. If residual risk remains high, Article 36 requires the controller to consult the supervisory authority before proceeding with the processing.

Common Mistakes in DPIA Practice

Enforcement actions and supervisory authority guidance reveal recurring deficiencies in how organisations approach DPIAs. Understanding these pitfalls helps compliance teams avoid repeating them.

Conducting the DPIA too late. A DPIA must be carried out before processing begins (Article 35(1)). The Belgian DPA fined Brussels Airport EUR 200,000 for deploying a thermal camera system without completing a prior DPIA. Conducting the assessment retroactively does not satisfy the legal requirement.

Treating the DPIA as a one-time exercise. Article 35(11) requires controllers to review the DPIA when there is a change in the risk represented by the processing. System upgrades, new data sharing arrangements, or changes in the volume of data processed can all alter the risk profile. Organisations should establish review triggers and schedule periodic reassessments, at least annually for high-risk activities.

Insufficient risk analysis. A DPIA that merely lists risks without assessing their likelihood and severity, or that fails to describe concrete mitigation measures, does not meet the Article 35(7) requirements. The ICO’s DPIA guidance emphasises that the risk assessment must be specific to the processing activity, not a generic template.

Streamlining DPIAs with Legiscope

Building a data protection impact assessment from scratch is resource-intensive. Legiscope’s AI-powered platform streamlines the process by generating DPIA templates pre-populated with information from your Records of Processing Activities, automatically mapping data flows and identifying processing operations that meet the DPIA threshold, and tracking mitigation measures with assignable action items and deadlines.

By integrating the DPIA workflow with your broader compliance programme — including processor registers, breach management, and Article 30 records — Legiscope ensures that assessments remain current and audit-ready without duplicating documentation effort.

FAQ

Is a DPIA required for every processing activity?

No. A DPIA is only mandatory when processing is likely to result in a high risk to the rights and freedoms of individuals. However, the EDPB recommends conducting a DPIA for any processing that presents more than minimal risk, even where not strictly required, because it serves as evidence of accountability.

What happens if you fail to conduct a required DPIA?

Failure to carry out a required DPIA is an infringement under Article 83(4)(a), punishable by administrative fines. Supervisory authorities can also order the controller to suspend the processing activity until a DPIA is completed, effectively halting the project.

Who bears legal responsibility for the DPIA?

The controller bears legal responsibility. In practice, the task is often delegated to a project team, privacy office, or external adviser. The DPO must be consulted during the process (Article 35(2)), but the DPO does not sign off on or approve the DPIA — that decision rests with the controller.