The EU GDPR famously enforces the Right to Erasure (Article 17). It requires all who collect or process data on EU data subjects (pretty much any resident of the EU, regardless of their citizenship) to erase that data on request. This is already imposing egregious costs on larger organizations as they build the systems to respond to such requests.

Here are some questions to consider:

  • Is your organization set up to meet these requests?
  • Is your request process based on email?
  • How do you verify that the requestor is the real person?
  • How do you avoid abuse or false requests?
  • Do you have a formal process? Does a registered subscriber fill out a form?
  • Can you respond in a timely fashion? How do you demonstrate that you have erased a person’s record?
  • Can you report to the Data Protection Supervisor on the measures you have taken to comply with Article 17?

The Financial Times reports that many organizations saw large volumes of requests after the May 25, 2018 imposition of GDPR:

“to my request within one month, as required under Article 12, failing which I will be forwarding my inquiry with a letter of complaint to [the data protection authority],” reads one letter sent to multiple companies with a nine-point list of demands.

Here is the nightmare scenario: Your organization has thousands or millions of records. Hundreds of people request that their records are erased, and your records management people take action to remove those records. Fine. Now imagine that your database gets corrupted during an upgrade cycle one weekend. What do you do? You restore from backup, of course. In doing so you accidentally restore the records of everyone that had been “erased.” Any one of those people may find that their records are still online and viewable. They could complain to the Data Protection Supervisor and start a cascade of investigations, leading to considerable fines.

David Froud discussed the details of whether Article 17 requires backups to also be erased. He shoots down three arguments that an organization might make to claim backups are not covered by GDPR:

  1. Backing up is not “processing”. In fact, the definition of processing in GDPR is very broad and includes storage and retrieval, two functions of backups.
  2. Reasonableness. “…taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures…” I agree with Froud that you do not want to get into an argument over what is reasonable with a regulator. Litigators are good at finding examples of best practices to demonstrate reasonableness.
  3. Pleading ignorance. This is a non-starter. Many of the requirements of GDPR are meant to force you to demonstrate that you do know what you have, where it is and why you need it.

Erasure is a technically challenging process. For most compliance regimes, it entails overwriting the actual sectors in storage media so that data cannot be extracted with forensic tools. Although the common interpretation of GDPR is that once a record is not retrievable it has been “erased,” you still have to be worried about the fact that a database erasure merely removes the pointers to the record so they cannot be retrieved. The data still resides on the hard drive, solid state memory or magnetic tape until it is overwritten by new data.

One process used by large social media sites for removing accounts is to physically move the records to a designated hard drive and de-provision the account. They then wait 30 days because invariably someone realizes they need those records after all (or law enforcement may want them.) They then perform a full data sanitization of the hard drive using software overwrite, degaussing, or physical crushing.

But how would you remove a data subject’s record from a backup? You would have to perform a restore of the database to a non-production server, remove the records, and then re-write to backup. If you have a robust disaster recovery process in place you may have to do this on the live backup, the daily backup, and the weekly backups going as far back as you have them. This is beginning to sound like an expensive proposition. An alternative would be to build a process that would automatically remove records whenever a backup is restored.

Backups pose a problem for the right to erasure. But wait, there is more to consider.

One key aspect to consider is logs. When a record is created in a database most systems log that action. The logs contain all the data fields that are created. In extreme cases it is possible to rebuild a complete database from the logs. It may be a good idea to look at your logging policy. Many organizations keep everything, including logs, for a long time. You should revisit that policy in light of GDPR.