A privacy review checklist for schema changes and pull requests

A privacy review in code review asks six questions whenever a pull request adds or moves personal data: why, how little, how long, who can see it, who else gets it, and how it is deleted. Put them in the pull request template so they are answered every time, not only when someone remembers.

When to trigger it

Trigger the checklist when a change does any of these:

• Adds a column, field or event property that could identify a person.
• Adds an SDK, integration or webhook that sends data off your systems.
• Changes who can read a data set.
• Creates a new log, cache, export or report that includes personal data.
• Changes retention or deletion behaviour.

You can detect many of these automatically, such as migrations that add columns or changes to dependency manifests, and apply a label that requests the review.

The six questions

1. Purpose. What is this data for? Is the purpose recorded and consistent with what users were told? Article 5(1)(b) wants specified, explicit and legitimate purposes.
2. Minimum. Is each field needed? Could a coarser value do, such as age band instead of date of birth? Article 5(1)(c).
3. Retention. How long do we keep it, and what job enforces that? Article 5(1)(e). No period, no merge.
4. Access. Who and which services can read it? Is access role based and logged? Does anything expose it by default?
5. Recipients. Does it leave our systems, to a vendor, partner or another region? Is that recipient in the inventory?
6. Deletion and export. Can we find and delete or export this person's data across every place it lands? Is it in the data map?

Add the code level checks

• Is the data class tagged on the new column?
• Are logs free of the new fields?
• Do tests cover deletion and export of the new data?
• Does the response schema avoid returning it to clients that do not need it?
• Is encryption or tokenization applied where the sensitivity calls for it?

Keep it light

A heavy form gets ignored. For low risk changes, three checkboxes and a sentence are enough. For high risk ones, such as sensitive categories or new profiling, route to the privacy lead and consider whether a formal assessment is needed. See do I need a DPIA.

Make it enforceable

Checklists in a template are advisory. A gate makes the important parts mandatory: a migration without a data class tag fails the check, a new outbound domain without an inventory entry blocks the merge.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a policy check can block a merge, and imagine a rule for your own required privacy tags.

Quick check

Sources

• GDPR Article 5

Last reviewed: 19 October 2026.