Store data and keys seperately.

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.

Wouldn't you need to edit every single backup where the key is stored in order to comply?

I assume they mean the standard practice of encrypting your backups with per-customer encryption keys. If you ever want to destroy all of the data for a particular customer you don't have to do any editing of backups, you just have to nuke every copy of the encryption key you use for that customer.

Storing names separately can help but the subset of data you have a legitimate legal reason to "refuse to forget" can change faster than you would want to rewrite your backups(well, nobody wants to rewrite backups, but you get what I mean)

You need to denormalize the non-forgettable information. This way you don't have to worry about what you can delete or not.

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.

Legislation can change and what you once thought to be forgettable becomes suddenly not.

It'd be extremely unusual for such changes to be retrospective. For example, if you are currently required to keep certain kinds of financial records for 3 years, and you delete records older than that, you won't be held at fault when that law gets updated to say 5 years, and you then fail to produce a 4-year-old document; it has not yet been a year since the new law took effect.

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.

Well, yes, but the topic here was data. And if at some time you thought it was forgettable and you scheduled it for deletion, once the law changes you should make damn sure all code involved in that deletion was checked or the data will be gone - against the new law. A big opportunity for human error here.

Not necessarily. While it's not set in stone, GDPR right to erasure might not be in conflict with backup retention.

>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...

As I understood it at the time this is the difference between archives and backup.

I see memory served me incorrectly! Apologies if I have spread misinformation. It was an offhand comment from an AWS rep a few years ago and things may have changed.

When GDPR passed there was a bit of a scramble to understand it, and people had all sorts of different interpretations that they were sharing.

I suspect you can square the circle, if you encrypt all the files, and store the keys in storage you can delete quickly.