• home
  • blog
  • GDPR - right to erasure ('right to be forgotten')
02 March 2018

GDPR - right to erasure ('right to be forgotten')

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:

  • Where the personal data is no longer necessary in relation to the purpose for which it was originally collected/processed.
  • When the individual withdraws consent.
  • When the individual objects to the processing and there is no overriding legitimate interest for continuing the processing.
  • The personal data was unlawfully processed (i.e otherwise in breach of the GDPR).
  • The personal data has to be erased in order to comply with a legal obligation.
  • The personal data is processed in relation to the offer of information society services to a child.

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.

When can you refuse to comply with a request for erasure?

You can refuse to comply with a request for erasure where the personal data is processed for the following reasons:

  • to exercise the right of freedom of expression and information;
  • to comply with a legal obligation or for the performance of a public interest task or exercise of official authority;
  • for public health purposes in the public interest;
  • archiving purposes in the public interest, scientific research historical research or statistical purposes; or<
  • the exercise or defence of legal claims.

If a supporter requests erasure what cannot be erased?

Certain information held in alms.NET falls under the reasons to refuse erasure. These include, but are not limited to:

  • Financial records must be retained for six years.
  • Giftaid Information (declarations and claims) must be retained for six years, but HMRC recommend you retain them indefinitely for auditing purposes.
  • Where the data relates to the rights an individual has/had in regards to the organisation eg. Membership, or assigned agents, there is a requirement to retain that information in case of future investigation, especially where that relates to membership of decision making bodies. This is because complaints can be made against the organisation in regard to their members conduct and this has no time limit.
  • Grant application must be retained for 2 years, and records of any awards for 7 years. In addition certain grant award decisions may be required to be retained for longer periods of time.

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.

What is the process alms.NET will follow?

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 for additional posts on GDPR as well as other topics of interest for our sector.

Follow @westwoodforster

Other articles in this series



Leave a Comment




stay connected