Many organisations treat a data protection impact assessment, or DPIA, as paperwork: a form completed at the end of a project to tick a compliance box. That is the surest way to make it useless. Done at the right moment, a DPIA is one of the cheapest design tools you have, because it finds problems while they are still easy to fix.
What the law requires, in plain terms
Under Article 35 of the UK GDPR, you must carry out a DPIA before you start processing that is "likely to result in a high risk to the rights and freedoms" of individuals, particularly where it uses new technologies. The Article lists cases where one is particularly required, including large-scale processing of special category data such as health information, systematic and extensive profiling that leads to significant decisions about people, and systematic monitoring of publicly accessible areas on a large scale.
The Article also sets the minimum content: a description of the processing and its purposes, an assessment of whether it is necessary and proportionate, an assessment of the risks to individuals, and the measures you plan to address those risks. Nothing in it requires a long document.
The ICO is clear about the spirit. Its accountability guidance says: "Accountability is not about ticking boxes." And its guidance on data protection by design says it is "better to think about data protection issues from the start rather than at the end."
Why "paperwork" DPIAs fail
- They are written after the decision. If the system is bought and the launch date set, nobody can say "not like this", so the DPIA becomes a justification rather than an assessment.
- They describe the supplier, not you. A supplier's generic assessment says nothing about your data, your patients or customers, or how you will use the tool.
- They list risks without owners. A risk register with no named person and no date does not reduce anything.
- They sit in a drawer. The DPIA is not revisited when the product changes.
The ICO's seven steps, made practical
The ICO describes a DPIA in seven steps. Here is what each looks like in a small organisation.
- Decide whether you need one. Ask: does this involve special category data, large scale, new technology, profiling, monitoring, or children? If yes, do it. If no, write down why not.
- Describe the processing. One page: what data, from whom, for what purpose, where it goes, who sees it, how long you keep it. A simple diagram of data flows helps enormously.
- Consult the people affected. Where practical, ask staff, customers, pupils or patients what they expect and what worries them. Even five conversations can change a design.
- Consult others. Your data protection officer if you have one, your IT and security lead, and the supplier.
- Assess necessity and proportionality. Could you achieve the purpose with less data, less access or a shorter retention period?
- Identify and assess the risks. Think about harm to people, not to the organisation: embarrassment, distress, discrimination, fraud, loss of control. Rate each for likelihood and severity.
- Identify measures and conclude. For each risk, record what you will do, who owns it and by when. State the conclusion plainly: go ahead, go ahead with changes, or do not proceed.
If, after your measures, a high risk remains that you cannot reduce, UK GDPR Article 36 requires you to consult the ICO before you start processing.
A worked example
A membership body wants to add a feature to its website that suggests events based on members' browsing and attendance history. The team assumes this is low risk. A short DPIA changes the design in three ways.
Step 2 shows the feature would use data collected for a different purpose, so the privacy notice must change. Step 5 asks whether it needs browsing history at all, and the team decides attendance history alone does the job, which removes the tracking element and the cookie question. Step 6 spots that members in sensitive professions could be revealed by the events recommended on a shared screen, so the team adds a setting to turn recommendations off.
The feature launches two weeks later than planned and with a simpler build. The DPIA did not stop the project. It improved it. (An invented example, for illustration.)
Making DPIAs proportionate
Not every DPIA needs a template running to 30 pages. For a small project, three to five pages is enough if the thinking is honest. A useful rule: spend more effort where more could go wrong for people. Record screening decisions using a screening assessment for lower-risk tools, and keep full DPIAs for the projects that need them.
Four habits that keep DPIAs useful
- Put a DPIA screening question into every project kick-off and every purchase request.
- Give someone with authority the right to pause a launch until the DPIA is done.
- Review DPIAs when the product, supplier or use changes, and at least annually for high-risk processing.
- Keep the DPIA short enough that the people who run the system can actually read it.
Frequently asked questions
Is a DPIA a legal requirement? Where processing is likely to result in a high risk, yes. For lower-risk processing it is good practice, and recording why you decided one was not needed is sensible.
Who should write it? Whoever best understands how the system will be used, supported by your data protection officer or adviser. The controller remains responsible.
How long does it take? For a typical small business tool, a few hours spread across a few days. For major projects, longer.
Can we use the supplier's DPIA? It is a helpful input, but you still need to assess your own use.
Do we publish it? There is no legal duty to publish, though sharing a summary can build trust.
How Pathway 2 Privacy can help: a DPIA service gives you a proportionate assessment, run alongside your project team so it shapes the design rather than following it. Data Protection by Design support helps you build a screening step into the way you buy and build. See our GDPR support for professional services and our DPIA guide for GP practices, or start with a free data protection review.
Sources: UK GDPR Article 35; ICO guidance on DPIAs; ICO guidance on data protection by design and by default; ICO Accountability Framework.
