DPIA: When a Data Protection Impact Assessment under Art. 35 GDPR Becomes Mandatory
Anyone who processes personal data with a high risk owes a data protection impact assessment under Art. 35 GDPR. This article explains thresholds, must-lists, review steps and the role of the data protection officer in the procedure.
A data protection impact assessment (DPIA) must be carried out under Art. 35(1) GDPR whenever a form of processing – in particular using new technologies – is likely, by virtue of its nature, scope, circumstances and purposes, to result in a high risk to the rights and freedoms of natural persons. The obligation falls on the controller, not first on the supervisory authority, and it applies before processing begins.
In practice, the points of dispute lie less in the wording of the provision than in the interpretation of the three criteria: when is a risk "likely to be high", which processing operations are on the supervisory authorities' must-lists, and who documents the result in an audit-proof manner? This article supplies the thresholds, the operational review steps and the role of the data protection officer up to the filed deed of appointment.
Key Takeaways
- A DPIA is mandatory as soon as the processing is likely to entail a high risk to data subjects' rights – not only once damage occurs.
- The state supervisory authorities keep must-lists under Art. 35(4) GDPR; if a processing operation is on one, the case-by-case threshold assessment is dispensed with.
- The data protection officer must be involved under Art. 35(2) GDPR; the result and consultation belong in the record of processing activities.
The Legal Basis: Art. 35 GDPR in Its Wording
Art. 35(1) GDPR obliges the controller to carry out, in advance, an assessment of the impact of the envisaged processing operations on the protection of personal data as soon as a processing operation is "likely to result in a high risk to the rights and freedoms of natural persons". What matters is the ex-ante view: the obligation arises before processing begins, not after an incident.
Art. 35(3) GDPR names three standard examples in which a DPIA is "in particular" required: first, the systematic and extensive evaluation of personal aspects with legal effect or similarly significant impairment (profiling, scoring); second, the large-scale processing of special data categories under Art. 9 or of data on criminal offences under Art. 10; third, the systematic large-scale monitoring of publicly accessible areas, for example through video surveillance.
Art. 35(4) supplements these standard examples with must-lists: the competent supervisory authority – in Germany the state data protection authorities – establishes and publishes a list of processing operations for which a DPIA must be carried out. These lists are binding; they replace the case-by-case threshold assessment. Anyone who needs clarity on the appointment will find the requirements for the external data protection officer on the role page.
The "High Risk" Threshold: The Nine WP 248 Criteria
The European Data Protection Board (EDPB), successor to the Article 29 Working Party, named nine criteria in its guidelines WP 248 rev.01 by which a high risk can be determined. If two or more criteria apply, a DPIA is as a rule deemed to be required. If three or more apply, it is deemed indisputably required.
The nine criteria, in abbreviated form, are: evaluation or scoring; automated decision-making with legal effect; systematic monitoring; confidential or highly sensitive data; large-scale data processing; matching or combining of data sets; data of particularly vulnerable data subjects (children, employees, patients); innovative use of new technological or organisational solutions; processing that prevents data subjects from exercising a right or making use of a service.
In practice, this means: a classic CRM with standard email marketing rarely meets two criteria. AI-supported applicant pre-selection regularly meets four (scoring, automated decision, vulnerable group, new technology) and triggers the DPIA obligation. The threshold assessment should be documented, even where it turns out negative. In the event of an examination, the supervisory authority asks why a processing operation was classified as not subject to a DPIA. The deadline runs from awareness.
The German Must-Lists: What Is Subject to a DPIA Without a Case-by-Case Assessment
The German Data Protection Conference (DSK) has published a largely nationally harmonised must-list under Art. 35(4) GDPR, which has been adopted by the state authorities. If a processing operation is on this list, the DPIA is mandatory without any further threshold assessment.
The listed processing operations include, among others: large-scale processing of biometric data for unique identification, large-scale processing of genetic data, AI-supported applicant selection and employee profiling, large-scale employee monitoring (keystroke, screen recording), telematics systems for behavioural observation, creditworthiness scoring, anonymous whistleblowing systems with personal follow-on effects, large-scale patient-record processing outside of treatment, data-intensive smart-home solutions with behavioural profiles.
It is important that the lists are not exhaustive. A processing operation that is not on the must-list may nonetheless be subject to a DPIA if the nine EDPB criteria apply. Conversely, Art. 35(5) GDPR expressly provides for negative lists – processing operations for which no DPIA is required. This list is considerably shorter in Germany and rarely applicable in practice. Controllers should therefore consult the must-list of the state authority competent for them and compare it with their own record of processing activities. A central overview of further mandatory questions is provided by the CIVAC FAQ page.
Mandatory Contents of a DPIA under Art. 35(7) GDPR
Art. 35(7) GDPR names four minimum contents without which a DPIA is deemed not to have been properly carried out. First: a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interests pursued by the controller.
Second: an assessment of the necessity and proportionality of the processing operations in relation to the purpose. Here it must be examined whether a less intrusive means is available. Third: an assessment of the risks to the rights and freedoms of data subjects under Art. 35(1). The risk assessment follows the classic matrix of likelihood of occurrence and severity of damage.
Fourth: the measures envisaged to address the risks, including safeguards, security measures and procedures to ensure the protection of personal data and to demonstrate it. These include technical measures (encryption, pseudonymisation, access restriction) and organisational measures (training, role separation, erasure and retention periods). The measures must push the remaining residual risk below the "high" threshold. If that does not succeed, the supervisory authority is consulted under Art. 36 GDPR – with an obligation to wait until the opinion is issued. Others run compliance like a filing cabinet. We run it like software.
The Role of the Data Protection Officer in the DPIA Procedure
Art. 35(2) GDPR obliges the controller to seek the advice of the data protection officer (DPO), where one has been designated. This involvement is neither optional nor informal. The DPO checks the methodology, completeness, depth of assessment and the appropriateness of the proposed protective measures.
Art. 39(1)(c) GDPR specifies the advisory duty: the DPO monitors, on request, the performance of a DPIA pursuant to Art. 35. In practice, the DPO often takes on the moderation of the DPIA process, coordinates IT, the specialist department, processors and the works council, and ensures that the mandatory contents are fully addressed.
The consultation of the DPO is part of the accountability obligation under Art. 5(2) GDPR. It belongs documented in the DPIA file: when advised, with what result, whether the recommendations were followed, and if not, with what justification. For external DPOs, the advisory service runs via the deed of appointment and the service relationship. In case of doubt, the supervisory authority examines both sides: the technical depth of the advice and management's response. The deed of appointment, signed, filed, demonstrable.
Prior Consultation of the Supervisory Authority under Art. 36 GDPR
If a DPIA reveals that the planned processing would result in a high residual risk despite all envisaged measures, the competent supervisory authority must be consulted before processing begins, under Art. 36(1) GDPR. The prior consultation is not to be confused with the notification of a personal data breach under Art. 33.
Art. 36(3) GDPR lists the documents to be submitted: the responsibility structure, the purposes and means of processing, the measures and safeguards envisaged to protect the rights of data subjects, the contact details of the DPO, the DPIA itself and any other information requested by the supervisory authority. The authority has eight weeks under Art. 36(2) for a written recommendation. For complex processing, it can extend the deadline by six weeks.
During the consultation phase, the processing is suspended. Anyone who starts nonetheless risks orders under Art. 58(2) GDPR up to a processing ban, and fines under Art. 83(4)(a) GDPR: up to EUR 10 million or 2 % of worldwide annual turnover. In practice, prior consultations are rarely used in Germany, because most controllers deliberately push the residual risk below the threshold via the DPIA measures. Anyone who actually needs a prior consultation should plan for at least ten weeks of lead time.
Update Obligation and Ongoing Review
A DPIA is not a one-off document. Art. 35(11) GDPR requires the controller to carry out a review "to assess whether the processing is performed in accordance with the data protection impact assessment, at least when there is a change of the risk represented by the processing operations".
Triggers for an update include, among others: a change in the processing purpose, new data categories, new recipients or processors, a change of legal basis, the use of new technologies (e.g. generative-AI components), transfers to third countries without an adequacy decision, incidents under Art. 33/34 GDPR relating to the processing, new EDPB guidelines or binding requirements of the competent authority.
A periodic review at least every 24 months is advisable, documented with date, reviewer, result and, where applicable, the need for an update. The DPIA itself should contain a change register. For systemic changes – such as the introduction of AI-supported components under the EU AI Act – a complete revision may be required. More on the interface between the GDPR and the AI Regulation can be found in the CIVAC notes on the EU AI Act. The auditor calls, the evidence is ready.
Typical Use Cases from Practice
Anyone wishing to assess the threshold in practice benefits from typified case groups. Example HR-Tech: a personnel software that pre-sorts applications with AI-supported scoring and generates recommendations for the HR department meets the criteria of scoring, automated decision-making, vulnerable group and new technology. DPIA obligation clear-cut.
Example health: a patient app that collects vital parameters and transmits them to a doctor processes health data under Art. 9 GDPR on a large scale. DPIA obligation regularly, depending on user numbers, data flow and circle of recipients. Example employee monitoring: telematics systems in field service that capture position, speed and break times meet extensive monitoring and vulnerable group (employees). DPIA obligation explicitly named in the German must-lists.
Example video surveillance: a camera at the employee entrance without audio capture meets monitoring, vulnerable group and systematic processing. Here it depends on scope and purpose limitation. A point-specific access control without a behavioural profile is, in borderline cases, not subject to a DPIA; comprehensive observation of the work areas regularly is. Example newsletter: standardised dispatch with double opt-in, without profiling and without third-country transfer, meets hardly any criterion. No DPIA obligation, but documentation of the negative result is recommended. Audit-proof, documented, Section 35-proof.
Turning Reading into a Mandate
The DPIA is an operational standard process, not a special legal project. Anyone working with a high processing frequency – AI rollouts, new marketing stacks, HR-Tech, IoT – needs a procedure that carries the threshold assessment, risk assessment, DPO consultation and follow-up in one system. CIVAC operates a compliance platform and Officer-as-a-Service for this: 37 ready-to-use audit templates, a DPIA workflow with the nine EDPB criteria as a filter, the DPO's deed of appointment cleanly filed, the record of processing activities beside it.
License the workspace for your internal officers – or have our officers appointed. Both paths culminate in the same evidence: threshold assessed, DPIA carried out, measures implemented, follow-up set. The workspace uses EU data residency and an ISO 27001:2022 ISMS, so that the supervisory authority finds no side issues.
Turn reading into a mandate. Anyone wishing to have a specific processing operation checked against the threshold or to work through a DPIA backlog writes to info@civac.de or uses the contact form. We get back to you within two working days with an assessment and a proposal on whether a workspace, an external DPO or both models are the right path.
FAQ
Must we also carry out a DPIA for existing processing operations?
In principle, Art. 35 GDPR applies to new processing operations from May 2018 onwards. For existing processing there is a catch-up obligation as soon as purpose, scope or technology changes or an increased risk situation becomes apparent. Supervisory authorities recommend periodically re-assessing critical legacy processing.
Who is liable if a DPIA is omitted or carried out incorrectly?
Responsibility remains with the controller within the meaning of Art. 4(7) GDPR, that is, the company. Fines reach up to EUR 10 million or 2 % of worldwide annual turnover under Art. 83(4)(a) GDPR. The DPO itself is not personally liable, but management can be held accountable under Section 130 OWiG.
How long does a DPIA take in practice?
A structurally prepared DPIA with a clearly delimited processing operation and an existing record takes four to eight weeks. Complex procedures with several processors, third-country transfers or AI components take twelve weeks and longer. A prior consultation under Art. 36 extends the period by at least eight further weeks.
Is a single DPIA sufficient for several similar processing operations?
Yes. The second sentence of Art. 35(1) GDPR allows a single DPIA for several similar processing operations with comparably high risks. In practice this works, for example, for standard CRM modules across subsidiaries, provided the technical and organisational measures are uniform.
Must the DPIA be published?
There is no obligation to publish. The EDPB and several German supervisory authorities nonetheless recommend publishing a summary as a transparency and trust measure. The full version remains internal and is handed over on the authority's request.
When must an existing DPIA be updated?
An update is required under Art. 35(11) GDPR with every relevant change in the risk situation, for example with new purposes, new data categories, a change of technology, new processors or incidents. In addition, a routine review every 24 months is advisable, documented with date and reviewer.
Turn this into a mandate.
Let us carry the operational weight. External officer, templates and documentation in one workspace. No obligation.