Most organizations now have a DPIA template. The problem is often not that the template is missing, but that it insufficiently compels correct or complete completion. In practice, this results in DPIAs that fall short on precisely the points that matter: the processing is not described sharply enough, the risks are not filled in or are irrelevant, the link to measures is not traceable, and the legal basis is too weak to stand up in a supervisory or audit context.

Article 35(7) of the General Data Protection Regulation (GDPR) states what a DPIA must at least contain: (a) a systematic description of the envisaged processing operations and the purposes of the processing, (b) an assessment of the necessity and proportionality of the processing, (c) an assessment of the risks to the rights and freedoms of data subjects, and (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 with the GDPR. A DPIA model that "assumes" rather than documents one of these components is rarely defensible in a supervisory or audit context, because it does not show how the organization arrived at its choices.

A DPIA is therefore intended as a decision-making tool before the start or significant change of a high-risk processing operation (Article 35(1) GDPR). The organization must understand exactly what the processing entails, what risks arise from it, what measures are needed, and why these measures are adequate. If the template does not compel these questions, you will not get a true assessment. The question is therefore not whether a DPIA template exists, but whether that template enforces the right depth and justification.

Five practical checkpoints to review your DPIA template 

If you want to practically assess a DPIA model, it helps to use five checkpoints that ensure the model complies with the GDPR:

1. Does the template compel a thorough description of the processing?

A DPIA can be no better than the organization's understanding of its own processing. Yet, this is the component that is most often rushed in practice. It then says something like "we process personal data of customers for the purpose of our services," and the description ends there.

A good DPIA template compels more. It asks for a concrete description of the processing: what personal data is collected, from whom, by what means, and for what purpose. It clarifies what the IT landscape looks like: which systems are involved, where data is stored, what links exist between systems, and what data flows go to external parties? It identifies all involved parties and their GDPR role: who is the data controller, is there joint data controllership, which processors and sub-processors are involved, and what do they actually do with the data? [1]

Without this basis, every subsequent step (risk analysis, measures, legal basis) is built on assumptions instead of facts. A template that does not provide sufficient space and guidance here produces DPIAs that look neat but do not reflect reality.

2. Does the template compel identifying the real risks?

A risk analysis with only labels like "data breach," "discrimination," or "lack of transparency" does not provide useful insight. The problem is not that these risks are irrelevant, but that at this abstract level they say nothing about the specific processing being assessed.

A good DPIA template asks for scenarios: what can concretely go wrong, who will be affected, how serious is that for the data subjects, and how likely is it that this scenario will occur? This requires the completer to refer back to the description from checkpoint 1, as the risks depend on the type of data, the type of data subjects, the technology, the scale, and the context of the processing. [2]

In an HR context, this can involve exclusion, chilling effects (e.g., when employees adapt their behavior, communicate less freely, or refrain from exercising rights because they fear that data about them will be negatively recorded or evaluated), or pressure to consent to processing when refusal is practically not an option. This is a situation where the EDPB is critical of the validity of consent as a legal basis. In fraud or credit processes, the risks are more likely to be incorrect alerts, unjustified rejections, or insufficient opportunities to correct errors. A template that does not compel the completer to make that distinction will result in a risk analysis that is interchangeable between processing operations, and therefore, by definition, too superficial. [3]

3. Does the template establish a traceable link between risks and measures?

This is where most DPIAs most visibly fall short. There is a list of risks and next to it a list of measures, but the reasoning between them is missing. Which measure addresses which risk? Why is that particular measure appropriate? And what risk remains after the measure has been implemented?

Article 35(7)(d) GDPR requires a description of the measures and safeguards put in place to address risks and demonstrate compliance. A strong template therefore provides space for concrete and verifiable measures per risk: who is responsible for implementation, when must the measure be implemented, how is it determined that the measure not only exists on paper but actually works, and what are the evidence: configuration, logging, test results, audit reports.

The residual risk must also be explicitly visible. Not every risk disappears completely. Precisely for this reason, the template must compel an assessment of the risk that remains after the measures have been implemented. If that residual risk remains high, prior consultation of the supervisory authority is not optional but mandatory (Article 36(1) GDPR).

4. Does the template ensure the legal basis?

Technical and organizational measures are necessary, but not sufficient. A DPIA must also stand up legally. In practice, this is often the weakest layer: a legal basis is mentioned without being substantiated, the necessity and proportionality test is no more than a formality, and the GDPR principles are ticked off instead of being elaborated.

A good template forces the legal basis to have the same depth as the technical description. This means: an argued legal basis that is sustainable in the specific context, a substantive test of necessity and proportionality. Why exactly is this personal data needed, why can the purpose not be achieved in a less intrusive way, how are retention periods justified, and how are access rights structured in relation to the purpose (Article 35(7)(b) GDPR)? In addition, the template must show how privacy by design and by default have been concretely implemented: what standard settings, what data minimization, what access management (Article 25 GDPR). [4]

Without this legal layer, the DPIA is essentially a technical risk report with a GDPR label. This is not defensible in a supervisory context, because it does not show how the organization arrived at its choices.

5. Does the template keep the DPIA alive?

A DPIA is not a one-off exercise. The GDPR requires that, where appropriate, the views of data subjects or their representatives are sought (Article 35(9) GDPR). In an employment context, this may mean involving the works council, especially for monitoring, assessment, or new HR technology. In addition, based on the Works Councils Act, consent may be required, for example for employee tracking systems (Article 27(1)(l) Works Councils Act). Furthermore, where a data protection officer has been appointed, their advice must be sought when carrying out the DPIA (Article 35(2) GDPR). [5]

At least as important is that the DPIA remains up-to-date. The GDPR requires an assessment of whether the processing is still carried out in accordance with the DPIA, at least when the risk profile changes (Article 35(11) GDPR). A good template therefore includes a review date, an owner, and clear triggers for re-assessment: new purposes, expansion of datasets, new technology, changes in the processing chain, scaling up, incidents, or complaints.

Additional weight for AI and profiling

For AI applications, profiling, or models that effectively heavily guide the outcome of a decision, the bar is raised. A reference to "innovative technology" or "algorithmic risks" is then not sufficient. The template must compel the organization to describe what personal data the system uses, how the logic influences decision-making, where risks of bias or erroneous outcomes lie, what role human judgment still actually plays, and how data subjects can have an outcome checked or corrected. [6]

These requirements follow from a combination of the GDPR risk-based approach, the transparency and fairness principles, and the rules surrounding automated individual decision-making (Article 22 GDPR). For certain high-risk AI applications, a separate assessment of the impact on fundamental rights may also be required under the AI Act (Article 27 AI Act). In practice, this assessment will partially overlap with the GDPR DPIA. All the more reason to design the template in such a way that it truly analyzes the actual impact of a system, and not just ticks off privacy questions. [7]

Conclusion

The question is not whether an organization has a DPIA, but whether the DPIA template enforces the right depth. A template that superficially describes the processing, keeps risks abstract or general, does not traceably link measures, and treats the legal basis as a formality, results in a DPIA that looks complete but does not stand up to the first serious test.

Precisely for this reason, it is worthwhile to critically review one's own template against these five points: not on whether all boxes can be filled, but on whether the template compels the organization to truly understand the processing, make the risks concrete, and visibly and defensibly record the choices.

Sources

1. Art. 35(7)(a) GDPR (systematic description of processing and purposes). See also WP29/EDPB, Guidelines on Data Protection Impact Assessments (WP248 rev.01), 4 October 2017, p. 9–10 (description of processing as the foundation of the DPIA).

2. WP29/EDPB, Guidelines on DPIA (WP248 rev.01), p. 11–12 (criteria for high risk: scoring, profiling, systematic monitoring, innovative technology, vulnerable data subjects).

3. See on valid consent in power imbalances: EDPB, Guidelines 05/2020 on Consent under Regulation 2016/679, version 1.1, 4 May 2020, pars. 21–23.

4. EDPB, Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, version 2.0, 20 October 2020.

5. Art. 35(2) GDPR (DPO advice); Art. 35(9) GDPR (consultation of data subjects); Art. 27(1)(l) Works Councils Act (works council's right of consent). See also AP, List of processing operations for which a DPIA is mandatory, autoriteitpersoonsgegevens.nl/documenten/lijst-verplichte-dpia.

6. WP29/EDPB, Guidelines on Automated individual decision-making and Profiling (WP251 rev.01), 6 February 2018.

7. Regulation (EU) 2024/1689 (AI Act), Art. 27 (fundamental rights impact assessment for deployers of high-risk AI systems).