In practice, people often say “GDPR risk assessment”, but the legal test under the UK GDPR is whether you need a data protection impact assessment before you start processing. The question is not whether a project feels sensitive. It is whether the processing is likely to create a high risk to people’s rights and freedoms, based on the nature, scope, context and purpose of what you plan to do.
The ICO says you should use a screening step early in the project, not wait until the processing is already live. That matters because some projects are straightforward, but others involve red flags such as new technology, profiling, special category data, children’s data or systematic monitoring. If you are building that decision into the project plan, you are much less likely to miss the point at which a DPIA is required.
When a DPIA is required
ICO guidance on when to do a DPIA says you must carry one out where a type of processing is likely to result in a high risk to the rights and freedoms of individuals. That is a screening test. You do not need certainty that harm will happen. You need to ask whether the features of the processing point towards a real possibility of serious impact if things go wrong.
The ICO also says that “high risk” depends on both the likelihood and severity of possible harm. That means a project can trigger a DPIA because the harm would be severe even if it is not especially likely, or because the same harm becomes more likely at scale. For more detail on the regulator’s view of the process, see the ICO DPIA guidance and the EDPB DPIA guidelines.
Which processing usually triggers one
The safest way to think about this is to look for red flags rather than trying to tick a single box. The ICO’s list of processing likely to result in high risk includes several familiar patterns, and they often overlap in one project:
- new technology or novel use of personal data
- systematic and extensive profiling or automated decision-making
- large-scale processing of special category data
- large-scale monitoring of publicly accessible places
- use of children’s data or other vulnerable people’s data for marketing, profiling or similar uses
- biometric processing, such as fingerprints or facial recognition
If that list sounds familiar, the project probably needs a DPIA before launch. Our related articles on fingerprint data and facial recognition show how quickly a routine business use case can move into higher-risk territory.
How to decide in practice
The ICO’s practical guidance is simple: start early, describe the processing clearly, assess necessity and proportionality, identify risks, then set out mitigation measures. Their step-by-step approach is designed to force a real decision, not a paperwork exercise. If you want the official sequence, follow the ICO’s page on how to do a DPIA.
A useful internal rule is this: if the project would be hard to explain to a sceptical employee, customer or regulator in one sentence, stop and do the DPIA. That check is especially useful for marketing teams, HR teams and product teams, because those groups often move faster than the governance process around them.
What to do if the residual risk is still high
A DPIA is not automatically the end of the story. If, after mitigation, the residual risk is still high, the ICO says you must consult the regulator before you go ahead. If the measures you put in place reduce the risk so it is no longer high, you do not need to consult. That distinction matters, because it changes both the timetable and the sign-off route for the project.
You can read the ICO’s consultation guidance here: Do we need to consult the ICO? For teams that need a reusable decision trail, the ICO’s DPIA checklist is also worth using alongside the main assessment.
Common mistakes
- treating the DPIA as a form to fill in after launch
- assuming every project needs one, which makes the process meaningless
- looking only at the privacy policy and ignoring the actual processing design
- failing to involve the people who understand the system, the data and the business risk
- stopping at “we identified a risk” without documenting the mitigation and the residual risk
For teams that need to build this habit into day-to-day compliance work, our Measured Collective Plus subscription is the place to start. The point is not to produce more paperwork. It is to spot the projects where privacy risk needs to be designed out before the work goes live.
FAQ
Is a DPIA the same as a risk assessment?
Not exactly. A risk assessment is a broad business term. A DPIA is the specific UK GDPR process for assessing high-risk personal data processing before it starts. In practice, many teams use the terms loosely, but the legal trigger still sits under Article 35.
Do we need a DPIA for every new project?
No. The ICO’s screening approach is there to separate routine processing from processing that is likely to result in a high risk. A simple internal update, a low-risk system change or a small administrative process will not always need a formal DPIA.
Who should sign off the DPIA?
That depends on the organisation, but the sign-off should sit with someone who can actually accept the risk and fund the mitigation. In many cases that will be a senior manager, information asset owner or privacy lead, with the DPO advising where needed.
Sources
- UK GDPR Article 35
- ICO: When do we need to do a DPIA?
- ICO: How do we do a DPIA?
- ICO: Do we need to consult the ICO?
- ICO: Examples of processing likely to result in high risk
- EDPB DPIA guidelines
