GDPR as engineering controls, not legal theory

The gap that costs money is not between a company and the regulation. It is between the privacy notice the legal team wrote and what the systems actually do. The notice says support tickets are kept for two years. The ticketing system has never deleted anything, the analytics warehouse has a copy of every ticket body, and the nightly database backup from four years ago is still in an object storage bucket with no lifecycle rule.

Nobody lied. The notice described an intention and nobody translated it into a retention job. That translation is the whole of GDPR compliance from an engineering perspective, and there are six places it has to happen.

Know where the data is before anything else

The record of processing activities is a legal document that most companies write from memory, which is why it is wrong. Build it from the systems instead.

List every datastore, every third-party service that receives data, and every export. For each, answer four things: what categories of personal data are in it, why you hold them, how long you keep them, and who it goes to. Data discovery tooling helps on large estates, and every major cloud has a service that classifies fields in a database or a bucket, but on a small estate an afternoon with the engineering leads produces a better list than a year of survey emails.

The rows that surprise people are always the same: the analytics warehouse, the logging platform, the CRM, the support tool, the backup bucket, and a spreadsheet on somebody's drive. Special category data, meaning health, biometrics, political opinions and the rest, raises the bar significantly, so flag it explicitly when it appears.

Lawful basis is a field, not a paragraph

Every processing activity needs a basis, and the basis determines what you have to build.

Consent means you need a consent record with a timestamp, a version of what was agreed to, and a mechanism to withdraw that is as easy as giving it. That is a table, not a checkbox. If you cannot produce the consent record for a specific user on a specific date, you do not have consent.

Legitimate interest means you need the balancing assessment written down and a working objection mechanism. Contract and legal obligation are the easiest to defend and cover most core product processing.

The engineering consequence is that consent state has to be readable by every system that acts on it, in real time. A marketing platform that syncs consent nightly will send an email to someone who withdrew this morning.

Minimisation and retention are jobs that run

Minimisation means not collecting the field in the first place, and it is cheaper than every control that follows. The date of birth you collect because the form template had it is a liability with no offsetting benefit.

Retention is where most estates fail. A retention rule that exists only in a policy document is not a control. It has to be a scheduled job with a dashboard, per data class, and it has to reach:

• The primary database, including soft-deleted rows that are still readable.
• Replicas and the analytics warehouse, which usually have their own copies and no deletion path.
• Logs, where personal data arrives accidentally through request bodies and error messages.
• Object storage, including exports and generated reports.
• Backups, which are the hard case.

On backups the defensible position is that you cannot surgically delete from an immutable backup, so you define a maximum backup retention window, document that a restore triggers re-application of deletions, and you actually implement that re-application. Saying "backups are out of scope" is not a position that survives a question. This is one of the places where privacy and a backup strategy that resists ransomware pull in opposite directions and the tension has to be resolved deliberately.

Data subject rights are an API, not an inbox

Access, rectification, erasure, restriction, portability and objection all arrive as a request with a statutory deadline of one month, extendable in limited circumstances. A manual process that takes two engineers three days works at ten requests a year and collapses at two hundred.

Build one function per right that operates across every system in your record of processing. The access request needs to return everything, which means it needs the same inventory as the retention job. Erasure needs to handle the legitimate exceptions, such as an invoice you are legally required to keep, and it needs to record what was kept and why. Portability needs a structured, machine-readable export.

Identity verification before you act is a control people skip. Deleting the wrong person's account because an attacker asked nicely is a worse breach than the one you were trying to prevent.

Access control is most of the technical measure

"Appropriate technical and organisational measures" is deliberately open, but in practice an auditor looks at the same list every time: who can read production personal data, is that access logged, is it time-bound, and is it reviewed.

Concretely: role-based access with the production data role held by few people, just-in-time elevation rather than standing access, an audit log of every read of a sensitive table that is itself protected from the people it logs, encryption in transit and at rest with managed keys, and pseudonymisation wherever the workload does not need the real identifier. Test environments should carry synthetic or masked data, because a production dump in a staging database is one of the most common findings we make.

Most of this is the same control set you already run for ISO 27001 or SOC 2, which is why it belongs in one control set mapped across frameworks rather than a separate privacy programme.

Processors, transfers and the 72-hour clock

Every vendor that touches personal data on your behalf is a processor and needs a data processing agreement, documented sub-processors, and a place in your inventory. Your customers will ask for your sub-processor list, and a change to it usually carries a notice obligation. The engineering half of this is knowing which vendors receive data, which is harder than it sounds once a frontend loads six third-party scripts.

Transfers outside the EEA need a mechanism and, in most cases, a transfer impact assessment. The mechanics and the current state of the frameworks are their own topic, covered in where your data actually sits.

Breach notification runs to 72 hours from awareness, to the supervisory authority, with notification to individuals when the risk to them is high. That deadline is why detection and logging are privacy controls and not just security ones: you cannot assess what was accessed if you were not logging reads. Wire the decision into the incident runbook with a named decision-maker, because the clock starts whether or not anyone has noticed it started.

What to do this week

Pick your largest customer-facing datastore and answer one question: what is the oldest personal data record in it, and what rule should have deleted it? Run the query. In almost every estate we have looked at, the answer is years older than the privacy notice claims, and that single number is the most persuasive thing you can put in front of a leadership team. We start the privacy workstream of a security engagement with exactly that query.