Does GDPR require deleted backups to be rendered unrecoverable?



  • Although GDPR has been in place for some time, my organisation has had a dispensation to essentially ignore it up until now. The dispensation was because the contract from the government we were on was an interim basis while a new provider got their system online. The thinking was we'd be turning off our system at any time and handing over. Fast-forward seven years and the new provider hasn't done what was asked of them, so we're staying put.

    We've now been told by the ministry to bring ourselves into GDPR compliance and one of the issues being raised is about backups. My understanding is that for day-to-day business, simply deleting the backup file when it ages out is enough to be compliant. More thorough cleansing is possibly needed when disposing of hardware, but no extra measures are required for business-as-usual backup maintenance.

    However, there's some questions being asked about whether we need to completely erase any deleted files from the disk. This complete erasure apparently uses third-party software to totally remove the file and render it unrecoverable.

    Is it now the norm to completely erase backups due to GDPR?

    If that's what people have always done and we've never been doing it right, I'll take that too.



  • From my position as not-at-all-a-legal-expert, we consider making a backup unrecoverable to be due diligence even though not explicitly stated anywhere. If regulations say it needs to go, then it needs to be fully gone. Many suggest that just deleting backups is sufficient, but we take a more careful interpretation partly because we'd prefer to anyway and partly because some clients would insist anyway. We work with significantly regulated companies, and store PPI of our clients' users and our clients' customers.

    For local storage this is done with:

    1. Encryption at rest: all our drives use FDE (via BitLocker with Windows). This covers any active data too.
    2. While the above should be sufficient for most threats (someone taking the drive shouldn't be able to unlock it), I suggest shredding files instead of just deleting them. This doesn't protect you from much more than FDE (if someone gets access to the drive while mounted via an RCE flaw they'll still get the not-yet-deleted backups) it is easy to do so do it as due diligence.
    3. As you state, properly disposing of drives when they are no longer in use: secure wipe then physical destruction.
    4. Consider configuring TDE for your databases too.

    For cloud storage we have less control, the data may be moved all over the place while it is active and even if you knew what drives it had existed on you don't have the level of control needed to properly ensure they are securely wiped, and almost all of our DBs with sensitive data are out in Azure. Here you need to:

    1. Make sure all the relevant options for storage protection are turned on. TDE in the DBs, FDE on storage accounts and VM drives, ... These are usually by default anyway these days, but make sure and consider if you feel the need to use “bring your own key” variants and so forth.
    2. Make sure backup retention levels are correctly set for the expiry promises you have given to your client(s).

    Backups are a bit of a grey area by our reading of the GDPR, and we would take a very similar stance with our data anyway even if it didn't exist, so you may need to get someone with legislative expertise to assess your stance with respect to what data you hold and about whom and for who.

    A key question to ask yourself when thinking about these matters is: if you were your client, or you were a third party auditor assessing you on behalf of such a client, or your personal data was in those systems, would you be satisfied that what is done with the data represents due diligence & best practise?




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2