Article 35 — Data protection impact assessment

Article 35 is one of the most important accountability provisions in the GDPR because it changes the way organisations are expected to think about privacy risk. It does not merely ask, “Is this processing lawful?” It asks a much more practical question:

“Before we start this processing, have we properly understood what could go wrong for people, how serious those consequences could be, whether the processing is genuinely necessary, and what we can do to prevent or reduce those risks?”

A DPIA is therefore not simply a document to be completed by the privacy team. Properly understood, it is a decision-making mechanism. It should influence whether a project is launched, what data is collected, what technology is used, how long data is retained, which vendors are engaged, what rights individuals receive, and whether the project should be redesigned or abandoned altogether.

The EDPB currently describes a DPIA as a process for identifying and managing risks to individuals and states that it must be carried out before processing likely to result in high risk. Importantly, in 2026 the EDPB has also developed a DPIA template intended to harmonise and structure DPIA reporting, although the template itself is not a mandatory GDPR format. (European Data Protection Board)

The deepest way to understand Article 35 is to see it as a bridge between:

• the accountability principle under Article 5(2);

• the controller's responsibility under Article 24;

• data protection by design and by default under Article 25;

• security risk assessment under Article 32;

• the special safeguards applicable to sensitive processing;

• the rights of data subjects;

• the DPO's advisory and monitoring function;

• and, ultimately, prior consultation with the supervisory authority under Article 36.

The following commentary examines Article 35 provision by provision and then examines the major conceptual and practical issues that arise when applying it.

1. The basic philosophy of Article 35

Before examining individual paragraphs, it is important to understand what a DPIA is not.

A DPIA is not:

• a privacy policy;

• a consent form;

• a data inventory;

• a security audit;

• a vendor due-diligence questionnaire;

• a Record of Processing Activities;

• a generic risk register;

• a legal memo stating that processing is lawful;

• or a document prepared merely because a regulator might ask for it.

A DPIA is instead a structured assessment of a particular processing operation and its consequences for individuals.

Suppose a company wants to introduce an AI recruitment system.

A weak privacy exercise might say:

“The company has a lawful basis, has obtained appropriate contractual assurances from the AI vendor, encrypts the data and has a privacy notice.”

That is not enough.

A proper DPIA would ask:

• What information is being fed into the system?

• Where does that information originate?

• Is it actually necessary to feed all of it into the system?

• Does the system infer characteristics that were not expressly supplied?

• Does it score candidates?

• What characteristics influence the score?

• Could apparently neutral variables act as proxies for protected characteristics?

• Could the model systematically disadvantage particular groups?

• Is the decision automated?

• Does a human genuinely review the output?

• Can candidates challenge an adverse result?

• How accurate is the model?

• What happens when the model is wrong?

• Who receives the results?

• How long are scores retained?

• Can the vendor use the information to improve its own model?

• What happens to prompts and logs?

• What happens if the model is replaced?

• What happens when the system is retrained?

• What safeguards reduce the identified risks?

• After those safeguards are implemented, what risk remains?

That final question is particularly important.

A DPIA is not complete merely because safeguards are listed. The organisation must assess whether the safeguards actually reduce the risk sufficiently.

2. Article 35(1): The fundamental obligation to conduct a DPIA

The central trigger in Article 35 is the concept of processing that is “likely to result in a high risk” to the rights and freedoms of natural persons.

This formulation contains several separate legal questions.

The controller must effectively ask:

First: What processing are we proposing?

Second: What is its nature, scope, context and purpose?

Third: What risks could arise for individuals?

Fourth: How likely are those risks?

Fifth: How severe could the consequences be?

Sixth: Taken together, is the processing likely to result in ahigh risk?

If the answer is yes, the DPIA must be carried out before the processing begins.

3. “Where a type of processing”

The obligation attaches to a type of processing, rather than merely to a database or IT system.

This distinction is extremely important.

Imagine a hospital implements a new digital platform.

The platform might involve:

• patient registration;

• appointment scheduling;

• billing;

• clinical records;

• diagnostic information;

• AI-assisted diagnosis;

• employee administration;

• analytics;

• research;

• fraud detection.

Calling the entire system “the hospital database” is not sufficient.

Different processing activities can have radically different risk profiles.

The billing component may involve ordinary identity and payment information.

The AI diagnostic component may involve:

• health data;

• automated analysis;

• potentially life-changing consequences;

• sensitive medical predictions;

• large-scale processing.

The DPIA must therefore identify the actual processing operation or coherent group of operations being assessed.

This is why a DPIA should begin with a precise description of the processing rather than with generic statements such as:

“The company will process customer data through its new platform.”

That statement is too vague to permit meaningful risk analysis.

4. “In particular using new technologies”

The reference to new technologies does not mean that every new technology automatically requires a DPIA.

Instead, new technology is a warning sign.

The GDPR was drafted in a technologically neutral manner, but Article 35 expressly recognises that technological innovation can create unfamiliar risks.

This is particularly relevant today for:

• artificial intelligence;

• machine learning;

• facial recognition;

• emotion recognition;

• biometric identification;

• behavioural analytics;

• connected devices;

• Internet of Things systems;

• location tracking;

• autonomous vehicles;

• wearable technology;

• predictive analytics;

• large-scale behavioural profiling;

• neurotechnology;

• synthetic-data systems where re-identification remains possible;

• and sophisticated data-matching systems.

The legal difficulty is that “new” does not necessarily mean “high risk.”

A company could introduce a new internal software tool that processes only the names of ten employees for a simple administrative purpose. It is technologically new, but the risk may be low.

Conversely, a technology may no longer be “new” but could remain highly risky.

Example

CCTV is no longer technologically novel. Yet large-scale facial recognition in public spaces can produce profound risks because of the scale, persistence, identification capability and consequences of the processing.

Thus, novelty is a risk indicator, not an independent universal DPIA trigger.

The EDPB's guidance continues to identify innovative use of technology as one of the important criteria for assessing whether processing is high risk. (European Data Protection Board)

5. “Nature, scope, context and purposes”

These four concepts are crucial because risk cannot be assessed in the abstract.

The same data can create completely different risks depending upon how it is processed.

Nature

“Nature” concerns what the processing actually involves.

Consider location data.

Collecting location data once to provide a navigation service is one thing.

Continuously tracking an employee's location throughout the working day is something else.

Tracking a person's location for several years and combining it with:

• religious sites visited;

• medical facilities visited;

• political events attended;

• personal relationships;

• workplace attendance;

creates a much more intrusive processing operation.

The nature of the processing has therefore changed.

Scope

Scope concerns the breadth of the processing.

Relevant considerations include:

• number of individuals;

• quantity of information;

• number of data categories;

• geographical coverage;

• duration;

• frequency;

• number of recipients.

Processing 500 employees is different from processing 50 million users.

Processing one data point per person is different from maintaining detailed behavioural profiles containing hundreds of attributes.

Context

Context concerns the circumstances surrounding the processing.

The same information can carry different risks depending upon the relationship between the controller and the data subject.

For example:

A retailer monitoring customer browsing behaviour raises one set of concerns.

An employer monitoring employee behaviour raises another.

A government monitoring citizens raises another.

A hospital processing patient information raises another.

A school monitoring children raises another.

Context therefore requires attention to power relationships, expectations, vulnerability and consequences.

Purpose

Purpose asks:

Why is the data being processed?

A purpose such as:

“Improve services”

is generally too vague to support a meaningful DPIA.

The controller should be able to explain what it actually intends to accomplish.

For example:

“Analyse customer purchasing behaviour to predict which customers are likely to cancel their subscription within the next 30 days and automatically offer them retention incentives.”

That purpose immediately reveals potential issues involving:

• profiling;

• prediction;

• automated decision-making;

• fairness;

• transparency;

• economic consequences;

• data minimisation;

• accuracy;

• and potentially Article 22.

6. “Likely to result in a high risk”

This is probably the most difficult phrase in Article 35.

The GDPR does not say:

“Perform a DPIA whenever there is a risk.”

That would be practically impossible.

Almost every processing activity creates some risk.

Instead, the threshold is high risk.

The EDPB explains the assessment in terms of both the likelihood andseverity of consequences. (European Data Protection Board)

A useful conceptual model is:

Risk = likelihood × severity of impact

This should not be misunderstood as requiring mathematical precision.

A controller does not need to pretend that privacy risk can always be calculated as:

0.17 × 8 = 1.36.

The numbers are merely a methodology.

The real legal inquiry is:

How plausible is the harmful event, and if it occurs, how serious would the consequences be for the individual?

7. Likelihood and severity must be considered together

Suppose a company accidentally exposes a person's name and favourite colour.

The probability of exposure may be relatively high, but the severity may be low.

Now consider a hospital database containing:

• HIV status;

• genetic information;

• psychiatric history;

• sexual health information;

• medication records.

Even if the probability of unauthorised disclosure is relatively low because strong security exists, the severity of the potential consequences may be extremely high.

Conversely, consider a processing operation where the potential harm is relatively modest but extremely likely.

That too can justify serious intervention.

Thus, “unlikely” does not automatically mean “low risk.”

8. “Rights and freedoms” is broader than privacy

One of the most important conceptual mistakes is to treat Article 35 as a narrow confidentiality assessment.

It is not.

The risk concerns the rights and freedoms of natural persons.

This includes risks such as:

• discrimination;

• exclusion;

• loss of autonomy;

• loss of control over personal information;

• reputational damage;

• financial harm;

• identity theft;

• fraud;

• physical harm;

• psychological harm;

• loss of confidentiality;

• inability to exercise legal rights;

• unfair treatment;

• wrongful denial of services;

• chilling effects;

• surveillance;

• manipulation;

• and other significant social or economic disadvantages.

Recital 75 expressly identifies many of these categories, including discrimination, identity theft, financial loss, reputational damage, confidentiality breaches, loss of control, profiling, processing involving vulnerable persons and large-scale processing.

The implication is profound:

A perfectly secure database can still create a high-risk processing operation.

Suppose an organisation develops an extremely secure algorithm that profiles job applicants.

There may be:

• no hacking;

• no data breach;

• perfect encryption;

• perfect access controls.

Yet the system could still create serious risk because its predictions may discriminate against particular groups.

Security therefore addresses only some risks.

A DPIA must examine the broader impact on individuals.

9. DPIA versus ordinary risk assessment

Article 35 should also be distinguished from the general risk assessment required by other GDPR provisions.

Articles 24, 25 and 32 already require controllers to assess and manage risk.

Article 35 adds something more specific.

The ordinary Article 32 security assessment might ask:

What happens if this database is hacked?

A DPIA asks:

Should we collect this information in the first place?

Is the purpose legitimate and sufficiently specific?

Is the processing necessary?

Could we achieve the same result with less information?

What happens to individuals if the algorithm is wrong?

Can people challenge the outcome?

Does the system create discrimination?

Is the retention period justified?

What are the effects on vulnerable persons?

Thus, security risk is only one part of DPIA analysis.

10. The controller bears the responsibility

The controller is responsible for ensuring that the DPIA is conducted.

This is a fundamental accountability point.

A controller may hire:

• external counsel;

• a consultancy;

• a cybersecurity firm;

• a processor;

• a technology vendor;

• a privacy professional;

• or another expert.

But outsourcing the work does not outsource accountability.

This is especially important with processors.

Suppose Company A hires an AI vendor.

The AI vendor says:

“We have already conducted our own DPIA.”

That does not automatically discharge Company A's Article 35 responsibility.

The vendor's assessment may be extremely useful.

But Company A's DPIA must assess Company A's processing, including:

• its purposes;

• its lawful basis;

• its relationship with individuals;

• its instructions to the vendor;

• the data it sends;

• the outputs it receives;

• the consequences for individuals;

• and the controls Company A itself implements.

The processor must assist the controller where required under Article 28, but the controller remains accountable for the Article 35 obligation.

11. A DPIA is not necessarily written by lawyers

Another misconception is that DPIAs are legal documents and therefore should be written entirely by lawyers.

That is usually a mistake.

A genuinely useful DPIA may require input from:

• privacy lawyers;

• engineers;

• cybersecurity specialists;

• product managers;

• HR personnel;

• data scientists;

• procurement teams;

• compliance personnel;

• business owners;

• DPOs;

• and sometimes affected individuals.

The legal team may identify:

“The proposed processing is likely to involve profiling.”

But the data scientist may be the person who knows:

“The model uses postcode as an input variable.”

The lawyer may immediately recognise that postcode could operate as a proxy for socioeconomic characteristics.

Similarly, the security team may identify that:

“The vendor's logs contain complete prompts for 90 days.”

The legal team may then recognise that the supposed deletion mechanism does not actually eliminate all copies of the personal data.

A good DPIA is therefore multidisciplinary.

12. The DPIA must be conducted “prior to the processing”

Timing is not a technical formality.

It is one of the most important aspects of Article 35.

A DPIA is supposed to influence the design of processing before the processing begins.

The best time to conduct it is often not immediately before launch.

It is during the design stage.

Suppose a company spends €8 million developing a facial-recognition system.

After development, the DPIA identifies that:

• the system cannot reliably distinguish certain groups;

• retention is excessive;

• the vendor architecture makes deletion difficult;

• individuals cannot meaningfully challenge matches.

At that stage, redesign may be extremely expensive.

If the DPIA had been performed during the architecture stage, the organisation might have selected a different technology.

Thus:

The earlier the DPIA is performed, the more useful it becomes.

The EDPB expressly treats DPIA as a process that should support risk identification and mitigation before high-risk processing begins. (European Data Protection Board)

13. A DPIA should not become a post-hoc justification

A particularly dangerous practice is:

“The project has already been approved. Please prepare the DPIA.”

This reverses the purpose of Article 35.

The DPIA should help management decide:

• whether to proceed;

• what conditions must be imposed;

• what architecture should be selected;

• what safeguards must be implemented;

• whether the purpose should be narrowed;

• whether certain data should be removed;

• whether a vendor should be rejected;

• and whether the residual risk is acceptable.

If the DPIA is merely written after the commercial decision has already been made, it can become a rubber-stamping exercise.

That creates a serious accountability problem.

14. Single DPIA for similar processing operations

Article 35 permits a single assessment to cover multiple similar processing operations presenting similar high risks.

This is commercially sensible.

Imagine a railway operator has CCTV systems at:

• Station A;

• Station B;

• Station C;

• Station D;

• Station E.

If the systems use:

• identical technology;

• identical purposes;

• identical retention;

• identical access rules;

• identical safeguards;

• identical processing logic;

conducting five entirely separate DPIAs may create unnecessary duplication.

One properly constructed DPIA can cover the common processing architecture.

But there is a critical limitation.

Similarity must be genuine.

A controller cannot create one 300-page “master DPIA” and use it to cover completely different operations.

Suppose the railway operator introduces:

• ordinary CCTV at one station;

• facial recognition at another;

• behavioural analytics at a third.

Those processing operations have materially different risk profiles.

A generic master DPIA is unlikely to be enough.

15. The “template DPIA” trap

Organisations frequently create a DPIA template containing:

• purpose;

• data categories;

• retention;

• security;

• risk score;

• mitigation.

They then reuse the same document for every project.

This is dangerous.

A template is useful as a methodology.

It is not a substitute for actual assessment.

A regulator looking at a DPIA would reasonably ask:

“Where is the evidence that this organisation actually analysed the risks of this particular system?”

If the same risk analysis appears word-for-word in 30 different projects, that may indicate that the DPIA process is merely bureaucratic.

The EDPB's 2026 template similarly aims to structure and standardise DPIAs without requiring organisations to abandon their own methodologies. (European Data Protection Board)

16. Article 35(2): The DPO's role

Where a DPO has been designated, the controller must seek the DPO's advice when conducting the DPIA.

This provision is more significant than it initially appears.

The DPO is not merely someone who receives a completed DPIA for signature.

The DPO should be involved meaningfully.

The DPO can advise on:

• whether a DPIA is required;

• the scope of the DPIA;

• methodology;

• risk identification;

• safeguards;

• data-subject consultation;

• compliance with other GDPR provisions;

• residual risk;

• and whether prior consultation may be necessary.

17. DPO does not own the DPIA

There is an important distinction:

Controller: responsible for the DPIA.

DPO: advises and monitors.

The DPO is therefore not the ultimate decision-maker.

Suppose the DPO says:

“The proposed processing should not proceed because the residual risk remains high.”

Management might disagree.

The organisation cannot simply say:

“The DPO approved it.”

Nor should it say:

“The DPO is responsible for the DPIA.”

The controller remains responsible.

If management rejects the DPO's recommendation, the reasons should be documented.

This protects both the accountability structure and the independence of the DPO.

18. Why DPO independence matters

Imagine the Chief Product Officer says:

“We are launching Friday. I need the DPO to sign this DPIA today.”

The DPO identifies substantial unresolved risks.

The company pressures the DPO to sign anyway.

That creates an organisational governance problem.

The DPO's function is to provide independent advice, not to provide a compliance stamp.

A healthy DPIA governance structure therefore looks more like:

Business proposes → privacy assesses → DPO advises → security assesses → legal evaluates → management decides → safeguards implemented → processing monitored.

It should not be:

Business decides → DPO signs.

19. Should the DPO decide whether a DPIA is required?

The DPO can provide strong advice on the question.

But the controller remains responsible for the final decision.

For example:

DPO: “Given large-scale profiling, vulnerable data subjects and automated decision-making, I consider the processing high risk and recommend a DPIA.”

Controller:

“Agreed. DPIA required.”

Or:

“We disagree. We consider the processing low risk because it does not involve significant effects.”

If the controller chooses the second position, it should document why.

A regulator can then examine whether the reasoning was defensible.

20. Article 35(3): The three expressly identified high-risk situations

Article 35(3) identifies three particularly important categories.

They are:

1. systematic and extensive automated evaluation/profiling connected with significant decisions;

2. large-scale processing of special-category or criminal-offence data;

3. systematic large-scale monitoring of publicly accessible areas.

The expression “in particular” is critical.

These are not the only circumstances in which a DPIA is required.

They are prominent examples of processing that Parliament considers especially likely to involve high risk.

The EDPB continues to explain the DPIA requirement using these categories alongside the broader risk criteria. (European Data Protection Board)

21. Article 35(3)(a): Systematic and extensive evaluation

This is perhaps the most important DPIA category in the modern AI economy.

It concerns:

• evaluation;

• profiling;

• automated processing;

• systematic and extensive assessment;

• and decisions that have legal or similarly significant effects.

Consider a bank's automated credit system.

The system might process:

• income;

• employment history;

• payment history;

• debt;

• transaction patterns;

• address;

• financial behaviour.

It calculates a credit score.

That score influences whether the person receives a loan.

This presents multiple risks:

• inaccurate data;

• biased variables;

• proxy discrimination;

• opaque scoring;

• erroneous predictions;

• inability to understand the outcome;

• exclusion from essential financial services.

A DPIA is therefore not simply asking:

“Is the algorithm secure?”

It is asking:

“What does this algorithm do to people?”

22. What does “systematic” mean?

Systematic does not simply mean “large.”

A processing activity may be systematic if it is:

• organised;

• methodical;

• pre-arranged;

• continuous;

• based on a general plan;

• or part of an established strategy.

Example

a company randomly reviewing one customer account for fraud may not constitute systematic monitoring.

A company applying a fraud-detection algorithm to every transaction according to predefined rules is clearly systematic.

23. What does “extensive” mean?

“Extensive” introduces another dimension.

It may relate to:

• duration;

• geographical reach;

• number of people;

• quantity of data;

• depth of profiling;

• frequency;

• range of characteristics evaluated.

Imagine a retailer creates a simple customer segmentation:

“Customers who purchased shoes in the last 12 months.”

That is profiling, but may not necessarily constitute the kind of extensive evaluation contemplated here.

Now imagine the retailer creates a behavioural profile using:

• browsing history;

• purchase history;

• location;

• device information;

• inferred income;

• inferred interests;

• browsing speed;

• interaction patterns;

• social media activity;

and continuously predicts:

• financial situation;

• health interests;

• personality;

• purchasing propensity;

• likelihood of cancellation.

That is far more extensive.

24. Legal or similarly significant effects

The significance of the resulting decision matters enormously.

Examples

may include:

• denial of credit;
• refusal of insurance;
• employment decisions;
• access to housing;
• admission to educational institutions;
• access to essential services;
• significant financial decisions. But the phrase “similarly significantly affects” prevents the rule from becoming artificially narrow. A decision need not technically create a legal right or obligation to be highly significant.

Example

a platform may automatically downgrade a seller so substantially that the seller's income collapses.

There may be no formal legal consequence.

Yet the economic effect could be profound.

25. AI recruitment example

Illustration

A company deploys an AI tool to rank 100,000 job applications. The system analyses:

• CVs;
• employment history;
• educational qualifications;
• writing style;

• online tests;

• interview transcripts.

It produces a score from 0, 100.

Candidates below 65 are automatically rejected.

This is an obvious DPIA candidate.

Why?

Because the system involves:

• systematic evaluation;

• extensive processing;

• profiling;

• automated processing;

• potentially significant employment consequences.

The DPIA should investigate not merely security but also:

• discriminatory outcomes;

• accuracy;

• proxy variables;

• training-data bias;

• explainability;

• human intervention;

• contestability;

• retention;

• vendor access;

• model retraining;

• data provenance.

26. Article 35(3)(b): Large-scale special-category data

The second category involves large-scale processing of:

• racial or ethnic origin;

• political opinions;

• religious or philosophical beliefs;

• trade-union membership;

• genetic data;

• biometric data used for unique identification;

• health data;

• sex life or sexual orientation;

as well as personal data relating to criminal convictions and offences.

The reason is obvious.

These data categories can create much more serious consequences if misused.

But the important word is:

large-scale.

A small doctor's office processing patient records does not automatically become “large-scale” merely because health data is sensitive.

Recital 91 expressly recognises that processing patient information by an individual physician or similar professional does not ordinarily constitute large-scale processing.

27. How to determine “large scale”

The GDPR does not give one numerical threshold.

The EDPB recommends examining factors such as:

• number of data subjects;

• proportion of the relevant population;

• volume of data;

• range of data categories;

• duration;

• geographical extent. (European Data Protection Board)

This produces an important legal principle:

Large scale is contextual, not purely numerical.

100,000 people may be large scale for one processing activity.

For another, 100,000 could be relatively modest.

28. Four-factor large-scale analysis

Consider a health insurer processing data relating to 5 million policyholders.

The processing is:

• nationwide;

• continuous;

• long-term;

• involves health information;

• includes claims history;

• includes diagnostic information;

• includes treatment information.

Every factor points toward large-scale processing.

Now consider a small specialist clinic with 800 patients.

Even though the information is extremely sensitive, the processing is:

• geographically limited;

• small in number;

• directly related to medical care;

• conducted by a small professional practice.

The analysis is therefore different.

29. Criminal-offence data deserves particular attention

Article 35(3)(b) also captures large-scale processing of criminal-offence information.

Consider:

A recruitment platform creates a database containing criminal records of applicants and uses automated algorithms to score applicants according to perceived risk.

This could produce serious consequences involving:

• employment;

• stigma;

• discrimination;

• accuracy;

• rehabilitation;

• proportionality;

• access to opportunities.

The DPIA should therefore examine the entire lifecycle:

collection → verification → analysis → scoring → decision → retention → disclosure → deletion.

30. Article 35(3)(c): Large-scale systematic monitoring of publicly accessible areas

This category is particularly relevant to:

• CCTV;

• facial recognition;

• public Wi-Fi tracking;

• location analytics;

• smart-city systems;

• crowd analytics;

• behavioural monitoring.

The key elements are:

systematic monitoring + publicly accessible area + large scale.

A camera inside a private office is different from a city-wide camera network.

A camera observing one entrance may be different from thousands of cameras connected to facial-recognition technology.

31. Why public-space monitoring is particularly sensitive

Public monitoring creates a special problem:

People may have no realistic way to avoid it.

Imagine walking through a city.

You may encounter:

• CCTV;

• facial-recognition cameras;

• vehicle-number recognition;

• mobile-device tracking;

• behavioural analytics.

Even if each system is individually defensible, combining them can create a detailed map of a person's movements.

This creates a chilling effect:

People may change their behaviour because they believe they are being watched.

That is a broader rights-and-freedoms concern.

32. CCTV is not automatically low risk

A common mistake is:

“CCTV is standard technology, so no DPIA is necessary.”

Wrong.

The technology's age does not determine risk.

Consider two systems.

System A

One camera at a warehouse entrance.

• limited area;

• short retention;

• no facial recognition;

• limited access;

• clear signage.

System B

A nationwide network of cameras that:

• identifies faces;

• tracks individuals;

• links identities across locations;

• stores movement histories;

• generates behavioural profiles.

Calling both “CCTV” conceals the enormous difference in risk.

System B is an obvious DPIA candidate.

33. Article 35(3) is not exhaustive

This is one of the most important examination points.

A controller cannot say:

“Our processing does not fall into any of the three categories, therefore no DPIA is required.”

That reasoning is incorrect.

The opening provision remains the controlling test:

Is the processing likely to result in a high risk?

The three categories are examples of particularly high-risk processing.

34. The nine high-risk criteria

The WP29/EDPB methodology provides a very useful practical framework.

The commonly used criteria include:

• evaluation or scoring;

• automated decision-making with legal or similarly significant effects;

• systematic monitoring;

• sensitive or highly personal data;

• large-scale processing;

• matching or combining datasets;

• vulnerable data subjects;

• innovative technology;

• processing that prevents individuals from exercising a right or using a service or contract.

The EDPB's current SME guidance continues to use these criteria as practical indicators and states that in most cases processing meeting two criteria should be assessed through a DPIA. (European Data Protection Board)

But this is a risk-assessment methodology, not a mechanical statutory formula.

35. The “two criteria” rule is not a mathematical safe harbour

This is a frequent mistake.

Suppose a company says:

“Our processing satisfies only one criterion, so we don't need a DPIA.”

That is not legally correct.

A single criterion may be sufficient.

For example:

A system involving extremely intrusive biometric surveillance may justify a DPIA even if the organisation struggles to identify a second criterion.

Conversely, satisfying two criteria is a very strong warning sign.

The correct approach is:

The more high-risk characteristics present, the stronger the case for a DPIA.

But the controller must ultimately apply Article 35(1).

36. Matching or combining datasets

This criterion is particularly important in modern data ecosystems.

Suppose a company has:

Dataset A: customer purchases.

Dataset B: website browsing.

Dataset C: location.

Dataset D: publicly available information.

Individually, each dataset may appear relatively harmless.

Combined, they may reveal:

• income;

• interests;

• health concerns;

• political activity;

• relationships;

• behavioural patterns.

The risk arises from the combination.

This demonstrates why a DPIA should not merely analyse each dataset independently.

It should analyse what can be inferred from their combination.

37. Vulnerable data subjects

Children are the obvious example.

But vulnerability is not restricted to children.

Depending upon context, vulnerable persons may include:

• patients;

• elderly persons;

• persons with disabilities;

• migrants;

• individuals in dependent relationships;

• employees;

• economically vulnerable persons;

• persons dealing with government authorities.

Vulnerability matters because the same processing may have different consequences depending on the ability of individuals to understand, resist or challenge it.

For example:

A behavioural advertising system targeting wealthy adult consumers is not necessarily equivalent to an algorithm targeting children.

Children may have:

• reduced understanding;

• reduced ability to assess consequences;

• greater susceptibility to manipulation;

• limited bargaining power.

38. Innovation plus vulnerability

Consider an AI system used to monitor children's behaviour in schools.

The system:

• uses facial recognition;

• predicts emotional states;

• creates behavioural profiles;

• sends alerts to teachers;

• stores historical information.

This combines multiple high-risk indicators:

• innovative technology;

• systematic monitoring;

• sensitive information;

• vulnerable individuals;

• profiling;

• potentially significant consequences.

The case for a DPIA is overwhelming.

39. Article 35(4): DPA “blacklists”

Supervisory authorities are required to publish lists of processing operations that require DPIAs.

These are often described as:

• blacklists;

• positive lists;

• mandatory DPIA lists.

The purpose is to give organisations more certainty.

Example

a DPA might identify:

• large-scale biometric processing;

• systematic employee monitoring;

• large-scale profiling;

• certain AI applications;

• certain vulnerable-person processing;

as requiring DPIAs.

The EDPB maintains a register of such national authority decisions. (European Data Protection Board)

40. Absence from a blacklist does not mean “no DPIA”

This is an extremely important legal trick.

Suppose a company's processing does not appear on its national DPA's list.

The company cannot conclude:

“The DPA has not listed it, so Article 35 does not apply.”

The statutory Article 35(1) test remains independently applicable.

The lists are therefore additional regulatory guidance, not the complete definition of high-risk processing.

This is expressly recognised in DPA materials. For example, the Hungarian authority's published list emphasises that processing outside the list can still require a DPIA where Article 35(1)'s conditions are satisfied. (European Data Protection Board)

41. Article 35(5): DPA “whitelists”

The opposite mechanism is the whitelist.

A DPA may identify processing activities for which a DPIA is not required.

But unlike the blacklist obligation, creation of a whitelist is optional.

The crucial point is that a whitelist operates only within its specified conditions.

Suppose a whitelist says:

“Routine payroll processing by small employers does not require a DPIA.”

That does not necessarily mean:

“Any employee-related processing never requires a DPIA.”

If the employer later introduces:

• continuous employee surveillance;

• AI productivity scoring;

• facial recognition;

• behavioural monitoring;

the organisation must reassess.

The processing has changed.

42. Why whitelists must be read narrowly

A whitelist is not a general immunity.

It is better understood as:

“For this specific processing activity, under these specified conditions, the DPA considers a DPIA unnecessary.”

Change the conditions and the conclusion may change.

This is why controllers should preserve the exact version of the DPA list relied upon and document the reasoning.

43. Article 35(6): Consistency mechanism

The consistency mechanism prevents European data protection regulation from becoming fragmented where processing has significant cross-border implications.

This becomes particularly relevant for:

• multinational platforms;

• online services;

• cross-border behavioural monitoring;

• EU-wide AI systems;

• common industry platforms.

Suppose France develops a DPIA blacklist that affects a processing operation used by a company throughout:

• France;

• Germany;

• Italy;

• Spain;

• Netherlands.

It would be problematic if one Member State considered the processing high risk while another adopted a radically different position.

Article 35(6), read with the consistency mechanism, helps address that problem.

44. Article 35(7): What must actually be inside the DPIA?

This is the heart of the practical DPIA.

A proper DPIA must contain at least four major components:

1. description of processing and purposes;

2. necessity and proportionality assessment;

3. risk assessment;

4. mitigation measures and compliance mechanisms.

These should not be treated as four boxes to tick.

They form a logical chain:

1. What are we doing?
2. Why are we doing it?
3. Do we actually need to do it this way?
4. What could go wrong?
5. How serious is that?
6. What will we change to reduce the risk?
7. What risk remains?
8. Can we proceed?

45. Article 35(7)(a): Systematic description

The first requirement is to describe the processing.

This should ordinarily include:

• categories of data;

• data subjects;

• purposes;

• collection methods;

• sources;

• systems;

• recipients;

• processors;

• transfers;

• retention;

• access;

• storage;

• deletion;

• automated processing;

• profiling;

• relevant technologies.

A good DPIA should allow an external reviewer to understand the processing without having to interview ten employees.

46. Data-flow mapping is essential

One of the most useful techniques is to create a data-flow diagram.

For example:

Customer → Mobile App → API → Cloud Platform → AI Model → Analytics Database → Customer Service → Marketing System

Each arrow creates potential questions.

What data travels?

Who receives it?

Where is it stored?

Is it copied?

Is it logged?

Is it transferred outside the EEA?

Does the vendor retain it?

Does the model learn from it?

Is it deleted?

Can a data subject exercise their rights against every copy?

This is why DPIA analysis often reveals problems that ordinary legal review misses.

47. Purpose limitation belongs inside the DPIA

Suppose the stated purpose is:

“Provide personalised recommendations.”

The company later says:

“We will also use the same information for employee monitoring, fraud detection, insurance scoring and advertising.”

The DPIA should expose this expansion.

A purpose should be sufficiently specific to permit meaningful necessity and proportionality analysis.

If the purpose is vague, the necessity analysis becomes meaningless.

48. Article 35(7)(b): Necessity and proportionality

This is perhaps the most underappreciated part of a DPIA.

Many organisations treat a DPIA as:

“Risk identification + security controls.”

That is incomplete.

The controller must first ask:

Is this processing actually necessary?

And then:

Is the processing proportionate to its purpose?

These are different questions.

49. Necessity is not convenience

A business cannot establish necessity simply by saying:

“This technology makes our work easier.”

Suppose an employer wants to monitor every employee's exact location during working hours.

The employer says:

“It helps us understand productivity.”

That does not establish necessity.

Could the same purpose be achieved by:

• monitoring project completion;

• recording attendance;

• measuring output;

• using aggregate statistics?

If yes, continuous location tracking may be unnecessary.

50. The “less intrusive alternative” test

A very useful DPIA question is:

Can we achieve substantially the same legitimate objective with less personal data or less intrusive processing?

Consider a university trying to prevent cheating.

Option A:

Record students' entire screens continuously.

Option B:

Use limited technical controls during examinations.

Option C:

Use supervised examination rooms.

Option D:

Use a combination of targeted controls.

The DPIA should compare these alternatives.

The organisation should not begin with:

“We have decided to use Option A.”

It should ask:

“Why is Option A necessary compared with Options B, C and D?”

51. Data minimisation is therefore part of DPIA analysis

Suppose an AI system needs:

• age;

• location;

• purchase history;

but the engineering team also wants:

• full name;

• email;

• exact GPS coordinates;

• browsing history;

• social-media information.

The DPIA should challenge this.

The question is not:

“Can we technically collect it?”

The question is:

“Do we need it for this purpose?”

This is where Article 35 connects directly to Article 5(1)(c).

52. Retention must also be justified

Suppose a company says:

“We need to retain this information for ten years.”

The DPIA should ask:

Why ten years?

If the actual purpose is completed after six months, retaining the information for ten years increases exposure without necessarily increasing utility.

Retention should therefore be connected to:

• purpose;

• legal obligations;

• operational requirements;

• risk;

• deletion mechanisms.

53. Necessity and proportionality of AI

AI makes this particularly difficult.

Suppose an organisation wants to deploy emotion-recognition software.

The business purpose is:

“Improve employee wellbeing.”

The DPIA should ask:

• Is emotion recognition actually necessary?

• Is there evidence that it achieves the objective?

• Could employee surveys achieve the same result?

• Is the inference scientifically reliable?

• Is the technology proportionate?

• Do employees reasonably expect such monitoring?

• What happens when the system incorrectly labels someone as stressed?

• Could management use the information for performance decisions?

The fact that technology is available does not establish necessity.

54. Article 35(7)(c): Risk assessment

Once necessity has been established, the DPIA must assess the risks to individuals.

The crucial distinction is between:

risk to the organisation, and

risk to the data subject.

A business risk might be:

“We may suffer reputational damage.”

A data-subject risk might be:

“An employee may be wrongly classified as dishonest and denied promotion.”

The second is the type of risk Article 35 is centrally concerned with.

55. The risk should be expressed as a scenario

Weak DPIA:

“There is a risk of discrimination.”

Better DPIA:

“The recruitment model may systematically assign lower suitability scores to candidates whose employment histories contain career interruptions. If the model uses historical recruitment outcomes as training data, this may reproduce existing structural patterns and disproportionately disadvantage candidates with career gaps.”

The second statement identifies:

• event;

• mechanism;

• affected individuals;

• potential consequence.

That makes mitigation possible.

56. Threat is not the same as risk

Another important distinction:

Threat: something capable of causing harm.

Risk: the possibility that the threat materialises and causes consequences.

For example:

Hacker access = threat.

Unauthorised disclosure of medical records affecting patients = consequence.

The likelihood of such disclosure combined with its severity = risk.

A DPIA should therefore move beyond a generic threat list.

57. Inherent risk versus residual risk

This distinction is extremely useful.

Inherent risk

What would the risk look like without safeguards?

Residual risk

What risk remains after safeguards are implemented?

Suppose facial recognition creates a high inherent risk.

The controller implements:

• encryption;

• limited retention;

• strict access;

• human review;

• accuracy testing;

• audit logs.

The risk may fall.

But it does not necessarily become low.

That remaining risk is the residual risk.

58. Mitigation does not erase the original risk

This is a subtle but important point.

A controller should not write:

“Risk = high. Encryption = implemented. Risk = low.”

That is not a meaningful assessment.

The organisation must explain:

How does encryption reduce the specific risk?

Encryption may significantly reduce:

• unauthorised access;

• disclosure after theft.

But encryption does nothing to address:

• algorithmic discrimination;

• excessive collection;

• inaccurate profiling;

• unfair automated decisions.

Different risks require different controls.

59. Article 35(7)(d): Mitigation measures

Mitigation can involve:

Technical measures

• encryption;

• pseudonymisation;

• access controls;

• tokenisation;

• differential privacy;

• data minimisation mechanisms;

• deletion automation;

• audit logging;

• model monitoring.

Organisational measures

• policies;

• training;

• role separation;

• approval processes;

• incident procedures;

• human review;

• governance committees.

Legal measures

• processor contracts;

• confidentiality obligations;

• restrictions on secondary use;

• contractual audit rights;

• transfer safeguards.

Product measures

• privacy settings;

• opt-outs;

• transparency interfaces;

• appeal mechanisms;

• human review.

A strong DPIA connects each safeguard to a specific risk.

60. Example of proper risk-mitigation mapping

Risk	Potential consequence	Safeguard	Residual risk
Incorrect AI classification	Candidate wrongly rejected	Human review + model validation	Medium
Unauthorised vendor access	Disclosure	Encryption + access control	Low
Excessive retention	Long-term exposure	Automatic deletion	Low
Proxy discrimination	Unequal treatment	Bias testing + feature restrictions	Medium
Lack of transparency	Inability to challenge	Explanation + appeal mechanism	Medium

The important point is that the table is not the analysis itself.

The controller should explain why each safeguard works and why the remaining risk is acceptable.

61. What if residual risk remains high?

This is where Article 35 connects to Article 36.

A controller should not think:

“We completed the DPIA, so we can proceed.”

Completion of a DPIA does not authorise processing.

If high residual risk remains and cannot be sufficiently mitigated, prior consultation with the supervisory authority becomes relevant.

The EDPB expressly states that where residual risks remain high despite mitigation, prior consultation is required. (European Data Protection Board)

Thus:

DPIA → mitigation → residual risk assessment → if high and unmitigable → Article 36 consultation.

62. A DPIA is not a “permission to process”

This deserves emphasis.

A DPIA does not make unlawful processing lawful.

It cannot cure:

• absence of a lawful basis;

• incompatible purposes;

• prohibited processing;

• failure to satisfy Article 9;

• unlawful transfers;

• violation of data-subject rights.

Similarly:

“We conducted a DPIA”

is not a defence to every GDPR violation.

A DPIA is one accountability mechanism within the larger GDPR framework.

63. Article 35(8): Codes of conduct

Approved codes of conduct under Article 40 should be taken into account when assessing processing.

Why?

Because a sector-specific code may already contain:

• recognised safeguards;

• standards;

• technical controls;

• retention practices;

• governance mechanisms.

Example

a healthcare code may provide practical guidance concerning:

• access controls;

• confidentiality;

• retention;

• processor relationships;

• patient rights.

The DPIA can use those standards as part of its analysis.

64. But a code of conduct is not a magic shield

This is another important nuance.

Suppose a controller says:

“We comply with the industry code, therefore no DPIA is required.”

That is incorrect.

The code is taken into account.

It does not automatically eliminate risk.

A processing operation can comply with an approved code and still create high risk.

Example

a code may address cybersecurity adequately but say little about:

• algorithmic discrimination;

• intrusive profiling;

• new AI capabilities.

The specific processing must still be assessed.

65. Article 35(9): Consulting data subjects

Where appropriate, the controller should seek the views of data subjects or their representatives.

This reflects an important democratic idea:

The people exposed to the risk may understand the practical consequences better than the organisation designing the system.

For employee monitoring, representatives may include:

• staff councils;

• employee representatives;

• trade unions.

For consumer services:

• consumer groups;

• customer representatives.

For public-sector systems:

• civil-society organisations;

• affected communities.

The consultation can identify risks that management overlooked.

66. Consultation is not the same as consent

This is an important distinction.

Suppose a company asks employees:

“Do you consent to the DPIA?”

That is conceptually wrong.

Article 35(9) concerns obtaining views, not obtaining consent to the processing.

The controller might ask:

“What concerns do you have about this monitoring system?”

The answer becomes evidence in the DPIA.

The legal basis for any processing involved in conducting the consultation must separately be considered.

67. What if data subjects disagree with the controller?

Suppose employees say:

“This monitoring system is excessive and will create pressure and unfair performance comparisons.”

Management disagrees and launches the system.

The GDPR does not necessarily require the controller to follow the views expressed.

But the organisation should document:

• what views were received;

• how they were assessed;

• why certain concerns were accepted or rejected;

• what safeguards were introduced.

This creates an accountability trail.

68. Commercial confidentiality does not eliminate consultation

A company might argue:

“We cannot consult employees because our new product is confidential.”

That may be relevant.

Article 35(9) expressly recognises protection of:

• commercial interests;

• public interests;

• security of processing operations.

But confidentiality should not become an automatic excuse.

The controller should consider whether it can provide enough information to obtain meaningful views without disclosing:

• trade secrets;

• security-sensitive details;

• commercially confidential information.

69. Article 35(10): Processing required by law

This provision deals with processing under:

• Article 6(1)(c): legal obligation;

• Article 6(1)(e): public task/official authority;

where:

1. EU or Member State law regulates the processing;

2. a DPIA has already been carried out as part of adopting that legal basis.

The logic is that the risk assessment may already have been undertaken at the legislative level.

70. Example of Article 35(10)

Imagine Parliament creates a statutory national database for a specific public function.

During the legislative process, the legislature conducts a detailed impact assessment examining:

• data categories;

• purposes;

• access;

• safeguards;

• retention;

• risks.

The law precisely regulates the processing.

A government agency implementing that statutory system may fall within Article 35(10).

The GDPR recognises that repeating the same DPIA at every implementing institution may sometimes create unnecessary duplication.

71. Article 35(10) is not a general public-sector exemption

This is an important trap.

A government authority cannot say:

“We are a public authority, so Article 35 does not apply.”

That is wrong.

The exemption requires specific conditions.

There must be:

• a qualifying legal basis;

• law regulating the specific processing;

• a prior DPIA or equivalent impact assessment carried out as part of adoption of that legal basis.

If those conditions are absent, Article 35 may still apply.

72. A broad statute may not be enough

Suppose a law merely says:

“The Ministry may process personal data necessary to perform its functions.”

That is not necessarily the same as a detailed legal framework specifically regulating a particular processing operation.

If the ministry then deploys a nationwide AI surveillance system, it cannot automatically rely upon Article 35(10).

The specificity of the legal framework matters.

73. Article 35(11): DPIA is a living process

This paragraph prevents the DPIA from becoming a dead document.

The controller must review the processing when necessary, at least where the risk changes.

This is essential because technology and processing environments evolve.

A DPIA prepared in 2019 may become inadequate in 2026 because:

• the technology changed;

• the data categories expanded;

• the model changed;

• new vendors were introduced;

• the number of users increased;

• retention changed;

• new vulnerabilities emerged;

• legal requirements changed;

• case law changed;

• individuals became more vulnerable;

• new uses were added.

74. Material change should trigger review

Consider an AI system initially designed for:

customer-support categorisation.

Later, the company adds:

automated fraud scoring.

That is not merely a minor software update.

The purpose and consequences have changed.

A DPIA review should therefore occur.

Similarly:

Initial processing

10,000 customers.

Later processing

20 million customers.

The scale has radically changed.

A review is necessary.

75. Technology change can alter risk

Suppose encryption was state-of-the-art when the DPIA was conducted.

Years later, new vulnerabilities emerge.

The organisation cannot simply say:

“Our DPIA already assessed security.”

The risk environment has changed.

The controller must reassess.

The same applies to:

• new AI model capabilities;

• new biometric techniques;

• new tracking technologies;

• new attack methods;

• new inference capabilities.

76. Legal change can alter risk

Risk is not only technological.

A change in:

• legislation;

• regulatory guidance;

• CJEU case law;

• EDPB guidance;

• national DPA interpretation;

can change the legal assessment.

A processing activity previously considered defensible may need redesign.

Thus DPIA governance should connect with the organisation's wider legal-monitoring function.

77. DPIA should be integrated with change management

One of the best operational approaches is to make DPIA review part of the company's change-management process.

For example:

Trigger DPIA review when

• purpose changes;

• data categories change materially;

• new sensitive data is introduced;

• new AI functionality is introduced;

• new profiling is introduced;

• automated decisions are introduced;

• number of individuals increases substantially;

• new countries are involved;

• new processors are added;

• retention increases materially;

• technology changes significantly;

• security architecture changes;

• risk assumptions change.

This turns Article 35(11) into an operational control rather than an annual paperwork exercise.

78. DPIA and Article 25: Privacy by design

The relationship between Articles 25 and 35 is extremely important.

Article 25 says, broadly:

Build privacy into the system.

Article 35 says:

Identify and assess the risks of the proposed processing and determine how those risks should be addressed.

The DPIA therefore becomes one of the practical mechanisms through which privacy by design occurs.

79. DPIA and Article 32: Security

Article 32 asks whether security is appropriate to the risk.

Article 35 asks about the broader risks created by the processing.

For example:

Article 32 question

“How do we protect this medical database against unauthorised access?”

Article 35 question

“Should we collect all these medical variables at all, and what could happen to patients if the resulting profiling is wrong?”

The first is security-focused.

The second is rights-and-freedoms-focused.

Both are necessary.

80. DPIA and Article 22

Article 35(3)(a) is closely related to automated decision-making.

But the two provisions should not be collapsed into one.

Article 22 asks whether a particular automated decision-making activity is legally permissible and what safeguards apply.

Article 35 asks whether the processing creates high risk and therefore requires assessment.

A system may therefore create a DPIA obligation even where Article 22 does not ultimately prohibit the decision.

Conversely, Article 22 analysis does not substitute for a DPIA.

81. DPIA and Article 9

Similarly, special-category processing under Article 9 may strongly increase risk.

But the DPIA does not replace Article 9's requirements.

The controller must separately establish:

• Article 6 lawful basis;

• Article 9 condition where applicable;

• Article 35 DPIA requirement;

• appropriate safeguards.

One provision cannot be used as a substitute for another.

82. DPIA and legitimate interests

Article 35(7)(a) expressly refers, where applicable, to the legitimate interest pursued.

This makes sense because a DPIA can help reveal whether the controller's legitimate interest is sufficiently compelling when weighed against the intrusion.

For example:

A company wants to monitor employees' keystrokes to detect inactivity.

The DPIA might show:

• the purpose is productivity;

• the system captures highly detailed behavioural information;

• less intrusive alternatives exist;

• employees reasonably expect limited monitoring;

• the system may create significant stress.

That analysis may fundamentally weaken the controller's legal and proportionality position.

Thus, a DPIA can expose problems with the underlying lawful basis.

83. DPIA and transparency

A DPIA can also reveal whether transparency is meaningful.

Suppose a company says:

“Our privacy notice tells users that automated analytics are used.”

Technically, that may be disclosure.

But the DPIA may reveal that users cannot understand:

• what is being inferred;

• why it matters;

• how it affects them;

• how long the profile persists;

• how they can challenge it.

The DPIA can therefore push the organisation toward better transparency.

84. DPIA and data-subject rights

A mature DPIA should ask whether people can realistically exercise their rights.

For example:

“Can a person request deletion?”

If the data exists in:

• production database;

• backup;

• analytics platform;

• AI training dataset;

• vendor environment;

• logs;

the answer may not be straightforward.

Similarly:

“Can a person obtain access?”

If their information has been transformed into:

• embeddings;

• derived scores;

• behavioural profiles;

• model features;

the organisation must consider how those rights operate.

85. AI and DPIAs: why Article 35 has become more important

AI systems are almost perfectly suited to Article 35 analysis because they often combine several high-risk characteristics:

• large-scale data;

• profiling;

• automated evaluation;

• inference;

• innovative technology;

• vulnerable populations;

• significant decisions;

• data matching;

• opacity;

• potential discrimination.

Consider an AI model that predicts employee attrition.

The model uses:

• email metadata;

• attendance;

• performance ratings;

• meeting patterns;

• work hours;

• project assignments.

It predicts:

“Probability employee will leave within six months: 82%.”

Management begins treating high-risk employees differently.

Even if the model never formally fires anyone, it may influence:

• promotions;

• salary increases;

• training;

• important projects;

• performance evaluations.

The DPIA must therefore examine the actual effects, not merely the formal description of the system.

86. A critical AI DPIA question: what is being inferred?

One of the biggest mistakes in AI governance is focusing only on the data that enters the system.

A DPIA should also examine:

What information does the system infer?

For example:

Input:

• location;

• purchasing behaviour.

Inference:

• likely health condition.

Input:

• writing style;

• browsing behaviour.

Inference:

• personality trait.

Input:

• employment history;

• financial information.

Inference:

• creditworthiness.

The inferred information can be more sensitive than the original data.

87. Another AI issue: proxy discrimination

Suppose a model does not receive race.

Management says:

“Therefore the model cannot discriminate based on race.”

That is naïve.

The model may use:

• postcode;

• school;

• language;

• purchasing behaviour;

• employment history.

These variables may correlate with protected characteristics.

The DPIA should therefore consider indirect discrimination and proxy effects, not merely whether an expressly sensitive field exists.

88. Another AI issue: model drift

A model may be safe at launch but become riskier over time.

For example:

• user population changes;

• training data changes;

• model is retrained;

• new variables are introduced;

• business objectives change.

This makes Article 35(11) particularly important for AI.

The DPIA should establish:

• monitoring metrics;

• review frequency;

• trigger events;

• ownership;

• escalation mechanisms.

89. Case study: AI recruitment system

Illustration

Imagine “HireAI”, a hypothetical multinational company, deploys a system that ranks candidates. The system processes:

• CVs;
• interview transcripts;
• assessment results;
• previous employment;

• publicly available professional information.

It generates a candidate score.

Candidates below a threshold are rejected automatically.

Step 1: Nature

The processing involves:

• profiling;

• automated evaluation;

• large-scale data processing.

Step 2: Context

The data is used in an employment relationship.

Candidates have limited ability to influence the processing.

Step 3: Purpose

The purpose is recruitment efficiency.

Step 4: Necessity

Could recruitment efficiency be achieved using:

• simpler keyword filtering;

• human screening;

• limited automated assistance?

This must be considered.

Step 5: Risk

Potential risks include:

• discrimination;

• inaccurate rejection;

• proxy bias;

• opacity;

• reputational consequences;

• inability to challenge the result.

Step 6: Mitigation

Possible safeguards include:

• human review;

• bias testing;

• exclusion of inappropriate variables;

• candidate appeal;

• model validation;

• accuracy monitoring;

• limited retention.

Step 7: Residual risk

Suppose bias testing continues to reveal significant disparities.

The organisation cannot simply say:

“We performed a DPIA.”

The DPIA has revealed a substantive problem.

The correct response may be:

redesign the system.

That is the real value of Article 35.

90. Case study: Employee productivity monitoring

Illustration

A company wants to install software that records:

• keystrokes;
• active windows;
• screenshots;
• mouse movement;
• application usage.

It argues:

“The purpose is productivity.”

The DPIA should challenge:

Is it necessary?

Could productivity be measured by:

• completed tasks;

• deadlines;

• output;

• project metrics?

Is it proportionate?

Does recording screenshots every five minutes go beyond what is necessary?

What are the risks?

• constant surveillance;

• stress;

• chilling effect;

• unfair performance evaluation;

• exposure of personal information;

• monitoring of privileged communications;

• monitoring of health or personal activity.

What alternatives exist?

Perhaps aggregate productivity metrics are sufficient.

This illustrates why the DPIA is not merely a security document.

91. Case study: Smart-city facial recognition

Illustration

A city wants to deploy facial recognition across major public areas. The system:

• captures faces;
• compares them against watchlists;
• generates matches;
• retains records;

• links movements across cameras.

The processing clearly involves:

• innovative technology;

• systematic monitoring;

• public space;

• biometric data;

• potentially large scale;

• identification;

• potentially significant consequences.

The DPIA should examine:

• false positives;

• false negatives;

• discriminatory accuracy;

• watchlist governance;

• retention;

• access;

• human verification;

• appeal;

• police access;

• secondary use;

• function creep.

The key issue is not:

“Is the camera encrypted?”

It is:

“Should society conduct this form of identification, under what conditions, and with what safeguards?”

92. Case study: Health-risk prediction

Illustration

A biotechnology company offers consumers genetic testing. The system predicts: “Your probability of developing disease X is 72%.” The processing may involve:

• genetic data;
• health-related information;

• profiling;

• predictions;

• potentially significant consequences.

Risks include:

• psychological harm;

• discrimination;

• inaccurate predictions;

• family privacy implications;

• secondary use;

• insurance consequences;

• security risks.

A proper DPIA must therefore examine not only data security but also the social consequences of prediction.

93. Case study: Public scraping and profiling

Illustration

A company scrapes:

• public websites;
• professional directories;
• public records. It combines the information with:
• income statistics;

• geographic information;

• purchasing data.

It creates profiles of millions of individuals.

The company says:

“All the information is public.”

That does not eliminate DPIA risk.

The issue is not merely whether individual pieces of information were publicly accessible.

The combination may create:

• intrusive profiles;

• unexpected inferences;

• loss of control;

• inability to exercise rights;

• significant reputational or economic consequences.

The processing can therefore become high risk despite the public origin of the data.

94. Case study: Children's behavioural advertising

Illustration

An online platform profiles children based on:

• viewing history;
• game activity;
• clicks;
• interests;
• location;

• interaction patterns.

It uses the profile for targeted advertising.

The risk analysis should immediately identify:

• vulnerable data subjects;

• systematic monitoring;

• profiling;

• large-scale processing;

• potentially intrusive behavioural analysis.

The child's inability to understand or meaningfully resist the profiling increases the risk.

A DPIA is therefore strongly indicated.

95. DPIA and public authorities

Public authorities deserve special attention because their processing may involve:

• large populations;

• compulsory participation;

• sensitive data;

• surveillance;

• public services;

• enforcement;

• immigration;

• taxation;

• policing.

The power imbalance may mean that individuals cannot simply choose not to participate.

Therefore, a DPIA can operate as an important safeguard against unchecked administrative data power.

This is particularly significant because the consequences of public-sector decisions can involve:

• benefits;

• immigration status;

• taxation;

• education;

• policing;

• healthcare;

• housing.

96. DPIA as a governance mechanism

The deepest conceptual understanding of Article 35 is that the DPIA is a form of risk-based governance.

It forces the organisation to move from:

“Can we technically do this?”

to:

“Should we do this?”

and then:

“If we do it, under what conditions?”

This is why the DPIA can influence business architecture.

Example

the DPIA might result in:

• deleting unnecessary data fields;

• rejecting a vendor;

• reducing retention;

• changing an algorithm;

• introducing human review;

• restricting access;

• changing a lawful basis;

• redesigning the user interface;

• abandoning a project.

A DPIA that never changes anything may be a warning sign that the process is not genuinely integrated into governance.

97. The “paper DPIA” problem

A common compliance failure is creating a beautifully formatted DPIA containing:

• risk tables;

• signatures;

• colour-coded scores;

• policy references.

But nobody actually changes the project.

That is a paper DPIA.

A genuine DPIA should have evidence of consequences.

For example:

Original proposal: retain data for five years.

DPIA conclusion: excessive retention.

Revised proposal: retain identifiable data for twelve months, aggregate statistics thereafter.

That is evidence of meaningful assessment.

98. DPIA should influence procurement

DPIA analysis should often occur before vendor selection is finalised.

Suppose the organisation wants to use an AI vendor.

Vendor A:

• stores prompts for 12 months;

• uses them for model improvement;

• has limited deletion functionality.

Vendor B:

• offers zero-retention processing;

• supports customer-controlled deletion;

• provides audit logs.

If the organisation selects Vendor A first and performs the DPIA afterward, it may discover that the architecture is unsuitable.

The better approach is:

DPIA + procurement + security review + legal review

before contractual commitment.

99. Processor information is often essential to the DPIA

A controller cannot meaningfully assess risk if the processor refuses to disclose:

• sub-processors;

• data locations;

• retention;

• logging;

• security controls;

• deletion mechanisms;

• model-training practices;

• access controls.

Therefore, Article 28 diligence and Article 35 should work together.

The DPIA may reveal that a processor contract needs to be renegotiated.

100. International transfers and DPIA

Where processing involves transfers outside the EEA, the DPIA should consider:

• where data goes;

• who receives it;

• applicable transfer mechanism;

• governmental access risks;

• supplementary safeguards;

• encryption;

• key control;

• onward transfers.

The DPIA does not replace Chapter V.

But the transfer architecture may materially affect the risk assessment.

For example:

Data encrypted before transfer with keys controlled exclusively by the EU controller

may present a different risk profile from:

Data transferred in plaintext to a foreign cloud provider that controls the decryption keys.

101. The DPIA should assess rights practically

A good DPIA should ask:

“Can the individual actually exercise the right?”

Not simply:

“Do we have a policy?”

For example:

Access

Can the organisation retrieve all relevant information?

Rectification

Can incorrect information propagate into derived profiles?

Erasure

Can deletion reach:

• production;

• analytics;

• backups;

• vendor systems;

• model-related stores?

Objection

Does the system actually stop processing after a valid objection?

Human review

Is the reviewer genuinely independent, or merely clicking “approve”?

These practical questions make the DPIA meaningful.

102. Human review must be real

This is especially important for AI.

A company may claim:

“There is a human in the loop.”

But if the human:

• receives thousands of decisions per hour;

• sees only the algorithmic recommendation;

• lacks authority to override;

• lacks sufficient information;

• almost always follows the algorithm;

then human review may be little more than a formal safeguard.

A DPIA should therefore ask:

What exactly does the human reviewer do?

103. Documentation of rejected alternatives

One of the best DPIA practices is to document alternatives that were considered and rejected.

For example:

Option A: collect exact location continuously.

Option B: collect approximate location.

Option C: collect location only when the user requests navigation.

The organisation selects Option B.

Why?

Because it achieves the business purpose while reducing intrusiveness.

This creates evidence of proportionality.

104. DPIA and “function creep”

Function creep occurs when information collected for one purpose gradually gets used for others.

Example

CCTV installed for physical security. Later: employee attendance monitoring. Later: productivity monitoring. Later:

behavioural profiling.

The DPIA should prevent such silent expansion.

A change in purpose should trigger reassessment.

105. DPIA and secondary use

A particularly difficult situation arises where the controller says:

“We already have the data, so using it for another purpose costs us nothing.”

That is economically true but legally irrelevant.

The DPIA should ask:

• Is the new purpose compatible?

• Is additional information needed?

• Is the new use expected?

• Does it create new risks?

• Does it involve new recipients?

• Does it create profiling?

• Does it affect rights differently?

The existence of data in a database does not make every future use low risk.

106. DPIA and anonymisation

Anonymisation can significantly reduce risk.

But the controller must ensure that the data is genuinely anonymised.

Removing names does not necessarily anonymise information.

If a dataset contains:

• exact location;

• timestamp;

• occupation;

• age;

• rare characteristics;

individuals may still be identifiable.

A DPIA should therefore examine the actual re-identification risk.

107. Pseudonymisation is not anonymisation

Pseudonymisation reduces risk but does not remove the GDPR's application.

Suppose:

Name → Customer ID 48291.

If the company retains the mapping table, the information remains personal data.

Pseudonymisation may be an excellent safeguard.

But the DPIA should not treat it as elimination of risk.

108. DPIA should distinguish types of harm

A mature DPIA does not simply say:

“Data breach = high risk.”

Different risks should be analysed separately.

For example:

Confidentiality risk

Unauthorised disclosure.

Integrity risk

Incorrect information changes the person's profile.

Availability risk

Loss of information prevents access to essential services.

Fairness risk

Algorithm produces discriminatory outcomes.

Autonomy risk

Continuous monitoring changes behaviour.

Transparency risk

Individuals cannot understand processing.

Rights-exercise risk

Individuals cannot effectively exercise their rights.

This produces a much richer analysis.

109. DPIA and physical harm

The phrase “data protection” can cause organisations to focus entirely on informational harm.

But personal-data processing can contribute to physical harm.

Examples

• location tracking exposing a victim to an abuser;
• disclosure of a person's medical information;
• publication of a vulnerable person's address;
• incorrect medical profiling;
• surveillance creating risks to physical safety. The DPIA should therefore consider real-world consequences.

110. DPIA and psychological harm

Similarly, psychological consequences matter.

Examples

include:

• constant employee surveillance;
• predictive mental-health profiling;
• exposure of intimate information;
• incorrect fraud suspicion;
• automated rejection;
• public disclosure of sensitive information. A DPIA should not assume that harm must be financial.

111. DPIA and reputational harm

Suppose an algorithm incorrectly labels someone:

“High fraud risk.”

Even if the label is never publicly disclosed, it may influence:

• banking;

• insurance;

• employment;

• account access.

The reputational and economic implications can be substantial.

Therefore, accuracy should be a DPIA concern.

112. Accuracy is not merely an Article 5 issue

Accuracy under Article 5 is often treated as a separate compliance requirement.

But inaccurate information can be a risk to rights and freedoms.

Suppose:

incorrect address → wrong identity match → wrong fraud score → account blocked.

The DPIA should assess this chain.

The question is not merely:

“Do we have an accuracy policy?”

It is:

“What happens to a person when the system is wrong?”

113. DPIA and explainability

Where automated systems significantly affect people, the DPIA should consider:

• what explanation can be given;

• what information is necessary for meaningful challenge;

• whether the organisation understands the model sufficiently;

• whether outputs can be audited.

A system that cannot explain why it makes high-impact decisions may create greater rights risks.

114. DPIA should examine worst-case scenarios

Risk assessment should not focus only on the average outcome.

Suppose:

99.5% of facial-recognition matches are accurate.

That sounds excellent.

But if:

0.5% of matches lead to police intervention,

the number of affected individuals could still be substantial at scale.

The DPIA should therefore examine:

• rare but severe events;

• systemic errors;

• vulnerable groups;

• catastrophic consequences.

115. DPIA and scale can amplify small errors

This is one of the most important mathematical intuitions.

Suppose an AI system has a 99.9% accuracy rate.

For 1,000 users:

approximately 1 error.

For 10 million users:

approximately 10,000 errors.

A low error percentage can therefore produce enormous absolute harm at scale.

This is one reason why “large scale” matters.

116. DPIA and cumulative risk

Sometimes individual risks are moderate, but their combination becomes severe.

For example:

• location tracking;

• purchasing history;

• browsing;

• social interactions;

• health-related searches.

Each may reveal something limited.

Together they can create an extremely detailed profile.

The DPIA should therefore consider cumulative privacy impact.

117. DPIA and group harms

Article 35 focuses on individuals, but group-level effects can still matter.

Suppose an algorithm disproportionately disadvantages:

• women;

• particular ethnic communities;

• older workers.

Even if no single individual can immediately prove discrimination, systemic patterns can create significant rights risks.

Therefore, fairness testing should often be part of the DPIA for high-risk algorithms.

118. What should a strong DPIA ultimately conclude?

A DPIA should not merely conclude:

“Risks identified and mitigated.”

It should reach a meaningful decision.

For example:

Option 1, Proceed

Residual risk is sufficiently reduced.

Option 2, Proceed subject to conditions

Processing may begin only after specified safeguards are implemented.

Option 3, Redesign

Current architecture creates excessive risk.

Option 4, Escalate

Residual risk remains high and requires prior consultation under Article 36.

Option 5, Abandon

The processing is disproportionate or cannot be sufficiently mitigated.

This is what makes the DPIA a governance mechanism rather than a document.

119. A practical end-to-end DPIA methodology

A strong DPIA process can be structured as follows.

Step 1, Identify the processing

Define precisely:

• what happens;

• who processes;

• whose data is processed;

• why;

• how;

• where.

Step 2, Screen for DPIA requirement

Apply:

• Article 35(1);

• Article 35(3);

• DPA lists;

• high-risk criteria.

Step 3, Map data flows

Identify:

• sources;

• systems;

• recipients;

• processors;

• transfers;

• retention.

Step 4, Assess necessity

Ask:

Do we actually need this processing?

Step 5, Assess proportionality

Ask:

Is this level of intrusion justified by the purpose?

Step 6, Identify risks

Describe concrete scenarios.

Step 7, Assess likelihood and severity

Consider:

• probability;

• scale;

• affected persons;

• severity;

• vulnerability.

Step 8, Identify safeguards

For each risk, identify specific measures.

Step 9, Calculate residual risk

Do not assume mitigation eliminates risk.

Step 10, Consult DPO

Record the advice.

Step 11, Consult affected persons where appropriate

Record their views.

Step 12, Decide

Proceed, modify, escalate or stop.

Step 13, Implement

Ensure safeguards are actually deployed.

Step 14, Monitor

Test whether the real processing matches the DPIA.

Step 15, Reassess

Review when risk changes.

120. The biggest Article 35 mistakes

The most common mistakes are worth collecting because they frequently appear in practical GDPR work.

Mistake 1: “Every processing activity requires a DPIA.”

Wrong.

The threshold is high risk.

Mistake 2: “Only Article 35(3) processing requires a DPIA.”

Wrong.

Article 35(3) is not exhaustive.

Mistake 3: “Our processing isn't on the DPA blacklist.”

Not sufficient.

Article 35(1) still applies.

Mistake 4: “We have encryption, so the risk is low.”

Wrong.

Encryption addresses certain security risks, not discrimination, unfairness, excessive surveillance or inaccurate profiling.

Mistake 5: “The vendor completed the DPIA.”

Not enough.

The controller remains responsible.

Mistake 6: “The DPO signed it.”

The DPO advises; the controller remains responsible.

Mistake 7: “We completed the DPIA after launch.”

Defeats the prior-assessment purpose.

Mistake 8: “The DPIA is only a privacy team's responsibility.”

It requires multidisciplinary input.

Mistake 9: “The DPIA is finished once signed.”

Article 35(11) makes it a continuing process.

Mistake 10: “Two criteria automatically means DPIA.”

The two-criteria methodology is a strong practical indicator, not a mechanical statutory formula.

Mistake 11: “One criterion can never be enough.”

Also wrong.

One criterion may be sufficient depending on the risk.

Mistake 12: “Sensitive data automatically means DPIA.”

Not necessarily.

The Article 35(3)(b) formulation specifically concerns large-scale processing.

Mistake 13: “CCTV automatically requires a DPIA.”

Not every camera system does.

But systematic large-scale monitoring of publicly accessible areas is expressly identified as high-risk.

Mistake 14: “Publicly available data creates no DPIA risk.”

Wrong.

Aggregation, profiling and inference can create substantial risks.

Mistake 15: “A DPIA proves compliance.”

Wrong.

It demonstrates that risk assessment has been performed; it does not cure every other GDPR violation.

121. DPIA and accountability

Article 35 should ultimately be read through the lens of Article 5(2).

The controller must be able not merely to say:

“We believe the processing is compliant.”

It should be able to demonstrate:

“We identified the risks, considered alternatives, consulted relevant stakeholders, implemented safeguards, assessed residual risk, and continue to monitor the processing.”

That is accountability in action.

A well-maintained DPIA can therefore become valuable evidence during:

• regulatory investigations;

• audits;

• litigation;

• procurement;

• security incidents;

• internal governance;

• board-level decision-making.

122. DPIA as evidence of responsible decision-making

Suppose a regulator investigates an organisation after an incident.

Company A says:

“We never considered the risks.”

Company B produces:

• DPIA;

• DPO advice;

• risk assessments;

• data-flow diagrams;

• mitigation records;

• testing evidence;

• consultation records;

• review history.

Even if Company B experienced an incident, its governance position is fundamentally different.

This does not automatically eliminate liability.

But it demonstrates that the organisation had a functioning accountability process.

123. DPIA and sanctions

Failure to comply with Article 35 is not merely an internal governance defect.

Article 83(4) places controller and processor obligations under Articles 25, 39 within the lower administrative-fine tier, with a maximum of €10 million or 2% of worldwide annual turnover, whichever is higher. (EUR-Lex)

The actual penalty depends on the circumstances and Article 83's proportionality factors.

The CJEU has also clarified the importance of the “undertaking” concept and worldwide turnover in determining the maximum fine under Article 83. (EUR-Lex)

Therefore, Article 35 should not be treated as a soft recommendation.

124. A DPIA can itself reveal that a project should not proceed

This is perhaps the most important practical lesson.

A successful DPIA does not necessarily produce:

“Approved.”

It may produce:

“Do not launch.”

For example:

Facial-recognition system has unacceptable residual discrimination risk.

Or:

Employee surveillance is unnecessary because less intrusive productivity measures exist.

Or:

Vendor architecture prevents effective deletion.

Or:

AI model cannot be sufficiently validated for the proposed high-impact use.

If the organisation nevertheless launches the system, the DPIA may become evidence that management knew about the risk.

Therefore, the integrity of the DPIA process matters enormously.

125. DPIA as an iterative design process

The strongest way to understand Article 35 is:

DPIA → redesign → reassessment → implementation → monitoring → reassessment.

Suppose the original design involves:

continuous location tracking.

The DPIA identifies excessive risk.

The company changes it to:

approximate location only.

That changes the processing.

The DPIA should be updated to examine the new architecture.

This is not wasted effort.

It is exactly what Article 35 is designed to achieve.

126. The 2026 EDPB development: DPIA template

An important contemporary development is that the EDPB adopted a DPIA template in April 2026 and put it through public consultation from April to June 2026. The stated objective is to help organisations structure, harmonise and evidence DPIA processes while still allowing controllers to use their own risk-analysis methodologies. (European Data Protection Board)

This is significant because it shows the direction of European enforcement:

DPIAs are increasingly being treated as structured governance instruments rather than informal privacy checklists.

However, the template should not be misunderstood as changing Article 35's legal test.

The statutory question remains:

Is the processing likely to result in a high risk?

The template merely helps organisations demonstrate that they have answered the question properly.

127. A model example of a complete DPIA reasoning chain

Consider a fictional company, “HealthConnect”, that wants to deploy an AI system predicting which patients are likely to miss appointments.

The system uses:

• medical history;

• appointment history;

• age;

• location;

• previous attendance;

• socioeconomic indicators.

It generates:

“High probability of non-attendance.”

The hospital uses the score to prioritise reminders.

Stage 1, Nature

The system involves:

• health-related data;

• profiling;

• predictive analytics;

• automated scoring.

Stage 2, Scope

It covers:

2 million patients.

The processing is therefore potentially large scale.

Stage 3, Context

Patients are vulnerable and the relationship is healthcare-related.

Stage 4, Purpose

The purpose is reducing missed appointments.

Stage 5, Necessity

Could reminders be sent to all patients without profiling?

Could a simpler model use only:

• appointment history;

• previous attendance?

If yes, extensive health profiling may not be necessary.

Stage 6, Risk

Potential risks include:

• inaccurate prediction;

• discrimination;

• inappropriate use of health data;

• exclusion;

• stigma;

• excessive data collection.

Stage 7, Mitigation

Possible safeguards:

• data minimisation;

• exclusion of unnecessary health variables;

• model validation;

• fairness testing;

• human review;

• strict access;

• short retention;

• patient challenge mechanism.

Stage 8, Residual risk

Suppose testing shows the model is significantly less accurate for a particular patient group.

The DPIA cannot simply say:

“Bias testing conducted.”

The result must affect the decision.

Possible outcomes:

redesign the model;

or

remove certain variables;

or

limit use;

or

abandon the automated score.

This is the essence of a genuine DPIA.

128. The deepest legal principle: prevention rather than reaction

The GDPR is often associated with:

• breach notification;

• complaints;

• fines;

• data-subject rights.

Article 35 represents a different philosophy.

It is preventive.

Instead of waiting for:

discrimination → complaint → investigation → enforcement,

the GDPR asks:

identify the possibility of discrimination before the system is launched.

Instead of:

breach → harm → notification,

the DPIA asks:

what architecture could reduce the likelihood and consequences of the breach?

Instead of:

excessive data collection → later deletion,

the DPIA asks:

why collect the unnecessary data at all?

This is why Article 35 is central to modern privacy governance.

129. The relationship between Article 35 and Article 36

The two provisions should be mentally connected.

Article 35

Assess the risk.

Mitigation

Reduce the risk.

Residual risk

Determine what remains.

Article 36

If high residual risk remains and cannot be sufficiently mitigated, consult the supervisory authority before proceeding.

The EDPB expressly describes this sequence: where the controller cannot reduce residual risks to an acceptable level through appropriate measures, prior consultation is required. (European Data Protection Board)

Thus, the DPIA is not the final destination.

It may lead to regulatory consultation.

130. The relationship between Article 35 and accountability

The ultimate significance of Article 35 can be summarised as follows:

Article 5(2)

Be accountable.

Article 24

Implement measures and be able to demonstrate compliance.

Article 25

Build privacy into the processing.

Article 32

Secure the processing according to risk.

Article 35

Where risk is high, systematically assess it before processing begins.

Article 36

If serious risk remains unmitigated, consult the regulator.

This makes Article 35 a central operational component of GDPR accountability.

131. Final synthesis

Article 35 should ultimately be understood through five questions.

First, What are we doing?

The controller must understand and document the processing in sufficient detail.

This requires mapping:

• data;

• people;

• systems;

• purposes;

• recipients;

• technologies;

• retention;

• transfers.

Second, Do we really need to do it?

The controller must assess:

• necessity;

• proportionality;

• minimisation;

• alternatives.

A business objective does not automatically justify intrusive processing.

Third, What could happen to people?

The controller must examine risks to:

• privacy;

• autonomy;

• dignity;

• equality;

• reputation;

• finances;

• physical safety;

• psychological wellbeing;

• legal rights;

• access to services.

Fourth, What can we do about those risks?

Safeguards must be:

• specific;

• technically realistic;

• organisationally enforceable;

• legally appropriate;

• demonstrably effective.

And residual risk must be assessed after implementation.

Fifth, What happens next?

The organisation must decide whether to:

• proceed;

• modify the processing;

• impose conditions;

• conduct further assessment;

• consult the DPA;

• or abandon the processing.

132. The single most important lesson from Article 35

The biggest mistake is to think of a DPIA as a document.

It is better understood as a process of disciplined decision-making.

A 100-page DPIA that does not change the project can be worse than a 20-page DPIA that genuinely identifies a problem and causes the organisation to redesign its system.

The real test of a DPIA is therefore not:

“Did we complete the form?”

It is:

“Did the assessment meaningfully influence how the processing was designed, whether it was necessary, how risks were mitigated, and whether the organisation should proceed?”

That is the core of Article 35.

A sophisticated controller should consequently treat the DPIA as a privacy engineering, legal, governance and risk-management instrument simultaneously.

It begins before processing.

It examines the entire processing lifecycle.

It considers not merely cybersecurity but the full spectrum of risks to human rights and freedoms.

It challenges the necessity of intrusive processing.

It forces consideration of less intrusive alternatives.

It involves the DPO.

Where appropriate, it involves affected individuals.

It records safeguards.

It identifies residual risk.

It can trigger Article 36 prior consultation.

And it does not end when the document is signed: Article 35(11) requires continuing attention when the risks change.

In short, Article 35 transforms privacy from a purely reactive compliance exercise into an ex-ante risk-management discipline.

That is why it is one of the most important accountability provisions in the GDPR.

The strongest practical formulation is therefore:

Do not ask merely whether the processing is lawful. Ask whether it is necessary, proportionate, sufficiently safe, fair, explainable, controllable, and defensible in light of its consequences for the people subjected to it. Then document that reasoning before the processing begins, implement what the assessment requires, and revisit the assessment whenever the risk materially changes.

That is the real meaning of a DPIA under Article 35. (European Data Protection Board)