GDPR DPIAs: when Article 35 is mandatory, and how to write one that is not a template

A DPIA is a decision record for high-risk personal-data processing under GDPR Article 35. It should explain what data is processed, why the processing is necessary, who is affected, what could go wrong for those people, which safeguards reduce risk, and what residual risk remains after mitigation.

The process is most useful before design choices harden. DPIAs can apply to systematic monitoring, large-scale special-category data, scoring, automated decision support, new technologies, vulnerable groups, or combinations of data that change the risk profile. The output should be actionable enough for product and engineering teams, not only readable by lawyers.

A strong DPIA also records alternatives. If the team considered shorter retention, on-device processing, pseudonymization, sampling, manual review, smaller vendor scope, or opt-out design and rejected those options, the rationale should be visible. That history shows the organization treated the assessment as design governance rather than a compliance form. It also gives reviewers a practical trail from identified harm to product choice, which is often missing when teams draft the assessment after decisions are already locked.

The checklist cannot decide whether residual risk is acceptable. It can force the team to name risks and measures, but the controller must decide whether remaining risks to people are justified, whether the processing should change, or whether consultation with a supervisory authority is needed.

It also cannot define necessity and proportionality for the business. Teams must decide whether the same objective can be achieved with less data, shorter retention, weaker identifiability, more human review, or fewer recipients. That decision is product design, not paperwork.

The checklist will not replace DPO judgment. Where a DPO exists, their advice should be requested early enough to affect the design and recorded even when the organization chooses a different path with reasons.

The most damaging failure is writing the DPIA after launch. At that point, high-risk choices about data collection, model features, vendor integration, retention, and user transparency are expensive to change. The DPIA becomes a justification exercise instead of a risk-reduction tool.

Copy-paste templates are another real problem. Teams reuse language from a low-risk SaaS rollout for a machine-learning model, biometric workflow, workplace monitoring system, or vendor enrichment project. The document looks complete but ignores the specific harms, affected groups, and technical safeguards that matter.

DPIAs also fail when the DPO is not consulted, vendors are not assessed, or reviews never happen after material change. A DPIA for a model trained on one dataset may be obsolete after new data sources, new recipients, new geographies, or new automated decisions are added.

Machine-learning and vendor projects create particular blind spots. Teams describe the user-facing feature but omit training data, inference logs, model monitoring, human review queues, subprocessors, and feedback loops. Those details are often where risks to individuals become concrete, especially for discrimination, overcollection, explainability, and contested decisions.

Use the checklist first as a screening gate. For each new or changed processing activity, ask whether high-risk indicators are present and document the result. If a full DPIA is required, assign owners from product, engineering, privacy, security, legal, and vendor management.

Work through the checklist with system diagrams, data flows, vendor documents, model documentation, retention rules, and user journeys open. Each answer should be tied to evidence or a design decision. If the answer is unknown, the action is to investigate, not to mark the item complete.

Close the DPIA with decisions: mitigations accepted, mitigations still required, residual risk, DPO advice, consultation analysis, and review trigger. Revisit it when the product, data, model, vendor, or user population changes materially. Store the final decision next to the product record so launch, procurement, and engineering teams can see which safeguards are commitments rather than optional recommendations.