DPIA Guide: Data Protection Impact Assessment Under GDPR — Step by Step

A Data Protection Impact Assessment (DPIA) is a structured process for evaluating the privacy risks of data processing activities before they begin. GDPR Article 35 makes DPIAs mandatory for processing that is "likely to result in a high risk to the rights and freedoms of natural persons." Beyond compliance, DPIAs are a practical tool for identifying and mitigating privacy risks — catching problems during design is vastly cheaper than fixing them after deployment.

This guide walks through when a DPIA is required, the complete 6-step methodology, how to evaluate and mitigate risks, documentation requirements, and common pitfalls that undermine DPIA quality.

When Is a DPIA Required?

A DPIA is mandatory when processing is likely to result in high risk. GDPR Article 35 lists specific triggers:

• Systematic and extensive profiling with significant effects on individuals (e.g., automated credit scoring, behavioral targeting)
• Large-scale processing of special category data (health, biometric, genetic, political, religious, sexual orientation data)
• Systematic monitoring of publicly accessible areas (CCTV, location tracking)
• Processing on the supervisory authority’s mandatory DPIA list (each DPA publishes a list of processing types requiring DPIA)

Additionally, the Article 29 Working Party identified nine criteria that indicate high risk. If your processing meets two or more, a DPIA is strongly recommended: evaluation or scoring, automated decision-making with legal effects, systematic monitoring, sensitive data, large scale processing, combining datasets, vulnerable individuals (employees, patients, children), innovative technology use, and processing that prevents individuals from exercising rights.

The 6-Step DPIA Methodology

Step 1: Describe the Processing

Document comprehensively: what personal data is collected and from whom, for what purpose is it processed, what is the legal basis (consent, legitimate interest, contractual necessity, legal obligation), how is data collected, stored, used, shared, and deleted, who has access to the data (internal teams, processors, sub-processors), and what technology systems are involved and where is data physically stored.

Step 2: Assess Necessity and Proportionality

Evaluate whether the processing is necessary and proportionate to the stated purpose: Is the processing necessary for the stated purpose, or could the purpose be achieved with less data? Is data minimization applied (collecting only what is needed)? Are retention periods defined and enforced? Are there less intrusive alternatives that achieve the same result? Is the legal basis appropriate and documented?

Step 3: Identify Risks to Individuals

Consider what could go wrong from the perspective of the individuals whose data is processed: unauthorized access or data breach, excessive data collection beyond stated purpose, inaccurate data leading to wrong decisions, automated decisions with significant effects without meaningful human review, data shared with unauthorized third parties, inability to exercise data subject rights (access, deletion, portability), re-identification of pseudonymized data, and cross-border data transfers to jurisdictions without adequate protection.

Step 4: Evaluate Risk Severity

For each identified risk, assess likelihood (how probable is this risk?) and severity (what would the impact be on individuals?). Use a risk matrix: Likelihood: unlikely, possible, likely. Severity: minimal, significant, severe. Impact categories to consider: financial harm to individuals, discrimination or social disadvantage, physical harm or safety risk, psychological distress, reputational damage, and loss of control over personal data. Focus on risks rated as high (likely + significant/severe or possible + severe).

Step 5: Identify and Implement Mitigating Measures

For each high-priority risk, define measures to reduce likelihood or impact:

• Technical measures: Encryption (at rest and in transit), pseudonymization, access controls (RBAC/ABAC), data loss prevention, automated deletion after retention period, and secure development practices.
• Organizational measures: Data protection policies, staff training, data processing agreements with processors, regular audits, clear data handling procedures, and defined retention and deletion processes.
• Transparency measures: Clear privacy notices, accessible data subject rights mechanisms, and transparent communication about data use.

Step 6: Document, Consult, and Review

Document the entire DPIA process: processing description, necessity assessment, identified risks with severity ratings, mitigating measures and their expected effectiveness, residual risk assessment, and sign-off by the data controller. Consult the DPO throughout the process — their input is required by GDPR Article 35(2). If residual risk remains high after mitigation, consult the supervisory authority before processing begins (Article 36).

Frequently Asked Questions

What happens if we skip the DPIA?

Failure to conduct a mandatory DPIA can result in GDPR fines up to EUR 10 million or 2% of global turnover. Beyond fines, it undermines your accountability defense and may invalidate the legal basis for processing. Supervisory authorities regularly check for DPIAs during audits and investigations.

How long is a DPIA valid?

There is no fixed expiration. DPIAs should be reviewed when processing changes significantly, new risks emerge, or at regular intervals (annually is good practice). A DPIA is a living document that evolves with the processing it assesses.

Who should conduct the DPIA?

The data controller is responsible. In practice, DPIAs are conducted by the project or product team (who understand the processing), with input from IT security (risk assessment), legal (legal basis, contractual safeguards), and the DPO (oversight and advice). The DPO advises but does not approve — that responsibility lies with the controller.

Do we need a DPIA for every data processing activity?

No. DPIAs are required for processing likely to result in high risk. Low-risk, routine processing (standard employee payroll, basic customer contact management with consent) typically does not require a DPIA. However, when in doubt, conducting a DPIA is always defensible and demonstrates accountability.