> If you were compliant before, because you respected the users‘ privacy, the effort was relatively low.
Why? Don't you still have to build systems to be able to comply with user requests in a timely matter?
Why? Don't you still have to build systems to be able to comply with user requests in a timely matter?
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).
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).
This is not an easy problem to solve.
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.
Are you implying that those 3 requests are simple to fulfill in a business running a modern software architecture?
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.