Any activity likely to result in high risk to individuals, such as profiling, tracking, large-scale processing, sensitive data use, or cross-border transfers.

“Likely high risk” is assessed before harm occurs, not after.

You should treat risk as high when:

• The impact could be significant, even if uncertain

• The processing involves sensitive data or large-scale analysis

• Individuals may lose control or visibility over their data

GDPR Article 35 focuses on likelihood and severity together, while Article 35(3) explicitly identifies cases such as automated decision-making, large-scale sensitive data processing, and systematic monitoring.

If you are unsure, the safer and more defensible position is to conduct a DPIA.

Mitigation measures allow you to proceed only if they reduce risk to an acceptable level.

A DPIA must define safeguards under Article 35(7), including technical and organisational measures. But if high risk remains after mitigation, Article 36 requires consultation with the supervisory authority.

This is where many organisations misstep. Having controls is not enough. You must be able to demonstrate that those controls are effective.

If the risk cannot be reasonably reduced, proceeding is not a business decision. It becomes a regulatory issue.

Necessity means the purpose cannot reasonably be achieved with less intrusive means.
Proportionality means the impact on individuals is balanced and justified.

Under Article 35(7) and Article 25, you need to:

• Map each data input to a specific purpose

• Challenge whether all data and automation are required

• Consider less intrusive alternatives

• Implement safeguards such as human oversight where decisions have significant effects

This is not just a technical exercise. It is a documented judgment call that must stand up to scrutiny.

A DPIA must be revisited when the risk profile changes.

Typical triggers include:

• New data categories

• New user groups

• New technologies or models

• Expanded scope or use cases

Article 35(11) requires review when risk changes, and Recital 89 highlights new technologies and time as key factors.

If the change affects how risk is created or managed, you are no longer operating under the original DPIA.

Vendor input can support your DPIA, but it cannot replace it.

Under Article 5(2), accountability remains with the controller. Article 28 requires that processors provide sufficient guarantees, and Article 28(3) confirms they must assist with DPIA obligations.

In practice:

• Vendors provide inputs

• Controllers make the final assessment

Relying blindly on vendor documentation is a common failure point, especially in AI deployments.

Consultation is required when high risk remains after mitigation.

Under Article 36, if risks cannot be reduced to an acceptable level using available measures, you must consult the supervisory authority before proceeding.

Recital 94 clarifies that this applies where risk cannot be mitigated by reasonable means.

This is not optional. It is often avoided in practice, but regulators expect it in high-risk scenarios.

While the concept is more explicitly defined in the EU AI Act, it aligns closely with GDPR risk thinking.

You should:

• Identify realistic misuse scenarios based on user behaviour

• Assess their likelihood and impact

• Define mitigation measures

• Reflect these scenarios in documentation and instructions

In AI systems, misuse is not theoretical. It is expected.

A strong DPIA anticipates not just how a system is intended to be used, but how it might realistically be misused and what that means for risk.

Each purpose must have a clear and valid legal basis under Article 6.

You should:

• Define each purpose separately

• Assign the appropriate legal basis to each

• Assess compatibility if purposes evolve (Recital 50)

What you should not do is mix legal bases in a way that weakens accountability.

For example, combining consent with a legal obligation for the same activity creates confusion and risk. Clarity is critical.