Compliance Guides
What is a DPIA, and when does GDPR require one?
A DPIA is required before processing that is likely to result in a high risk to people’s rights. Here is the threshold, the three automatic triggers, what the assessment must contain, and when you must consult the regulator.
Photo: Anastassia Anufrieva / Unsplash
New to the topic? Start with What sovereign compliance actually means.
A DPIA is required where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons — and it must be carried out before the processing starts (GDPR Article 35(1)). Three cases trigger one automatically, your national supervisory authority publishes further lists on top, and if the assessment shows a high risk you cannot mitigate, you must consult the regulator before going ahead. Here is the whole test, what the document must contain, and who signs it off.
DPIA or PIA — what is the difference?
PIA— privacy impact assessment — is the generic, international term for assessing the privacy risk of something before you build it. It has no specific definition in EU law. DPIA— data protection impact assessment — is the instrument defined in GDPR Article 35, and it is the one with legal force in Europe. In practice people use the terms interchangeably; if you are operating under GDPR, the thing you actually need is a DPIA.
- Definition
- Data protection impact assessment (DPIA)
- The assessment required by GDPR Article 35 where a type of processing — in particular using new technologies, and taking into account its nature, scope, context and purposes — is likely to result in a high risk to the rights and freedoms of natural persons. It must be carried out before the processing begins.
When does GDPR require a DPIA?
The general threshold is Article 35(1): processing that is likely to result in a high risk to the rights and freedoms of natural persons. Article 35(3) then makes a DPIA required in particular in three cases.
| Automatic trigger (Art. 35(3)) | Typical examples |
|---|---|
| (a) Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions producing legal or similarly significant effects are based | Credit scoring, automated hiring or promotion decisions, insurance pricing |
| (b) Processing on a large scale of special-category data (Art. 9) or data on criminal convictions and offences (Art. 10) | Health records, biometric identification, background-screening services |
| (c) Systematic monitoring of a publicly accessible area on a large scale | CCTV across a retail estate, people-counting or tracking in public spaces |
On top of that, Article 35(4) requires each national supervisory authority to publish a list of processing operations that require a DPIA in its member state. This is the step most often missed: the answer can differ by country, so if you operate in several member states you have to check each one rather than relying on the directive text alone. It is the same national-variation trap that catches people under NIS2.
What a DPIA must contain
Article 35(7) sets a minimum of four elements. A document missing any of them is not a DPIA, whatever it is called:
- A systematic description of the envisaged processing operations and their purposes, including any legitimate interest pursued.
- An assessment of the necessity and proportionality of the processing in relation to those purposes.
- An assessment of the risks to the rights and freedoms of data subjects.
- The measures envisaged to address the risks— safeguards, security measures and mechanisms that both protect personal data and demonstrate compliance.
Note what the fourth element really asks for: not a list of intended controls, but measures that demonstrate compliance. That is an evidence requirement, and it is where most DPIAs quietly fail.
Who signs off, and when you must consult the regulator
- Your DPO. Article 35(2) requires the controller to seek the advice of the data protection officer, where one is designated.
- Data subjects, where appropriate. Article 35(9) asks the controller to seek the views of data subjects or their representatives on the intended processing, without prejudice to commercial or security interests.
- The supervisory authority, in one case. Article 36(1) requires prior consultation where the DPIA indicates the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk. Read literally that is about unmitigated risk; in practice regulators and guidance treat it as the case where a high risk remains after your mitigations. Either way, it happens before processing begins.
There is no routine filing duty. You are not sending DPIAs to the regulator as a matter of course — you are keeping them as accountability evidence and producing them on request.
Keeping DPIAs current — and out of spreadsheets
Article 35(11) makes a DPIA a living document: the controller must review it, at least where there is a change in the risk represented by the processing. That single line is what breaks the template approach.
Most organisations run DPIAs as Word or Excel templates, one per project. Every new feature, vendor, or dataset spawns another, each a point-in-time snapshot with no link between “risk identified” and “control that actually mitigates it” — and nothing that notices when either changes. Two years in you have dozens of files, an unknown number of which are no longer true. The fix is the same one that applies to compliance records generally: hold them as linked records rather than documents.
What happens if you skip one
Failing to carry out a required DPIA is an infringement of Article 35, which falls under Article 83(4)— the lower of the two fine tiers: up to €10 million, or up to 2% of total worldwide annual turnover of the preceding financial year, whichever is higher. Lower than the headline 4% tier, and still calculated on group-wide global revenue.
How COMPLY.Reg helps
COMPLY.Reg is a regulatory compliance platform that uses AI to turn requirements like these into a working, maintained record: it identifies which regulations apply to you, breaks each into individual requirements, maps them to controls, and tracks the evidence that proves each one — with a person reviewing every determination before it counts. For DPIAs specifically, that means the four Article 35(7) elements stay linked to live controls and evidence rather than frozen in a template. Your source documents stay on your own systems and your compliance data is processed in the EU. Not sure which regimes apply to you in the first place? Start with which EU regulations apply to your company.
Frequently asked questions
- What is the difference between a DPIA and a PIA?
- A PIA (privacy impact assessment) is the generic international term for assessing the privacy risk of a project. A DPIA is the specific instrument defined in GDPR Article 35 — it is the one that carries legal force in the EU. People often use “PIA” loosely to mean a DPIA.
- When is a DPIA mandatory under GDPR?
- Where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons. Article 35(3) makes it automatic for large-scale systematic evaluation or profiling with legal or similarly significant effects, large-scale processing of special-category or criminal-offence data, and large-scale systematic monitoring of a publicly accessible area. National supervisory authorities also publish their own lists.
- Do we have to send our DPIA to the regulator?
- Not routinely. You keep it as accountability evidence. You must consult the supervisory authority before processing only in the Article 36 case — where the DPIA indicates the processing would result in a high risk absent measures to mitigate it.
- What happens if we skip a required DPIA?
- Infringements of Article 35 fall under GDPR Article 83(4), the lower fine tier: up to €10 million, or up to 2% of total worldwide annual turnover of the preceding financial year, whichever is higher.