GDPR deletion concept: what it must settle

Which duties sit behind a deletion concept?

The GDPR does not use the term, but the duties behind it are there. Personal data may be kept in a form that permits identification “for no longer than is necessary for the purposes for which the personal data are processed” (Art. 5(1)(e)).

Art. 17(1) obliges your company to erase data without undue delay where one of the listed grounds applies, for example when the data is no longer necessary for its purpose or consent has been withdrawn. That applies on request and, as the German Data Protection Conference (DSK) writes in its Kurzpapier Nr. 11, without one too.

Art. 17(3) lists exceptions, such as a legal obligation to retain the data (point (b)) or the defence of legal claims (point (e)). In the DSK's view, these do not allow unlimited storage either: once their purpose is met, the data is erased.

Art. 5(1)(e) · Art. 17(1) and (3) GDPR

What a deletion concept must settle

At its core it is one deletion rule per type of data: the time limit, the event that starts it, and the basis for it. The European Data Protection Board (EDPB) names as a good practice of some controllers a table that brings together type of data, legal basis and retention period.

The DSK's Standard Data Protection Model (SDM) covers deletion in its building block 60. Under it, you settle who checks, orders and carries out deletions. It expressly lists quick formatting and a mere promise not to use the data any more as not enough.

According to the SDM, a piece of data is erased only once no copy remains with you or a processor. Processors delete or return the data at the end of the service and delete existing copies (Art. 28(3)(g)). You tell recipients about each erasure unless that proves impossible or involves disproportionate effort (Art. 19).

Art. 19 · Art. 28(3)(g) GDPR

What applies to backups?

A backup is a copy. According to SDM building block 60, the duty to erase in principle covers backup copies too, though not necessarily at the same moment as in the live system. If deleting safely in the backup would take so long that it coincides with the scheduled overwrite anyway, it can happen then.

The rule that matters most concerns restores. When your IT restores data from a backup, data already erased comes back. The SDM requires that it be erased again immediately afterwards, and processes that monitor this.

The EDPB does not consider it always advisable to modify backups, because they protect against attacks such as ransomware. In that case, its February 2026 report says, you need a procedure that keeps track of erasure requests and applies them to restored systems. Half of the responding supervisory authorities raised concerns about deletion in backups.

So your deletion concept states, for each backup system, how long copies are kept, and keeps a list of erasures that is worked through again after a restore. The list names which record is to be erased, for example by a customer number. For documentation of erasures, the SDM requires that it contain no content data that has to be erased.

Example: one deletion rule and one restore

Muster Metall GmbH, a made-up company with 80 employees, keeps correspondence on orders as commercial letters for six years under the German Commercial Code (§ 257(1) and (4) HGB). The period starts at the end of the calendar year in which the letter was received or sent (para. 5). An email from March 2026 therefore stays until the end of 2032.

In the example, its daily backup is kept for 30 days. After an attack, its IT restores the state from two weeks earlier. Before the restart it works through that fortnight's erasure list again; it holds, for example, the customer number of a customer who had withdrawn her consent to the newsletter, and her address is erased again afterwards.

Which mistakes to avoid in a deletion concept

Do not set one time limit for everything just because it sounds safe. Data without a retention duty then stays too long, and in the DSK's view a general reference to retention duties is not enough.

Do not delete only in the main system. Copies can also sit in mailboxes, on mobile devices and in cloud services; the SDM requires processes that catch every copy. For retired devices, item 10.1 of the NIS 2 walkthrough provides for secure wiping or destruction.

Retaining is not continuing to use. The exception in Art. 17(3)(b) applies only “to the extent that” processing is necessary for the legal obligation.

Art. 17(3)(b) GDPR

With an AI assistant: what it can prepare for the deletion concept

An AI assistant such as Claude, ChatGPT or Copilot can build a table of all types of data from your record of processing activities and propose a deletion rule for each. Through MCP (Model Context Protocol), an open standard, it also reads what the NIS 2 walkthrough records about your backup systems.

Check every proposed time limit in the current statute. § 257(4) HGB, for example, has applied in a new version since 1 January 2025 and gives eight years for accounting vouchers. Which time limit applies is for your company to decide as controller.

Erasure lists can contain personal data, which the assistant's vendor then processes too. Where the vendor acts as a processor, a contract under Art. 28(3) GDPR is required. A GDPR walkthrough on nisd2.eu is in the works, with the same MCP server as the NIS 2 walkthrough.