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, analytics pipelines and machine-learning models, each one 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 have not caught up.
Compliance is a floor, not a ceiling. That is 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. The piece does not 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 logs, analytics tools and machine-learning models. When a customer opts out of personalisation or asks for their data to be deleted, that instruction has to travel to every one of those places. If any of them is running on yesterday's copy of the data, 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, financial receipts, analytics snapshots and trained machine-learning models can all hold fragments of your information. Some of those 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 are not entirely sure."
The author's recommendation is not to panic about this, but to design systems that know where every copy lives, who owns it and what the rule is when a deletion comes in.
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.
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 does not feel that way.
If you have made a data-deletion or opt-out request and then seen the old behaviour continue, you are not imagining it. A reasonable follow-up step 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 ask for 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, and it means the "where can old data survive?" question now has one more answer than it did five years ago.
