Five engineering habits that actually earn customer trust (and one that is quietly expanding the problem)
A privacy expert argues that compliance checkboxes are the easy part. The hard part is making sure a customer's choice is respected by every system that touches their data, even the ones nobody thinks about.
Key points
- Most privacy failures happen not because a control is missing, but because data moves between systems faster than the customer's latest choice does.
- A single deletion request can touch transactional databases, caches, event streams and machine-learning models, each a place where the old data can survive.
- Article 25 of the General Data Protection Regulation (GDPR) requires "data protection by design", but engineers say meeting that rule on paper is easier than meeting it in practice.
- Reducing the amount of data collected in the first place cuts both privacy risk and the operational burden of cleaning it up later.
- AI systems are widening the boundary of where customer data ends up, and most organisations haven't caught up.
Compliance is a floor, not a ceiling. That's the central argument of a long essay published by CSO Online, written by a practitioner who spent years building large-scale personalisation and e-commerce systems. It doesn't break news, but it makes a case worth hearing: the gap between "we have a privacy control" and "our systems actually respect what the customer asked for" is much wider than most security teams admit.
Here are the five areas the author says matter most, translated from engineering speak into plain English.
Why does changing a privacy setting sometimes not seem to work?
Because one system records the change, but several others may not hear about it straight away. Think of it like updating your address with one government department and discovering six others still have the old one.
In a large company's systems, a customer's preference might live in a main database, copies stored briefly for speed (called caches), event pipelines and machine-learning models. When a customer opts out of personalisation or asks for their data deleted, that instruction has to travel to every one of those places. If any runs on yesterday's copy, the old preference can quietly keep shaping what the customer sees. Privacy regulators call the fix "data protection by design"; engineers call it a distributed-systems problem. Both names describe the same gap.
A useful diagnostic question the author suggests: "If a customer's intent changes here, where can the old intent still survive?"
What actually happens when you ask a company to delete your data?
Your request is usually genuine and usually acted on. But the data may exist in more places than the team handling your request can easily reach.
Transactional records, fraud logs and trained machine-learning models can all hold fragments of your information. Some copies have legitimate legal reasons to stay: fraud investigation, tax records. Others are just there, because nobody thought to clean them up. The honest answer to "is it gone?" is often "from the main system, yes; from everywhere, we're not entirely sure."
The author's recommendation is to design systems that know where every copy lives and what the rule is when a deletion comes in. Not knowing is the problem. Our coverage of Uber's €825 million GDPR fine on 24 August showed what happens when automated systems act on data with no human ever checking whether that data should still be in play.
How should organisations think about this practically?
Four habits cover most of it.
| Habit | What it means in plain English |
|---|---|
| Make customer intent travel everywhere | A preference change must reach caches, pipelines and analytics, not just the main database |
| Collect less data | Every extra copy is another thing to secure and eventually delete |
| Design for failure | Decide in advance what the system does when it cannot confirm the latest privacy state |
| Monitor privacy like uptime | Track how long preference changes take to reach downstream systems, and where deletions fail |
The fourth habit is the one most teams skip. Organisations measure whether a server is up, how fast a page loads. They rarely measure how quickly a privacy preference propagates, or whether a deletion request completed in every system that received the original data. That's an operational blind spot, not a theoretical one.
Should ordinary people worry about this?
Not in a "your data is being sold" sense. The issue is subtler: when you update a privacy setting, you reasonably expect it to stick. These engineering gaps are why it sometimes doesn't feel that way.
If you've made a data-deletion or opt-out request and then seen the old behaviour continue, you're not imagining it. A reasonable follow-up is to contact the company directly, ask for written confirmation that the deletion is complete, and note the date. Most data-protection laws give you the right to that confirmation.
Common questions
Does the GDPR fix this?
Partly. Article 25 of the GDPR requires companies to build privacy into their systems from the start, and the NIST Privacy Framework treats privacy as a risk to manage during design, not after. Both push in the right direction, but neither specifies how fast a preference change must reach every downstream system. That gap is where the engineering problem lives.
What is the AI angle?
AI models are trained on customer data and then used to make decisions. Once data is baked into a trained model, removing it is genuinely hard, sometimes impossible without retraining the whole thing. This is a known open problem in the field. It means the "where can old data survive?" question now has one more answer than it did five years ago, and most organisations haven't updated their deletion workflows to account for it.
