Do I need a DPIA?

What “do I need a DPIA?” actually asks

The question stacks three different ones. Collapsing them produces either a DPIA nobody needed or a missing DPIA for processing that should have had one before it launched.

1. The necessity screen. Is this processing likely to result in a high risk, so that Article 35 requires a DPIA before it starts? That is the question this guide answers.
2. The assessment itself. If the screen says yes, the DPIA is a separate exercise: describe the processing, test necessity and proportionality, assess the risks to people, and set out the measures to address them (Article 35(7)).
3. The downstream duty. If the completed DPIA still shows a high residual risk your measures do not mitigate, Article 36 requires prior consultation with the supervisory authority. That is a third, later step.

This guide stays on question one. It paraphrases the structure of Article 35, Article 36, and the WP248 rev.01 guidelines in original wording. It is educational content, not legal advice and not a binding determination.

The nine EDPB criteria, and the counting rule

Where Article 35(3) does not settle it, the WP248 rev.01 guidelines turn “likely high risk” into nine features. Count how many the processing meets. Two or more generally means a DPIA is required; a single one can be enough, and a documented decision that one is not enough is the only defensible way to stop there.

Version and jurisdiction stamp: the criteria labels condense the Article 29 Working Party Guidelines on DPIA, WP248 rev.01, endorsed by the EDPB; the guidelines themselves are the source of record. Checked 2026-08-13.

How to decide, step by step

1. 1

   Know that a necessity check is a screen, not the DPIA itself

   “Do I need a DPIA?” is a screening question, not the assessment. Under GDPR Article 35(1) a Data Protection Impact Assessment is required prior to the processing where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons, taking into account the nature, scope, context, and purposes. The word doing the work is likely. You are not proving the processing is high risk here. That is what the DPIA does in detail. You are screening for red flags that say a fuller assessment is needed. So this page answers the necessity question. When it lands on “yes,” the DPIA itself is the next, separate exercise.

2. 2

   Check the three Article 35(3) presumptive cases first

   Start here, because these are the settled cases. Article 35(3) says a DPIA shall in particular be required for three types of processing:(a) a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the person (credit decisions, automated hiring, eligibility scoring);(b) processing on a large scale of special categories of data under Article 9(1) (health, biometrics for identification, race, religion, sexual orientation, and the rest) or of criminal conviction and offence data under Article 10;(c) a systematic monitoring of a publicly accessible area on a large scale (public-space CCTV, wifi tracking).This list is illustrative, not exhaustive. Matching one case is enough to treat a DPIA as required, and you do not need the wider nine-criteria screen to get there. If none fits cleanly, do not conclude “no.” Go to the screen.

3. 3

   Run the nine EDPB criteria and count them

   Where Article 35(3) is silent, the EDPB-endorsed WP248 rev.01 guidelines turn “likely high risk” into nine checkable criteria: evaluation or scoring (including profiling and prediction); automated decision-making with a legal or similarly significant effect; systematic monitoring; sensitive data or data of a highly personal nature; data processed on a large scale; matching or combining datasets; data concerning vulnerable data subjects (children, employees, patients); innovative use or new technological or organisational solutions; and processing that in itself prevents data subjects from exercising a right or using a service or contract. The rule of thumb is a guide, not a mechanical count: in most cases processing that meets two or more criteria is likely high risk and should have a DPIA, though a single criterion can be enough. If you conclude that processing matching one or more criteria is nonetheless not likely to result in a high risk, the guidelines expect you to record the reasons and note the DPO's view. When in doubt, the EDPB position is to carry out the DPIA anyway.

4. 4

   Check your supervisory authority's Article 35(4) and 35(5) lists

   The Regulation deliberately pushes part of the answer down to national regulators. Under Article 35(4) each supervisory authority establishes and makes public a list of the kinds of processing subject to a DPIA, and under Article 35(5) it may publish a list of kinds for which no DPIA is required. Two cautions matter. First, a listed category can carry conditions, so it does not follow that every bare description on a list always forces a DPIA; read the entry and its qualifications. Second, the lists are not identical between authorities, and more than one authority or Member State can be competent for a given operation, so check the list for everysupervisory authority competent for your processing. An Article 35(5) exemption helps only where the operation falls fully within its scope and continues to meet its conditions. As a UK comparator (UK GDPR, outside the EU/EEA, so illustrative rather than an applicable Member-State list for EU processing), the ICO identifies ten further categories on top of the Article 35(3) three, several of which trigger a DPIA only when combined with another criterion. The lesson is procedural: after the generic screen, read your own regulator's published list and its conditions.

5. 5

   Check the narrow Article 35(10) legal-basis exemption

   One carve-out is worth checking before you treat a DPIA as mandatory (it is not the only one; an Article 35(5) exemption list or a sufficiently similar operation already assessed can also apply). Article 35(10) disapplies Article 35(1) to (7) where processing under Article 6(1)(c) (compliance with a legal obligation) or Article 6(1)(e) (a public-interest or official-authority task) has its legal basis in EU or Member State law, that law regulates the specific operation or set of operations, and a data protection impact assessment was already carried out as part of the general impact assessment in the context of adopting that legal basis, unless the Member State deems an assessment necessary before processing. It is aimed at processing a legislature has already impact-assessed, so it fits public-sector and legally-mandated processing far more readily than a company relying on legitimate interests or consent for its own product. WP248 adds a caution: an operation-specific assessment may still be needed where the enacted law differs from the proposal, or the legislative assessment lacked the operational detail. Check it, but do not lean on it unless it squarely fits.

6. 6

   Mind timing, scope, review, and the Article 36 follow-on

   Four mechanics decide whether a “yes” is handled correctly. First, timing: Article 35(1) makes the DPIA a prior assessment, carried out before the processing begins, not documented after launch. Second, scope: a single DPIA may address a set of similar processing operations that present similar high risks, so related features can share one assessment. Third, review: under Article 35(11) you reassess when the risk represented by the processing changes (new data, new purpose, new technology), and you seek the DPO's advice where one is designated (Article 35(2)). Fourth, the follow-on: if, after the DPIA, a high residual risk remains that your mitigations do not bring down, Article 36 requires you to consult the supervisory authority before you start. The DPIA is not the end of the road; it is the thing that tells you whether the road needs a checkpoint.

Six mistakes that produce the wrong answer

• Treating 'the data feels sensitive' as the test

  GDPR does not require a DPIA whenever data is personal or uncomfortable. It requires one when processing is likely to result in a high risk. Screen against Article 35(3) and the nine criteria, not against a gut feeling.

• Stopping at Article 35(3)

  The three listed cases are examples, not the whole test. Processing that matches none of them can still be likely high risk under the nine WP248 criteria. The list is a floor, not a ceiling.

• Ignoring your own regulator's list

  Article 35(4) lists go beyond Article 35(3) and differ between authorities, and a listed category can carry conditions. Read the list and its qualifications for every supervisory authority competent for your processing, not just the Article 35(3) three.

• Concluding 'not high risk' without documenting it

  The guidelines let a controller decide that processing matching one or more criteria is nonetheless not likely high risk, but expect the reasons recorded and the DPO's view noted. An undocumented 'not high risk' is hard to defend later.

• Doing the DPIA after launch

  A DPIA is a prior assessment (Article 35(1)). Running it after processing has started defeats the purpose and does not satisfy the obligation. Build it into the design stage.

• Forgetting Article 36 when residual risk stays high

  If, after mitigation, the DPIA still shows a high residual risk, you must consult the supervisory authority before processing. Skipping that step turns a completed DPIA into an incomplete obligation.

Frequently asked questions