The Right to Erasure (Right to Be Forgotten) (Article 17 GDPR) (Chapter 2, Section 5) — Guide to the GDPR

The right to be forgotten introduced by the GDPR is not a completely new institution. It should be treated as a development and clarification of the current legal status and the case law of the CJEU. However, the new regulation needs to be carefully examined. It imposes far-reaching obligations on data controllers which will require insightful consideration, especially in terms of the technical aspects of implementing solutions that enable individuals to exercise their rights.

The Data Protection Directive (replaced by the GDPR), mentions the right to request the deletion of data not processed in accordance with the provisions of the Directive, especially due to incompleteness or inaccuracy of the data (Article 12 b of the Directive).

The most famous judgment of the CJEU regarding the right to be forgotten is the judgment of 13.05.14, C-131/12, Google Spain SL and Google Inc. vs. Agencia Española de Protección de Datos (AEPD) and Mario Costeja González, EU:C:2014:317. In this case, the Court examined the question of the processing of personal data by the internet search engine in the context of search capabilities based on the name of a given person. The Tribunal decided that the search engine operator should be considered as the data controller, and the data subject may request the discontinuation of processing so that the information in question would no longer be visible to searchers. The Tribunal derives this right from Articles 7 and 8 of the EU Charter of Fundamental Rights (OJ EU C 202, 2016, p. 389) – the right to respect for private and family life, home, and communication and the right to the protection of personal data. The wording: ‘so that the information is no longer visible’ reflects the functional meaning of the right to delete data.

According to Article 17 GDPR, a person may request that a data controller immediately deletes data relating to them. The controller is obliged to:

The data subject may request that their data be deleted by the controller in cases where:

The GDPR imposes the ability to request the deletion of data when this data is no longer necessary for the purpose for which it was collected or otherwise processed.

This requires the interpretation of the principle of purpose. For example, when data is no longer useful for performing a contract because the contract has already been executed, it will still be useful ‘in case of claims’ until the expiry of the limitation period. Therefore, the expiration of the primary purpose of data processing does not necessarily mean that the data has become unnecessary. The person requesting the deletion of their data has the right not to know this. Essentially, it is up to the controller to ‘do their homework in assessing the life cycle’ and usefulness of personal data by implementing the GDPR. The ability to request the deletion of data when it is no longer useful is a supplement to the principle of minimising the processing time of personal data (time restriction, retention).

A data subject may request the deletion of their data after withdrawing consent for its processing, provided there is no other legal ground for processing. As in the case of the purpose for which the data was collected no longer being relevant, this data should also be deleted on the controller’s own initiative. Data processing may take place only in accordance with one of the legal grounds provided by the GDPR, so the lack of any such basis should be considered as exempting the possibility of further processing. A deletion request issued after the withdrawal of consent, or at the same time as withdrawal, should also be treated as an additional obligation of the controller.

Practical problems may arise when there is an alternative legal basis for data processing and consent has been withdrawn. To avoid ambiguity, the controller should clearly identify the legal basis for processing the data (e.g., it is a common mistake to request consent to process data when the data is needed to conclude or perform a contract), as well as the data life cycle and possible scenarios for its use.

Now let us make an observation that when processing took place based on consent (e.g., marketing communications were sent) data should be deleted from consent databases (a marketing database), but we believe the controller is not obliged to delete such communications or the initial consent from the data controller’s systems as they serve to prove the legitimacy of such communications (principle of accountability). The legal basis for processing would be the controller’s legitimate interest (Article 6(1)(f) GDPR).

The controller is obliged to delete the data of a person who executes their right to object to the processing of their data. The right to object is discussed separately. This topic is quite complicated in itself, so it cannot be covered in full here, but we can give an example. Objecting to direct marketing does not require any justification. Therefore, if a person objects to direct marketing and requests the deletion of their data, their demand must be met. This example seems to be simple, but in reality it is not. In reality, the situation is identical to that described in a preceding paragraph concerning a withdrawal of a consent. A data controller is obliged to delete an objecting person’s contact data from the data controller’s marketing database but not to delete communications preceding filing an objection to processing. Moreover, if the data subject is at the same time the data controller’s client, the data controller will not delete the contact details of that data subject from the data controller’s CRM, but instead an objection to direct marketing has to be registered in the CRM system or otherwise if the CRM does not have such functionality. As in the cases discussed so far, the obligation to delete data actually results from other regulations of the GDPR, so this provision should be treated as a supplement and, in principle, a description of the effects of objecting data processing.

The processing of personal data in accordance with the law is the guiding principle of data processing (legality). The failure to adapt data processing within the organisation to the requirements of the GDPR may lead to serious consequences – especially financial – for the controller.

If the controller refuses a request to delete data on claiming the processing is legal, it is likely that they will come into conflict with the data subject. The controller should be prepared for this eventuality and take into account the need to defend their position.

The burden of proving the legality of processing by demonstrating compliance with the requirements imposed by the GDPR lies with the controller, so the processes of data processing should be clear enough to be able to demonstrate the appropriateness of processing relatively easily. Data processing should be constantly monitored by the controller so that any irregularities can be detected immediately, and the controller should always be ready to demonstrate the legal compliance of the processing. Probably the best tool to map and monitor business processes involving data processing is an RDPA in most cases required anyway by Article 30 GDPR.

A request to delete data can also be made when the controller is faced with a direct legal obligation to delete it resulting from EU law or national law.

One of the intentions of the GDPR is to facilitate the deletion of data posted by children online. Requesting the deletion of data makes it possible to ‘fix’ decisions taken during childhood. The GDPR has stricter requirements when it comes to the ability to process the personal data of children in terms of the use of information society services.

As set out in Recital 65 GDPR, even if the data subject is no longer a child, they have the right to request at any time the deletion of data they shared as a child.

The GDPR stipulates a number of exceptions which exempt the controller from having to comply with the right to be forgotten. Data does not have to be deleted if the processing is necessary for any of the following reasons:

This exception acknowledges the possibility of conflict between the rights of the individual regarding their data and the right to freedom of expression and information, which also belongs to the catalogue of fundamental freedoms described in the Charter of Fundamental Rights. The right to freedom of expression and information includes the right to obtain and transmit information.

When citing this exception, we need to take a balanced look at how these values clash in the case in point. Guidance comes from the above-mentioned judgment C-131/12, Google Spain, in which the Court noted that the removal of links to certain information might cause conflict with the interests of internet users trying to access this information. The interests of internet users may be strengthened, for example, by the data subject playing a particular role in public life (judgment C-131/12, Google Spain, point 81).

When refusing to delete data on the basis of this exception, the controller should not only consider the opposing interests but also justify their position in detail. The press will usually rely on this exception, though in most cases probably the Member States enacted specific provisions of their national laws to deal with a conflict of interest between the right to privacy and the freedom of expression and information.

Complying with the law or performing a task carried out in the public interest or exercising of official authority vested in the controller overrides the right to erasure.

The legal obligations regarding the processing of personal data will result from various provisions (e.g., the creation of medical records, employers keeping personal files), depending on the type of business. It is the responsibility of the controller to be familiar with these regulations and to keep track of any changes that may have consequences for the processing of personal data.

The exception of public interest in the protection of public health may be invoked by a controller who processes data necessary for the purposes of preventive health or occupational medicine, to assess an employee’s ability to work, for medical diagnosis, the provision of healthcare or social security, the treatment or management of healthcare systems and services or social security under the law of the EU or a Member State, or in accordance with a contract with a healthcare professional, provided this data is processed by a person obliged to observe professional confidentiality – in this case, doctor–patient confidentiality, nurse–patient confidentiality, etc.

In addition, the controller may refuse to delete data if its processing is necessary for reasons related to public interest in the field of public health – for example, protection against serious cross-border health threats, or ensuring high standards of quality and safety for healthcare, health products and medical devices.

This exception should be treated as an ‘industry’ exception, applicable to the medical and pharmaceutical sectors. In addition, the possibility of its use is limited by the issue of the existence of public interest in relation to the processing of data. The public health exception is sometimes abused in some countries as pharmaceutical and healthcare sectors are heavily lobbed.

Processing for these purposes may take place if it meets the conditions stipulated in Article 89 the GDPR. This means that such processing must be subject to the appropriate safeguards of the rights and freedoms of the data subject. These safeguards should involve the implementation of suitable technical and organisational measures to ensure that the principle of data minimisation is respected.

The wording of the provision indicates that the controller may invoke this exception if the processing complies with the terms of Article 89 and, at the same time, if exercising the right to be forgotten will prevent or seriously hinder the realisation of the goals of this processing.

The means by which the requirements of Article 89 GDPR can be met include: securing IT systems where data is located or processed, authorising access for people conducting research, and signing confidentiality agreements with people involved in the processing. The choice of resources should depend on the type of activities carried out. For example, if the data is used to extract statistics that refer exclusively to current trends within a certain group of people, without publishing their identities, then the controller should take measures to ensure that the identities of the people whose behaviour was studied do not become widely known.

This exception will apply mainly in cases where there are outstanding debts or other dispute proceedings between the controller and the data subject. It will allow the controller to pursue their claims pending the termination of enforcement of the obligation imposed on the data subject relative to the controller – for example, against a former client. This exception also allows for storing data for defensive purposes. When combined with the accountability principle it could actually lead a conclusion that storing data up to prescription deadlines which in some countries is up to twenty years (in relation to claims resulting from crimes) is justified. Of course, when further combined with the risk-based approach, the data controller might perform a risk assessment to counterweight risks resulting from storing data for a longer time (data breach mainly) against risks resulting from earlier deletion of data (mainly deletion of evidence). A practical issue most of the controllers encounter is though how to separate data outdated from ‘usable data’. Dealing with the latter requires adopting the privacy by design approach and redesigning a data storage logic and systems which is a major challenge to any organisation.

The controller should immediately delete data for which a valid request for deletion is received. This applies to all places where the data of the person exercising their right to be forgotten is located. This usually means the servers used by the controller, including email servers (though an exception from Article 11 GDPR may apply), documents in the organisation’s resources, and contact details – both digitised and paper copies. The data should be deleted in such a way as to exclude any access to it in the future, especially access that enables the identification of the data subject. One of the proposed ways of deleting personal data from paper copies is blacking out the relevant data in paper documents and replacing identification data with meaningless data in computer databases entries (to avoid decomposing of a database).

However, we should keep in mind the basic issues that can be determined by residual or technical purposes of data processing, particularly two of them:

We should also be aware that deleting data in a way that is understood explicitly as completely forgetting about the data and the person goes against the principle of accountability. In the field of accounting, where the principle of accountability prevails, there is no such thing as deleting data. There is only the addition of a negative state (contra entry, red-ink entry). The question of how to effectively achieve the purpose of the right to delete data without exposing all personal data to an unacceptable level of risk forms the axis of the problem and the dispute over the right to delete data.

Another area of potential conflict is unstructured data (Article 11 GDPR). As a rule, the controller is not required to search all of their information resources to find and delete data. Where the controller does not know the identity of the people whose data is being processed (including the content of the data being processed), it is generally not necessary to search this kind of unstructured data only to erase the data of the person requesting the data deletion.

The implementation of the right to be forgotten should be documented in case of a potential dispute and to facilitate accountability. This makes it hard to imagine the complete erasure of a person from a company’s memory. In this case, like the lead singer of Chumbawamba’s hit song Amnesia, we would not remember whether we were meant to forget something.

From a functional perspective, the right to be forgotten serves to ensure that a company or other organisation does not perform certain activities with regards to the concerned party or does not spread certain information about them. Erasing information from a company’s systems does not protect us completely from the company ‘assimilating’ this information again, in particular when information is exchanged between different controllers (hence the obligation to inform other controllers about the deletion). Therefore, it is possible that, in addition to deleting all information from the company’s ‘production’ systems and resources, it will be necessary to add the person to a list of exceptions (people whose data is subject to processing restrictions), such as a Robinson list (people who do not wish to be contacted, etc.). Moreover, different business units may collect deleted and then ‘prohibited’ data separately, so there need to be a mechanism in place allowing to identify data ‘forgotten’. Specialists point to a mathematical hashing function as a method of marking specific data without knowing their contents. Theoretically, that can be used to recognise and ban data forgotten in result of a specific data subject request. However such solutions need to be developed to achieve market maturity; their developing probably will not be cheap, and they will not be error-free, especially taken into consideration variations of the natural language and required multilanguage capabilities.

The supervisory authorities take the position that everything should be deleted, including backup copies and archives. The UK Information Commissioners Office as well as the Polish Ministry of Digitalisation recommend to delete data from backups and logs, by manually ‘reheating’ the backup, deleting the data and then ‘refreezing’ the copy. We do not advocate this approach if backups are made on magnetic tape. It might make sense if online storage is used for backup.

Deleting or changing individual data from a backup copy deprives the copy of integrity, may impede or prevent its subsequent reproduction, and thus compromises the security of the information. It increases the threat to the integrity and availability of all personal data in the backup. Therefore, deleting data from backups as a rule contradicts the data security principle.

In fact, tampering with backup copies generates a problem with accountability, hinders or prevents the use of the copy as evidence, and opens up routes to abuse.

Single or multiple interferences with backup copies can be difficult to handle from a resource and backup process perspective. The concept of ‘rewriting’ backups creates an organisational problem.

In theory, it is possible to imagine the development of this process. However, this will generate significant costs, and – even worse – in the long run, it will lead to the centralisation of personal data processing, therefore increasing the threat to privacy.

The rationale, terms, and scope of data deletion can be reconciled at the level of the GDPR with information security and common sense:

There are technical possibilities for appropriate re-deletion without coming into contact with the content of the data to be deleted. The record subject to deletion (which can also be done by overwriting with generic data, if we use some kind of anonymisation to delete the personal data) can be marked with a unique identifier. Then, when performing the original deletion, all you have to do is record the ID on the exceptions list and, if you restore the backup, automatically delete or overwrite the identified data with the original replacement content. Companies to which we have recommended this approach have highlighted the option of using a compound key. This may consist, for example, of the system ID and the client’s personal ID number. As a result, if necessary, we are able to reach and identify the data in the backup so that it can be automatically deleted on the restored copy. If the system will not mark a record with a unique identifier by itself, you can use a different method of identifying the ‘forbidden’ content, such as a checksum.

The right to delete data creates another problem of interpretation, which can be seen when compared to a stance of the Polish Ministry of Digitization: ‘The controller must ensure appropriate technical and organizational measures enabling the complete deletion of the data of a person who is exercising the right to be forgotten. It is necessary to delete the data from all places, including: servers, email, Word and Excel files, external and portable disks, and paper copies. The storage of the data by the controller alone still qualifies as personal data processing.’

The Ministry refers to the necessity of also deleting the personal data of specific people from resources where the content is not really known – that is, from resources containing unstructured data (e.g., the content of emails and Word files). However, according to Article 11 GDPR, we do not need to implement the rights of an individual with respect to these resources until the data subject identifies themselves.

On receiving a data deletion request from Joe Bloggs, do we need to search all our resources, check through emails, documents, and so on, to determine all the places where he may have been mentioned and from where he will have to be erased? There is no clear answer at present. A literal interpretation of the GDPR would indicate that we actually need to delete all information about Joe Bloggs from our systems and therefore from emails, as well as from content developed by us or located in our documentary check. Does this mean that we need to change the content of previously written documents or delete them? Do we have to search all our information resources to identify occurrences of Joe Bloggs’ data and erase them completely?

It seems that the scope of data deletion is limited to the data in relation to which Joe Bloggs identifies himself – it is not enough simply to present himself; he must also indicate the data (information resources) where he might appear. However, this is not a trivial interpretation, and it requires some deliberation.

Another problem – once Joe Bloggs has defined the scope of the data, we need to try to resolve the issue of deleting it from our documents on the grounds of the data processing purposes.

We could probably find a good basis for our lawyer’s data processing (e.g., overriding legitimate grounds), but this is the kind of dilemma we face after GDPR.

According to Article 17(2) GDPR if the controller ‘make published’ the data which should be erased, the controller should inform controllers which are processing data subject to erasure about the request to erase the data made by the data subject, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures. These are mostly quotations from the letter of law, which we repeat here as they require a few words of explanation.

The duty to inform other controllers in case data subject to erasure were published (made public) by the controller overlaps with the general duty to inform recipients of data about that fact that they were erased in result of application of the right to erasure provided by Article 19 GDPR. That duty applies to every recipient of data to whom the personal data have been disclosed unless this proves impossible or involves a disproportionate effort. Article 17(2) GDPR concerns specifically data published (e.g., in the internet, social media) and should be understood as making it clear that not knowing who actually reached to the data subject to erasure does not relieve the data subject from taking steps aimed at ‘withdrawing’ the erased data from the public space.

Reasonable steps to inform other data controllers about erasing the data previously ‘made public’ can be, for example, announcing it on the website where they were first published and directly notifying those who can be traced to delete all links, copies, and replications of this data. The data controller should approach that duty in a sensible manner, in particular consulting the way of acting with the data subject, in order not to achieve unintended results (e.g., the data subject might not be interested in publishing an announcement referring to incorrect data).

Based on Article 19 GDPR, the data controller is also obliged to notify the data subject about recipients of deleted data, should the data subject requests. We discuss understanding the notion of ‘data recipient’ in the context of Article 19 and how to comply with duties to notify in a relevant chapter below.

This obligation is subject to the following restrictions:

In short: you should do what is possible, and not disproportionately expensive, under the circumstances to inform everyone who should know that the data has been deleted.

Identify places where our organisation is keeping personal data.
Understand how our organisation processes data and how our employees use this data.
Set up a procedure for the data deletion process; appoint people to be responsible for verifying and handling requests.
Train employees.
Consider how the controller will be able to demonstrate the deletion of data once it has been deleted.
Implement technical measures to facilitate data deletion.

The above checklists should be treated purely as examples and indications of what directions to take. When planning activities, the controller should take into account the specific operating conditions.

#5.1 History of the Right to Be Forgotten

#5.2 Principles of the Right to Be Forgotten

#5.3 Basis for Requesting the Deletion of Data

#5.3.1 Necessity for the Purposes of Processing

#5.3.2 Withdrawing Consent

#5.3.3 Objecting to Processing Data

#5.3.4 Illegal Processing

#5.3.5 Legal Obligation to Delete Data

#5.3.6 Offering Information Society Services to Children

#5.4 Exceptions

#5.4.1 Exercising the Right to Freedom of Expression and Information

#5.4.2 Complying with Legal Obligations or Tasks Carried Out in the Public Interest or Due to Exercising Public Authority

#5.4.3 Public Interest in Protecting Public Health

#5.4.4 Archival Purposes, Scientific and Historical Research, Statistical Purposes

#5.4.5 Establishing, Investigating, and Defending Claims

#5.5 Scope of Data Deletion

#5.6 Processing in Order to Exercise the Right to Delete Data and the Right to Be Forgotten

#5.7 Processing to Ensure Security: Backup and Archive Problems

#5.7.1 Everything Means Everything

#5.7.2 The Problem of Security and Business Continuity

#5.7.3 The Problem of Accountability

#5.7.4 Practical Problems: Resources and Processes

#5.7.5 The Solution

#5.8 The Problem of Unstructured Data

#5.9 Informing Other Controllers

#5.10 Limitation of the Obligation to Inform

#5.11 Checklists

#5.11.1 Preparing for the GDPR: Implementing the Right to Be Forgotten Within the Organisation

#5.11.2 Processing Requests for the Deletion of Data