When is a Data Protection Impact Assessment required?

Why this matters for the AIGP exam

DPIA threshold questions test whether candidates can apply a structured analysis to a described processing scenario and correctly determine whether a DPIA is required. The difficulty is that the threshold is not a single rule but a combination of Article 35 mandatory triggers, supervisory authority lists, and a nine-criteria risk assessment framework from the Article 29 Working Party (now EDPB).

Exam questions often present scenarios that appear to require a DPIA but where one element is missing, or scenarios that appear routine but where a high-risk element is present. The goal is to test systematic analysis, not just pattern recognition.

The legal requirement

Article 35(1) GDPR requires a DPIA where processing is "likely to result in a high risk to the rights and freedoms of natural persons." This is a substantive standard, not a checklist. However, Article 35(3) identifies three specific types of processing that always require a DPIA:

1. Systematic and extensive evaluation of personal aspects of individuals based on automated processing, including profiling, which produces legal or similarly significant effects.
2. Large-scale processing of special category data or data relating to criminal convictions and offences.
3. Systematic monitoring of a publicly accessible area on a large scale.

Supervisory authorities must also publish lists of processing operations that require a DPIA in their jurisdiction. These lists extend beyond the three mandatory Article 35(3) categories and are jurisdiction-specific.

The nine risk criteria (EDPB guidance)

The EDPB (formerly WP29) identified nine criteria that indicate high-risk processing. When two or more of these criteria apply, a DPIA is generally required:

1. Evaluation or scoring of individuals (including profiling)
2. Automated decision-making with legal or similarly significant effects
3. Systematic monitoring
4. Sensitive or highly personal data (special categories, financial data, location data)
5. Large-scale data processing
6. Matching or combining datasets from different sources
7. Data concerning vulnerable data subjects (children, employees, patients)
8. Innovative use of technology or organizational solutions
9. Processing that prevents data subjects from exercising a right or using a service

A single criterion meeting an Article 35(3) trigger always requires a DPIA. Two or more criteria from the EDPB list generally require one.

Scenario example

A hospital wants to implement an AI system that analyzes patient health records to predict which patients are at high risk of hospital readmission. The system will be used to prioritize outreach from a care coordination team.

Applying the Article 35 analysis: this involves large-scale processing of special category health data (Article 35(3)(b) trigger, mandatory DPIA). It also involves automated processing that produces significant effects on which patients receive priority care. It involves a vulnerable data subject group (patients) and innovative technology. Multiple criteria are satisfied, and one mandatory trigger is met. A DPIA is clearly required before the system is deployed.

The hospital must conduct the DPIA before deployment, not after. If the DPIA identifies a residual high risk that cannot be mitigated with reasonable measures, the hospital must consult its supervisory authority before proceeding.

Common confusion and exam trap

The most common trap is conflating "large scale" with any processing involving multiple people. GDPR does not define large scale precisely, but guidance considers factors including the number of data subjects, the volume of data, the geographic extent, and the duration of processing. Processing records for a single employee health issue is not large scale. Processing records for all patients at a regional hospital network is.

A second trap involves timing. A DPIA must be conducted before the processing begins. A retrospective DPIA conducted after a system is already in use is not compliant with the proactive obligation in Article 35, even if the DPIA itself is thorough.

A third trap involves the outcome of a DPIA. A DPIA does not authorize high-risk processing. It identifies risks and documents mitigation measures. If the DPIA concludes that processing poses a high residual risk that cannot be adequately mitigated, the organization must consult the supervisory authority before proceeding. The supervisory authority may prohibit the processing.

When a DPIA is not required

A DPIA is not required for every processing activity. Processing that is unlikely to result in high risk to individuals, that uses anonymized data, or that is a minor continuation of existing activities that have already been subject to a DPIA may not require one. Supervisory authorities also publish lists of processing types that do not require a DPIA. These white lists help organizations prioritize where their DPIA efforts are needed.