An email arrives at 4pm on a Friday. A former customer wants every piece of personal data you hold about them, and they want it deleted. You have one month.
For most businesses the honest reaction is not concern about compliance. It is the sinking realisation that nobody actually knows where that data is.
Why this is an engineering problem wearing a legal costume
The UK GDPR gives people the right to see their data, correct it, and have it erased. The legal questions are usually the easy part — whether the request is valid, whether an exemption applies, whether you have a lawful basis for keeping some of it.
The hard part is mechanical: finding it. And that difficulty is decided years earlier, by how the systems were built, not by how good the policy document is.
If a customer’s name, email and phone number live in one record that everything else references, a deletion is a transaction. If they were copied — into an order row for convenience, into an invoice PDF, into a monthly export, into the CRM, into a spreadsheet somebody keeps for reporting, into three years of email — then a deletion is a search. The search has no defined end, and you have to certify that it is complete.
Pick a real customer from two years ago and find every place their personal data exists. Not a policy list — go and look.
Count the places. Count the ones that are copies rather than references. Count the ones that live outside a system entirely, in a spreadsheet or an inbox. That number is your actual exposure, and it is usually several times what the data map says.
The five places it is always hiding
1. Denormalised copies
The order table has customer_name and customer_email on it, because at some point a query was easier that way. Now every order is a copy of the customer. Multiply by invoices, shipments, support tickets and notifications.
2. Documents you generated
Invoices, contracts, delivery notes, reports. Each one is a PDF in object storage with a name and an address burned into it. They are rarely in anyone’s data map and they are exactly what a subject access request means.
3. Logs and audit trails
The uncomfortable one. You are told to keep an audit trail; you are also told to erase personal data. Those requirements meet head-on, and the answer is to design the audit trail so it records who acted by reference rather than by copy, and never puts payloads of personal data in a log line. Retrofitting that means editing an append-only log, which defeats its purpose.
4. Third parties
Your email provider, payment processor, support desk, analytics, backup vendor, and whichever AI service somebody trialled last year. Erasure obligations follow the data to processors. If you cannot list them, you cannot comply, and the list is almost never current.
5. Spreadsheets
The one nobody wants to say out loud. If a critical process runs on a spreadsheet — and in most mid-sized businesses at least one does — then customer data is sitting in a file, on a drive, in versions, in the attachments of every email it was ever sent in. There is no query that finds it and no mechanism that deletes it.
This is worth sitting with, because it reframes the spreadsheet problem. It is normally discussed as inefficiency: slow, error-prone, dependent on one person. It is also an uncontrolled store of personal data that you are legally responsible for and cannot search.
What good looks like, structurally
Four properties. None is exotic, and all four are far cheaper to build than to retrofit.
One home for a person. A single record per individual. Everything else references it by identifier and does not copy the personal fields. Erasure then has one target, and the references become anonymous rather than orphaned.
Personal data is marked as such. The schema knows which columns are personal. That sounds bureaucratic until the first request arrives, at which point the difference between a query and an archaeology project is exactly this.
Generated documents are linked, not scattered. Every artefact that contains personal data is recorded against the person it concerns, so the set is enumerable. Whether a given invoice must be deleted is a legal question — there are retention obligations that override erasure — but you cannot answer it about documents you cannot find.
The audit trail references, never copies. Record the actor and the action by identifier. Keep payloads out of log lines. Then the audit trail survives an erasure with its integrity intact, which is the outcome both regimes actually want.
The same design, in two jurisdictions
If you operate in the UK or EU you are working to the GDPR. If you also operate in India, the Digital Personal Data Protection Act sets out consent, retention and erasure obligations that are recognisably similar, with penalties up to ₹250 crore. Neither is satisfied by a policy page.
The convenient part is that the engineering answer is the same in both. One home per person, references not copies, enumerable documents, a clean audit trail. Build it once and both regimes are addressed, along with whichever one arrives next.
What to do on Monday
Not a compliance project. Start with one question and follow it honestly: for one real customer, where does their data live?
Write down every location, including the spreadsheets and the inbox. Mark each as a reference or a copy. The copies are the work, and the count tells you whether this is a fortnight of schema changes or something larger.
The request will arrive eventually. The month you get to respond in is not enough time to fix the architecture — it is only enough time to discover that you should have.