The retention period is over – how do we actually delete the data?

A period written in your record is only a decision. Article 30(1)(f) GDPR requires the record to contain, where possible, the envisaged time limits for erasure of the different categories of data. Recital 39 adds that "time limits should be established by the controller for erasure or for a periodic review". But writing the period down does not mean that anyone deletes anything.

The problem may not be a wrong period, but that nobody applies it. For example, the CV folder grows for five years, a list of former customers sits in an old CRM, and a departed employee's mailbox stays "just in case". Under Article 5(2) GDPR the controller must be able to demonstrate compliance with the storage limitation principle. So deletion has to be a process, not good will.

Take your record of processing activities and, for each process, write down three things: when the period starts, how long it lasts and how often you will clean up. The result is a table:

Take the length from your record; do not invent it here. If your record has no period, set one first – how to do that is in a separate answer (link below).

Our recommendation: where possible, make deletion automatic (for example, overwriting CCTV recordings or a mailbox rule). Where it is not possible, put a recurring event in the calendar of a named person. What has no date and no name does not happen.

One process almost always leaves data in several places. For each calendar entry, list every place:

• the main system – CRM, HR software, the online shop's admin system;
• mailboxes – emails with attachments, especially shared "info" or "jobs" mailboxes;
• shared drives and cloud storage – exported spreadsheets, downloaded CVs, copies of offers;
• employees' computers and phones – "Downloads" folders, chat apps;
• paper – binders, printed forms;
• backups – see step 4;
• processors – external systems where someone else holds your data (see step 5).

The list does not have to be perfect at once. Start with the main system and email, and add other places after the first clean-up, once you see where else you found copies.

There are two lawful ways to end storage:

1. Delete – the data is removed so that it cannot be restored by ordinary means.
2. Anonymise – turn the data into a form from which neither you nor anyone else can identify the person, including by singling out one entry, and keep only aggregated statistics. Recital 26 GDPR says the Regulation "does not therefore concern the processing of such anonymous information", meaning information from which the person is not or no longer identifiable; the test takes account of all the means reasonably likely to be used by the controller or by another person.

An important line: pseudonymisation is not anonymisation. The same recital 26 says that data which have undergone pseudonymisation and which could be attributed to a person by the use of additional information should be considered information on an identifiable person. If you replaced the name with a code, it is still personal data, and the period still applies to it. Even deleting the code table does not necessarily make the data anonymous if the remaining fields still allow the person to be identified.

A practical example: an online shop wants to know how many purchases it had five years ago. It is enough to keep a summary – the number of purchases and the total amount for each month and product category – and to delete the individual orders with the buyer's name, address and email. Individual order lines with an exact amount and date are not anonymous if they can be matched to an invoice you still keep.

The storage limitation principle (Article 5(1)(e) GDPR) makes no exception for backups. But deleting single entries from each backup is often technically impossible. Good practice looks like this:

• limited backup life – backups are kept for a set, preferably short, time and overwritten in rotation, so deleted data disappears from them once the last copy is overwritten; treat that time as part of the retention period;
• access for restoring only – backups are not used for daily work or searches;
• delete again after a restore – if a backup has to be restored, first delete again the data already destroyed under the calendar.

Write the backup lifetime into the security-measures description in your record, so you do not have to explain it from memory later.

If your data is held by your provider (a CRM, accounting software, cloud storage), it is usually a processor and acts on your instructions. Under Article 28(3)(a) GDPR the data processing agreement must stipulate that the processor processes data only on documented instructions from the controller. So a deletion rule in the provider's system is your instruction – set it in the system itself or write to the provider.

When the service ends, under Article 28(3)(g) GDPR the agreement must stipulate that the processor, at the choice of the controller, deletes or returns all the personal data and deletes existing copies, unless the law requires storage. Check that your agreement contains this clause. When you change provider:

1. choose in writing – return or delete;
2. ask for written confirmation that the data and copies have been deleted;
3. keep the confirmation with the data processing agreement.

The GDPR does not expressly require a deletion log. But the accountability principle (Article 5(2)) requires you to be able to demonstrate that you respect retention periods, and a short log is the simplest proof. Our recommendation – one entry after each clean-up:

Do not write in the log whose data you deleted. A list of names in the log would be a new copy of personal data. The category, the period and the number are enough. This applies to scheduled deletion. If you deleted at a specific person's request, record the request and your reply in your requests log – the person has to be named there so you can demonstrate that you handled the request (Article 5(2) GDPR).

Sometimes another reason appears to keep specific data longer. The exception in Article 17(3)(b) GDPR applies where storage is needed to comply with a legal obligation, and Article 17(3)(e) where the data is needed for the establishment, exercise or defence of legal claims. For example, if there is a dispute with a former customer, their file is not destroyed until the dispute is over.

In that case:

• stop deletion only for the data that is needed, not for the whole process;
• write down the reason and the date on which you will review it;
• when the reason disappears, delete the data in the usual way.

Scheduled deletion is your own initiative: it follows from the storage limitation principle and the periods in your record, and Article 17(1)(a) GDPR obliges the controller to erase data that is no longer necessary even if nobody asks. An erasure request is a person's right under the same Article 17: for example, where the data is no longer necessary for the purpose (Article 17(1)(a)) or where the person withdraws consent and there is no other legal ground (Article 17(1)(b)). Then you do not wait for the calendar date.

Two things worth knowing:

• after erasing data under Article 17(1) – whether on request or on schedule because it is no longer needed – you must communicate this to each recipient to whom you disclosed it, unless this proves impossible or involves disproportionate effort (Article 19 GDPR); so mark in the deletion calendar who received the data;
• on a request only: if you made the data public and are obliged to erase it, Article 17(2) GDPR requires you, taking account of available technology and the cost of implementation, to take reasonable steps to inform other controllers processing it of the request to erase links and copies.

This week, take the one process with the most data (for example, candidate CVs or website enquiries) and do a first clean-up using the list in step 2. Fill in the first log entry. Then add the other processes, one a month.

The deletion calendar is built from your record, so first you need to know whether the record is mandatory for you. With the tool (in Lithuanian) you can find out free of charge whether you must keep a record of processing activities. A record with retention periods can also be ordered as a one-off procedure: €95 excl. VAT.

Is it enough to move the data to an archive folder?
No. An archive folder is the same storage under another name. If the period has ended and there is no other reason to keep the data, it must be deleted or anonymised.

Do we also have to delete the emails that contained the data?
Yes, if the emails belong to the same process and the same period applies to them. Mailboxes are a place where data is easily forgotten.

Can we keep the data for statistics?
You can keep anonymised data – data from which the person can no longer be identified, for example aggregated summaries, not individual entries. Pseudonymised data that can still be linked to a person is still personal data. Article 5(1)(e) GDPR allows longer storage solely for statistical purposes with the safeguards of Article 89(1), but where anonymous data is enough for the statistics, Article 89(1) requires you to use it.

How often should we clean up?
The GDPR sets no specific frequency. Our recommendation is to choose it by volume: processes with many new entries monthly, others quarterly or once a year, and to put it in the calendar.

• How to set a retention period when the law does not give one? (in Lithuanian)
• How long to keep employee data? (in Lithuanian)
• Do we need a data processing agreement with an IT provider? (in Lithuanian)
• A description of security measures: how to prepare it

The law and the risk: How long to keep personal data when the law sets no retention period – dat.lt

• Storage limitation – Article 5(1)(e) GDPR; accountability – Article 5(2).
• Time limits for erasure or periodic review – recital 39 GDPR; erasure time limits in the record – Article 30(1)(f).
• Anonymous information and pseudonymisation – recital 26 GDPR
• Processor acts on instructions – Article 28(3)(a) GDPR; deletion or return at the end of services – Article 28(3)(g).
• Right to erasure – Article 17(1)(a) and (b) GDPR; data made public – Article 17(2); exceptions – Article 17(3)(b) and (e).
• Notifying recipients of erasure – Article 19 GDPR
• Longer storage for statistics and anonymous data – Article 89(1) GDPR

Legal texts checked on 2026-09-25: GDPR – official consolidated English text (02016R0679, 04.05.2016). This text is general information and is not individual legal advice.