GDPR, the right to be forgotten and backup systems

As you probably already know, on May 25, 2018. new provisions on the protection of personal data enter into force - the so-called GDPR. One of the novelties defined in the regulation is the right of persons whose data we process to "be forgotten". They are defined in article 17 of the GDPR, the content of which is as follows:

Art.17

Right to erasure ("right to be forgotten")
1.The data subject has the right to request the administrator to delete his personal data without undue delay, and the administrator is obliged to delete personal data without undue delay, if one of the following circumstances occurs:
a) personal data are no longer necessary for the purposes for which they were collected or otherwise processed;
b) the data subject has withdrawn consent on which the processing is based in accordance with art. 6 sec. 1 lit. a) or Art. 9 sec. 2 lit. a), and there is no other legal basis for the processing;
c) the data subject objects to the processing pursuant to Art. 21 paragraph 1 against processing and there are no overriding legitimate grounds for processing or the data subject objects to the processing pursuant to art. 21 paragraph 2 against processing;
d) the personal data have been processed unlawfully;
e) personal data must be removed in order to comply with the legal obligation provided for in the Union law or the law of the Member State to which the controller is subject;
f) the personal data have been collected in relation to the offering of information society services referred to in art. 8 sec. 1.

However, the client's request, which seems to be easy to fulfill, raises some doubts. Backup system administrators pay attention to the fact that deleting a single record of personal data from an archival copy, which is stored on an external medium, sometimes in an external location and the use of e.g. cryptographic mechanisms is not a trivial task to be carried out. In such a situation, it is necessary to restore the systems from backup, delete the data of a specific person from them and re-archive them. For all these activities, we will need additional resources, time and availability of the infrastructure used for backup. What's more, data related to one person may appear in many IT systems, e.g. HR, financial, postal, as well as in utility applications used for business purposes. All this complicates our ability to meet the demands related to the right to "be forgotten".

So how to deal with this difficult situation? Unfortunately, backup software producers are not yet meeting the new market needs. While there are already solutions that allow you to restore individual files, e-mails or even SQL queries (eg Veeam) from backups, unfortunately, editing them in an archived form is not possible. In such a situation, we are faced with the need to review and perhaps modify our backup procedures. At the next change or choosing a new solution, it is worth paying attention to the functionality that allows for efficient restoration, modification and re-archiving of data. In the process of planning procedures, we should definitely take into account the fact that multi-level, incremental or differential backups involve the need to carry out additional steps.

Backup system producers have a lot to show off here. The market will be appreciated by those who are the first to offer functionalities such as:

• Possibility to edit archived databases using agents that support SQL queries
• Possibility to edit at the level of individual mailboxes and even e-mail messages in Exchange archives
• Possibility to modify the archived directory services database (e.g. Active Directory)

These are only some of the useful functionalities that can help us comply with the requirements of the GDPR.

But what until such solutions appear in the offer? The only sensible idea I have come across so far is to create a "forget register", i.e. a list of people whose data has been removed from production systems but still remains in backup or archival copies. Restoration procedures should oblige backup operators to verify that the first step after data recovery is to verify the list and remove all data from the restored resource. In order to avoid reservations regarding the fact that such a register itself is also a collection of personal data, it is worth using an identifier from the target system in it - e.g. user ID in the database, account number in the system or SAM ID in Active Directory.

Until a better idea, GDPR implementing regulations or new functionality appear in backup systems, this will probably be the most frequently used approach.