DPIA: What GDPR Article 35 Actually Requires

A DPIA is not a risk assessment with a privacy label on it. Article 35 of the GDPR asks for something specific, and two of its four required elements are the ones templates most often leave out.

It also has to happen before the processing starts. A DPIA written after launch documents a decision; it does not inform one, and that is the difference between compliance and paperwork.

When a DPIA is required

The trigger in Article 35(1) is general: where a type of processing, in particular using new technologies, and taking into account the nature, scope, context and purposes, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall carry one out prior to the processing.

Article 35(3) then names three cases where a DPIA is required in particular:

• Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the person.
• Large-scale processing of special categories of data under Article 9(1), or of criminal conviction and offence data under Article 10.
• Systematic monitoring of a publicly accessible area on a large scale.

Read “in particular” carefully. That list is illustrative, not exhaustive — the actual test is the high-risk test in 35(1). Organisations that treat the three cases as a checklist conclude no DPIA is needed for processing that plainly meets 35(1).

There is also a published shortcut most people never use. Article 35(4) requires every supervisory authority to establish and publish a list of processing operations that need a DPIA, and Article 35(5) lets them publish a list of operations that do not. Check both for your authority before arguing the point internally.

What a DPIA must contain

Article 35(7) sets a minimum of four elements. The wording is “at least”, so this is a floor rather than a template.

(a) A systematic description of the envisaged processing operations and the purposes, including where applicable the legitimate interest pursued by the controller.

(b) An assessment of the necessity and proportionality of the processing operations in relation to the purposes.

(c) An assessment of the risks to the rights and freedoms of data subjects.

(d) The measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance.

Element (b) is the one that gets skipped, and it is not a risk score. Necessity and proportionality is a legal test: is this processing actually needed to achieve the purpose, and is the intrusion proportionate to what is gained? A DPIA that rates risks and lists controls but never answers that question has missed a mandatory element — and it is the element that occasionally produces the right answer, which is not to do the processing.

Note also the last four words of (d): the measures must demonstrate compliance, not merely achieve it.

Two obligations around the assessment

Article 35(2) requires the controller to seek the advice of the data protection officer, where one is designated. That is an obligation on the controller, not a courtesy — and it should be visible in the document.

Article 35(9) is the one almost nobody does: where appropriate, the controller shall seek the views of data subjects or their representatives on the intended processing, without prejudice to commercial or public interests or the security of processing.

“Where appropriate” gives latitude, but a high-risk processing operation affecting a defined group — employees, patients, students — is exactly where a regulator will ask whether you asked them. Recording why you judged it inappropriate is a much better position than silence.

When you must consult the regulator

Article 36 is widely misread as “high risk means consult”. It does not.

The obligation bites 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. If your mitigations bring the residual risk down, you proceed without consulting. If high risk remains after everything you can reasonably do, you consult before processing.

The timeline matters for planning. The supervisory authority provides written advice within up to eight weeks of receiving the request, extendable by a further six weeks where the processing is complex. Fourteen weeks is a long time to discover in a project plan.

Two efficiencies in the text

One DPIA can cover several operations. Article 35(1) says a single assessment may address a set of similar processing operations presenting similar high risks. You do not need one per system, and organisations that produce dozens of near-identical DPIAs are creating work the Regulation does not ask for.

Codes of conduct count. Article 35(8) says compliance with approved codes of conduct is to be taken into due account when assessing impact.

How the DPIA connects to other regimes

Where to start with a DPIA

1. Check your supervisory authority’s Article 35(4) and 35(5) lists before debating whether one is needed.
2. Start before the processing does. If the system is live, you are remediating, not assessing.
3. Answer necessity and proportionality explicitly, in its own section, as a legal question.
4. Involve the DPO on the record, as Article 35(2) requires.
5. Decide about data subjects’ views and write down the decision either way.
6. Group similar operations into one assessment rather than producing dozens.

This guide reflects Regulation (EU) 2016/679 as published on EUR-Lex, read at 15 August 2026. National supervisory authorities publish their own lists and guidance — check yours.

The GDPR Toolkit provides 100+ editable templates including the DPIA template and screening questionnaire, the records of processing, the legitimate interests assessment and the data subject rights procedures.