GDPR-compliant backup

A backup is often the last resort when it comes to loss of data or encryption by an extortion trojan.
In order to make the backup GDPR-compliant, the handling of deletion requests should be included in the backup and restore concept in accordance with Art. 17 GDPR.

Backup strategy: Perform backup in compliance with GDPR

In order to meet the requirements of Art. 5 GDPR and Art. 32 GDPR, it is essential to secure the data in the form of a backup.

The backup is intended to provide protection in the event of loss, destruction or damage to the data. A backup thus also guarantees the availability and the possibility of rapid restoration of the (personal) data.

You should always store backups offline and disconnected from the system. In this way, you ensure that these are not encrypted at the same time, for example in the event of an attack by an encryption Trojan. This is the only way to restore the system and data from the backup.

The frequency with which a backup is created should be based on the frequency with which the data is changed so that the most current data possible is contained in the most recent backup in the event that the data is restored using a backup. For companies with transaction frequencies, such as banks or online shops, it makes sense to back up data every hour or even more frequently. For other systems in which the data does not change so quickly and in terms of quantity, a daily backup is usually sufficient.

You should also regularly test the recoverability of the backup.

In order to regulate all these points uniformly, a backup and restore concept should be available in every company, which is often used from a data protection point of view as evidence of compliance with the requirements of Art. 5 GDPR and Art. 32 GDPR.

Deletion requests and backups

Now the question arises: what to do if e.g. a customer makes a deletion request in accordance with Art. 17 GDPR and whose data is of course also included in the backup?

Restore the backup, delete the respective data and then save the changed data again? That would be a considerable effort if this were done for each individual deletion request.

One possible solution, taking into account the proportionality of time, effort, costs and purpose would be that the deletion requests in the active system are of course carried out accordingly. In the event that the data is restored from the backup, the deletion requests should be documented accordingly and, in this case, the corresponding data should be edited or deleted again. This procedure should be noted in the backup and restore concept. To ensure that this process does not misuse it, it must be ensured that only a few people have access to the backups.

This post is also available in: German