3 ms·

This is an issue with European GDPR "right to be forgotten" requirements. Some interpretations say that if a user requests their data to be deleted, it must al

by dkarp 6y ago

This is an issue with European GDPR "right to be forgotten" requirements. Some interpretations say that if a user requests their data to be deleted, it must also be removed from backups. If your backups are kept in a binary format, then it's a nightmare. You have to restore them, delete the data then backup them up again for every backup you have. Other interpretations say that it is enough to remove the data if/when you restore the backup data. I.e. keep a record of deletion requests and on restoring a backup check if you need to re-perform the deletion request and then do so if necessary.

Silhouette 6y ago
For new systems where this sort of privacy requirement can be designed in from the start, I quite like a strategy that was proposed around the time of the big GDPR discussions, which seems useful in some situations: individually encrypt records of personal data with a separate key for each person (or some other granularity that makes sense for your processing and storage requirements). Then your main database and its backups only contain the separately encrypted data, you keep a rolling backup of your current set of encryption keys, and in response to any permanent data deletion requirement you can delete the key for the relevant record(s) to immediately render the data unusable in any large backups or long-term archives without having to regenerate them. When your key backup rolls over, which might only be a matter of days or even hours, any old copies of they key also get destroyed and the personal data is, for practical purposes, gone forever. Obviously there are many edge cases around deleting partial or related records that would limit the usefulness of a simple scheme like this, and obviously it's no use for data storage and processing that was already set up before the GDPR came into effect and didn't have this sort of mechanism designed in, but I suspect there are quite a lot of data controllers that have relatively simple record-keeping requirements where this kind of approach could work well.

by dkarp 6y ago

Silhouette 6y ago

For new systems where this sort of privacy requirement can be designed in from the start, I quite like a strategy that was proposed around the time of the big GDPR discussions, which seems useful in some situations: individually encrypt records of personal data with a separate key for each person (or some other granularity that makes sense for your processing and storage requirements). Then your main database and its backups only contain the separately encrypted data, you keep a rolling backup of your current set of encryption keys, and in response to any permanent data deletion requirement you can delete the key for the relevant record(s) to immediately render the data unusable in any large backups or long-term archives without having to regenerate them. When your key backup rolls over, which might only be a matter of days or even hours, any old copies of they key also get destroyed and the personal data is, for practical purposes, gone forever. Obviously there are many edge cases around deleting partial or related records that would limit the usefulness of a simple scheme like this, and obviously it's no use for data storage and processing that was already set up before the GDPR came into effect and didn't have this sort of mechanism designed in, but I suspect there are quite a lot of data controllers that have relatively simple record-keeping requirements where this kind of approach could work well.