i gave the example with data deletion. deleting someone’s data means also deleting or altering data products derived from it - like statistics, machine learning models etc. which are, in turn, used to create different data products and so on. which are shared, stored and processed beyond the company with different partners (called processors, which may have processors of their own that not even the original data controller needs to be aware of). and you as the primary data controller are technically reaponsible for all of it everywhere. and erasure or withdrawal of consent is the easy case… data subject can, in principle, withdraw consent only for specific purpose or specific processor.
Hm, alright, I can see that - but to me, this is an example of business practices that the GDPR is explicitly trying to restrict. Of course it will be difficult to delete someone’s data if you’ve been sharing it with many other companies.
you are not wrong about that. it’s just the reality we live in means that to implement gdpr as it is now you’d have to kill the entire data driven ecosystem and start from scratch… and nobody will do it unless everyone else is doing it. the result is that we have well meant but ultimately unenforced legislation that causes everyone to stretch it just a little bit.
We definitely encountered challenges, like rouge data sets from silod teams, rehydration of backups, etc. but we managed to comply with the right to be forgotten. And these are large companies. If someone as a data engineering manager admits to not being able to do it? Well thats either a resourcing problem, a negligence problem, or a skill issue.
Could you expand on some of these challenges? We haven’t had these issues in any companies I’ve worked at, but those were mostly on the smaller side.
i gave the example with data deletion. deleting someone’s data means also deleting or altering data products derived from it - like statistics, machine learning models etc. which are, in turn, used to create different data products and so on. which are shared, stored and processed beyond the company with different partners (called processors, which may have processors of their own that not even the original data controller needs to be aware of). and you as the primary data controller are technically reaponsible for all of it everywhere. and erasure or withdrawal of consent is the easy case… data subject can, in principle, withdraw consent only for specific purpose or specific processor.
Hm, alright, I can see that - but to me, this is an example of business practices that the GDPR is explicitly trying to restrict. Of course it will be difficult to delete someone’s data if you’ve been sharing it with many other companies.
you are not wrong about that. it’s just the reality we live in means that to implement gdpr as it is now you’d have to kill the entire data driven ecosystem and start from scratch… and nobody will do it unless everyone else is doing it. the result is that we have well meant but ultimately unenforced legislation that causes everyone to stretch it just a little bit.
We definitely encountered challenges, like rouge data sets from silod teams, rehydration of backups, etc. but we managed to comply with the right to be forgotten. And these are large companies. If someone as a data engineering manager admits to not being able to do it? Well thats either a resourcing problem, a negligence problem, or a skill issue.