Data Protection Impact Assessments Explained Simply

21 Apr

This post strips the jargon and legalese from the GDPR’s Data Protection Impact Assessments (DPIAs). Below is a simple guide for teams who know, or don’t know, that they should be doing them, and how best to approach them.

What is a DPIA? A Practical Way to Sense-Check Projects Using Personal Data

A DPIA is a risk management and regret prevention tool. DPIAs have been in the news recently, with the ICO fining Reddit and noting they hadn’t done one for data use affecting children, and the European Data Protection Board publishing a harmonised DPIA template.

A DPIA focuses on:

How your proposed new or changed activities will affect personal data
Whether these operations will give rise to a high risk to the rights of the people whose data you’re using
How you can mitigate these risks.

Controllers that decide what, why and how to use personal data are responsible for DPIAs.

A DPIA is not:

A policy (but you may have one for when to complete them)
A one-time form (you should update it if the processing or risk changes)
Something that the DPO does alone (the project owner completes the details, DPO reviews).

DPIAs have a bad name because they usually come at the end of a project, which makes data protection feel like a “blocker” and an annoyance. This is an error and a misconception – DPIAs should be done at the beginning of the project, or they lose their value.

Done early, the assessment embeds data protection and privacy by default, which is a key GDPR principle. In other words, when you use them as intended, you are ahead in your GDPR compliance game.

Sometimes, if the risks are high or the context is contentious, you may want to ask different people for their views on your processing. This is often the people whose personal data you will use, which builds your credibility.

If there are high risks that you can’t mitigate, it is a legal requirement to consult the regulator before proceeding. If you continue without doing this, you are in the red zone of noncompliance.

A DPIA doesn't necessarily make unlawful data use lawful, but it may help you decide this is the case. It will show that you have considered the implications, and not just gone ahead and hoped for the best.

You should ask your DPO for advice. They want you to do a DPIA and want to help you.

What is in a DPIA? Structured Thinking

A DPIA is a recorded thinking process, sometimes legally required by the GDPR, which helps you spot and address risks.

To achieve this, a skeleton structure of the assessment should include:

A description of what you want to do with the personal data
Why you are doing this and why no other way can help you achieve your goal
An overview of how the intended processing operations might affect the people whose data you plan to use
Ways to mitigate or eliminate those risks.

When we think about risks, we should think broadly: it could be financial loss, loss of control of data, fraud, but also inability to exercise other rights, loss of confidentiality, worse security or less choice. Both material and non-material damage should be included.

When Do You Need a DPIA? Best Practice or a Legal Requirement

The GDPR sometimes requires you to do a personal data risk assessment in cases that are considered as being high risk by default. A simple way to think about it is:

Legal requirement: high risk to people (e.g. children, special category data like health, new technologies, monitoring)
Best practice: new, unclear, or slightly uncomfortable use of personal data.

If you’d hesitate to explain it to a customer or employee, it probably needs a DPIA.

If you have done a DPIA when you didn’t technically need to, you are in a privacy-responsible mindset, and should stay there.

Examples of When It’s a Legal Requirement

HR: Monitoring employees or handling “sensitive” staff data

You’re introducing software to track employee activity, monitor performance, or process data like health or wellbeing information.
You’re dealing with high-impact, sensitive data in a context where people have less choice (employees).
The risks to individuals are higher, so this needs a DPIA.

Marketing: Using customer data for targeting or profiling

You’re setting up things like email segmentation based on behaviour, retargeting ads (e.g. custom audiences), combining data from multiple sources
It might feel like “normal marketing,” but you’re shaping how people are profiled and targeted — often in ways they don’t fully see. A quick DPIA helps avoid creepiness and complaints later.

I also wrote about a school installing CCTV in toilets requiring a DPIA, listing the reasons why.

Examples of When It’s Best Practice

Operations: Cleaning up or reorganising existing data

You’re migrating data between systems, merging duplicate records, changing how long you keep data
Why it’s worth a DPIA: it appears low risk, but mistakes here can lead to data loss, over-retention, or accidental exposure.

Internal tools: Giving teams broader access to data

You’re rolling out a new dashboard, expanding access to customer or employee data internally, making data easier to search or analyse
Why it’s worth a DPIA: the data isn’t new, but who can see it and how easily is changing. That’s where risk creeps in.

Common DPIA Mistakes to Avoid

In an ideal world, DPIAs are a tool, not a purely compliance step. They fail when they are:

Too long, too late, too legal
Seen as a tick-box exercise
Done by one person instead of the team
Written and signed off by Legal, with no team input or senior manager sign-off.

A Simple DPIA Checklist for Busy Teams

Use this as a quick sense-check before you launch.

1. Do we understand what we’re trying to do?

Can we explain the project in plain English (no jargon)?
Is the goal clear to someone outside the team?

2. Are we clear on what data we’re using?

What personal data is involved?
Do we actually need all of it?
Are we using it in a new or different way?

3. Could this surprise or concern people?

Would customers or employees expect this?
Would we feel comfortable explaining it openly?
Does it involve tracking, profiling, or monitoring?

4. What could realistically go wrong?

Could data be misused, lost, or seen by the wrong people?
Could this impact someone’s privacy, reputation, or opportunities?
Are we relying on a third party we don’t fully understand?

5. How are we reducing the risk?

Can we minimise the data we collect or share?
Are access controls and security in place?
Have we chosen the least intrusive option?

6. Who else should be involved?

Have we spoken to the right teams (e.g. legal, security, HR)?
Does this need input from a DPO or specialist?

7. Are we comfortable going ahead?

Have we documented the key decisions?
Would we be happy to stand behind this if questioned?
If not, what needs to change?

If you’re unsure, pause and do a light-touch DPIA. If it feels uncomfortable, definitely do one.

You may find that splitting this into a two-step process: 1) to understand if the processing is likely to be high risk (pre-DPIA step), and 2) if the answers to 1) point to high risk and therefore legally required, you can continue to a full assessment.

DPIAs Summarised

Teams often do DPIAs in their head, when they talk to each other and discuss a new tool, new project, and ask questions about what data is needed and how it will be used.

As soon as this is written down, inviting the DPO to contribute and getting a senior team member to approve the processing, the team has produced evidence of GDPR accountability and done something sensible for the personal data used.

Use them early, do them lightly at the beginning if needed, and complete them for full compliance when required.

Sofia Carroll