GDPR and the Right to be Forgotten: How to process requests for erasure

How should you implement the Right to be Forgotten? Experts share best practices for dealing with customers who exercise their right to erasure. 

In an ongoing series, MyCustomer speaks with a panel of experts to try to bring clarity to some of the more opaque areas of the impending General Data Protection Regulation (GDPR).

So far, we have examined the issue of “legitimate interest”, with our team of experts answering what legitimate interest is and how to know if your use of data qualifies.

We have also explored repermissioning - specifically, how to know if you need to repermission your customers for consent to continue using their data, and best practices for repermissioning.

In the latest in the series, the panel is exploring the Right to be Forgotten.

How should you implement the Right to be Forgotten?

Kim Smouter, the head of Government Affairs at ESOMAR 

The ‘Right to be Forgotten’, or the ‘Right to Erasure’ under the GDPR, came into the spotlight with the now well-known case involving Google and has since been integrated into the new legal framework. It essentially means that any information held on the individual should be removed from your database and this has to be done within a month of the request being submitted to the organisation.

In practice, what this will mean for organisations is firstly having systems, databases and solutions that allow for this level of intervention, and secondly having the procedures in place to ensure that effective deletion takes place following receipt of the request. This might mean having to audit your systems and solutions to make sure these features exist and if they don’t to upgrade to new versions that allow for these sorts of intervention or to migrate to new solutions that will allow it. The impossibility of your organisation to respond to such a request due to technical incapability will not be an acceptable reason to request a request coming from a data subject.

Similarly, one of the challenges the organisation might face is that the information could be duplicated or triplicated in back-ups or the information might be found also with partners, as part of the right to be forgotten these back-ups must also have this information removed as well and this is where it gets particularly tricky. The law also requires organisations to take reasonable steps to inform and secure from partners the deletion of information the data subject has asked to be removed.

Some top tips:

1. Audit your systems, databases and softwares to ensure they allow you to delete data at an individual record level.
2. Make sure you have procedures and contracts in place that enable you to enforce the same requirement on your processors and their sub-processors so that you can guarantee effective erasure.
3. Consider implementing anonymisation techniques as quickly as possible so that you are not able to link the information back the individual and therefore not fall under a right to be forgotten request.   

Paul Laughlin, founder, Laughlin Consultancy

First, be clear as to the basis for the request for erasure of personal data. There are several valid reasons, including withdrawal of consent, data no longer needed to fulfil purpose originally communicated, data subject objects to your processing and you have no overriding legitimate interest basis, or your use was a breach of GDPR. However, I caution clarity on the case for erasure, because it’s not an absolute right.

With regards to how to implement such a request, the starting point is the work all organisations should have done as preparation – an audit of data you hold. One of the biggest challenges for many businesses is their lack of a single customer view. Disaggregated or disconnected customer data risks you only deleting some of the data you hold on an individual. Poor data quality can make this situation worse.

Minor discrepancies in customer data records, could mean you appear to have only deleted one version of your data on a person, while still processing or communicating using a slight variant. For this reason, investing in data quality improvement and more complete customer data indexing, is a sensible precaution before receiving your first request.

Your audit of personal data will probably reveal that different elements are held across your landscape of new and legacy systems. Prior to receiving a request, ensure you have a good understanding of the work involved for each system.

How long will it take you to find customer data on different systems? How interconnected are records, do you even have systems where it is not possible to delete data completely? Those systems which process data in a way that impacts customers (e.g. communications, service or product actions) should be prioritised for erasure. You should be able to justify why you prioritised certain deletions and why the time it takes is ‘reasonable’.

Given that the cost, or viability of deleting certain records, may be disproportionate to the impact on customers, it is also worth considering alternative mitigations. It may be sufficient to isolate data from processing (or wider user access). For some situations you might also consider the acceptability of aggregation or even just pseudonymisation. Your litmus test should always be is this action ‘reasonable’ and proportionate to any current or potential impact on the data subject. Honour deletion legitimate requests whenever you can, but be prepared for the possibility of a whole industry of agencies submitting bulk requests on behalf of clients. Once again, prioritisation and a prescribed process should help defend reasonable response times.

Your preparation for GDPR should have also included identifying any data processors or other organisations with whom you share personal data. Remember that you have a responsibility to also notify them of requests for erasure. As with your own actions to delete personal data, you should take ‘reasonable steps’ to do so, ‘without undue delay’.

Finally, be aware of your extra responsibilities with regards to children. As well as needing to take reasonable steps to identify that any personal data you hold belongs to a minor, they also have extra rights to deletion. They continue to hold the right, throughout their life to withdraw past consent and claim they did not appreciate the implications of sharing their data with you. The ICO is likely to always defend this right and so it is wise to prioritise making it easier to delete data where the person was a child at the time (e.g. restricting usage of this data anyway, like not adding to CRM or marketing pools).

Jim Roberts, director and founder, BlacklerRoberts 

The ‘Right to Erasure’ is a subject that has caused lots of conversation and hand wringing. Do they actually mean deletion of all personal data? Well yes they do, but there are considerations when looking to implement this, which impact not only the data controller but the data subject as well.

The first thing to consider is have you have completed a data audit and do you understand where personal data is collected, stored and used within your organisation? Without this, your ability to erase personal data will be difficult at best and you will run the risk of leaving instances of the person behind.

So assuming this has been completed, the ‘Right to Erasure’ procedure should consider the following elements:

1. Verify the identity of the individual making the request. A key part of several rights of individual is ensuring you authenticated the individual is who they say they are. Ensure you process considers how this will be achieved and the information required to proof identity.
2. Explain the implications of full erasure. Erasing all personal details will mean they no longer exist in your data universe, so if they reappear legitimately through say a 3rd party data provider or via a subsequent purchase, they will then be treated as a new person. This impact should be identified and explained to the individual to ensure they want actual erasure or do they want to Restrict Processing or Object to Processing.
3. Inform other recipients of erasure. As with rectification and restriction of processing, there is an obligation to inform recipients of the personal data, unless this proves impossible or involves disproportionate effort. Look at how this step will be achieved and what is practical.
4. What to erase? All personal data of the person requesting the erasure. If we assume that the request is valid and the data subject has been explained all implications of full erasure, then yes the onus is to delete all instances of personal data. In practical terms this may prove trickier to achieve and although is absolutely the target, is best achieved through a risk based approach. So using the data audit you have completed look at where data maybe held and then the impact of not deleting data. Implement procedures to remove personal data from those areas with biggest impact  and identify those areas where personal data maybe harder to find/remove and document your approach, for example internal Support Systems, with screen shots to explain a problem and solution, may contain personal data so could this obfuscated without losing the knowledge base type value.