When Is a DPIA Required? The EU GDPR Article 35 Test

Q: Is the EDPB DPIA template mandatory?

The EDPB adopted its DPIA template on 14 April 2026, but it is not mandatory: controllers remain free to use the DPIA methodology of their choice. The consultation closed on 9 June 2026, and the official page still says the template will be finalised after consultation. It offers a free structure for a first method and a cross-check for an established one, without creating a new DPIA trigger.

Q: When should a DPIA decision be reviewed?

Review the decision when the processing or the risk it presents changes. Article 35 expressly requires review when necessary, at least when the risk represented by processing operations changes. WP248 treats a DPIA as a continuing process. A material change can therefore reopen an earlier no decision or require an existing assessment to be updated.

The question when is a DPIA required is not answered by company size, a supplier's label or the mere presence of an algorithm. A data protection impact assessment, or DPIA, is the assessment carried out before likely-high-risk processing to describe the operation, test its necessity and proportionality, examine risks and set out measures that address them ¹. GDPR Article 35 asks whether the proposed type of processing is likely to result in high risk to people's rights and freedoms, taking account of its nature, scope, context and purposes.

Quick Answer: A controller needs a DPIA before any processing likely to create high risk for people, including the three Article 35 cases ¹. Screen the facts against the nine WP248 criteria and applicable supervisory-authority lists ². Record a reasoned yes or no, then review it if risk changes.

Last updated: 26 August 2026.

A useful screen does not force every project toward yes. It gives the no branch equal weight, preserves the facts behind the result and makes later review possible. The controller owns either decision, and timing matters: the conclusion belongs before processing starts, while the design can still change ¹.

Start with likely high risk

The screen begins with one defined processing operation: what personal data will be used, for which purposes, about whom, through which steps and at what scale. The Article 35 trigger concerns the type of processing as a whole. It does not turn on a single fashionable word.

Nature, scope, context and purposes provide the statutory frame ¹. For an online retailer, “personalisation” is too vague to decide anything. The useful description says which behaviour is observed, how profiles are built, what ranking follows and whether the result significantly affects anyone. For a camera project, “we use cameras” is equally incomplete. The relevant facts include whether monitoring is systematic, whether the area is publicly accessible and whether the operation is large scale.

New technology can matter, but it does not create an automatic yes. Article 35 says processing may in particular use new technologies and still directs the controller back to the full high-risk test ¹. The same discipline applies to special-category data. Its presence matters, while the specific mandatory branch also asks whether Article 9 or Article 10 data is processed on a large scale.

The practical output is a short, stable scope statement. Another reviewer should be able to understand the proposed operation and recognise a later change from it. Unrelated purposes or systems need separate descriptions before screening. Conversely, Article 35 allows one assessment to address several genuinely similar processing operations that present similar high risks ¹.

Three cases that require an assessment

Article 35 gives a general likely-high-risk trigger and then identifies three cases in which a DPIA is required in particular ¹. These cases are not a complete list. A project outside all three may still be likely to result in high risk and may still fall within a published required list.

Article 35 case	What must be present	Decision consequence
Systematic and extensive evaluation	Automated processing, including profiling, evaluates personal aspects; decisions based on it produce legal effects or similarly significant effects	A DPIA is required ¹.
Large-scale sensitive or offence data	Special categories under Article 9, or personal data about criminal convictions and offences under Article 10, are processed on a large scale	A DPIA is required.
Systematic public-area monitoring at scale	Monitoring is systematic, covers a publicly accessible area and occurs on a large scale	A DPIA is required.

Each row must be read as a complete test. An automated product ranking does not enter the first row merely because software evaluates signals. The row also concerns systematic and extensive evaluation and decisions with legal or similarly significant effects. A clinic handling health data should not stop at “health data means yes”; it should test the large-scale limb and then continue through the general trigger, guidance criteria and competent-authority lists.

Likewise, not every camera creates the third case. The statutory wording combines systematic monitoring, a publicly accessible area and large scale ¹. A depot open to visitors could raise the question, but the controller still needs the actual layout, coverage, duration, population and operational purpose to apply the words honestly. Those project facts are evidence; the shorthand “CCTV” is not the decision.

The order is useful. Check all three cases first because a matched case settles the need for an assessment. If none matches, do not write “DPIA not required” yet. Continue to the general likely-high-risk test, the WP248 screen and the relevant published lists.

Screen mandatory cases, guidance criteria and authority lists, then record the outcome.

The proposed processing is defined before the three Article 35 cases are tested, followed by the nine WP248 criteria and the competent authority's published lists ¹^,2^,3. A mandatory-case or required-list match leads to a DPIA; otherwise the complete facts determine whether high risk is likely, with the familiar two-criteria point kept as guidance rather than an automatic rule. A reasoned no is recorded when the full screen supports it, while a yes leads to a DPIA before processing. Residual high risk that cannot be reduced opens prior consultation, and either decision is reviewed when the processing risk changes.

Use the nine-factor screen

WP248 gives nine criteria for recognising processing that is more likely to result in high risk ². They are guidance, not nine new statutory triggers. The EDPB endorsed WP248 rev.01 at its first plenary meeting ³. That endorsement does not turn the criteria into the text of Article 35.

WP248 criterion	Question for the project record
Evaluation or scoring	Does the operation evaluate, predict or score aspects concerning people ²?
Automated decision-making with legal or similarly significant effect	Is an automated decision expected to have a legal or comparably significant effect on a person ?
Systematic monitoring	Does the operation observe, monitor or control people in an organised or recurring way ?
Sensitive or highly personal data	Does it use sensitive or otherwise highly personal information ?
Large scale	Do the scale characteristics of the operation point to large-scale processing ?
Matching or combining datasets	Are datasets matched or combined in a way relevant to the risk screen ?
Data concerning vulnerable people	Does the processing concern people whose circumstances make them vulnerable ?
Innovative technology or organisational solutions	Does the operation use a novel technological or organisational solution ?
Preventing exercise of a right or use of a service or contract	Could the processing prevent someone from exercising a right or using a service or contract ?

The familiar “two criteria” point needs a firm fence. WP248 says that, as a rule of thumb, a processing operation meeting two criteria ordinarily indicates that a DPIA is required. More criteria increase the likelihood. It also says that a controller can consider processing meeting only one criterion to require a DPIA ². This is EDPB-endorsed guidance, not a legal formula that replaces Article 35 ³.

That distinction protects both branches. One tick is not an automatic no, because a single criterion can be sufficient on the facts. Two ticks do not convert the guidance into statutory wording. A readable conclusion states which criteria apply, which do not, and why their combination points toward or away from likely high risk.

Context matters within each criterion. “Innovative technology” should not become a proxy for every newly purchased tool. “Large scale” should not be reduced to the fact that a business hopes to grow. The record should describe the actual processing that supports the answer. Where a fact is unknown, it should remain an open item rather than being quietly treated as low risk.

A compact criteria record can use four columns: criterion, yes/no/uncertain, supporting fact and consequence for the overall decision. An uncertain material fact should stay visible, with an owner and a date for resolution. It should not silently become a no. The screen is a route to a reasoned conclusion, not a scorecard whose total decides the law.

Check the national lists

The competent supervisory authority's publications are a separate checkpoint. Article 35 requires each supervisory authority to establish and publish a list of processing operations subject to the DPIA requirement. It also permits an authority to publish a list of operations for which a DPIA is not required ¹.

Check your supervisory authority's published list. The relevant publication is the one issued by the authority competent for the controller and operation, and the record should identify the version reviewed. This EU-level article does not reproduce any national item because the lists belong to individual authorities and may not be interchangeable.

A required-list match gives the yes branch. A not-required-list match must still be recorded accurately, with the relevant facts, rather than expanded into a broad exemption. If no list item settles the operation, the Article 35 likely-high-risk test and WP248 analysis remain the basis for the decision.

The list check should occur before the conclusion, not as an afterthought. It also needs repeating when the operation, its competent authority or the applicable publication changes. The project record should make that future check possible by preserving the list identity it used.

The no branch is a real outcome

Many small organisations ask the question because they suspect every use of personal data now needs a DPIA. It does not. The legal test is likely high risk, not whether the controller is a small business, uses software or handles any personal data ¹. There is no universal small-business exemption either.

WP248 offers useful no-DPIA examples. A generic mailing-list digest and limited profiling for an online shop's own product advertising ordinarily do not require a DPIA in the examples given ². They are not EU-wide exemptions. The complete facts, the exceptions described in the guidance and the competent supervisory authority's lists still control the screen.

Consider a small publisher sending the same subscriber digest to its list. If the operation does not enter a mandatory case, the criteria screen does not point to likely high risk and no relevant required-list item applies, a documented no can be the proper result. The conclusion should remain tied to that described operation. Adding extensive behavioural scoring or a significantly different purpose would require a fresh look.

The same care applies to a small online shop. Limited profiling for its own product advertising appears in WP248 as an example that ordinarily does not require a DPIA ². That does not answer a different project involving extensive evaluation, significantly affecting decisions, extensive matching or other materially changed facts. The example is a reference point, not a permission slip.

A no decision does not erase ordinary accountability or risk management. WP248 says a controller deciding that a DPIA is not necessary should justify and document that decision, including the DPO's views where applicable ². That record is valuable precisely because a reviewer can see what was considered and can reopen the result when facts change.

Honesty works in both directions. A team should not commission a DPIA merely to avoid explaining a borderline screen. Nor should it force a no because the organisation is small or launch is close. When an unresolved fact could change the outcome, the record should name it and defer the conclusion until it is resolved. The defensible result is the one supported by the defined processing, statutory cases, guidance criteria and applicable lists.

Record the decision either way

A decision record can be short, but it should be reconstructable. Identify the proposed processing, its purposes and the date of the screen. Summarise its nature, scope and context. Then preserve the result of each mandatory-case test, each WP248 criterion and the supervisory-authority list check.

The conclusion should say yes or no and connect that answer to the material facts. It should also capture uncertainties and assumptions. A bare statement such as “only one criterion applies” is weak because one criterion can still be enough under WP248 ². A stronger record explains why that criterion, considered with the rest of the operation, does or does not make likely high risk.

Where a DPO is designated, the controller must seek the DPO's advice when carrying out the DPIA ¹. WP248 also calls for the DPO's view to be recorded when the controller concludes that no DPIA is required ². The decision record should therefore preserve the advice or view and note any disagreement rather than hiding it.

Useful fields are deliberately factual: operation owner; screening date; scope and purpose; people and data involved; scale; three-case result; nine-criteria result; required-list and not-required-list check; list version; DPO view; final reasoning; unresolved facts; and review trigger. These fields do not create a new legal test. They make the applied test visible.

The record can also point to the relevant entry in the organisation's record of processing activities, if one exists. Keep the reasoning with the project materials so a change review does not depend on someone's memory. One recorded no is not permanent clearance for every later version of the system.

What a yes decision opens

A yes means the controller carries out the DPIA before processing. The controller remains accountable for the assessment, even when specialists, suppliers or processors provide information. Article 35 says the DPO's advice must be sought where a DPO is designated ¹. WP248 adds that processors should assist and that affected people or their representatives should be involved where appropriate ².

Article 35 specifies the minimum contents ¹:

a systematic description of the envisaged processing operations and their purposes, including any applicable legitimate interest;
an assessment of the necessity and proportionality of the processing in relation to those purposes;
an assessment of risks to the rights and freedoms of the people concerned; and
the measures intended to address those risks, including safeguards, security measures and mechanisms for protecting personal data and demonstrating compliance.

This is more than copying the screening table into a longer document. The screen answers whether an assessment is needed. The DPIA then examines the proposed operation, the need and proportionality of that operation, the risks it creates and the measures that address them. The work happens early enough for those measures, or the processing design itself, to change.

The right contributors are the people who hold the relevant facts. A project lead can explain purpose and workflow, while technical staff and processors can explain data flows and planned controls. The DPO advises where designated. Appropriate involvement of affected people or representatives can test assumptions about the practical effect of the operation ². Accountability still rests with the controller ¹.

One DPIA may cover a set of similar processing operations that present similar high risks ¹. Similarity should be demonstrated rather than assumed. The shared assessment must still describe the covered operations clearly enough that a reviewer can tell whether a new project fits. A materially different purpose, population, data set, scale or effect may fall outside that scope and need its own decision.

The completed assessment should finish with an explicit view of the remaining risk and the measures on which that view depends. If a planned safeguard is later removed, the earlier conclusion no longer describes the same operation. That is a review trigger, not merely an implementation detail.

The EDPB template is optional

The EDPB adopted a DPIA template on 14 April 2026, but expressly leaves controllers free to use the DPIA methodology of their choice ⁴. It therefore adds no new Article 35 trigger. For an organisation without a house method, it offers a free structure for recording the assessment; for one with an established method, it works as a cross-check. The consultation closed on 9 June 2026, and the official page still says the template will be finalised after consultation ⁵.

Revisit the decision and unresolved risk

Article 35 requires the controller to review whether processing is performed in accordance with the DPIA when necessary, at least when the risk represented by processing operations changes ¹. WP248 likewise treats the DPIA as a continuing process rather than a form completed once ².

Review therefore applies to both starting decisions. A prior no may become yes after a new purpose, broader data collection, larger scale, combined dataset, changed decision effect or different monitoring design alters the risk screen. An existing DPIA may need revision when its operation or safeguards change. The review record should state what changed and whether the conclusion still holds.

If a DPIA identifies residual high risk that the controller cannot sufficiently reduce, WP248 directs the controller to the prior-consultation route ². The competent supervisory authority remains generic here. The practical response is to pause the unresolved operation, preserve the assessment and follow that authority route before proceeding.

Worked screens for everyday projects

Large patient-system replacement. A clinic proposes a replacement system using health information. The first question is not whether the supplier calls the system modern. The team defines the people, data, purpose, scale, access and flows. If the operation processes Article 9 data on a large scale, it matches an Article 35 mandatory case and the decision is yes ¹. The record still notes the applicable list check and criteria, because they help define the assessment's scope. The DPIA then covers description and purpose, necessity and proportionality, risks, safeguards and mechanisms before the new processing begins.

If the scale limb is not established, the team should not convert that uncertainty into no. The project pauses the conclusion long enough to confirm scale, then completes the general high-risk analysis, nine-factor screen and competent-authority list check. The result follows the confirmed facts.

Limited product advertising. A ten-person online shop proposes limited profiling for its own product advertising. WP248 uses that kind of operation as an example that ordinarily does not require a DPIA ². The owner still describes the actual signals, purpose, population, scale and effect; tests the three mandatory cases; applies all nine criteria; and checks the competent authority's lists. If those facts do not point to likely high risk, the project can record no, the supporting reasons and the DPO's view where applicable.

That conclusion is narrow. Behaviour-based ranking that develops into systematic and extensive evaluation tied to decisions with legal or similarly significant effects could enter the first mandatory case ¹. New matching, a much larger scale or a changed effect can also alter the guidance screen. The earlier record provides a baseline for the new decision.

Public-facing depot cameras. An operations lead proposing cameras around a depot should identify which spaces are publicly accessible, whether monitoring is systematic and whether it is large scale. All three elements belong to the statutory case ¹. If the complete case is met, the answer is yes. If it is not, the analysis continues; “some cameras” does not prove no, just as “cameras” alone does not prove yes.

These examples share one discipline. The label never substitutes for the facts. A defensible file shows the operation screened, the three cases, nine criteria, list version, DPO input and reasoning. It ends with a real yes or no, names open facts, and says what change will reopen the decision.

Frequently asked questions

When is a DPIA required under GDPR Article 35?

A DPIA is required before processing when the proposed type of processing is likely to result in high risk to people's rights and freedoms. Article 35 also identifies three cases that require one in particular ¹. The controller should apply those tests, the WP248 criteria and its competent supervisory authority's published lists to the specific facts ².

Do two WP248 criteria automatically make a DPIA mandatory?

No. WP248 says that meeting two criteria ordinarily indicates that a DPIA is required, while more criteria make that outcome more likely. One criterion can also be enough ². This is an EDPB-endorsed rule of thumb, not a statutory threshold, so the controller must still assess the nature, scope, context and purposes of the processing ¹^,3.

Does every use of new technology require a DPIA?

No. Article 35 refers to new technologies within a broader test of whether processing is likely to create high risk, taking account of its nature, scope, context and purposes ¹. The controller should screen the actual operation and its effects. A technology label by itself does not replace the Article 35 test, WP248 criteria or applicable lists.

Can a small business decide that no DPIA is needed?

Yes, if the complete assessment supports that result. There is no universal small-business exemption, but everyday processing is not automatically high risk. WP248 gives conditional examples such as a generic mailing-list digest and limited profiling for a shop's own advertising ². The controller should document its reasoning, relevant criteria, list check and the DPO's view where applicable.

What must a DPIA contain after a yes decision?

Article 35 requires at least a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of risks to people's rights and freedoms, and the measures intended to address those risks ¹. Those measures include safeguards, security measures and mechanisms that protect personal data and demonstrate compliance.

Is the EDPB DPIA template mandatory?

No. The EDPB adopted the template on 14 April 2026, but it is not mandatory: controllers remain free to use the DPIA methodology of their choice ⁴. The consultation closed on 9 June 2026, and the official page still says the template will be finalised after consultation ⁵. It provides a free structure for a first method or a cross-check for an established one and creates no new DPIA trigger.

When should a DPIA decision be reviewed?

A review is needed when the processing or the risk it presents changes. Article 35 expressly requires review when necessary, at least when the risk represented by processing operations changes ¹. WP248 treats a DPIA as a continuing process ². A material change can therefore reopen an earlier no decision or require an existing assessment to be updated.