GDPR DPIA: When Is a Data Protection Impact Assessment Required? (2026)

A DPIA is required under Article 35 of Regulation (EU) 2016/679 whenever processing is likely to result in a high risk to the rights and freedoms of natural persons. Controllers must complete the assessment before the processing begins, not after.

For a full overview of the regulation, see what is GDPR. If you are building a compliance programme, the GDPR compliance checklist covers the broader set of obligations, and GDPR DPO requirements explains when you must appoint a Data Protection Officer to advise on the DPIA.

What Is a DPIA Under GDPR?

A Data Protection Impact Assessment is a structured, documented process by which a data controller identifies and evaluates the privacy risks created by a planned processing operation and determines measures to reduce those risks to an acceptable level. Article 35(1) of Regulation (EU) 2016/679 defines the obligation: "Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data."

The DPIA replaces the prior-notification regime under Directive 95/46/EC. Recital 89 explains the shift: the GDPR eliminates "the general obligation of notification" because blanket registration created administrative burdens without reliably improving protection. Instead, the regulation concentrates regulatory attention on the subset of operations that genuinely create elevated risk.

The obligation rests on the controller. Processors may assist, and Article 28(3)(f) specifically requires the processor to "assist the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36," but the legal duty belongs to the controller alone.

A DPIA is not a one-time exercise. Article 35(11) requires controllers to review the assessment "at least when there is a change of the risk represented by processing operations." Processing assessed as low-risk when designed may become high-risk if the technology, scale, data categories, or context of use shifts.

When Is a DPIA Mandatory? The High-Risk Threshold

The triggering condition is that processing is "likely to result in a high risk" to individuals, a predictive, forward-looking standard. The controller must assess whether such risk is probable, not wait until harm materialises. New technologies receive particular mention in Article 35(1) because they tend to create risks that have not yet been assessed or governed by established practice.

Article 35(3) supplies three explicit categories that inherently mandate a DPIA. These are floors, not ceilings: other types of processing not listed in Article 35(3) may still require a DPIA if the general high-risk standard in Article 35(1) is met.

Article 35(3)(a): Systematic Automated Profiling With Legal or Significantly Similar Effects

Article 35(3)(a) requires a DPIA for "a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly affect the natural person in a significant way." Three elements must be present together: the evaluation is systematic and extensive; the processing is automated; and the resulting decisions produce legal effects (changing rights or legal status) or similarly significant effects (denial of employment, exclusion from a benefit, material deterioration in financial terms).

Recital 71 gives concrete examples: online credit applications, automated recruitment screening, and insurance pricing models. The category also covers algorithmic scoring in predictive policing, automated fraud detection that blocks a customer's account without human review, and behavioural advertising pipelines where differentiation is material.

The limiting principle is "legal effects or similarly significant effects." Personalisation that changes the colour of a webpage or a playlist recommendation that carries no consequence does not reach the threshold.

Article 35(3)(b): Large-Scale Processing of Special-Category or Criminal-Offence Data

Article 35(3)(b) requires a DPIA for "processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10." Special categories include racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data processed for unique identification, health data, and data concerning sex life or sexual orientation.

The large-scale qualifier is important. Recital 91 explains that an individual healthcare professional processing their own patients' data is not engaged in large-scale processing. WP248 recommends considering four factors: number of data subjects; volume or range of data items; duration of the activity; and geographic extent. A hospital system processing records of hundreds of thousands of patients across a regional network clearly meets the threshold; a sole-practitioner clinic serving a few hundred patients does not.

Article 35(3)(c): Large-Scale Systematic Monitoring of Publicly Accessible Areas

Article 35(3)(c) requires a DPIA for "a systematic monitoring of a publicly accessible area on a large scale." Recital 91 gives as an example "monitoring publicly accessible areas on a large scale, especially when using optic-electronic devices." CCTV systems in public spaces are the paradigm case. The criterion applies to private entities and public authorities alike. Modern video analytics using facial recognition or gait recognition fall squarely within this category and trigger an additional consideration under Article 35(3)(a). A single camera inside a small shop monitored manually during opening hours is unlikely to be large-scale or systematic. A network of hundreds of cameras across a city centre with automated analytics and multi-week retention plainly is.

The EDPB Nine Criteria for High Risk

The EDPB's WP248 guidelines (adopted October 2017, endorsed by the EDPB May 2018) identify nine criteria as indicators of likely high risk under Article 35(1). No single criterion is individually determinative; the EDPB position is that any processing satisfying two or more should be treated as requiring a DPIA.

1. Evaluation or scoring. Processing evaluates or scores individuals, including profiling and predicting, from aspects such as work performance, economic situation, health, personal preferences, reliability, behaviour, location, or movements.

2. Automated decision-making with legal or similar effects. Processing involves automated decisions that produce legal or significantly similar effects, as in Article 35(3)(a).

3. Systematic monitoring. Processing involves systematic observation or control of individuals, including data collected through networks or covert surveillance of employees or consumers. Covers device fingerprinting, persistent cookie tracking, network traffic monitoring, and employee monitoring software.

4. Sensitive data or data of a highly personal nature. Processing involves Article 9 special-category data, Article 10 criminal-offence data, financial data, location data, health data, or other data whose misuse could cause significant harm. The EDPB singles out financial-transaction data as a high-risk indicator.

5. Data processed on a large scale. A standalone consideration applying the large-scale qualifier from Article 35(3)(b) to all types of personal data, not only special categories.

6. Matching or combining datasets. Processing combines, cross-references, or matches data from two or more distinct sources in ways that might exceed data subjects' reasonable expectations when each source was originally collected.

7. Data concerning vulnerable subjects. Processing involves individuals in a position of vulnerability relative to the controller: children, employees, patients, elderly people, and asylum seekers. Children receive special mention because they are "less aware of the risks, consequences and safeguards concerned and their rights in relation to the processing of personal data."

8. Innovative use or applying new technological or organisational solutions. Processing applies technology in a novel way (IoT, biometric recognition, AI, connected devices) where the wider societal or individual consequences have not yet been established.

9. Processing that prevents data subjects from exercising a right or using a service. Processing decides whether to grant or deny access to something the data subject has a right or legitimate expectation to receive: a bank account, a government benefit, medical treatment, employment, or housing.

National Supervisory Authority DPIA Blacklists

Article 35(4) requires each national supervisory authority to "establish and make public a list of the kind of processing operations which are subject to the requirement for a data protection impact assessment pursuant to paragraph 1." These blacklists are legally binding within their jurisdictions. Controllers operating in multiple EU/EEA Member States must check each relevant national authority's blacklist, as triggering categories can differ.

Article 35(5) permits supervisory authorities also to publish a whitelist of processing types requiring no DPIA. Where a whitelist entry covers a proposed operation, a DPIA is not needed unless specific circumstances bring the operation above the general high-risk threshold.

The consistency mechanism in Article 35(6) applies when a proposed list involves processing "related to the offering of goods or services to data subjects or to the monitoring of their behaviour in several Member States, or may substantially affect the free movement of personal data within the Union." In that case the authority must use the consistency mechanism in Article 63, bringing the EDPB into the process.

Illustrative blacklist entries from selected national authorities: the French CNIL included biometric access control at workplaces, predictive scoring of social risk in public-sector contexts, large-scale health data processing, and automated matching of employer and welfare-benefit databases. The German Data Protection Conference included systematic employee behaviour data processing, large-scale patient health records, and AI-driven credit assessment. The UK ICO (UK GDPR) lists large-scale profiling of children, systematic monitoring of employee communications, biometric data for staff authentication, and multi-source behavioural profiles.

Controllers must check the current list published by each relevant supervisory authority, not rely on a summary. Lists are updated as the EDPB adopts new guidance or national authorities respond to new technologies.

What a DPIA Must Contain: Article 35(7)

Article 35(7) sets out the minimum content requirements. The assessment must include "at least" four elements, expanded in WP248.

Beyond the four mandatory elements, WP248 recommends also documenting: the identity and contact details of the controller and DPO; categories of data subjects and personal data; retention periods; a record of how the DPO was consulted; and the assessment date and scheduled review date.

The DPIA is a working document. A two-page summary asserting that "appropriate measures have been taken" is not compliant. The EDPB position is that the document should reflect a structured, repeatable methodology such as the CNIL Privacy Impact Assessment methodology, ISO 29134, or BSI-Standard 200-2, though the regulation does not mandate any specific methodology.

Who Is Responsible for the DPIA?

The controller is legally responsible for carrying out the DPIA and for the accuracy and completeness of its content. This cannot be delegated away by contract with a processor or a DPIA-consultancy vendor.

Article 35(2) requires the controller to "seek the advice of the data protection officer, where designated, when carrying out a data protection impact assessment." This is a consultation obligation, not a transfer of responsibility. The DPO's role in the DPIA is listed in Article 39(1)(c), which requires the DPO to "provide advice where requested as regards the data protection impact assessment and monitor its performance pursuant to this Article." If the controller disregards the DPO's advice, it should document the reasons.

Article 35(9) encourages controllers to "seek the views of data subjects or their representatives on the intended processing." This is a best-practice recommendation, not a mandatory requirement, but for consumer-facing products it can strengthen the risk-identification phase.

Processors who build products used by controllers for high-risk processing have an indirect stake. Article 28(3)(f) requires the processor to assist the controller, and many processors now provide pre-built DPIA documentation or data flow mapping tools as a contractual deliverable.

Timing: Before Processing Begins

Article 35(1) is unambiguous: the DPIA must be completed "prior to the processing." The assessment must be finished, risks evaluated, mitigating measures in place (or prior consultation completed if residual risk remains high), and the controller satisfied that processing can proceed lawfully. All of this must be done before any live processing begins.

Controllers must build DPIA completion into project timelines. A DPIA started after go-live, or backdated to paper-cover processing already in progress, is not compliant. Supervisory authorities have expressly criticised post-hoc DPIAs as evidence that the accountability principle in Article 5(2) has not been observed.

Recital 90 states the required sequence: design the processing; conduct the DPIA; if residual risk remains high, consult the supervisory authority; only then begin processing.

For large organisations, a phased process is common. A screening phase determines whether a full DPIA is needed. Where the screen confirms high risk, the full DPIA follows before the processing design is finalised. The ICO and CNIL both publish screening templates that controllers can use to document the outcome even where the conclusion is that a full DPIA is not required.

Step-by-Step DPIA Workflow

Step 1: Identify the processing operation and confirm whether a DPIA is required. Map the planned operation including data types, subjects, purposes, legal basis, technology, retention period, and parties. Apply the three-part test: (a) Does the operation fall within an Article 35(3) mandatory category? (b) Does the supervisory authority's blacklist cover this processing type? (c) Do two or more EDPB nine criteria apply? If any answer is yes, a DPIA is required. Document the outcome regardless.

Step 2: Consult the DPO. Under Article 35(2), if a DPO has been appointed, share the Step 1 output, ask them to confirm the methodology, and flag preliminary legal concerns. Record the date of consultation and the DPO's response.

Step 3: Describe the processing systematically. Prepare a written description covering: categories and volume of personal data; data subjects affected; collection method; specific purposes; legal basis under Article 6(1) (and Article 9(2) if special categories are involved); data flow from collection through deletion; processors and sub-processors and the contractual relationship with each; retention schedule; and jurisdictions of processing.

Step 4: Assess necessity and proportionality. For each processing purpose, evaluate: whether the purpose could be achieved without personal data, with anonymised or pseudonymised data, or with less data; whether the retention period is the minimum necessary; whether the legal basis is appropriately matched; and whether the processing is consistent with the reasonable expectations of data subjects. Where a less intrusive alternative exists, document the reason for choosing the more intrusive path.

Step 5: Identify and assess the risks. For each element of the processing, identify risk scenarios categorised by impact on individuals (inability to exercise rights; physical, economic, or reputational harm; discriminatory treatment; loss of confidentiality; re-identification; chilling effects) and by likelihood accounting for existing safeguards. For each scenario, record likelihood rating, severity rating, and existing mitigating measures.

Step 6: Identify and document mitigating measures. For each medium- or high-risk scenario, identify additional measures: technical (encryption, pseudonymisation, data minimisation, automated deletion, access control, audit logging) and organisational (staff training, processor contractual obligations, breach response procedures, access reviews, privacy-by-default). For each measure, record the residual risk that would remain.

Step 7: Evaluate the overall residual risk. If all identified risks have been reduced to low or acceptable, the DPIA supports a decision to proceed. If any risk scenario retains high residual risk, the controller must redesign the processing to reduce it, or proceed to Step 8.

Step 8: Prior consultation with the supervisory authority if residual high risk remains. Article 36(1) states: "The controller shall consult the supervisory authority prior to processing where a data protection impact assessment pursuant to Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk." Processing may not begin until the authority has responded or the consultation period has elapsed.

Step 9: Document, approve, and record the DPIA. The completed DPIA should be signed off by the controller or a designated representative with authority to accept risk. Where the DPO was consulted, their advice and the controller's response should be part of the record. Retain as accountability documentation under Article 5(2).

Step 10: Set a review schedule. Article 35(11) requires review "at least when there is a change of the risk represented by processing operations." Build a review date into the document: typically 12-24 months for moderate-risk operations and 6-12 months for those near the high-risk threshold. Any material change in technology, scale, data types, purposes, or regulatory context should trigger an interim review.

Prior Consultation Under Article 36

Article 36 is activated when the DPIA concludes that residual risk remains high even after applying all reasonable mitigating measures. The controller must then consult the supervisory authority before proceeding. Article 36(1) uses the mandatory "shall."

When submitting a prior consultation request, the controller must provide the materials listed in Article 36(3): respective responsibilities of controller and processor; purposes and means of the intended processing; measures and safeguards to protect data subjects; DPO contact details; the completed DPIA; and any other information the authority requests.

The supervisory authority has up to eight weeks to provide written advice under Article 36(2), extendable by a further six weeks for particularly complex processing. During the consultation period the authority may use "any of its powers referred to in Article 58," including issuing a formal warning, imposing a temporary processing ban, or bringing infringement proceedings.

Prior consultation is not regulatory pre-approval or a safe harbour. A supervisory authority that does not object within the consultation period has not affirmatively approved the processing. The controller remains legally responsible for GDPR compliance. A completed prior consultation does, however, create a contemporaneous record that the controller identified residual risk, disclosed it to the competent authority, and was not instructed to stop.

Article 36(4) requires Member States to consult the supervisory authority "during the preparation of a proposal for a legislative measure to be adopted by a national parliament... which relates to processing," the public-sector equivalent of the same principle.

Consequences of Failing to Conduct a Required DPIA

Failure to carry out a required DPIA is a direct infringement of Article 35. Under Article 83(4), infringements of Articles 35 and 36 are subject to the lower administrative fine tier: up to 10 million euros, or 2% of total worldwide annual turnover, whichever is higher. The fine is per infringement and per establishment.

The Spanish AEPD and the Hungarian supervisory authority have both issued decisions where absence of a DPIA for high-risk processing was among the listed violations. The EDPB's annual reports identify DPIA compliance as one of the most frequently identified gaps during inspections.

Beyond the direct fine risk, the absence of a DPIA creates downstream accountability problems. A controller that cannot produce a DPIA for plainly high-risk processing cannot demonstrate compliance with Article 5(2) or with the obligation to implement appropriate technical and organisational measures under Article 24(1). The absence of the document is itself evidence of systemic failure.

Processors operating under Article 28 agreements are increasingly required by controllers to certify their cooperation with DPIA processes. Processors who cannot document their data flows, sub-processors, and security architecture create compliance gaps for their controller customers.

Interaction With Other GDPR Provisions

Data protection by design and by default (Article 25). Article 25(1) requires controllers to implement measures designed to implement data-protection principles and integrate necessary safeguards into the processing. The DPIA is the primary mechanism for identifying what those measures must be for high-risk processing, feeding directly into the privacy-by-design process.

Records of processing activities (Article 30). The DPIA should be cross-referenced against the Article 30 record. The record is the inventory; the DPIA is the deep-dive for high-risk entries.

Security of processing (Article 32). Article 32(1) requires appropriate technical and organisational measures to ensure a level of security appropriate to the risk. The DPIA risk assessment is the natural foundation for the Article 32 analysis. Controllers who treat these as separate exercises often find their security assessment contradicts their DPIA.

Special categories and criminal offences (Articles 9 and 10). Beyond triggering the Article 35(3)(b) mandatory DPIA, the narrower list of permissible legal bases under Articles 9 and 10 means the necessity and proportionality assessment must engage more rigorously with whether the specific Article 9(2) condition relied upon genuinely applies to every element of the processing.

Transfers to third countries (Articles 46-49). Where processing involves transferring personal data outside the EU/EEA, the transfer mechanism must be documented in the DPIA and the adequacy of protection in the recipient country factored into the risk assessment. The Schrems II ruling (Data Protection Commissioner v Facebook Ireland Limited and Maximillian Schrems, Case C-311/18, Grand Chamber, 16 July 2020) requires controllers to conduct a transfer impact assessment for transfers relying on Standard Contractual Clauses; that assessment should be integrated with or directly referenced from the DPIA.

Disclaimer: This article presents general legal information about Regulation (EU) 2016/679 (GDPR) and does not constitute legal advice. The GDPR is interpreted and enforced by supervisory authorities across 30 EU/EEA Member States, and applicable requirements may vary based on the nature of your processing, the Member States in which you operate, and developments in regulatory guidance and case law. The information on this page was verified against official sources as of June 2026. Consult a qualified lawyer or data protection specialist licensed in the relevant jurisdiction for advice on your specific situation.

Frequently Asked Questions

When is a DPIA required under GDPR?

A DPIA is required under Article 35(1) when processing is likely to result in a high risk to the rights and freedoms of natural persons, particularly when using new technologies. Article 35(3) makes DPIAs mandatory in three cases: systematic automated profiling with legal or similarly significant effects; large-scale processing of special-category or criminal-offence data; and large-scale systematic monitoring of publicly accessible areas. Controllers must also check their national supervisory authority's published blacklist. When two or more of the EDPB's nine high-risk criteria are met, the EDPB position under WP248 is that a DPIA should be conducted.

Who is responsible for carrying out a DPIA?

The controller is legally responsible for conducting the DPIA. Article 35(2) requires the controller to consult its designated Data Protection Officer during the assessment if one has been appointed, but the DPO's role is advisory: responsibility for the DPIA's accuracy and completeness remains with the controller. Processors must assist controllers under Article 28(3)(f), but they cannot assume the controller's legal responsibility. Controllers cannot contract out of the DPIA obligation by engaging a third-party vendor, though they may use external expertise to support the process.

What happens if a controller does not carry out a required DPIA?

Failure to carry out a required DPIA is an infringement of Article 35 subject to administrative fines under Article 83(4) of up to 10 million euros, or 2% of total worldwide annual turnover, whichever is higher. Beyond the direct fine, the absence of a DPIA is evidence of a failure to implement appropriate technical and organisational measures under Article 24(1) and a failure to demonstrate compliance with Article 5(2). Supervisory authorities conducting inspections or handling complaints routinely identify missing DPIAs as a compliance gap, and their absence can transform a single infringement into a broader finding of systemic accountability failure.

Is a DPIA mandatory for CCTV surveillance?

Large-scale systematic monitoring of publicly accessible areas using CCTV falls within the mandatory DPIA trigger in Article 35(3)(c). Whether a specific installation meets the large-scale and systematic thresholds depends on the facts: a single camera inside a small retail unit monitored manually during trading hours is unlikely to require a DPIA, whereas a network of cameras across a large public space with automated analytics and extended retention periods plainly does. Controllers should also check their national supervisory authority's blacklist. Where the CCTV system incorporates facial recognition or biometric analysis, Article 35(3)(a) and (b) will also be engaged.

What is prior consultation under Article 36 GDPR?

Prior consultation is the process by which a controller must notify and consult its competent supervisory authority before beginning processing that, even after applying all reasonable mitigating measures, retains a high residual risk to data subjects. The obligation under Article 36(1) applies when the DPIA confirms that residual high risk cannot be adequately reduced. The controller must submit the completed DPIA, a description of the processing, the safeguards in place, and DPO contact details. The supervisory authority has up to eight weeks to respond, with a possible six-week extension for complex operations. The authority may advise, issue warnings, or prohibit the processing if it considers the operation would violate the GDPR.

Does a DPIA need to be submitted to the supervisory authority?

Not routinely. A DPIA is an internal accountability document that the controller prepares and retains. Submission is required only in two situations: when prior consultation under Article 36 is triggered because the DPIA reveals unmitigable residual high risk; and when a supervisory authority exercises its inspection or investigation powers and requests to review the DPIA. Controllers should therefore treat DPIAs as documents that may be requested by authorities at any time and ensure they are detailed, well-documented, and up to date.

Can one DPIA cover multiple processing operations?

Yes. Article 35(1) refers to a 'type of processing operation,' and Recital 92 confirms that a DPIA may address a set of similar processing operations that present similar high risks. A single DPIA covering a platform that processes data in multiple comparable ways is acceptable, provided the assessment addresses the specific risks associated with each distinct activity. Similarly, public authorities establishing shared processing infrastructure and multiple controllers in the same industry deploying a common technology may carry out a single DPIA, subject to each controller reviewing the shared assessment for its own specific context.

How often must a DPIA be reviewed?

Article 35(11) requires controllers to review the DPIA 'at least when there is a change of the risk represented by processing operations.' There is no fixed calendar interval in the GDPR text, but WP248 recommends setting a review schedule when the DPIA is completed, with typical intervals of one to two years for moderate-risk operations. Any material change in processing (including new data types, a significant scale increase, new technology, a new purpose, new recipient countries, or a change in the legal or regulatory context) should trigger an interim review. Controllers should record the scheduled review date in the DPIA document itself.

What is the EDPB guidance document on DPIAs?

The primary EDPB guidance is WP248rev.01, 'Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is likely to result in a high risk for the purposes of Regulation 2016/679.' It was adopted by the Article 29 Working Party on 4 April 2017, revised on 4 October 2017, and endorsed by the EDPB at its first plenary in May 2018. WP248 sets out the nine criteria for high risk, recommends that controllers conduct a DPIA when two or more criteria are met, describes what a DPIA must contain, and explains the relationship between the DPIA and prior consultation. The full document is available from the EDPB website at edpb.europa.eu.

Do the GDPR DPIA rules apply to processors as well as controllers?

The legal obligation to conduct a DPIA rests on the controller, not the processor. However, Article 28(3)(f) requires that the data processing agreement include a provision under which the processor assists the controller in ensuring compliance with Articles 32 to 36, which expressly includes the DPIA and prior consultation obligations. In practice, processors must provide controllers with information about their data flows, sub-processors, and security architecture. Processors who design products likely to be used for high-risk processing are increasingly expected to produce pre-built DPIA documentation or privacy impact assessment templates as part of their product offering.