GDPR and backup: A potential minefield easily avoided

To find personal data in backups is practically impossible, and that would – in theory – mean organisations contravene key aspects of General Data Protection Regulation (GDPR) compliance, namely the right to erasure or right to be forgotten.

But, in practice, organisations should assume that such data is only subject to GDPR when available to production systems. That’s according to Andy Barratt, UK managing director of security consultancy Coalfire.

GDPR provides the right to data subjects – ie, individuals upon whom organisations hold data – to have their data erased or for corrections to data to be rectified if it is incorrect. That could be a problem when data is retained in backups and snapshots, for several reasons.

Data in backup software is often held in a different – usually proprietary – format to its original application format. Also, depending on the backup software, it might not be searchable, and in fact may be held on separate systems or even on tape, which in most cases is not searchable either (unless you have LTFS).

It might also be the case, as with snapshots and incremental backups, that data on a particular subject exists in fragmentary form, such as daily or more frequent deltas. “Backups are often point-in-time copies kept in an archive, off production systems,” said Barratt.

“For example, snapshots may comprise numerous deltas of previous copies that contain an entire chain of information about a person. So, they might provide different data depending on what you choose to restore.”

So, from a technical standpoint, it is almost certainly the case that an organisation’s backups can contain data that cannot be easily found, or processed, from a GDPR point of view.

But, according to Barratt, that should not be a problem unless the data hits production systems.

“It is important not to overthink things from the technology point of view,” he said. “To maintain the data an organisation has is in its legitimate interest and the data might only have to pass through the production systems to come under GDPR.”

“So, if we do a restore and the data subject has requested it be erased or corrected, then any relevant data in that restored backup should be dealt with as requested,” he said.

The key, said Barratt, is to make sure data in production data sets is dealt with in a compliant way. He suggested, for example, that GDPR requests be recorded and any processing associated with them be carried out on data as it hits production applications.

He did, however, advocate privacy-by-design as a more durable solution. “We’re now seeing developers building GDPR application program interfaces that can process data requests as the data hits the application,” he said. “In the interim, what’s needed is to manage these requests so we know if data hits production and that it can be dealt with as required.”

“More widely, policies are required around the length of retention and erased when necessary,” said Barratt.