You need a data protection impact assessment under GDPR Article 35 before starting processing that is likely to result in a high risk to people's rights and freedoms. The article names three cases, and regulators publish their own lists of further examples, so check your national authority too.
The three cases named in the article
A DPIA is specifically required for:
- Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, where decisions produce legal or similarly significant effects.
- Large scale processing of special category data (such as health data) or data about criminal convictions and offences.
- Systematic monitoring of a publicly accessible area on a large scale.
Outside those, the test is still "likely high risk", judged by the nature, scope, context and purposes of the processing. Supervisory authorities must publish lists of operations that need a DPIA and may publish lists of those that do not.
A screening checklist for product teams
Ask these questions when a feature enters planning, not when it ships:
- Does it score, rank or profile people in a way that affects access, price or opportunity?
- Does it handle health, biometric, political, religious or similar sensitive data at scale?
- Does it watch people continuously, in a public space or online?
- Does it combine datasets in a way people would not expect?
- Does it involve people who are less able to object, such as children or employees?
- Does it use a new technology whose privacy effects are not well understood?
Items 4 to 6 are screening prompts, not text from Article 35. Treat them as reasons to look closer and check your authority's list. If you answer yes to several, run the assessment.
What the assessment must contain
Article 35 sets a minimum of four parts:
- A systematic description of the processing and its purposes, including any legitimate interest relied on.
- An assessment of necessity and proportionality.
- An assessment of the risks to individuals.
- The measures planned to address those risks, including safeguards and security measures.
Where you have a data protection officer, you must seek their advice. Where appropriate, seek the views of the people affected. Review the DPIA when the risk changes, for example when you add a new data source.
Keeping it useful
A DPIA that lives in a shared drive and never changes a design decision has failed. Aim for a short document that records one thing at least: what the team changed because of it. Link it to the record of processing and to your security controls so that reviewers can follow the trail.
One DPIA can cover a set of similar processing operations that share similar risks, so you do not need a new document for every minor variation.
Quick check
Does a DPIA need approval from the regulator?
Article 35 itself does not describe that step. Prior consultation sits in Article 36, so read it if the residual risk stays high.
Who should write it?
The controller is responsible, but product, engineering and security input makes it accurate.
Safeguard's compliance and evidence automation can hold the control evidence a DPIA points to, such as access policies and scan results. The judgment about risk remains yours.
Sources
Last reviewed: 19 October 2026.
