What to Do After a DPIA

After a DPIA, write down what would make it out of date: a new data source, a new use for the data, a new location, or new people with access. Agree that any of those reopens the assessment before the processing changes, not after.

On 11 August 2020 the Court of Appeal declared that South Wales Police's live facial recognition was not in accordance with the law, and that, as a consequence, its data protection impact assessment did not comply with the Data Protection Act 2018. The legal flaw was officers' wide discretion over who went on each watchlist and where the cameras went, choices remade at every deployment.

A data protection impact assessment (DPIA) is the documented analysis, required before high-risk processing of personal data, of that processing's necessity, risks and safeguards.

A properly run DPIA puts necessity, risk and safeguards on the record

Article 35 of the General Data Protection Regulation requires a controller to assess processing before it starts where the processing, "in particular using new technologies", is likely to result in a high risk to people's rights and freedoms. The UK GDPR carries the same duty, and section 64 of the Data Protection Act 2018 applies an equivalent rule to police and other law enforcement processing.

Article 35(7) sets the minimum content. There must be a systematic description of the processing and its purposes, an assessment of whether it is necessary and proportionate, an assessment of the risks to the people affected, and the measures chosen to deal with those risks. Each part does real work. Writing out the data flows exposes collection nobody meant to design in. The necessity test asks whether a less intrusive route would serve the same purpose.

The process also brings in other people. The controller must seek the advice of its data protection officer, where one is designated. If the assessment shows a high risk the chosen measures cannot bring down, Article 36 requires prior consultation with the supervisory authority before processing begins. The ICO's guidance on how to do a DPIA ends its seven steps with sign-off and a record of outcomes: which risks were eliminated, reduced or accepted, and what residual risk remains.

The result is a document with value well beyond compliance. It shows a regulator that the questions were asked before the system went live. It records who accepted which risk. It gives later reviewers a baseline, and it fits inside a wider risk assessment cycle without much translation.

Compared with a line on a register produced by risk identification, a DPIA is specific: this data, these people, this purpose, these safeguards. That specificity is its strength, and it rests on one section. Every risk rating and every mitigation is reasoned from the description of the processing, which makes that description the anchor for every other finding.

Take the processing description in your DPIA, write down the first change that would make it wrong, and decide who will notice when it happens. Start the Walk →

Does the processing on the page stay the processing that runs?

A signed DPIA assumes that the system it describes is the system that will operate. The watchlist, or its equivalent, stays within the stated categories. The sites stay within the stated scope. The vendor's model is the version that was assessed. Data volumes stay near the estimate, the people affected are the people considered, and the purpose does not widen. None of these assumptions is written down as an assumption. Each sits inside the description as a fact.

The law expects change. Article 35(11) requires a review, "where necessary", to check that processing matches the assessment "at least when there is a change of the risk represented by processing operations." The Article 29 Working Party's DPIA guidelines (WP248 rev.01), endorsed by the EDPB, call the DPIA "a continual process, not a one-time exercise." The ICO says it may need repeating after "a substantial change to the nature, scope, context or purposes" of the processing. For an international transfer, the follow-up to a transfer impact assessment matches unresolved findings to the actual recipient and the contract that governs the transfer.

All three describe the duty. None names the change. The Regulation offers no concrete trigger, and the guidance leaves each controller to decide what counts as substantial. Left undefined, that call falls to whoever happens to notice a change, if anyone does.

The gap is sharpest where a third party controls part of the system. A supplier can retrain a model, add a data source or change a matching threshold between releases, and the controller learns of it through a release note, if at all. A vendor risk assessment covers the supplier on the day it was done. The DPIA inherits that date. The open question is who notices, and when.

South Wales Police and one map for fifty journeys

South Wales Police was the national lead on trialling automated facial recognition, using NEC's NeoFace Watch software. The Court of Appeal's judgment in R (Bridges) v Chief Constable of South Wales Police records about 50 deployments of its AFR Locate system between May 2017 and April 2019. Cameras on police vans or poles compared passing faces against a watchlist prepared for each deployment. Around 500,000 faces may have been scanned in 2017 and 2018.

Ed Bridges, a civil liberties campaigner, said he was caught on camera twice: on Queen Street in Cardiff on 21 December 2017, and at a protest outside a defence exhibition at the Motorpoint Arena on 27 March 2018. The watchlists differed. At Queen Street they included 382 people wanted on warrants and 536 suspects. At the arena they included 347 people wanted on warrants, 161 suspects and people arrested at the same event the previous year.

The force had a privacy impact assessment, an April 2017 equality impact assessment and, under the 2018 Act, a DPIA. In September 2019 the Divisional Court dismissed the claim, finding the DPIA met section 64. The Court of Appeal disagreed. It held that too much discretion was left to individual officers over who could be placed on a watchlist and where the system could be deployed.

The DPIA proceeded on the basis that Article 8 privacy rights were not infringed. Given that open discretion, the court found it "failed properly to assess the risks to the rights and freedoms of data subjects." On location, the DPIA said the force had "deployed in all event types ranging from high volume music and sporting events to indoor arenas." The court called that descriptive, setting no limit on where the system could go.

The equality finding followed the same shape. It was common ground that there had been no further Equality Impact Assessment since April 2017. The force had never checked, directly or independently, whether the software carried an unacceptable bias on race or sex, and the manufacturer would not disclose the details needed to test it, citing commercial confidentiality. The court said a trial made gathering that information "all the more important."

Monitoring was not the court's framing. Yet each finding concerned something that moved while the paperwork stood still: the watchlist, the venue, an algorithm never tested for bias. The ethics of algorithmic decisions are usually argued at approval. Here the exposure built up across deployments that each looked routine.

Before filing, write down what would make the description wrong

The artefact is one page appended to the DPIA's description of the processing. Each line names a change that would make the description inaccurate, the person placed to notice it, and what happens next: a check against the assessment before the next deployment, launch or release. It turns the DPIA from a record of approval into a working instrument for monitoring.

Write each line so a named owner can answer it yes or no. "Material change" is not a line. "Any watchlist category not listed in section 2" is. Then attach the check to a date that already exists in the project: the deployment plan, the change board, the vendor's release calendar. That is where the distinction between governance and compliance shows up in practice.

Deciding in advance what to watch, and which result would change the decision, belongs before approval, not after an incident. It is a distinct step in the Universal Decision-Making Method, taken before anyone signs.

---

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.