An easy to implement solution is this one: .) Move the "deleted" user IDs into a separate database and check the live database against it during each backup process -> delete the ones in the live database that are in the "deleted" items database. It is unclear whether this satisfies the RtbF and is an "all-or-nothing" approach. It is not possible to only delete parts of a record this way: techblog.bozho.net/gdpr-practical-guide-developers/ Other methods basically work by attaching labels to the data which makes it easy to track it down and delete them (and all copies of them): .) SAP for example offers solutions (SAP Lifecycle Management) to track down and delete personal data on all back ups. This is something you might want to look into, if you use SAP. .) Attaching labels (also called taints) to data which allows to monitor their flow. That way you can safely delete the data in all backups by following the data's flow. .) Other ideas are more theoretical. For example, setting expiration dates on data which automatically deletes it after the legal retention period. Or that personal data "degrades" over time (e.g., by being generalized more and more) which makes it less sensitive. Naturally, using blockchain has also been suggested by using it as access controll to the data which can be revoked by the user/customer. Again, those approaches exist in scientific literature only, AFAIK. .) For me personally, the solution from Microsoft looks the most promising. It is basically a real-time permission system users give to data controllers. By withdrawing consent or exercising their RtbF, the data can no longer be processed. I suggest reading up on it here: link.springer.com/article/10.1007/s12525-015-0184-z
Wow ! Thanks a lot Sir ! Much appreciated!
But if you are not really deleting the data, just the key, don't you end up with an overloaded database that will just extend the loading time?
Good observation. This is one additional problem of this technique. Lots of work to do to tackle this problem, it seems.
you mentioned that there are other techniques for the RTBF implementation. Which one would you consider as best approach if you had to pick one
An easy to implement solution is this one:
.) Move the "deleted" user IDs into a separate database and check the live database against it during each backup process -> delete the ones in the live database that are in the "deleted" items database. It is unclear whether this satisfies the RtbF and is an "all-or-nothing" approach. It is not possible to only delete parts of a record this way: techblog.bozho.net/gdpr-practical-guide-developers/
Other methods basically work by attaching labels to the data which makes it easy to track it down and delete them (and all copies of them):
.) SAP for example offers solutions (SAP Lifecycle Management) to track down and delete personal data on all back ups. This is something you might want to look into, if you use SAP.
.) Attaching labels (also called taints) to data which allows to monitor their flow. That way you can safely delete the data in all backups by following the data's flow.
.) Other ideas are more theoretical. For example, setting expiration dates on data which automatically deletes it after the legal retention period. Or that personal data "degrades" over time (e.g., by being generalized more and more) which makes it less sensitive. Naturally, using blockchain has also been suggested by using it as access controll to the data which can be revoked by the user/customer. Again, those approaches exist in scientific literature only, AFAIK.
.) For me personally, the solution from Microsoft looks the most promising. It is basically a real-time permission system users give to data controllers. By withdrawing consent or exercising their RtbF, the data can no longer be processed. I suggest reading up on it here: link.springer.com/article/10.1007/s12525-015-0184-z