Now for those who decided that a blockchain is the perfect solution for storing personal data however...
But you might have a hard time chasing down every copy, it's a distributed system by design.
The example I’m aware of is where personal information is held due to ‘legitimate interest’ and the request to delete isn’t deemed (however that is defined) to override that.
I won’t try to go further as it’s not 100% clear cut and IANAL.
Have a look at the legislation or the various explainers that have been posted online if you’re interested.
Edit: In this case I would guess that Canon would have trouble claiming a legitimate interest in keeping hold of your photos!
This does nothing to protect against a bad cron job script. The web frontend, and even backend, are not linked to background maintenance tasks.
And a field in a DB doesn't prevent a manual DB delete, or api call to a backing store.
The real problem here, was a lack of backup testing / restore testing.
If you have backups, you MUST manually verify they can be restored, in a desired state.
And this means restores MUST be tested every time code changes happen, which effect backups.
When I work on design I try to make catastrophic failure impossible. Not implementing deletion or implementing deletion with some unseparable constraint check is one way.
For example, the files could have a flag set and from that point on the only delete function would check the flag and refuse to remove the image regardless of how it got invoked or where the image is placed (think like write protect notch on a floppy disk).
Another way is to not actually remove the files but instead introduce grace period when they are marked as deleted, not accessible, to the user.
The only real deletion would happen in a vacuuming system that will actually remove the files but with a hardcoded constraint next to filesystem delet that the file must have been marked as removed at least XX days ago. This would give some time after deletion to actually recover files.
Yet another technique is to move objects marked as deleted to some other, cheaper form of storage. The function that moves objects must first confirm the object is available in new storage through its API and only then removes the original.
You can also prevent damage that could result from failed modification using immutable objects and Copy on Write. The copies would be deleted using the above described mechanism.
Yet another technique is to keep XX days of redo-log that could contain enough information to rebuild any object to any of its current or past state within XX days. Depending on the type of the file and nature of changes it can be much more efficient than keeping whole copies.
All of this of course adds overhead but you can recover a lot of that overhead by relaxing requirements on duplication of your operational or other forms of backup storage with rationale that if you have a redo log where you can locate current or past version of the object independently of operational or backup storage you can count it as one more operational or backup copy.
In my experience, the best way to mitigate these kind of things is to use PITR, which is always immutable. You make periodic snapshots, keep track of all changes since those snapshots. And then you use a policy to determine just how much data you want to keep here.
The problem is that not supporting delete operations is often very much impractical. Consider for example the recent heat Flickr (or was it Instagram?) has gotten for not physically deleting files but just marking them as deleted/invisible. You sometimes have really good reasons that you must support delete operations, so you must just make sure that there’s a reasonable delay before they are actually completely gone.
You can access your customer data, using the customer-specific AES key. You can access the customer-specific AES key using your private RSA key.
When you need to delete the customer data under GDPR, you can delete the encrypted AES key for that customer from your database.
Now you have the worst of both worlds. You also now have 2 points of failure where data can get lost, because if either has a problem you lose data.
The set of keys for all your customers should be only a few megabytes, so is much much easier to back up more frequently and more copies of.
It's also easier to have a "we do daily backups and delete any backups after 21 days" policy.
Store Invoices, billing, etc, separately. These also usually have a fixed pre-determined retaining policy time. Past that time? Anonymize/aggregate or just delete it.
This extends to criminal law too, for example with statutes of limitation. If, 20 years and 1 day ago, there was a 20-year statute of limitations for murder charges, you cannot be charged for committing a murder on that day (barring extraneous circumstances, such as tolling); even if a law was passed the day after said murder removing this limitation.
>The GDPR is open to interpretation, so we asked an EU Member State supervisory authority (CNIL in France) for clarification. CNIL confirmed that you’ll have one month to answer to a removal request, and that you don’t need to delete a backup set in order to remove an individual from it. Organizations will have to clearly explain to the data subject (using clear and plain language) that his or her personal data has been removed from production systems, but a backup copy may remain, but will expire after a certain amount of time (indicate the retention time in your communication with the data subject). Backups should only be used for restoring a technical environment, and data subject personal data should not be processed again after restore (and deleted again). While this adds some complexity, it allows organizations to have some time to re-engineer their data protection processes.
https://blog.quantum.com/2018/01/26/backup-administrators-th...