The principle of storage limitation introduced by the GDPR states that personal data may only be stored for as long as is necessary for the purposes for which it was processed3. The permitted storage period must be limited to the absolute minimum. Therefore, personal data must be deleted as soon as the data is not necessary anymore. Further causes that trigger the data subject's right to be forgotten are inter alia the withdrawal of the consent or the absence of a legal ground for the processing. The obligation to delete personal data can thus be triggered by various events.

As soon as there is a reason for deletion, the data must be deleted. But how and, above all, who determines the existence of such a reason for deletion? Does the controller have to act on his initiative and check whether there is a reason for deletion, or is he only obliged to do so if requested by the data subject based on Article 17 of the GDPR ("right to be forgotten")?

The answer is: both! The controller must check independently during its processing activity whether there is a reason for deletion. In addition, he must also take appropriate action when receiving a request for deletion.

Companies shall implement an internal deletion concept to comply with their deletion obligations. Such deletion concept should include the deadlines for deleting different categories of personal data and the regular checks for reasons for deletion. Further, the identified deadlines for deletion should be transparently documented in the record of processing activities.

However, the controller must not rely solely on its deletion concept and its record of processing activities when dealing with deletion obligations. These two tools only show the abstract route to erasure. The deletion goals set out in the concept, and the record must then also be implemented in practice. To do this, the data controller must choose from different technical implementation variants.

To implement a deletion concept, appropriate technical data management is needed. First, the company must become aware of which systems process which data to assess the internal data flow. However, analyzing one's own data streams is not enough to delete the respective systems. To do this, the systems must first be connected to a central data management service for data deletion. Such a data management service can also be used to implement other data subjects' rights (especially to respond to requests for information or deletion).

From today's perspective, there are two feasible options for designing such a central data management service:

1. Either the service fetches the data live from the individual systems or

2. all data (at least of one category) is consolidated by the service in a uniform data collection and kept up to date there.

The second alternative has the advantage of the consolidated data being used for other analysis purposes (such as automated information on the expiry of individual deletion periods). However, the connection of the internal service for data deletion to the individual systems can be a significant challenge, especially when it comes to exotic systems and proprietary developments by companies.

To comply with the deletion obligations under data protection law, both an abstract plan (i.e., deletion concept and record of processing activities) and practical implementation utilizing a suitable data management service is required.

In addition to the active obligation to delete data under GDPR, Article 5 (2) of the GDPR also establishes a general accountability obligation for the controller. Therefore, the controller must prove to the supervisory authorities that it has complied with its data protection obligations for deletion. Therefore, every data minimization measure should be documented in an audit-proof manner to make it objective and verifiable.

In addition to the active obligation to delete data under GDPR, Article 5 (2) of the GDPR also establishes a general accountability obligation for the controller. Therefore, the controller must prove to the supervisory authorities that it has complied with its data protection obligations for deletion. Therefore, every data minimization measure should be documented in an audit-proof manner to make it objective and verifiable.

With many data protection obligations, it can often be challenging to maintain an overview and not invest too many resources in data protection-related tasks and thus away from the core business.

Therefore, we have developed our Compliance Cloud. The Compliance Cloud Data Protection Module gives you the required overview of your data flow, creates reports and documentation for internal and external audits within seconds, supports you in creating deletion concepts and records of processing activities, and assists you in handling requests for information and deletion.

While our Compliance Cloud supports you in the abstract tasks related to your deletion obligations from A to Z, our Trust Layer plays its strengths in your favour when it comes to the technical implementation of your deletion concept. This is because the Trust Layer acts as a consolidated data collection. It can be connected to your internal systems or other data management services via suitable interfaces. In this way, it is possible to analyze the personal data available regarding their deletion deadlines, origin, and processing status. The Compliance Cloud thus actively supports you in complying with your data protection obligations.

In addition, the Trust Layer can be extended with a blockchain-based notarization function, whereby the entire history of the processed data, as well as the deletion or information notices submitted to data subjects, are stored in an audit-proof manner. The actual deletion or the information provided is thus stored in an audit-proof way. This means that it is possible to objectively prove to anyone at any time that individual deletions have been carried out. Our blockchain-based notarization function is 100% compliant with GDPR. Do you want to learn more? Then, get in touch with us!