Most GDPR programmes spend too much time producing artefacts and not enough time proving judgement.
Somewhere along the way, privacy compliance became a document factory. Another policy. Another register. Another DPIA filed in a folder nobody opens.
But that is not what the law asks for.
UK GDPR asks for something more practical and more uncomfortable: that organisations make sound, risk-based decisions about how they use personal data, put appropriate measures around those decisions, and show their working afterwards. Article 5(2) says the controller must be responsible for, and be able to demonstrate, compliance. Article 24 goes further, requiring appropriate technical and organisational measures that can be demonstrated. The ICO’s accountability guidance is blunt: accountability is not a box-ticking exercise.
The question is not “do we have the paperwork?”
The question is “can we show that someone thought properly about the privacy risk, challenged the design, made a reasoned decision, and recorded why?”
Documentation matters. But it matters because it is the trace left behind by governance, not because the document itself is a control. The ICO’s guidance points organisations toward practical measures: records of processing, contracts with processors, security measures, breach records, data protection by design and default, and DPIAs where high-risk processing is involved. Records should be granular, meaningful and kept up to date, and organisations should be able to use them to demonstrate accountability.
That is a different mindset from “complete the template and move on.”
When regulators look at something after the event, they are not checking whether you were broadly well-intentioned. They are checking whether your decisions can be followed, tested and defended.
DPIA is a risk tool, not a compliance receipt
A DPIA is not a ceremonial form you complete once the project team has already decided what it wants to do. It is not a receipt you staple to the file to prove privacy has been “covered.” And it is not a certificate that makes intrusive processing lawful.
The ICO defines a DPIA as a process to help identify and minimise data protection risks. It must describe the processing, assess necessity and proportionality, identify and assess risks to individuals, and identify measures to mitigate those risks. Critically, it should start early and run alongside planning and development, because its purpose is to influence the project, not document it afterwards.
That wording matters.
A DPIA is where an organisation forces itself to answer the awkward questions before go-live. What exactly are we doing, why is it necessary, why is it proportionate, what could go wrong for the people affected, what reduces that risk, what residual risk remains, and can we justify it?
A good DPIA is useful precisely when it is inconvenient. Its job is not to confirm the project team was right all along. Its job is to expose weak assumptions early enough that they can still be challenged.
What a retrospective DPIA actually looks like
I was auditing a company’s data protection compliance as part of a wider organisational review. They had DPIAs. Nicely formatted. Complete. Filed in the right place.
The problem was obvious within about ten minutes.
The metadata told the story before the content did. The project had launched eighteen months earlier, but the DPIA file had been created three weeks before we arrived. There was no version history. No drafts. No comments from the design phase. Just a single clean document, Version 1.0, that read like someone had reverse-engineered the assessment from the finished system.
That is what a retrospective DPIA looks like. And once you know the pattern, you see it everywhere.
A genuine DPIA leaves marks on the project. You can see where requirements changed because a risk was identified. You can see rejected ideas. You can see the DPO’s input dated during design, not bolted on at the end. When I check project board minutes from the early stages, data protection should be on the agenda. If it is not, the DPIA was not shaping the work. It was decorating it.
The tells are sometimes in the writing itself. Retrospective DPIAs slip into past tense. “We ensured data was encrypted.” A real DPIA written during development says “we will encrypt” because the decision has not happened yet. And they tend to be generic where a live assessment would be specific, because the author is working from the finished product rather than grappling with actual design choices.
The test I use is simple. I ask the project manager: can you show me a version of the system architecture from before this risk was mitigated? If they cannot, the DPIA did not drive the design. Someone wrote it afterwards and hoped nobody would check.
The under-read ICO case most teams should know: Chelmer Valley High School
If you want a case that makes the point cleanly, use Chelmer Valley High School.
It is not one of the blockbuster enforcement stories. That is why it is useful.
In July 2024, the ICO reprimanded Chelmer Valley High School after it introduced facial recognition technology for cashless catering without completing a DPIA beforehand. The school started processing biometric data from around 1,200 pupils in March 2023. No prior risk assessment. No DPO involvement. No proper consultation with parents or students. Consent was assumed through an opt-out letter rather than obtained through explicit opt-in.
The school later completed a DPIA and submitted it to the ICO in January 2024. But the ICO still focused on the fact that it had not been done before the processing started.
That is the lesson.
The ICO’s reprimand noted that had the school sought advice from its DPO, many of the compliance issues would have been identified before processing began. The structured privacy challenge had not happened when it needed to. A later tidy-up did not undo that gap.
This is a school, not a multinational. The technology was a canteen payment system, not a surveillance platform. And still the regulator treated the missing early-stage DPIA as a real compliance failure. That should make any organisation running a new data processing project pause and check whether their own DPIA happened upstream or after the fact.
The heavier backstop: the Home Office GPS tagging enforcement
If Chelmer Valley is the clean illustration, the Home Office migrant GPS tagging enforcement notice is the forensic one.
In February 2024, the ICO issued an enforcement notice after finding serious deficiencies in the Home Office’s DPIA for a pilot scheme that fitted GPS ankle tags to up to 600 migrants on immigration bail. The ICO found the Home Office could not adequately explain why it was necessary or proportionate to collect, access and use location data continuously. Staff guidance did not provide sufficient direction on when monitoring would be necessary and proportionate. Privacy information provided to those affected contained gaps and was inconsistent.
The critical finding was that the DPIA lacked sufficient detail to do its job. The ICO said the level of detail was not commensurate with the nature, context and scope of the processing. Without that detail, the Home Office could not rely on the DPIA to demonstrate compliance with Article 5(2). A weak DPIA left the organisation unable to demonstrate compliance at all.
That is the enforcement signal most organisations underestimate. A DPIA that exists but lacks rigour is not a partial pass. In the right circumstances, it is no better than not having one.
The shift
If you want GDPR to work properly inside an organisation, stop treating documentation as the finish line.
Use records of processing to show what is happening and why. Use governance records to show who approved what and on what basis. Use DPIAs for what they are meant to be: risk tools that challenge projects early enough to change them.
The form is not the control. The reasoning behind it is. And if you cannot show that reasoning existed before the processing started, you do not have privacy governance. You have privacy paperwork.
If you ran a DPIA in the last twelve months, go back and check one thing: can you find evidence that it changed a decision? If you cannot, it is worth asking what it was actually for.
ICO Guidance Sources:
- ICO Accountability Principle — Article 5(2) and the requirement to demonstrate compliance https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/accountability-principle/
- ICO Guide to Accountability and Governance — accountability is not a box-ticking exercise; proactive, organised, able to evidence steps taken https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/
- ICO Accountability Framework — audit toolkits and control measures for demonstrating compliance https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/accountability-framework/
- ICO DPIA Guidance (detailed) — definition, process, requirements under Article 35 https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
- ICO — What is a DPIA? — process to systematically analyse, identify and minimise risks; should begin early and run alongside planning https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/what-is-a-dpia/
- ICO — How do we do a DPIA? — steps, DPO involvement, stakeholder consultation, keeping under review https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/how-do-we-do-a-dpia/
- ICO — Data protection impact assessments (Guide to Accountability) — brief overview within the accountability guide https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/data-protection-impact-assessments/
Enforcement Cases:
- ICO — Chelmer Valley High School Reprimand (July 2024) — enforcement action page https://ico.org.uk/action-weve-taken/enforcement/2024/07/chelmer-valley-high-school/
- ICO — Chelmer Valley Press Release (July 2024) — media centre announcement with detail on FRT, consent, DPO involvement https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2024/07/essex-school-reprimanded-after-using-facial-recognition-technology-for-canteen-payments/
- ICO — Home Office Enforcement Notice (March 2024) — enforcement action page for GPS electronic monitoring pilot https://ico.org.uk/action-weve-taken/enforcement/2024/03/home-office/
- ICO — Home Office Press Release (March 2024) — media centre announcement with detail on DPIA deficiencies, necessity and proportionality findings https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2024/03/ico-finds-the-home-office-s-pilot-of-gps-electronic-monitoring-of-migrants-breached-uk-data-protection-law