I joined in on an interesting conversation the other day on twitter. It was about some unusual ramifications of GDPR (The EU General Data Protection Regulation). In case you haven’t heard of GDPR (maybe you’ve been offline for the last few months?), the GDPR is some rather sweeping security regulations for the data of anyone from the EU. Yes, that means if you aren’t in the EU but have the DATA about someone in the EU, you are affected. Does this include the UK? Well, I guess we will see.
However, back on topic, one of the things we discussed briefly was what about backups? Are they covered? If a customer requests their data be removed then what do we do about backups from before the removal? Well, as non-lawyers and non-experts, we decided that the backups are probably ok. However, if you have to restore the database for whatever reason, then you are absolutely going to have to re-run the delete scripts that removed the data.
Ok, no problem. We change our procedures to save every GDPR related script and when it was run. Then whenever a restore is done we check for any of those scripts that were run since the point in time of the restore.
Simple right? Well, there are some pretty important ramifications. What happens to your RTO (Recovery Time Objective or How long do I have to get this data back online in case of an emergency)? It’s going to go up, possibly not by much if your scripts are quick and hopefully automated. But if you have to manually review the list of scripts, and/or they take a while to run, this could add time.
Even more importantly, Do those scripts contain protected data? If your delete script uses some sort of public identification number (something equivalent to the US’s SSN) in order to remove them then can you save that script? Again, not a lawyer, not an expert, but I’m going to guess no. This does mean that in the Natural vs Artificial Keys argument the artificial keys side just got a big bump. Because to be honest, I’m going to want to play it safe with anything to do with the GDPR.
Summary: Your processes need to change.
- Scripts that are run to remove data for the GDPR need to be saved.
- After any restore any of the scripts run after the point in time of the restore need to be re-run.
- When building the scripts you need to make sure you aren’t using any form of protected information to identify the data to be deleted.
- Oh, and check your RTO
Final warning. I am NOT a lawyer. I am NOT an expert. Talk to your legal team, read the GDPR requirements. Take this stuff seriously.
