The Data Protection Impact Assessment (DPIA) is one of the most important and least understood tools in the GDPR. It is not paperwork: it is the prior analysis that requires an organisation to stop and think, before launching a risky processing operation, about what could go wrong for people and how to prevent it. This guide explains exactly what the DPIA is, when it is mandatory, how it is structured, who carries it out and what happens when the risk remains high after the analysis.
In 15 seconds
- The DPIA is the prior risk analysis required by art. 35 GDPR before a high-risk processing operation.
- It is mandatory, as a minimum, in the three cases set out in art. 35(3) (profiling with decisions, large-scale processing of art. 9 data, monitoring of public areas).
- The AEPD publishes a list of processing operations that require a DPIA; it must be checked case by case.
- It is carried out by the controller, with the advice of the DPO (art. 35(2) and art. 39). If the residual risk remains high, a prior consultation with the AEPD is required (art. 36).
What is a Data Protection Impact Assessment?
The Data Protection Impact Assessment —DPIA, or EIPD by its Spanish acronym— is the process, provided for in art. 35 GDPR, by which the controller analyses, before starting a processing operation likely to entail a high risk, how that processing may affect the rights and freedoms of individuals and what measures reduce it to an acceptable level.
It should not be seen as a form to be filled in, but as a decision-making tool. The DPIA forces you to look the processing in the eye and answer uncomfortable questions: do we really need all this data?, is there a less intrusive way of achieving the same purpose?, what happens if this database is leaked or used for something other than intended? It is the practical embodiment of two GDPR principles: data protection by design and by default (art. 25) and the risk-based approach that runs through the entire Regulation.
Art. 35(7) itself sets the minimum content of the assessment. Every DPIA must include at least four elements:
- A systematic description of the envisaged processing operations and their purposes.
- An assessment of the necessity and proportionality of the operations in relation to their purpose.
- An assessment of the risks to the rights and freedoms of data subjects.
- The measures envisaged to address those risks: safeguards, security measures and mechanisms to ensure the protection of the data.
It is important to put the DPIA in its place. It is not a legal basis or a permit: it does not make lawful a processing operation that would not otherwise be. It is a risk analysis. Processing always needs a valid legal basis under art. 6 (and art. 9 where there are special categories); the DPIA documents how its risk is managed, it does not replace that basis. Confusing the two —believing that "doing a DPIA" alone legitimises any intrusive processing— is one of the most frequent and most dangerous mistakes.
When is a DPIA mandatory?
The general rule in art. 35(1) GDPR is that the DPIA is mandatory when a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons, taking into account its nature, scope, context and purposes.
On top of that general rule, art. 35(3) sets out three cases in which the assessment is required in particular. They are not a closed list, but the cases the legislator considered to be of evident risk:
| Case (art. 35(3)) | What it involves |
|---|---|
| a) Profiling with decisions | A systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are taken that produce legal effects for individuals or similarly significantly affect them. |
| b) Large-scale sensitive data | Processing on a large scale of special categories of data (art. 9: health, biometrics, ideology, trade union membership, sexual orientation, etc.) or of data relating to criminal convictions and offences (art. 10). |
| c) Public areas | Systematic monitoring on a large scale of a publicly accessible area (for example, extensive video surveillance systems of public spaces). |
To these three statutory cases a practical reference tool is added: art. 35(4) tasks each supervisory authority with publishing a list of the types of processing operations that require a DPIA. In Spain, the AEPD publishes that list, which sets out criteria and combinations of risk factors that, on their own or added together, trigger the obligation to assess. It is a mandatory reference point when evaluating a processing operation: the organisation must compare its specific activity against those criteria, without assuming that "it does not apply" simply because it does not fit literally within one of the three cases in art. 35(3).
In practice, the operational question is not "am I on the list?", but "does my processing accumulate risk factors?". The more of these elements are present —profiling, sensitive data, large volume, vulnerable individuals, novel technology, combination of data sources, automated decisions—, the clearer the obligation to carry out the assessment.
A warning on biometrics
Biometric data intended to uniquely identify a person are a special category (art. 9) and their large-scale processing triggers the obligation to carry out a DPIA. It is worth being clear to avoid a widespread misunderstanding: the DPIA does not legitimise, on its own, the use of biometrics. The AEPD's criterion on the use of biometric data —for example, for time-and-attendance control or access to premises— is strict, and an impact assessment is not a shortcut that makes lawful what does not pass the test of necessity and proportionality. The DPIA measures the risk; it does not create the legal basis that the processing still needs.
The phases of a DPIA
The GDPR sets the content of the assessment (art. 35(7)), but does not impose a single form. In practice, a well-conducted DPIA works methodically through a series of phases that translate that minimum content into structured work. These are the usual stages:
1. Description of the processing
Document systematically what is going to be done: what data are processed, of which individuals, for what purpose, on what legal basis, who accesses them, which processors are involved (art. 28), what flows and transfers there are and for how long they are retained. Without a precise description, the rest of the analysis rests on thin air.
2. Necessity and proportionality analysis
Verify that the processing is necessary for its purpose and proportionate: that there is no less intrusive alternative, that data minimisation is applied, that retention periods are tailored and that data subjects' rights and the duty to inform (art. 13) are guaranteed. This is where many projects discover that they were asking for more data than they actually needed.
3. Identification and assessment of risks
Assess which threats weigh on the rights and freedoms of individuals —unauthorised access, uses incompatible with the purpose, loss or alteration of data, wrong decisions derived from a profile— and estimate their likelihood and impact. The result is a prioritised risk map, not a hunch.
4. Mitigation measures and decision
Define the safeguards and technical and organisational measures that reduce each risk to an acceptable level (pseudonymisation, encryption, role-based access control, minimisation, human review of automated decisions, etc.) and assess the residual risk that remains after applying them. With that result the controller decides: proceed, redesign the processing or, if the residual risk remains high, raise a prior consultation with the AEPD.
The DPIA is not a document that is signed and filed away. Art. 35(11) provides for its review when there is a change in the risk of the processing. If a new technology is incorporated, the purpose is extended or the volume of data changes, the assessment must be reviewed so that it continues to reflect reality.
Who carries out the DPIA: the controller and the DPO
Ownership of the DPIA is unequivocal: it is carried out by the controller (art. 35(1) GDPR). It is the controller who decides on the processing and therefore who must assess it and take on its conclusions. This responsibility cannot be delegated: external technical or legal support may be sought to prepare it, but the final decision and accountability remain with the controller.
Where the organisation has a Data Protection Officer, the controller is required to seek their advice when carrying out the assessment (art. 35(2) GDPR). And this is no coincidence: among the DPO's functions, art. 39(1) GDPR expressly includes providing advice on the DPIA and monitoring its performance. The allocation of roles is clear:
- The controller decides on the processing, carries out the assessment, adopts the measures and is accountable for all of it.
- The DPO advises on how to conduct the DPIA, on the methodology and on the measures, and monitors that the assessment is applied correctly. They advise and oversee; they do not replace the controller in the decision.
Where the processing relies on a processor (cloud software, a technology provider), the DPIA also draws on the information that processor provides about its security measures. The processor has a duty to assist the controller in complying with its obligations, including the impact assessment, under art. 28(3)(f) GDPR.
"A well-conducted DPIA usually saves more than it costs: it forces you to redesign the processing before launching it, not after a breach. The problem is not the one who does it and finds they have to change something; it is the one who does not do it and discovers the risk when there is no longer any remedy."
Mario P. Talamillo · Managing Partner, Certix®
Prior consultation with the AEPD: when the risk remains high
The DPIA can end in one of two ways. The usual outcome is that, after applying the mitigation measures, the residual risk is at an acceptable level and the controller can start the processing while documenting the assessment. But there is a second scenario, much less frequent and specifically regulated.
If the assessment concludes that, even with the measures envisaged, the processing would still entail a high residual risk, the controller cannot simply accept it and go ahead. Art. 36 GDPR requires them to carry out a prior consultation with the supervisory authority —the AEPD in Spain— before starting the processing.
In that consultation, the controller provides the AEPD with the relevant information about the processing and the impact assessment itself. The authority may request additional information and, if it considers that the processing would infringe the Regulation, issue written recommendations to the controller and even exercise its corrective powers. The practical consequence is direct: the processing must not be started while the consultation is pending resolution.
It is worth understanding the prior consultation for what it is: not just another bureaucratic step, but a safety valve in the system. It is triggered only when the organisation itself, after analysing it, has not managed to reduce the risk to a reasonable level. If you reach that point frequently, the signal is usually not that "you have to consult a lot", but that the design of the processing should be reconsidered.
Checklist before you start
Before considering the analysis phase of a risky processing operation closed, it is worth checking these points:
- ✅ Have I compared the processing against the three cases in art. 35(3) and against the AEPD's list of processing operations?
- ✅ Have I described the processing systematically: data, purposes, legal basis, processors, flows, retention periods?
- ✅ Have I justified the necessity and proportionality, genuinely applying data minimisation?
- ✅ Have I identified the risks to people's rights and estimated their likelihood and impact?
- ✅ Have I defined concrete mitigation measures and assessed the residual risk that remains after applying them?
- ✅ Have I sought the advice of the DPO (if the organisation has one) and recorded it?
- ✅ Have I checked whether a prior consultation with the AEPD is required (art. 36) due to high residual risk?
- ✅ Have I planned for the review of the assessment if the processing changes (art. 35(11))?
Frequently asked questions
What is a DPIA and what is it for?
The Data Protection Impact Assessment (DPIA, EIPD in Spanish) is the prior analysis required by art. 35 GDPR when a processing operation may entail a high risk to the rights and freedoms of individuals. It serves to describe the processing, assess its necessity and proportionality, identify the risks and define the measures that reduce them before the activity is started. It is an internal document for analysis and decision by the controller, not a formality to be submitted to anyone.
When is a Data Protection Impact Assessment mandatory?
Art. 35(3) GDPR requires it, as a minimum, in three cases: a systematic and extensive evaluation of personal aspects based on automated processing (including profiling) on which decisions with legal or similar effects are based; large-scale processing of special categories (art. 9) or of criminal data (art. 10); and systematic monitoring on a large scale of a publicly accessible area. In addition, the AEPD publishes a list of types of processing that require a DPIA, which must be checked case by case.
Who must carry out the DPIA, the controller or the DPO?
Responsibility for carrying out the DPIA lies with the controller (art. 35(1) GDPR). Where the organisation has a Data Protection Officer, the controller is required to seek their advice (art. 35(2)), and one of the DPO's functions is precisely to advise on the assessment and monitor its performance (art. 39(1) GDPR). The DPO advises and monitors; the decision and ownership of the document remain with the controller.
What happens if the risk remains high after the DPIA?
If the DPIA concludes that, even applying the mitigation measures envisaged, the processing would still entail a high residual risk, the controller must carry out a prior consultation with the supervisory authority (the AEPD in Spain) before starting the processing, in accordance with art. 36 GDPR. The AEPD may request additional information and issue recommendations. The processing must not be started until that consultation has been resolved.
How Certix supports you with the DPIA
The Impact Assessment is one of the tasks where the difference between filling in a template and doing a real analysis is most noticeable. A DPIA copied from a generic model does not describe your processing, does not identify your risks and does not protect you: it merely generates a document that looks like compliance. The value of the assessment lies precisely in the specific analysis of what your organisation does with the data.
At Certix we carry out the Impact Assessment starting from your real processing: we describe the operations, analyse their necessity and proportionality, map the risks and define the measures that reduce them, with the advice of the Data Protection Officer where that role exists. And we assess, with judgement, whether the case requires raising a prior consultation with the AEPD before starting.
If you want to understand the general framework in which the DPIA sits, you can start with our complete guide to the GDPR. And if your organisation must appoint or rely on a DPO for these assessments, review how the role of the Data Protection Officer works.
This content is purely informational and educational; it does not in any way constitute specialised legal advice. Applying the regulations to each specific case requires individual analysis.
Does your processing need an Impact Assessment?
At Certix we analyse whether your case requires a DPIA and carry it out based on your real activity, not on a generic template.
Speak to a consultant