Data Protection Impact Assessment (DPIA)

“A DPIA is useful only while the design can still change. ”

A Data Protection Impact Assessment is often treated as the privacy equivalent of a permission form. A project team completes a template, obtains a signature and files the document beside the system it describes. That approach records a decision already made. A DPIA is intended to shape the decision before high-risk processing begins.

Article 35 of the General Data Protection Regulation requires a DPIA where processing is likely to result in a high risk to the rights and freedoms of natural persons. The assessment should describe the planned processing and purposes, evaluate necessity and proportionality, assess risks and identify measures, safeguards and mechanisms that address them. The risk is to people, not primarily to the organisation.

Regulatory fines, reputational damage and project delay may matter internally, but the DPIA asks how processing can affect privacy, autonomy, equality, access to services, freedom of expression, physical safety or other rights. A low financial risk to the company can coexist with severe consequences for an individual.

Consider a system combining precise farm locations, household income, ethnicity, grievance history and automated risk scoring. Each dataset may have been collected for a legitimate purpose. Together they can reveal sensitive patterns, influence market access and expose households if shared. The DPIA should examine the combined processing rather than approve each field in isolation.

The EDPB-endorsed guidance identifies factors that may indicate high risk, including evaluation or scoring, automated decisions with significant effects, systematic monitoring, sensitive data, large scale, dataset matching, vulnerable people, innovative technology and processing that may prevent people exercising a right or using a service. Several factors together strengthen the case for assessment.

Necessity and proportionality are more demanding than stating benefit. The organisation should ask whether the purpose is legitimate, whether the processing can achieve it, whether less intrusive alternatives exist and whether the scale, precision, access and retention are proportionate. A technically useful feature may still be unnecessary. Participation improves the assessment.

Data-protection officers, security teams, field staff, subject experts and processors may see different risks.

Where appropriate, the controller should seek the views of data subjects or their representatives. A system affecting smallholder farmers may be reviewed very differently by people who understand local land conflict, household power or device sharing. Risk controls should change the design.

Measures may include removing fields, reducing location precision, separating identifiers, limiting automation, adding human review, restricting recipients, shortening retention, enabling correction or creating a safer appeal route. Listing encryption and training against every risk suggests the assessment has become generic. Residual risk remains after safeguards.

If high risk cannot be reduced sufficiently, prior consultation with the supervisory authority may be required before processing. The project owner should not simply accept the risk on behalf of individuals whose rights are affected. A DPIA is also a living assessment. New purposes, data sources, algorithms, partners or contexts can materially change risk.

Review should be triggered by change and by evidence from incidents, complaints or unexpected outcomes. The discipline is to use the DPIA as a design challenge, not a compliance defence. It should make assumptions visible, compare alternatives and document why the remaining processing is necessary and proportionate. The strongest result may be approval with safeguards, redesign or a decision not to proceed.

Practical application

Screen projects early for high-risk indicators. Complete the DPIA before procurement, coding or data collection becomes difficult to change. Map data flows, people affected, purposes, decisions, harms, likelihood, severity and existing controls. Involve independent privacy, security and contextual expertise. Record alternatives rejected and the reasons.

Assign actions, owners and deadlines, assess residual risk and set review triggers. Link the DPIA to change control, incident response and rights handling.

Why it matters

High-risk data systems can affect livelihoods, safety and rights at scale. A DPIA creates structured challenge before deployment, when intrusive features can still be removed and safeguards designed around real consequences.

Common misconception

A DPIA is often treated as a form proving GDPR compliance. It is a process for identifying and reducing risks to people. Completion does not authorise unlawful or disproportionate processing.

Connections

Privacy by Design turns DPIA findings into architecture and controls. Data Minimisation and legal basis tests shape necessity. Pseudonymisation may reduce risk, while Grievance Mechanisms and appeals provide evidence about harms after deployment.

A question worth asking

What material feature of your system changed because of the DPIA - and if nothing changed, was the assessment early and independent enough to matter?

Selected references

European Union. 2016. Regulation (EU) 2016/679, Articles 35 and 36. Article 29 Data Protection Working Party. 2017. Guidelines on Data Protection Impact Assessment and Determining Whether Processing Is Likely to Result in a High Risk. European Data Protection Board. 2018. Endorsement of the WP29 DPIA Guidelines. European Data Protection Board. 2026.

Template for Data Protection Impact Assessment, Consultation Version. ISO/IEC 29134:2023. Information Technology - Security Techniques - Guidelines for Privacy Impact Assessment.