Anyone searching for retention periods for job applications in Germany finds the same figure everywhere: six months. It appears in guidance articles, in privacy notices and in the default settings of many applicant tracking systems. It appears in no statute.
That is more than a technicality. Treat the six months as a statutory deadline and you hard-code it into a workflow, then wonder later why it is too short in some cases and too long in others. Understand what it is made of and you build a rule that calculates the right date for each record instead.
This article explains the derivation, the exceptions and the structure of a workflow that handles deletion. It describes the general framework and does not replace alignment with your data protection officer.
Where the six months come from
The figure is made of two deadlines and a buffer. A compensation claim for discrimination must be asserted in writing within two months, and for applicants that period starts when the rejection is received. Once the claim has been asserted, suit must be filed within three months of that point. Two plus three months makes five, and the rest is margin for delivery and post.
What follows is a permission to retain, not a duty to retain. The company may keep the documents for as long as it needs them to defend against a possible claim. Once that purpose ceases, the general principle applies: personal data must be erased without undue delay where it is no longer necessary for the purposes for which it was collected. Data may only be kept for as long as is necessary for the purposes of the processing.
For the workflow this means the starting point is not the date the application arrived but the date of the rejection. Two applications that arrive on the same day and whose rejections are six weeks apart have two different deletion dates. A workflow that rigidly adds six months to the arrival date deletes one record too early and the other too late.
The deletion concept comes before the workflow
Before an automation project makes sense, somebody has to decide which type of data is deleted when. There is a standard for that. The guideline for developing a deletion concept with derivation of deletion periods for personal data appeared in May 2016 as DIN 66398 and gives recommendations on the contents, the structure and the allocation of responsibility.
Its systematics are exactly what a workflow needs. It works with data types, meaning groups of data objects processed for a single purpose, with deletion classes that bundle data types sharing a period and a start date, and with deletion rules that set period and start date for each class. A deletion rule translates one to one into a workflow. A general statement about six months does not.
The standard itself has been withdrawn and was replaced in September 2025 by DIN EN ISO/IEC 27555, with the successor following the same method. Little changes in practice: anyone who already has a concept under the old standard can keep using it, and anyone starting now works with the same logic.
There is a second reason to do the concept first. The record of processing activities must document, where possible, the envisaged time limits for erasure of the different categories of data. And at the point of collection you must inform people about the storage period or about the criteria used to determine it. Both presuppose that the periods have been set at all.
The exceptions the workflow has to know
A deletion workflow that removes everything older than the period causes damage. Four cases need separate handling, and all four can be expressed as conditions in the flow.
The first is consent to longer storage, for instance for a talent pool. It extends the period but requires its own end date and a documented way to withdraw. The second is a pending procedure: while a claim has been asserted or a suit is pending, the purpose has precisely not ceased.
The third is a hire. Where the person is hired, the relevant documents move into the personnel file and follow its periods rather than those of the application process. The fourth is commercial and tax retention duties for the documents produced along the way. Commercial letters received and copies of commercial letters sent must be kept for six years, accounting vouchers for eight years, and commercial books and annual financial statements for ten years. These periods start at the end of the calendar year in which the document came into existence, not on the day itself.
That difference in start date is the most common error in home-built deletion routines. A period counted from the rejection date and a period counted from year end cannot share one calculation. In the workflow they belong in two separate branches.
Why manual handling breaks here
Deletion is a task without feedback. Nobody notices it has been skipped until somebody asks. That is exactly why it is a classic candidate for automation: it recurs, it depends on dates, and when it succeeds it produces no visible result.
The moment it surfaces is an access request. On request you must state the envisaged storage period or the criteria used to determine it, and you must respond within one month. That period may be extended by two further months, and you have to explain the delay within the first month. Anyone who has to work out during that window which systems still hold a rejected applicant's documents has a problem that can no longer be solved at short notice.
The framework for the worst case is known too. Infringements of the processing principles and of data subject rights can attract fines of up to 20 million euros or up to 4 percent of total worldwide annual turnover, whichever is higher. That is the ceiling rather than the normal case, but it describes the order of magnitude the topic sits in.
How the workflow is built
The flow has five steps, and the first is the one most often missing. It does not start with deleting but with setting the deletion date. As soon as a rejection goes out, the workflow writes a calculated field into the record: rejection date plus the period of the applicable deletion class. The decision is then made once and does not have to be reconstructed later.
The second step is a schedule that checks daily which records are due. The third step is the exception check: consent on file, procedure pending, person hired, retention duty applicable. If one of those applies, the record goes onto an exception list instead of into deletion.
The fourth step is the deletion itself across all systems involved, the fifth is the log. The log carries the proof, and it must not become a copy of the deleted content. It holds an internal identifier, the deletion rule applied, the date and the result per system, and nothing else.
Among the appropriate technical measures, the regulation expressly names pseudonymisation and encryption together with a process for regularly testing and evaluating the effectiveness of those measures. For a deletion workflow the second part means a recurring sample check confirming that nothing is left in the target systems. A workflow reporting that it deleted is not yet proof that deletion happened.
When the data sits in several systems
Application documents are rarely in one place. The typical spread is the applicant tracking system, the hiring manager's mailbox, a shared drive holding selection notes, a calendar with interview slots and sometimes a video tool with recordings. A deletion that happens only in the applicant tracking system is not a deletion.
For each of those systems the question of the service provider arises as well. Anyone having data processed on their behalf may only work with processors who provide sufficient guarantees for appropriate technical and organisational measures. And the processor must delete or return the data after the end of the provision of services and make available all information necessary to demonstrate compliance.
In practice this is where it is decided whether a workflow can be built at all. Systems with an API for deletion can be connected. Systems without such an interface get a task for a human in the flow, with a deadline and a confirmation. That is not a blemish but the honest version: partial automation with a visible remaining list beats full automation that quietly skips two systems.
What the workflow must not take over
The deletion itself is a mechanical act and suits automation. Judging whether an exception applies does not, in two cases. Whether a claim has been asserted depends on assessing the letter that arrived, and whether a consent is valid depends on how it was obtained.
So build an approval into those two points instead of writing a rule that has to guess. The workflow proposes, a person confirms, and the confirmation lands in the log. That costs a few minutes per case and is exactly the part somebody has to be able to follow later.
The second point concerns what the workflow can do while deleting. Deletion cannot be undone. So test the flow first in a report-only mode that shows what it would delete, and let that mode run for one or two cycles before you switch deletion on. The discrepancies that surface are almost always period calculations using the wrong start date.
