The right to erasure is also known as ‘the right to be forgotten’. The broad principle underpinning this right is to enable an individual to request the deletion or removal of personal data when there is no compelling reason for its continued processing.
When does the right to erasure apply?
The right to erasure does not provide an absolute ‘right to be forgotten’. Individuals have a right to have personal data erased and to prevent processing in specific circumstances:
Under the DPA, the right to erasure is limited to processing that causes unwarranted and substantial damage or distress. Under the GDPR, this threshold is not present. However, if the processing does cause damage or distress, this is likely to make the case for erasure stronger.
There are some specific circumstances where the right to erasure does not apply and you can refuse to deal with a request.
You can refuse to comply with a request for erasure where the personal data is processed for the following reasons:
Certain information held in alms.NET falls under the reasons to refuse erasure. These include, but are not limited to:
Note that in all the above cases anonymisation is also not possible. This is because the records relate to the individual concerned and that individual will need to be identified, for example in the case of Grant awards made.
It should be noted that this process is about requested erasure, not deletion of input error. For some years we have not offered a delete option for contacts. This is by design as an audit trail of the creation should be retained even where this was done in error. It may be that some future implementation will allow the apparent deletion of contacts created in error while retaining the audit trail of the actions taken. This is not in scope for this document.
Where an erasure request is received we advise that the organisational process for handling erasure requests should include a scripted dialogue with the person requesting erasure. In the majority of cases this will have been triggered by some undesirable communication they received. It may be more appropriate, with their agreement, to apply a block on further communication while retaining their data to ensure that block is effective. This is especially true where the supporter may return to the database via a purchased mailing list in the future. Deletion of specific data within that contact record can therefore be handled on a manual basis.
It is also worth noting that your backup retention policy has an impact on this process. The supporter must be informed that this is not an instant process (the law states that erasure is to be carried out ‘without undue delay’), and record of the deletion must be kept for the duration of your backup retention time. This is so that the deletion can be re-applied in the case of a restore of that backup.
Where erasure is demanded, and the supporter is made aware of the potential consequences, and there is no legal requirement to retain the data then the data should be erased or anonymised.
In addition data may be acquired for a specified period of time, necessitating erasure after that time. Therefore a mass erasure process could be the entry point as well as direct erasure for an individual.
An erasure process will therefore be implemented that encapsulates known legal data retention requirements and warns of these if applicable.
Only if there is no legal requirement to retain the data can the process continue.
The erasure process should also offer a ‘dump’ of stored data prior to erasure for the purposes of responding to a data access request, as it may be the case that you are requested to provide all data currently held and remove it from your system.
The erasure process should then offer the options of erasure and anonymisation dependent on organisational policy. Erasure will remove all data including audit trails and supporter references. Anonymisation would remove only data that can identify the individual e.g. Name, address, phone number, email address, supporter reference and any other identifying data from the current data set and any audit trails.
We are working on developing a mechanism to support this requirement in alms.NET.
See our blog at http://www.westwood-forster.co.uk/blog/ for additional posts on GDPR as well as other topics of interest for our sector.