First, if you cared about user privacy, you would store as few data points as possible.
Second, it’s very likely that you have APIs in place that can request all data for a user anyways. If you don’t know what data you have of your users, you don’t give a shit about their privacy, no?
Third, user requests are usually: a) what data do you store about me? B) Export all data. C) delete all my data (for real).
The orchestration of a data extract from even a midsized corporation is a significant endeavour.
Someone in the company knowing what data we have on an entity is a significant step away from the entire company being able to access that, because, you know, we take data privacy seriously, so we don’t make it easy to access all data on a single entity.
If your approach to privacy is putting all the eggs in a basket, allowing easy extraction of everything from that basket, and hoping the basket can be kept secure I’d argue your model is weird to begin with.
This is so simplistic. There are many storage solutions for many different use cases.
Some of these are write once and immutable afterwards.
There are relational structures for transaction history that may also link to customers.
These all have to be re-designed in such away that information can be removed from the system and exported from the system, while keeping essential information (such as past sales records).
> Some of these are write once and immutable afterwards.
Got an example of something like that that'd make it impossible to soft delete a person? I'm struggling to think of any datastore in regular use that's write only.
Yeah, as I thought, it's a blockchain/distributed ledger related technology. Hence why I said "regular use". I doubt large numbers of EU businesses are suddenly having to move data from their core ledger to another datastore because of this.
Why? Don't you still have to build systems to be able to comply with user requests in a timely matter?