How can organizations handle Right to be Forgotten requests?

by Ken Yip, Product Manager at Privitar

 
Complying with the Right to be Forgotten doesn’t have to be a binary trade-off between preserving the privacy of individuals or maintaining data utility. By leveraging the benefits of de-identified data, it is possible to achieve both.

What is the Right to be Forgotten?

The Right to be Forgotten (RtbF) empowers individuals to request the deletion of data relating to them and prevent entities from processing their data under the General Data Protection Regulation (GDPR).

To show how this works in practice, imagine that I use an online travel agency for some flight and hotel bookings. Once I’ve completed my trip, I may decide that I no longer wish to be a customer and that I would like them to delete any data they hold about me. I could exercise my right to be forgotten by submitting a request to the company asking that they delete any data relating to me.

The company receives my request and checks whether the grounds for complying with it (defined in Article 17(1) of the GDPR) are met. If the grounds are met, the company must delete the data about me.

However, the company has an incentive to retain some information. For example, the fact that the bookings existed may be relevant for analytics or their auditing requirements, even if those bookings can no longer be associated with an individual. In that case, the company needs to comply with the RtbF request, while retaining some information value in their systems.

Adhering to RtbF and Maintaining Data Utility

With Privitar, companies can generate de-identified data from their original data; this de-identified data could still be used for analytics after a RtbF request has been made, provided that the individual who has been “forgotten” cannot be reidentified in the de-identified dataset.

In the Privitar Data Privacy Platform^™, the mappings between the original and de-identified data are stored in the Token Vault; these mappings enable users to link the de-identified data back to its original value.

The Token Vault is the only place where the relationship between the original data and de-identified data is stored. Breaking the link between the original data and de-identified data in the Token Vault (i.e. removing the token mappings) can enable de-identified data to be used for analytics while still fulfilling the RtbF needs of individuals who are included in that de-identified dataset.

This method of deleting token mappings can enable organisations to respond to an RtbF request in one of two ways:

Either

1. ‘Forget’ the individual by anonymising data. Deleting the token mapping may be sufficient to anonymise the data within the meaning of Recital 26 of the GDPR.

Or

1. Reduce the risk to the individual’s rights and freedoms, allowing processing based on the ‘legitimate interest’ legal basis to continue. Deleting the token map makes it more difficult to re-identify an individual in the dataset, reducing the risk posed by the processing of their rights and freedoms. The GDPR allows controllers to continue processing if they can demonstrate an overriding legitimate interest for that processing to continue. Deleting the token map reduces the risk to the individual and may allow the legitimate interest to override that now-reduced risk to the individual.

There are some instances where deleting token mappings will not, on its own, be sufficient to meet RtbF requirements. This depends on factors including the nature of the dataset including whether it contains quasi-identifiers, the existence of other data, and who has access to the data.

Learn more about supporting the Right to be Forgotten in our whitepaper.