filerskeepers data retention schedules explained!

Our data retention schedules provide you with a comprehensive overview of all legal and regulatory rules that prescribe or inspire the storage and deletion of data or records. We call these “Retention Obligations”. A retention obligation can follow from the law (whether federal/national or state/provincial), subsidiary legislations (decrees, ordinances, orders, etc.), regulatory guidance or even industry standards. As a general rule, we look at guidance from competent authorities including data protection, financial, and telecom regulatory authorities.

Where can you access our legal retention obligations?

Our Dashboard

You can access our legal retention obligations in the filerskeepers Dashboard through various functionalities: the Retention Viewer gives a full overview of the retention obligations in our dashboard. You can then add legal retention obligations to a Business Rule (you do not have to). And when you create a MySchedule we will show the legal retention obligations in the jurisdiction specific results.

Our API

You can receive access to our legal retention obligations through the filerskeepers API. You will need an Enterprise tier or partnership agreement with us to gain access to our APIs.

Our Excel Sheets

You can also download our data retention schedules in an Excel format from our dashboard’s Retention Viewer.

Retention Obligation View

Retention obligations are represented as rows in our Dashboard, MS Spreadsheet, and API. You can see some samples of our Dashboard and Excel view of retention obligations on the left.

Structure of a Data Retention Schedule: Our style

We’ve organized our data retention schedules uniformly based on our taxonomy, which is a list of topics we frequently investigate.

Jurisdiction Name

We will first give you the name of the jurisdiction (so country or state) for the respective retention obligation. We will always name the lowest jurisdiction. If this is the country this will be e.g. Belgium or Nigeria. If this is a state we will say: California or British Columbia. If you are interested in federal or national rules always go for the country specific results.

Identifier

We will give you a semi unique identifier per retention obligation. We have truly unique identifiers, but they are under the “hood” and can only be consumed through our APIs. An identifier is meant to identify a unique retention obligation in our database. It will inform you about where in our taxonomy you are. To give an example: AD1.1.1.a is build up as follows: AD is the ISO-2 code for Andorra. The 1 means the first category (so “Accounts and Legal Records”) the second 1 means the 1st subcategory (so Bookkeeping, financial and accounting records) and the last 1 means the 1st record type (so Company accounts and books, including balance sheet, profit and loss account), the a means the first retention obligation within this record type.

Categorization

With hundreds and thousands of retention obligations, It is often difficult to navigate through them to find the ones relevant to you. To simplify these navigation processes we have structured our data retention schedules in 3 layers: Categories, Sub Categories, and Record Types.

Categories

Each data retention schedule comprises several categories. Each category covers an important retention topic such as accounts and legal records, HR, and data privacy that are universal to all companies and are crucial for business processes or classes of information. Our categories also cover industries such as the financial services industry, the telecommunications industry, and the manufacturing industry. Our dashboard has the categories listed on the top in the retention viewers section right beside jurisdictions. We have Excel sheets also that comprise various categories and our API provides an option to see what categories are available for a given country.

Subcategories

Although the categories segment the data, we noticed that regardless of that it is quite broad since each category has hundreds of retention obligations. Therefore we introduced subcategories to streamline your navigation experience further. These subcategories help distinguish the most important classes of retention obligations per category. For example, recruitment data, personnel files, payrolling, benefits, and severance pay are subcategories under the HR category. These subcategories further explain which actors in a given industry are regulated, for instance, insurers, banks, investment intermediaries, and pension providers are subcategories under the Financial services industry category. These subcategories are listed under categories in the Dashboard.

Record Types

Record types are the third layer we introduced under categories and subcategories to further specify the retention obligations to simplify the user experience further. Record types refer to data and records that are meant to be regulated. Our Excel sheets include all the record types in a natural flow under the subcategories. However, our advanced Dashboard and API take the experience one step up by streamlining what retention obligation belongs to what record type.

The actual content of the Retention Obligation

Per retention obligations explain further 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 try to stick as close to the original legal text as possible.

Who Keeps The Records

In managing the record retention schedules, it is important to identify who is being regulated. We offer a wide variety of industries that are presently used by industries like fashion, banking, food, chemical manufacturing, and so on. By looking at the section “Who” in our schedules, you can clearly identify if the law applies to you. We try to specify and keep them aligned with the law as much as possible. Statutory limitations are labeled as “anyone” as these rules often do not mention any specific party and could be relevant for anyone enforcing a certain right.

What Needs to be Kept

Now that you know who needs to keep the records, it is essential to know what should be kept. We closely analyze each law and seek out which information should be retained. Following the general rule, we stick to the law, for example, we don’t 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. We also include all the specifications on the data that should be kept if it is provided by the law. We provide legal references through our Dashboard and API to simplify your retention process. There are two ways we start our description of 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.

Minimum, Maximum, or Maximum (statutory limitation)

In our data retention plans, we outline both minimum and maximum timeframes for keeping information, along with statutory limitations. Minimum timeframes mean you can’t delete data before a certain period, but you can retain it longer if privacy laws permit. Maximum timeframes indicate when data shouldn’t be stored beyond a specific legal obligation. However, statutory limitations may vary; if there’s another legal requirement within the same jurisdiction applying to the same data, you might keep it for that purpose. When it’s time to delete, it should be done permanently and irreversibly.

Additionally, considering the risk of potential legal disputes in the future is important. Statutory limitation periods, which dictate the maximum time within which someone can file a claim, often guide what data to keep and for how long. In our schedules, we mark these limitations as “Maximum (statutory limitation).” Nearly every country has data protection laws stating that data shouldn’t be stored longer than necessary. Data protection authorities usually don’t allow companies to retain data beyond statutory limitations, as these limitations affect the legal basis for processing. This principle aligns with recent guidance from the processing on a contractual basis by the European Data Protection Board (EDPB). on processing based on contracts. There’s a distinction between a “maximum” retention period and a “maximum (statutory limitation).” The former requires data destruction according to a specified obligation, while the latter refers to data protection laws impacting record retention, even if not explicitly part of a retention obligation. Lastly, GDPR and other data protection laws emphasize not storing personal data longer than needed for its original purpose. Consequently, nearly every minimum retention period for data containing personal information essentially becomes a maximum retention period.

How Long the Data Should be Kept

The retention period is the beating heart of our data retention schedules, where we tell you precisely how long you need to store your data. This can be a period of years, months, weeks, days, and even in very rare cases hours (think of telecom regulations or CCTV recordings in certain countries). We give you a clear idea of what the law requires you to do. However, we have one exception, If the law has a permanent storage period or simply says “keep” without attaching a specific retention period to this, we will use a “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 idea behind setting a permanent retention period is mainly tied to a company’s lifespan. However, we’ve designated it as a minimum retention obligation because specific stakeholders, like liquidators, former directors, or shareholders, might need the chance to retain certain data for longer periods.

From When Data Should Be Kept (the from date or trigger)

To run a records retention program properly, knowing when the clock starts ticking is crucial. A retention trigger marks the official start of storing a record or data based on what the law dictates. It’s like setting a timer for when you need to keep something – whether it’s seven years from its creation or 27 years from the end of a 20-year contract. Laws use different ways to explain when this timer begins. In our retention schedules, we’ve summarized these ways into two approaches: 1. “From the date [on which/of]” means the retention period starts from the relevant date or event mentioned in the law. 2. “From the date following [the day on which/of]” indicates the retention period starts the day after the relevant date or event, as stated in the law.

Legal References

We aim to be transparent and always provide you with sources so you can double-check our work. We always mention the legal source of each retention obligation, referring to it as an “article” for consistency, even though laws might use different terms like sections or paragraphs. We provide a link to the official publication of the law in the country’s official language to ensure accuracy, avoiding English translations that might not be as up-to-date.

Try a free sample data retention schedule!

Want to see how our data retention schedules look like first? Try a free sample now!