What does the GDPR say?
The idea that personal data should not be stored longer than needed is not entirely new. In the EU legal environment, this idea is now introduced in the form of one of the personal data processing principles laid down in the GDPR – so-called “storage limitation principle”. Of course, this principle was not invented by the GDPR as we could have seen it already in the GDPR’s predecessor, now-repealed Data Protection Directive 95/46/EC.
The GDPR rules in respect of personal data storage limitations are neither detailed, nor self-explanatory. Article 6(1)(e) sets forth that personal data “shall be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed” and says little more than that.
In essence, this means that in order to avoid the application of the “storage limitation principle”, you either have to:
– transform personal data into a format that no longer permits identification of data subjects (in other words, to anonymise the personal data), or
– process personal data solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes.
In all other cases (in fact, 99,9% of scenarios), the data controller must not store the personal data for longer than necessary for the identified purpose. It means that the controller has to identify the retention period by itself, depending on the purpose of the processing. Thus, the retention periods are always purpose-driven.
At some point, the purpose might inform the lawful basis for the processing to rely on. For example, if we need data (purpose) to comply with some legal requirements, then “compliance with a legal obligation’ would be chosen as the appropriate lawful basis. In the same vein, if we need data to be able to perform our contractual obligations towards data subject, then “contractual necessity” would be relied on.
Consent, contractual necessity, legal obligation, and legitimate interest
Consent, contractual necessity, compliance with a legal obligation, and legitimate interest are by far the most usable legal bases in the practice of the commercial sector, while ‘public interest’ and ‘vital interests’ are, vice versa, normally rarely used.
When relying on ‘consent’, the controller normally has to limit the declared retention period to the duration of its purpose. There might be, of course, other circumstances that may trigger the requirement to delete the data (e.g., the obtained consent may be withdrawn by the data subject, while an individual may, under certain circumstances, also exercise the right to erasure and the right to object against the data processing) but this does not relate to the identification of retention periods as such. The same generally applies when ‘legitimate interest’ is relied on: the retention period is informed by the duration of the purpose’s existence, i.e. as long as the legitimate interest is present. In some cases the purpose might exist continuously or, at least, during an indefinite period of time – for example, when it comes to serving an individual with marketing messages, news updates, etc. In this scenario, the retention period should normally be connected with the moment of opting out of those messages (unless some other circumstances appear more relevant).
Things might get tricky when the processing relies on ‘compliance with a legal obligation’, while the purpose is to comply with that obligation. This basis refers to the laws of the EU itself or of a EU Member State (or, more accurately, of a country forming part of the European Economic Area). The extent to which this purpose is relevant might, thus, largely depend on how the provisions of a particular law are worded. Sometimes those might be vague – e.g., when attempting to rely on the local book-keeping law to justify the storage of data during a specified time period, the law might well set forth that the book-keeping is required in respect of, say, “documents used to preserve accounting information”. In the example above, it will then be a responsibility of the data controller to verify which data categories being processed will fall within the scope of “accounting information” and if the retention period will be informed by the requirement to comply with this legal obligation.
Similarly, reliance on ‘contractual necessity’ might pose a challenge when it comes to choosing appropriate retention periods. By itself, the scope of this lawful basis is limited, as defined by the EDPB Guidelines 2/2019. As the EDPB explains, “the legal basis only applies to what is necessary for the performance of a contract. As such, it does not automatically apply to all further actions triggered by non-compliance or to all other incidents in the execution of a contract”. Besides, when “the contract is terminated in full, then as a general rule, the processing of that data will no longer be necessary for the performance of that contract and thus the controller will need to stop processing”. Some specific scenarios might be covered by the purpose to perform a contract – e.g. storing some data for the purpose of warranties, sending formal reminders about outstanding payments or correcting errors or delays in the performance of the contract. Others, obviously, may not (e.g., exercising or defending legal claims arising out of the contract).
The inference from the above is that, by default, the controller may only store data necessary for the performance of a contract (and with the respective purpose) only during the contractual relations with the data subject and until the exchange of goods/services/payment has been finalised. Provided that some warranty obligations exist, the data necessary to perform those obligations might be stored by the controller until the warranty expires. However, the purpose of exercising or defending legal claims arising out of the contract will require identification of another legal basis, while retention periods should be set taking into account the statute of limitations.
An important sidenote here is that the same data categories might well be processed for several purposes simultaneously. When the retention period identified for one purpose expires, the factual deletion is, nevertheless, not required if the same dataset is processed for some other purposes, on the basis of other lawful grounds. Technically, if the same dataset is processed in the same system (database) for different purposes, this will require choosing the uniform retention period for this system – normally, this will be the longest retention period of those chosen for processing operations involving this dataset in question. It is also worth noting that storing the same datasets in the same system for different purposes and within different processing operations will likely require introduction of role-based access controls, so that the respective employees may only access those pieces of data needed to perform their duties.
The controller should have a documented data retention and deletion policy. A good policy plays an important role in ensuring the proper governance as it documents what pieces of data should be retained, establishes retention periods, describes methods of data deletion, and helps the controller to comply with the accountability principle. As appropriate, the policy might cover anonymisation aspects (or, alternatively, those might be covered in separate pieces of documentation). The policy should be reviewed periodically and kept up-to-date.
After the controller has identified data retention periods and put in place a data retention policy or schedule, it has to enforce them and factually implement retention periods, thus deleting personal data in a timely manner. The controller has to put in place a solid and workable process to ensure that personal data is timely deleted once the applicable retention period expires. Where possible (e.g., in multiple databases, cloud storages, etc.), the retention periods should be automated to facilitate the deletion. In other cases, the process for manual deletion should be properly designed to ensure timely deletion. When developing the deletion process, the controller should consider such issues as:
– who will be responsible for enforcing retention periods and exercising subsequent control (i.e., who are the process owners);
– are there any control mechanisms to prevent data loss and accidental deletion (those should be adjusted to the risk associated with the data, the scale of the processing activity being performed, and the volumes of data)
– is there appropriate training for responsible staff.
It is also recommended to have the designed process tested to identify any gaps and address them accordingly (e.g., through adding clarity to the process description, conducting additional trainings, etc.). Finally, if the controller has engaged third-party data processors, it should instruct them to delete or return personal data within specific timeframes.