How it works today in most organizations
The deletion concept is almost always created in the same week as the records of processing activities. Someone takes a template – from a seminar, from an association or from a law firm sample –, saves it as "Deletion_Concept_final.docx" and fills in the table. On the left the data category, in the middle the retention period, on the right the legal basis: application documents, contract data, accounting receipts, the candidate pool, video recordings, log files. The document is printed, signed off by management and filed in the "Data protection" folder.
In substance there is nothing wrong with that. The retention periods are usually researched carefully, the categories sensibly cut. The problem begins the day after: the document is never opened again. It describes what should be deleted – but there is no place in which it is recorded whether anything was ever deleted.
How you notice it in day-to-day work
In the "Responsible" column, if it exists at all, it says "IT" or "department". Nobody by name. There is no date on which a deletion is reviewed, no reminder and no task. When data disappears, it is usually because a system does so on its own – and nobody knows exactly whether it really does. Whether the applicant management software actually deletes after the retention period or merely hides, whether the old pool of prospects is still sitting in the CRM, whether the ticket system deletes attachments along with the ticket: none of that appears in any of the documents.
On top of that comes the break between two obligations that sit unconnected next to each other in the document. Retention obligations under German commercial and tax law (HGB and AO) require certain records to be kept. The principle of storage limitation under Art. 5(1)(e) GDPR requires everything else to go. Which records in a system fall under which rule, and what happens to them between the two deadlines, is not something a table with three columns settles.
As a rule, three areas are left out entirely: backups, archives and paper. The backup copies keep running to their own rhythm, the old file drive from the last migration sits untouched on the server, and nobody has looked at the personnel files in the basement cabinet since the concept was written.
The moment it becomes apparent
This becomes apparent in three situations. A data subject requests erasure under Art. 17 GDPR, and the response must as a rule be available within one month under Art. 12(3) GDPR – now someone has to find out in which systems that person appears at all. Or an auditor asks not about the concept but about its execution: "Show me the last deletion you carried out." Or the person in charge leaves the organization, and with them the knowledge of what from that table ever became reality.
In all three cases a cleanly worded document exists. And in all three cases it does not answer the question that was asked.
The analysis
Five Reasons Why the Deletion Concept Stays in the Folder
They have nothing to do with a lack of care. They arise from the fact that a text document cannot trigger a process.
View deletion concepts in preecoThe document proves the intention, not the execution
A table of retention periods shows what is supposed to be deleted. It contains no entry about when something was last actually deleted, and by whom. In a review that is exactly the question that gets asked – and the only one the concept has no answer to.
No link to systems and processing activities
The retention periods are attached to data categories, but deletion happens in systems. As long as it is not recorded which processing activity holds which data in which system, it remains open where a retention period would apply at all. When a system is replaced, this goes unnoticed all the more.
Without responsible people and reminders, nothing happens
Deadlines run by themselves, deletions do not. Without a person responsible by name and a fixed cycle there is no occasion to ever take the topic up again. The concept quietly ages while systems and processes keep developing.
Retention duty and deletion duty are never weighed against each other
Retention obligations under German commercial and tax law and storage limitation under Art. 5(1)(e) GDPR pull in different directions. If the balancing is not documented per data category, in case of doubt nobody decides – and nothing is deleted at all.
Backups, archives and paper do not appear
Deletion happens in the production system, while the data lives on in backup copies, old migration stores and filing cabinets. Without a described deletion procedure per system and storage medium, everything outside the application remains entirely unconsidered.
The target process in six steps
An effective deletion concept differs from the document in the folder not through more text, but through the fact that it regularly triggers something. These six steps describe the workflow – regardless of the tool in use.
1. Take over what already exists. The researched retention periods are the real groundwork and remain valid. They are not collected again but transferred into a structure in which they are addressable.
2. Form deletion classes instead of individual cases. Data with the same retention period and the same legal basis is grouped into classes – application data without a contract, contract master data, accounting-relevant receipts, log data, for example. A list of a hundred individual cases thereby becomes ten to fifteen rules that can actually be maintained.
3. Tie every deletion rule to a processing activity and a system. Only the link makes the rule applicable: this deletion class concerns this processing activity, which takes place in this system. In preeco | data protection the system thereby shows automatically which retention periods apply to which processing activity – records and deletion concept can no longer drift apart.
4. Deliberately weigh retention obligations against it. For every class it is recorded whether a retention obligation under commercial or tax law applies, which period follows from it and what applies in the meantime. Where deletion is permitted, deletion happens; where retention is required, further processing is restricted and access is limited. This balancing is the substantive core of the concept.
5. Name responsible people and set the cycle. Every deletion rule is given a responsible person and a review rhythm – monthly, quarterly or annually, depending on the data. Reminders prompt the deletion review that is due and can be turned into tasks that go to the responsible person. The reminder thereby moves out of one person's head and into the process.
6. Document the execution. Every completed review leaves a trace: who applied which rule, and when. The task log for the deletion rules is the evidence that turns a concept into a practice you can prove – and it is part of the export as PDF or DOCX.
The special case of backups, archives and paper
For ongoing operations, deletion in the production system is the decisive step. With backup copies, immediate targeted deletion is often technically impossible and is not demanded in practice either – what is necessary instead is a described procedure: a limited retention period for the backups, clear access protection and the rule that after a restore the deletions that became due in the meantime are carried out again.
Archives and legacy stores, by contrast, need a deliberate decision: delete, anonymize or archive with a justified period. Exactly these three paths belong documented per system and storage medium – including the paper stores, for which a destruction rule and a responsible person have to be recorded.
Before and after in direct comparison
| Criterion | Before: Word document | After: maintained deletion rules |
|---|---|---|
| System reference | Retention periods attached to data categories, without a place | Every rule hangs on a processing activity and a system |
| Responsibility | "IT" or no entry at all | A person responsible by name per deletion rule |
| Deadlines | A table in the document, without effect | Fixed cycle, reminder and task |
| Retention obligations | Sit unconnected next to the retention period | Balancing documented per deletion class |
| Verifiability | Proves the intention | Task log proves the execution |
| Backups and archives | Not considered | Deletion procedure per system and storage medium |
| Collaboration | One file, one person | Tasks to the departments, status visible |
| Information and reporting | Searching through folders and mailboxes | Filterable overview, export as PDF or DOCX |
In practice
This Is What It Looks Like in preeco | data protection
The three building blocks that turn the deletion concept into an ongoing routine.
Deletion Concept
Deletion classes, deletion rules, retention periods and deletion procedures captured in a structured way – including statutory retention periods under German commercial and tax law. Reminders prompt the deletion reviews that are due, and the task log documents the execution.
Processing Activities and Systems
Deletion rules are linked to the processing activities concerned. The system shows which period applies to which processing activity – records and deletion concept stay consistent.
Tasks and Reminders
A reminder becomes a task with responsibility, priority and due date. Notifications and the dashboard make sure the deletion review does not hang on a single person.
What the switch means in practice
The most common objection is that the deletion concept would then have to be worked out completely anew. That is not the case. Researching the retention periods is the real work, and it is already done. All that is new is the structure around it: forming classes, tying rules to systems, naming responsible people, setting the cycle. At a mid-sized organization, experience shows that takes one to two working days – the greater effort lies not in recording the information but in clarifying which system actually holds which data and who is able to delete there.
The gain shows itself on the first run. As soon as the first deletion review lands as a task in a department, it becomes visible which rules do not work in reality – because a system has no deletion function, because a data store belongs to nobody, or because a retention period cannot practically be met. These findings are uncomfortable, but they are the actual purpose of the concept.
Three mistakes that slow the implementation down
Cutting too finely. A concept with eighty individual retention periods will never be reviewed. Ten to fifteen deletion classes cover the bulk of the data and stay manageable.
Leaving responsibility with data protection. Only someone with access to the system can delete. If responsibility stays with the data protection officer, another list appears that only one person keeps.
Starting with the most difficult data store. The old file drive from the last migration is the toughest case and blocks the whole undertaking. Start with the stores that are clearly assigned – applications, newsletter, video recordings, log data.
How to tell that it is time
A deletion concept in Word format is not a mistake. It turns into a risk as soon as one of these points applies:
- You cannot say when something was last actually deleted.
- The retention periods in the concept are attached to data categories, not to systems.
- No deletion rule has a person responsible by name.
- An erasure request under Art. 17 GDPR triggers a search across several departments.
- Backups, archives and paper stores do not appear in the concept.
If none of these apply, the document is fine. If two or more apply, it documents a process that does not exist.
FAQ
Frequently Asked Questions About the Deletion Concept
The GDPR does not require a document by that name. It does require, however, that personal data is not stored longer than necessary (Art. 5(1)(e) GDPR), and it requires you to be able to demonstrate compliance (Art. 5(2) GDPR). A deletion concept is the usual way to meet both together – what is decisive is not the document but the evidence of the deletions actually carried out.
Then the data is not deleted; further processing is restricted instead. Art. 17(3)(b) GDPR exempts data from the erasure obligation where retention is required by a legal obligation – retention periods under commercial or tax law, for example. The data is kept for the retention purpose, access is limited, and once the period has expired the deletion rule applies. It is important to record this balancing in writing per data category.
Deleting an individual record in backup copies in a targeted way is usually not technically possible, and it is not expected in practice either. What is expected is a described procedure: a limited and documented retention period for the backups, tight access protection and the rule that after a restore the deletions that became due in the meantime are carried out again. Exactly this procedure belongs in the deletion concept, per system.
Through the documentation of the reviews carried out, not through the concept itself. In preeco | data protection you attach reminders and tasks to deletion rules; the task log for the deletion rules records who applied which rule, and when. It is part of the export as PDF or DOCX and can therefore be presented to auditors and supervisory authorities.
The GDPR does not prescribe a fixed cycle. An annual review of the concept as a whole has proven itself, supplemented by updates prompted by new systems, new processing activities or changed legal bases. That is to be distinguished from the cycle of the individual deletion review: depending on the data, it lies between monthly and annually and is set per deletion rule.
Go Through Your Deletion Concept With Us
Bring your existing document. In 30 minutes we group your retention periods into deletion classes and show where the rules would have to hang on systems.