Articles / Privacy

921 words

  • privacy
  • uk-gdpr
  • dpia
  • privacy-by-design
  • ci
  • code-review

Why Your Privacy Impact Assessment Should Be a Pull Request Check

Most data protection impact assessments are accurate on the day they are signed and wrong a month later. Someone adds a column, a new analytics call or a third-party SDK, and the document in the shared drive says nothing about it. It describes a system that no longer exists.

The fix is not a better document. It is moving the trigger for the review to the place where the change actually happens: the pull request.

What the law actually asks for

"Privacy impact assessment" is the older, informal name. The term in UK GDPR is a data protection impact assessment (DPIA), and it lives in Article 35. The relevant parts are short:

  • Article 35(1): a DPIA is required before processing that is likely to result in a high risk to individuals.
  • Article 35(7): it must describe the processing, assess necessity and proportionality, assess the risks, and set out the measures to address them.
  • Article 35(11): the controller must review it where the risk represented by the processing changes.

That last one is the point. The law expects the assessment to stay in step with the processing, not to be written once and forgotten. The ICO's DPIA guidance describes it as an ongoing process. That is regulator guidance rather than legislation, but it is how the regulator reads the Article.

Article 25 (data protection by design and by default) pulls the same way: build the safeguards in at the time you decide how to process, not after.

Why a document drifts and a check does not

A DPIA kept as a PDF has no connection to the repository. Nothing fails when the code diverges from it. Developers are not being careless; there is simply no moment where the question gets asked.

A pull request is that moment. It is already where you ask "does this break anything?", and it already has reviewers, a diff and a record of who approved what. Privacy review there costs a few minutes. Privacy review a quarter later costs an audit.

Which changes should trigger a review

Not every diff is a privacy event, and a check that fires on everything gets ignored within a week. Aim at changes that alter what personal data you hold, why, or who sees it:

  • schema migrations that add tables or columns
  • new outbound HTTP destinations or SDK dependencies
  • changes to logging, analytics or tracing configuration
  • changes to retention jobs, or their removal
  • new roles or access to existing data stores

Whether a particular change makes processing "high risk" is a judgement call. The Article 35(3) examples and the ICO's list of processing that always needs a DPIA are the starting point; the check only decides whether a human should look.

A check that is deliberately dumb

Here is a shell script that fails a pull request when a migration adds a column or table, unless the same PR also touches the data inventory file. It does not understand personal data. It just forces the conversation.

#!/bin/sh
# privacy-check.sh: run in CI with the base branch fetched
set -eu

base="${1:-origin/main}"
inventory="docs/data-inventory.md"

added=$(git diff "$base"...HEAD --unified=0 -- 'migrations/*.sql' \
  | grep -Ei '^\+.*(create table|add column)' || true)

[ -z "$added" ] && exit 0

if git diff --name-only "$base"...HEAD | grep -qx "$inventory"; then
  exit 0
fi

echo "Migration adds data but $inventory was not updated:"
echo "$added"
echo "Update the inventory (purpose, lawful basis, retention) or explain in the PR why not."
exit 1

Three things to know about it:

  • git diff base...HEAD with three dots compares against the merge base, so unrelated changes on main do not show up.
  • CI checkouts are often shallow; fetch enough history for the merge base to exist or the diff errors out.
  • It will miss things, such as a column added by an ORM auto-migrate. That is fine. A cheap check that catches 70% beats a perfect one nobody writes.

Quick detour: why the inventory file, not the DPIA?

Hang on, why check an inventory rather than the DPIA itself? Because a DPIA is a prose risk assessment and you cannot meaningfully diff it per change. The inventory is the small, structured layer underneath: what data, why, on what basis, kept for how long, shared with whom.

The DPIA then references the inventory. When an inventory row changes in a way that shifts the risk, that is the cue to revisit the assessment, which is exactly what Article 35(11) describes.

Give the PR a template and an owner

The script catches the mechanical cases. For the rest, a pull request template with three questions does most of the work:

  1. Does this change collect, store or share personal data in a new way?
  2. If yes, which inventory row changed, and does the DPIA need revisiting?
  3. If no, one line saying why not.

Then add a CODEOWNERS entry for the inventory and DPIA files, so a named person (your DPO, if you have one, or whoever holds the privacy hat) is requested as reviewer automatically. If you do have a DPO, Article 35(2) requires you to seek their advice when carrying out a DPIA, so this is the natural route.

What this does not do

A green check is not compliance. It cannot judge necessity, proportionality or whether your lawful basis holds up. If residual risk stays high after mitigation, Article 36 requires prior consultation with the ICO, and no CI job replaces that conversation.

It also does nothing for processing that starts outside the repository, such as a new spreadsheet export or a vendor switched on from a dashboard. Those need a procurement and change-management route of their own.

What you get instead is smaller and more useful: the assessment stops being a snapshot and becomes something the team trips over while the change is still cheap to alter. Whether a given system needs a full DPIA depends on the processing, so treat this as engineering practice and not legal advice.

← All articles