DPIA Guide: When You Need a Data Protection Impact Assessment

Article 35 of GDPR (Regulation 2016/679) requires organizations to conduct a Data Protection Impact Assessment (DPIA) before starting certain types of high-risk processing. For many organizations, the DPIA requirement is either systematically ignored — with significant legal exposure — or treated as an administrative checkbox that produces documents no one reads. Neither approach is right.

A properly conducted DPIA is one of the most useful exercises in your data protection programme. It forces systematic thinking about risk before systems are built, not after they are deployed. This guide explains when a DPIA is required, how to conduct one, and what the output should look like.

What Is a DPIA?

A DPIA is a documented process for identifying and minimizing the data protection risks of a project, product, or business process. It is not primarily a compliance exercise — it is a risk management tool that happens to be legally required in certain circumstances.

The EDPB's Guidelines 09/2022 on Data Protection Impact Assessments (updating the earlier WP29 Guidelines 248) describe the DPIA as a "process designed to describe the processing, assess its necessity and proportionality and help manage the risks to the rights and freedoms of natural persons resulting from the processing of personal data."

Critically, a DPIA must be completed before the processing begins. Article 35(1) is explicit: "where a type of processing... is likely to result in a high risk... the controller shall, prior to the processing, carry out an assessment." Conducting a DPIA retrospectively, after a system is already in production, does not satisfy the requirement.

When Is a DPIA Required?

Article 35 establishes a two-step trigger.

Step 1: High-Risk Processing Types

A DPIA is mandatory when processing is "likely to result in a high risk to the rights and freedoms of natural persons." Article 35(3) identifies three categories that always require a DPIA:

a) Systematic and extensive evaluation of personal aspects of natural persons based on automated processing, including profiling, that produces decisions with significant effects (e.g., credit scoring, employment screening algorithms, automated loan decisions)

b) Large-scale processing of special categories of data (Article 9) — health, biometric, genetic, racial/ethnic origin, religious beliefs, political opinions, sexual orientation — or data relating to criminal convictions

c) Systematic monitoring of publicly accessible areas on a large scale (e.g., CCTV systems in public spaces, employee monitoring tools, smart city data collection)

Step 2: National Authority "Must Conduct" Lists

Each national supervisory authority has published lists of processing types that require a DPIA in their jurisdiction. The EDPB has coordinated these lists, but national variations exist.

Processing types commonly found on national "must conduct" lists include:

• Biometric data used for unique identification (facial recognition, fingerprint authentication)
• Health data processed by insurers, employers, or health apps
• Location tracking at scale or with high precision over extended periods
• Employee monitoring beyond basic access control
• Matching or combining datasets in ways not reasonably expected by the data subject
• Processing of data concerning vulnerable individuals (children, patients, asylum seekers)
• Processing that could result in exclusion from services or opportunities
• IoT devices that collect personal data from domestic environments
• New uses of existing datasets for AI training

Beyond mandatory cases, the EDPB guidelines state that controllers should conduct a DPIA for any novel processing where they cannot clearly determine that risk to individuals is not high. When in doubt, conduct the DPIA.

The Three-Factor High-Risk Test

For cases not clearly covered by the lists, the EDPB's nine criteria help determine whether processing is "likely to result in high risk." Processing that meets two or more of these criteria should trigger a DPIA:

1. Evaluation or scoring (profiling, assessing performance, creditworthiness)
2. Automated decision-making with significant effects
3. Systematic monitoring
4. Sensitive data or data of a highly personal nature
5. Data processed at large scale
6. Matching or combining datasets from multiple sources
7. Data concerning vulnerable data subjects
8. Innovative use or application of new technological solutions
9. Processing that prevents data subjects from exercising their rights or obtaining a service

Who Conducts the DPIA?

The data controller is responsible for conducting and documenting the DPIA. In practice, this typically means the data protection or privacy team leads the process, with input from:

• Technical teams (who understand the system architecture and data flows)
• Legal/compliance teams (who assess proportionality and legal bases)
• Security teams (who assess technical and organizational security measures)
• Business stakeholders (who understand the purpose and necessity of the processing)

The Data Protection Officer (DPO), if one has been appointed, must be consulted in the DPIA process under Article 35(2). This does not mean the DPO conducts the DPIA — the controller retains responsibility — but the DPO's advice must be sought and documented.

Where the controller cannot resolve identified high risks through their own measures, Article 36 requires prior consultation with the supervisory authority before processing begins. Supervisory authorities have up to eight weeks to provide written advice on high-risk processing that cannot be mitigated.

The 9-Step DPIA Process

The EDPB guidelines and Article 35 together define the required elements of a DPIA. A robust process includes these nine steps.

Step 1: Describe the Processing

Document what data you are collecting, from whom, and how. This should include:

• Data categories: What personal data is involved (general personal data, special categories, children's data)
• Data subjects: Who the individuals are (customers, employees, users, the general public)
• Processing purposes: Why the data is being processed
• Recipients: Who will have access to or receive the data
• Transfers: Whether data will be transferred outside the EEA
• Data lifecycle: How long data will be retained and how it will be deleted

This step often reveals that the processing scope is broader than initially understood.

Step 2: Assess Necessity and Proportionality

Article 35(7)(b) requires the DPIA to include "an assessment of the necessity and proportionality of the processing operations in relation to the purposes."

Ask: Is this processing necessary to achieve the stated purpose? Could the purpose be achieved with less data, less invasive technology, or different processing? Is the retention period proportionate?

A DPIA that concludes that the processing is not proportionate must lead to a redesign of the system — not a rubber stamp that the risk is "accepted."

Step 3: Assess Compliance with GDPR Principles

Check that the processing design complies with:

• Lawfulness: Is there a valid legal basis under Article 6 (and Article 9 for special categories)?
• Purpose limitation: Is data used only for the stated purpose?
• Data minimization: Is only the necessary data collected?
• Accuracy: Are there mechanisms to keep data accurate?
• Storage limitation: Is retention proportionate and time-limited?
• Integrity and confidentiality: Are appropriate security measures in place?
• Accountability: Can you demonstrate compliance?

Step 4: Identify Risks to Data Subjects

This is the core of the DPIA. Identify the risks that the processing creates for the rights and freedoms of individuals. The EDPB framework focuses on three types of harm:

• Physical harm: Safety risks, physical violence (relevant for location data, domestic abuse contexts)
• Material harm: Financial loss, discrimination, denial of services, employment consequences
• Non-material harm: Reputational damage, loss of control over personal data, distress, social exclusion

For each risk, document:

• The threat (what could go wrong — data breach, unauthorized access, discriminatory profiling, function creep)
• The likelihood (how probable is this threat given current controls)
• The severity (how serious would the harm be for affected individuals)
• The residual risk level (after applying planned measures)

Step 5: Identify Risk-Mitigating Measures

For each risk identified in Step 4, document the technical and organizational measures that will be applied to mitigate it. These might include:

• Encryption at rest and in transit
• Pseudonymization or anonymization
• Access controls and least-privilege principles
• Audit logging
• Staff training
• Data minimization in system design
• Contractual protections with processors
• Regular security testing

The DPIA should result in a clear action list: specific measures, owners, and implementation timelines.

Step 6: Assess Residual Risk

After applying mitigating measures, re-assess each risk. Residual risk is the risk that remains after controls are applied. If residual risk is still high, additional measures are needed — or the processing design must be changed.

If residual risk cannot be brought to an acceptable level, Article 36 prior consultation with the supervisory authority is required.

Step 7: Consult the DPO (If Appointed)

Document the DPO's involvement, their advice, and whether their recommendations were followed. If the controller disagrees with the DPO's advice, this must be documented with reasoning.

Step 8: Consult Data Subjects or Representatives (Where Appropriate)

Article 35(9) states that "where appropriate, the controller shall seek the views of data subjects or their representatives on the intended processing." This does not mean a public survey for every DPIA. It applies where the perspectives of data subjects would be informative and where it is feasible to obtain them without prejudicing the project. User research, focus groups with representative stakeholders, or consultation with advocacy organizations can satisfy this requirement.

Step 9: Document and Maintain the DPIA

Article 35(7) requires the DPIA to include, at minimum:

• A systematic description of the processing operations and purposes
• An assessment of necessity and proportionality
• An assessment of risks to data subjects
• The measures envisaged to address the risks

The completed DPIA must be retained as documentation of accountability. DPIAs should be reviewed and updated when the processing changes materially or at regular intervals (annually for high-risk ongoing processing is a common practice).

When Does a DPIA Need to Be Updated?

A DPIA is not a one-time document. It must be reviewed and updated when:

• The purpose or scope of processing changes
• New data categories are added
• New third-party processors are engaged
• New technologies are introduced that change the risk profile
• A security incident reveals risks not previously identified
• The EDPB or national authority publishes new guidance affecting the processing type

DPIA Template: Core Sections

A functional DPIA does not need to be long. A well-structured document covering these sections typically runs 10–25 pages for a complex system:

| Section | Contents | |---|---| | 1. Description | Processing overview, data flows, purpose, legal basis | | 2. Necessity & Proportionality | Justification, could purpose be achieved with less? | | 3. GDPR Principles | Compliance assessment against each principle | | 4. Risk Assessment | Threats, likelihood, severity, affected subjects | | 5. Mitigation Measures | Controls, owners, timelines | | 6. Residual Risk | Post-mitigation risk level | | 7. DPO Consultation | Date, advice given, response | | 8. Conclusion | Decision to proceed / refer to supervisory authority | | 9. Review Schedule | Next review date and trigger events |

Common DPIA Failures

Conducting the DPIA after deployment: The requirement is prior assessment. Retrospective DPIAs document what was done, not what was considered — and do not satisfy Article 35.

Treating it as a checkbox: A DPIA that identifies high risks and then concludes "risks accepted" without documenting what was done to mitigate them, or why they are acceptable, will not withstand supervisory scrutiny.

Not updating when processing changes: Adding a new AI feature, engaging a new processor, or changing the retention period can materially change the risk profile of a system that already has a DPIA.

Failing to consult the DPO: Where a DPO has been appointed, consultation is mandatory. Document it.

WarDek's technical vulnerability scanning identifies the security exposures in your systems that directly affect DPIA risk assessments — giving you accurate, current information about residual technical risk rather than relying on assumptions.

This guide reflects GDPR Article 35 and EDPB Guidelines 09/2022 on DPIAs. Not legal advice. Complex processing scenarios should be assessed with qualified legal and data protection counsel.