Is there anything tricky about a Data Retention Policy? Does anyone get a headache thinking about what to put into the policy and what outcomes the policy will help them achieve? Is drafting a Data Retention Policy a simple matter of slapping a few policy statements into a document and calling it a “Data Retention Policy”? Or, is there more?

To answer these questions, I’ve had to put on my curiosity hat. I’ve had to reflect on all the conversations I’ve had with clients over the years about data retention, data deletion, and retention schedules. I’ve had to stubbornly pursue (as any good lawyer would) a number of helpful answers, so that I can give you an overview.

Here I am, then, about to plunge into the icy waters of the Data Retention Sea…

What is a Data Retention Policy?

Conventional wisdom says a Data Retention Policy is a collection of policy statements about an organisation’s stance on data retention. It is typically an internal policy that tells employees (and perhaps contractors and other third parties) about why an organisation typically retains information, and the reasons for no longer retaining it. The policy can also be external, although, in a data protection context, people usually use a Privacy Policy to speak to an external audience about data retention.

Generally, a Data Retention Policy speaks to an organisation’s retention of personal information, but can also speak to confidential information or any other types of information. People usually use the policy to address the requirements in data protection laws about how long organisations may keep the personal information that they process. Additionally, some policies I’ve encountered also deal with data deletion, and set out the organisation’s general stance on data deletion.

How does a Retention Schedule fit into the picture?

The trouble, from what I’ve seen, starts with the generic, principles-based provisions that exists in most data protection laws about how long an organisations may keep information… Most of these laws will usually only tell you that you should keep information for as long as is necessary and delete it as soon as keeping it is no longer necessary. These laws speak about you keeping the information for the original purpose for which you collected it (except in the case of lawful further processing, of course). The two prominent exceptions to this general requirement are that you may keep it if there’s a law that allows you to, or if you have the data subject’s consent.

Most of these laws will usually only tell you that you should keep information for as long as is necessary and delete it as soon as keeping it is no longer necessary.

This, while seemingly simple, is the part that often gives many people headaches. They come up with Retention Schedules to set out the different laws that require them to keep information for specific periods. But these Retention Schedules have a potentially fatal flaw: how does an organisation find out about and consolidate these laws? The answer is especially tricky when one considers that laws change, and that there are laws that apply generally to all organisations, and laws that apply only to organisations in certain sectors or industries.

Is managing data retention an impossible mission?

I say no. It’s possible to create a useful Retention Schedule. I wouldn’t have to be Tom Cruise to help you with this mission. My experience says it’s tricky but possible to work out. The answer lies, firstly, in deciding whether to use data protection software or do it manually. One Trust and Microsoft Purview Compliance Manager hold some solutions. We can assist you in deciding which software would be best for your organisation. Just complete this software requirements form and we will be in touch with the next steps.

The manual road is the harder one to travel, but we can help you there as well. It involves a good amount of research, to be sure, but it’s not a road that’s impossible to navigate.

So, are you ready to jump with me into the icy waters of the Data Retention Sea?