How does your software allow you to manage the ‘right to be forgotten’?
The right to be forgotten is more formally known as the ‘right to erasure’ in GDPR. It means that when an individual requests for you remove or stop processing their personal information, you must be able to do it within 30 days of their request.
It all comes back to the focus of GDPR being to enhance the rights that individuals have over their personal information and data.
Therefore, like when managing the ‘right to access’ for your data subjects that we discussed in part 1 of this series, you must also be able to comply with any requests for erasure free of charge unless you can demonstrate that the request is ‘manifestly unfounded’ or ‘excessive’.
Can I refuse a request to be forgotten?
GDPR does set out a number of instances where an organisation can refuse a request by an individual to be forgotten – for example, if your processing of their information relates to exercising the freedom of expression, or if you’re complying with legal obligations. A full list of reasons is available on the Information Commissioner’s Office website.
That shouldn’t be an excuse for complacency though, as it’s likely that most of the processing you do will not be covered by these exemptions.
So when does the right to be forgotten apply? For the most part, it will be when you’re processing an individual’s personal information with consent as your lawful basis for doing so (for example, if you’re marketing to that person).
It will also apply if you started processing or storing someone’s personal information with legitimate interests as your lawful basis for processing (such as fulfilling a customer’s order or investigating a complaint), but at the time you receive the request to be forgotten, those legitimate interests are no longer relevant or you cannot identify any overriding legitimate interests that would justify your refusal of the request.
The problem with ‘deleting’ personal information in order to ‘forget’ it
As far as the personal information contained in your software or database packages is concerned, you might think that complying with an individual’s request to be forgotten is as simple as hitting the ‘delete’ button for their record(s).
In some cases, this may well be true and it’s an easy job done. However, before settling on this as your approach to handling requests to be forgotten, it’s worth looking at whether simply deleting records has any further implications in your software.
The trick is identifying how best to meet your obligations for complying with the right to be forgotten without impacting the value of other non-personal information and data you have in your software.
For example, if you’re using a CRM package to manage your sales process, you should investigate whether deleting an individual’s record will also delete records of activity associated with it – such as conversations, quotations, order history or other points of contact.
Of course, you may have to remove some of this information as part of processing the request (specifically, if those records also contain personal information). But you should also check if this will consequently affect your top-level statistics and reports, such as those used for measuring any of your key performance indicators.
A better way to manage the right to be forgotten?
If deleting records outright will negatively impact the overall benefits that you get from your software, then it would be worthwhile looking into other options for managing requests to be forgotten.
One of these options would be seeing if your software contains options for anonymising records of personal information. This would mean having the ability to remove or permanently mask all the personal data in your records, while any other details on that record will stay untouched.
On the proviso that you will not be able to identify the person through the remaining information after you’ve anonymised the record, in many cases anonymization will be preferable to straightforward deletion.
However you choose to fulfil to requests to be forgotten, importantly, the options that are available to you in your software will depend on how your supplier has designed and structured the database that operates in the background.
For instance, if you do choose to remove rather than anonymise records, you should try to find out what your software does in the background when it ‘deletes’ something: does it actually delete it, or does it just hide it from your view? This matters as it may determine if information could accidently be recovered from by someone who wasn’t aware it was removed following a request to be forgotten.
What goes on in the background of your software may not be entirely obvious from what you see on your screen, so it would be worthwhile getting as much information as you can from your software providers before planning your procedure for requests to be forgotten.