Data retention periods: how to set them and justify them

Retention tables look convenient: the document on the left, a number on the right. But the number in the table is a summary of someone else's conclusion, not your justification. When a supervisory authority or a person asks why the data is kept for five years, "that's what the table says" means nothing.

The second problem is that the table describes documents, while data protection talks about processes. The same email can be evidence of contract performance or just day-to-day correspondence; the retention period will differ. So we start from the process, not the document's name.

Write down what the data is needed for, and when that need ends. For performing a contract, the data is needed for as long as the contract is in force.

For calculating wages — for as long as payments and reports are being made. For candidate recruitment — until the recruitment process ends.

This step often gives a surprisingly short answer, and that is fine. The purpose-based duration is the baseline other periods are added to, not the final deadline.

Some retention periods are set by law: archiving rules, accounting and tax requirements, and employment and social insurance rules. Where such a requirement exists, it is copied out precisely with its source noted; for the specific periods and their sources, see Article 12(1)(2) and Article 13(1) of the Law on Documents and Archives; the specific periods are set out in the Internal Administrative Document Retention Schedule approved by Order No. V-100 of the Chief Archivist of Lithuania of 9 March 2011.

It is important not to broaden the requirement. If a law sets a period for one group of documents, that does not mean the same period applies to the whole file. This kind of broadening is exactly how organisations end up holding data for decades.

To the purpose-based duration, add the time during which a claim or lawsuit could still realistically arrive. It is derived from the limitation periods that apply to the relevant relationship; for the exact rules, see Article 1.125 of the Civil Code.

This period should be applied only to the data groups that would actually be needed in a dispute: the contract, its amendments, settlements, and material correspondence. Keeping an entire database for the full limitation period is not a justification — it is procrastination.

Once you have the three figures, check whether the longest period really needs the whole data set. Often it is enough to keep part of it: the contract without its annexes, the summary without the source documents, the decision without the full correspondence thread.

Another option is anonymisation. If the statistics need figures rather than names, the data can be anonymised before the period ends. Once anonymised, the GDPR no longer applies to it, and the problem disappears on its own.

The decision is written into the record next to the process: the period, what it derives from, when it was decided, and who decided it. One sentence is usually enough. Without this entry, in a year nobody will be able to reconstruct why that particular period was chosen.

If the period differs across data groups, write it that way. A transparent list of different periods holds up better than one round number for the whole process.

A retention period without deletion is just a declaration. Agree who reviews each group and when, how electronic data is deleted, how paper is deleted, and how this is recorded. In practice it is most convenient to tie deletion to a calendar cycle.

Do not forget backups, shared drives, mailboxes and former employees' computers. These are the most common reason data officially deleted three years ago is still found.

Retention periods are reviewed together with the record, at least once a year and whenever the process changes. The review asks three questions: does the period still match the purpose, is deletion actually happening, and could the data be kept for a shorter time.

A shorter period is not only a compliance question but also a risk question. The less data you hold, the less can leak, the simpler a breach assessment is, and the faster you can respond to someone requesting a copy of their data.

Fourth: keeping consent-based data after the consent has been withdrawn. Fifth: assuming an archiving requirement justifies keeping the entire data set, when it in fact covers only specific documents. These five mistakes explain most of what we see in records.

Pick the three processes that hold the most data: employee administration, client contracts and marketing. For each one, derive the period using these seven steps and write down the justification. This will take about half a day.

The remaining processes will go faster, since much of it repeats. What matters is that the method stays the same: purpose, statutory requirement, dispute period, reduction, justification, deletion, review.

When the legal basis is consent, the period depends on how long the consent remains valid. Once consent is withdrawn, processing stops and the data is deleted, unless a separate, independent basis allows it to be kept.

One thing still remains: the proof of consent itself. It is worth keeping longer than the data, because it may be needed to prove the processing was lawful. This distinction is written into the record as a separate line.

The practical consequence is that the system must have the technical ability to delete the data while keeping the consent record. If it does not, it is better to find that out while negotiating with the vendor, not after the first withdrawal.

Backups are the most common reason a retention period fails to be implemented. Backups overwrite themselves on their own cycle, so the data in them remains for some time after it has been deleted from the main system.

The solution is not to give up backups. Write down the backup cycle, acknowledge that the data still exists during that period, and make sure that if data is restored from a backup, deleted records are not brought back into the live system.

Paper archives have the same problem in a different form: folders move into storage and stay there with no set period. Once you list what is stored where, it usually turns out that some documents could have been destroyed years ago.

In a privacy notice, the period must be understandable. "We keep data for the period set by law" says something formally but does not answer the question. It is better to give a specific time or a clear criterion, for example, "for the term of the contract and for two years after it ends".

When the periods differ, it helps to give a short list broken down by data group. It looks longer, but it reduces the number of questions and shows that the periods were actually thought through.

For someone requesting deletion of their data, the answer also follows from the retention period: what is deleted immediately, what remains because of a legal obligation, and when it will be destroyed. An answer like that closes the conversation, while a blanket refusal only prolongs it.

First month: list the processes and note current practice for each one — how long the data is actually kept today. It almost always turns out the real duration is longer than any document says.

Second month: derive the periods for the three largest processes and write down the justification. Third month: agree the deletion procedure and carry out the first deletion, recording who did it and when.

After this cycle, the record becomes a living document. Next year's review will take a fraction of the time, because the method will already be established and the decisions already written down.

The same data is often used for several purposes: performing the contract, accounting, and, say, marketing. Each purpose has its own basis and its own period, so the data is not deleted as long as at least one basis still applies.

That does not mean everything is kept for the longest period. Once one purpose ends, the corresponding use stops: the data stays in accounting but disappears from the marketing list. Technically this is handled by flagging the record, not by keeping it everywhere.

In the record this is written as two processes referencing the same data set. That way it is clear why the data still exists and what is no longer being done with it.

A retention period is not a permanent decision. When the process, the system or the law changes, it needs to be reviewed, and the review date written down next to the justification.

A longer period must always be justified separately, and before it is extended, not after. A shorter period takes effect immediately and usually requires just one action — the first deletion under the new rule.

It helps to keep a short change log in the record: when the period was changed and why. It is the only way to later explain why a different period applied three years ago.