Our data retention schedules include all legal and regulatory rules which prescribe or inspire the storage and deletion of data or records. We call them “retention obligations” (although not all of them technically count as such, please see below). A retention obligation can follow from the law, subsidiary legislations (decrees, ordinances, orders etc) or regulatory guidance. As a general rule we look at guidance from competent data protection,  financial, telecoms regulatory authorities.

A retention obligation equals one row in our MS Excels spreadsheets or API database. You can see an example of this on the left hand side.

We do not distinguish between “data retention” and “records retention”. Why? Because in a digital world legislatures and regulatory authorities care less and less about this distinction to be honest. Governments have the tendency to talk about data, information, records, registers, inventories, books and any other synonym you can think of. As a general rule we take that governments around the world want you to keep “information” regardless of its form so that they can exercise their regulatory powers and investigate compliance with rules. Such rules can apply to records in the old fashioned sense (printed paper) or the more modern version (a MS Word file) as well as data fields in a database. We appreciate that when it comes to managing retention obligations there are huge differences between “digital records” vs “hardcopy records” and “structured data” vs “unstructured data”. And although filerskeepers cares dearly about these differences, applicable law usually does not.

Our services start by knowing the law, and this is what we include in our data retention schedules. And when we know the law we can start building. For more information on add-on services please go to our pricing page. For more information on records retention please go to our FAQ page.

We have structured our data retention schedules all the same according to our taxonomy. Our taxonomy is a list of topics we always investigate. It was built on the back of our research. Our data retention schedules are structured in three layers: categories, subcategories and record types. This division makes it easier to browse through hundreds if not thousands of retention obligations.

Each data retention schedule contains a number of categories. A category covers either an important retention topic such as accounts and legal records, HR, data privacy that are universal to all companies.  These categories are closely linked to an important business process or class of information. On the other hand, categories can cover an industry such as the financial services industry, the telecommunications industry or the manufacturing industry. On our product pages we explain which categories we cover per schedule and in the API we provide for an option to see per country what categories are available for a given country.

We noticed that each category can sometimes contain literally hundreds of retention obligations. That is why we have come with a further refinement of each category in the form of subcategories. These subcategories are used by us to make distinctions between the most important classes of retention obligations per category. To give you an example: recruitment data, personnel file, payrolling, benefits and severance pay are subcategories under the HR category. Subcategories can also explain which actors in a given industry are regulated. Another example: insurers, banks, investment intermediaries and pension providers are subcategories under the Financial services industry category.

Even with the introduction of categories and subcategories we noticed that we needed a further specification of the retention obligations. This specification made in the third layer called “record types”. By record types we mean both the data and records that are meant to be regulated. Now, in our Excel spreadsheets you will find that although we have used the record types to put the retention obligations in the right order, we do not visibly include them. It is meant to give it a natural flow of each subcategory. Should you really want to access the record types and see what retention obligation belongs to what record type, please use our API. They are all in there.

Per retention obligation we will explain who should store, what should be stored, how long should be stored, when the retention obligation starts (trigger), and from which legal source this obligation originates (legal reference). As a general rule, we will try to stick as close to the original legal text as possible.

In our data retention schedules it is important to identify who gets regulated. Our data retention schedules are used by companies from various industries, from fashion to banking, from food to chemical manufacturing. As a result they include a wide variety of industries. By looking at the who you will know if a law applies to you. We try to make the who’s as specific as possible and aligned with the law as possible. We use “anyone” for statutory limitations as these rules often do not mention any specific party and could be relevant for anyone enforcing a certain right.

Now that you know who will need to keep, it is essential to know what should be kept. We read the law closely to seek out what information should be retained. As a general rule we will stick to the law. We will not say ‘user data’ if the law only requires you to store an ‘IP-address and login timestamp’. This will allow your IT team to implement the retention period. If the law provides a specification of the data that should be kept, we will include this specification. We do not attach examples of our own making. Examples will be a new feature of our filerskeepers API.

There are two ways we start our description of the what to store:

• “Information relating to [description of records/data]” to indicate a retention obligation.
• “Information relevant in view of possible [actions/claims]” to indicate a statutory limitation.

Our data retention schedules include minimum and maximum retention obligations as well as statutory limitations. Most retention obligations will amount to minimum retention periods. This means that you are not allowed to delete the data before the retention period has lapsed, but you are allowed to keep the data longer if this is allowed by privacy laws.

Some retention obligations will entail a maximum period. Maximum means that data should not be stored any longer for the purpose of the applicable legal obligation. If you can still prove that you need the data for another legal requirement (within the geographic scope of the law) which also applies to the same data you may store it for that purpose. No longer often means that data should be deleted and deletion should be irreversible.

In addition, you may need to think about the risk of future litigations. Statutory limitation periods (the maximum time within which someone can file a claim) are often very good guidance on what and how long you need to store data. In our schedules we identify statutory limitations by means of “Maximum (statutory limitation)”. We use this phrase to indicate that in almost every country there is a data protection (or one pending) which states that data should not kept longer than necessary. Data protection authorities generally do not accept that companies store data longer than a statutory limitation, hence the maximum retention period. The reasons for this is that a right to claim or to an action prescribes with the lapse of the statutory limitation. This has an effect on the legal ground for processing. This is also mentioned in the recent guidance on processing on a contractual basis by the European Data Protection Board (EDPB). Of course, this is a matter of interpretation and application. There is a difference between a “maximum” retention period and a “maximum (statutory limitation)”. The former means that data should be destroyed by the relevant obligation which is cited. The latter means that although a statutory limitation is not a retention obligation as such, there is a data protection law that impacts the retention of records.

Finally, never forget about the GDPR (and all other non-EU data protection laws). Data protection laws tell organizations never to store personal data longer than necessary for the purpose for which the data have been collected or used. As a result, virtually every minimum retention period relating to a piece of information containing personal data becomes a maximum retention period.

The retention period is the beating heart of our data retention schedules. We tell you exactly how long to store your data. This can be a period in years, months, weeks, days and even in very rare cases hours (think of telecoms regulations or CCTV recordings in certain countries). We will always tell you exactly what the law says here. There is one exception though. If the law has a permanent storage period or simply says “keep” without attaching a specific retention period to this, we will use “minimum 0 days from the date of final dissolution of the company”. The reason for this is that we always want to include a measurable retention obligation and well nothing is forever. If the company no longer exists it will not have a retention obligation. The logic we apply here is that a permanent retention period is primarily relevant for the duration of a company.  However, we have made it a minimum retention obligation because certain stakeholders such as liquidators, former directors or shareholders should have the opportunity to keep certain data longer.

It is impossible to sensibly manage a records retention program if you do not know when the retention period starts to run. A retention trigger is the moment when a law tells you when a maximum or minimum retention period or statutory limitation starts running. Easier said, it tells you when you should officially start storing the record or data.Why? It makes a big difference how long you need to keep something if the law say seven years from the date of creation (total retention period is 7 years) or from the date a 20-year contract has been terminated (total retention period is 27 years).

Different laws use different ways to explain when a retention starts to run. in our data retention schedules we have summarised these various ways in two manners:

• From the date [on which/of] to explain that the retention period starts running from the date of the relevant fact or event. The underlying law or regulation usually speaks of “from” or “on”.
• From the date following [the day on which/of] to explain that the retention period starts running the day following the date of the relevant fact or event. The underlying law or regulation usually speaks of “after” in such cases.

We want you to be able to check our work. That is why we always tell you the legal source where we got the retention obligation from. Firstly, we will tell you which article in the law we found the retention obligation. As a general rule we will always call every stipulation in the law “article”, it is a style choice we made. We are aware that some laws use section, clause or paragraph. Please don’t hate us. We will also provide you with a link to the official publication of the law in the official language of the respective country. As countries publish laws in their official language, we try to avoid English translations because we fear they my not be updated as frequently as the official language version.

We frequently update our data retention schedules. These changes entail changes in the law, new retention obligations, updates to links and sources, and new formats. When we publish a change, we will send you an email notification. When you download our schedules we will tell you what is new against the previous version by giving the first cell of the row a filerskeepers green colouring, explaining the nature of the change (new or updated) and what has changed. Please see the example on the left hand side.