GDPR and master data: what "delete this customer" actually requires

An erasure request landed on my desk once, forwarded by someone in legal with a single line: "Customer wants their data deleted, can you handle it?" Two minutes of work, in theory. Open the record, delete, reply done.

It took two weeks.

The customer's name, email and phone number were not sitting in one tidy row. They were in the CRM where sales first typed them, in the ERP that billed them, in the data warehouse that reported on them, in two downstream apps that had subscribed to the master feed years earlier, and in the master data hub that had quietly fed all of the above. Deleting the person meant reaching every one of those places. That is the part nobody budgets for.

Erasure is about a person, not a row

The right to erasure in Article 17 of the GDPR, the "right to be forgotten," is written about an individual. Your systems are written about rows. The gap between those two ideas is where the work lives, because personal data does not stay in one row. It gets copied the moment a record is useful to a second system, and useful records get copied a lot.

If you manage master data centrally, the customer exists once as a golden record and several times as copies downstream. An erasure request has to land on all of them. Hitting delete in one place and calling it finished is how the same personal data turns up in a warehouse report six months later, long after you told the regulator it was gone.

The first thing erasure collides with is the audit trail you also have to keep

Two requirements on the same project pull in opposite directions. Governance tells you to keep a complete history of who changed what. Compliance tells you to remove a person on request. Both are right.

The way out starts with something most people get wrong: the right to erasure is not absolute. Article 17(3) carves out data you are legally required to retain. Tax law in most of Europe makes you keep invoices for seven to ten years. Data you need to defend a legal claim can stay. So you rarely delete everything. You delete the personal data you no longer have a basis to hold, and you keep what the law forces you to keep, usually after stripping it of anything that still names the person.

The audit trail gets the same treatment. A field-level history that records the old name and email is itself personal data. Keeping a record that a change happened on a given date for a given request is fine and often necessary. Keeping the identifying values inside that history is not. So you anonymize the old values in the trail at the same moment you anonymize the live record, and the trail still does its job: it proves an erasure took place, without preserving what you erased.

The second collision is referential integrity

Even when you do want the data physically gone, you usually cannot just run a DELETE. Transactions point at that customer. Reports join on the key. Remove the row and the next warehouse load throws errors on a foreign key that no longer resolves, and finance is left with invoices attached to nobody.

The practical answer is anonymization in place. You keep the surrogate key so history stays consistent, and you overwrite the personal attributes: the name becomes something like "Erased customer 48213," the email and phone go to null. The invoice still balances. The report still runs. The person is no longer identifiable from any of it.

One distinction decides whether this actually counts. Anonymization has to be irreversible. Recital 26 puts truly anonymous data outside the scope of the GDPR, because the individual can no longer be identified by any means reasonably likely to be used. Pseudonymization is the trap: if you keep a lookup key somewhere that can rebuild the original, the data is still personal and you have not erased anyone. The honest test is simple. Can you, or anyone you might share with, get back to the person? If yes, you are not done.

You cannot erase what you cannot find

The delete is the easy part. The hard part is the inventory. Where, exactly, does this person live? In a company that has been running for fifteen years, the honest answer is often "we are not entirely sure," and that uncertainty is the real compliance risk. The copy you forget about is the one that surfaces in an audit.

This is the case for centralizing master data, made by an obligation rather than by a vendor. When the customer is one governed record, you can hold a cross-reference table that maps the master ID to the identifier the person carries in each downstream system. An erasure request stops being a search across seven systems and becomes one record to act on and a known list of places to propagate the change to. You can answer the question "where is this person?" before you start, instead of hoping you got them all.

A routine that actually closes the request

Once the architecture is in place, an erasure request follows the same six steps every time. The repeatability is the point. A process you run from memory is a process you eventually get wrong.

The architecture decides whether this is hard

When personal data is scattered across systems with no central record, every erasure request is archaeology. Someone spends days reconstructing where a person was copied, the answer is never quite complete, and the gap between "we think we got them all" and "we got them all" is exactly the gap a regulator asks about.

When the same data is governed in one place, the request is bounded. You know where the person is before you start, you act on the master record, the change flows out the way every other change flows out, and you keep a record that you did it. The right to be forgotten turns out to be a master data problem wearing a legal costume. Solve the master data, and the legal part gets a lot quieter. For the related question of proving who touched a record and when, the same audit infrastructure does double duty, which I wrote about in the post on regulators and supplier records.

Common questions