JPKCom DB

Retention Periods: How Long You May Really Keep Applicant and Contact Data

The six-month rule for job applications appears in no statute. Where it comes from, what applies to contact forms, where form data really ends up — and how to get it under control technically.

by ·

On 18 February 2026 the European Data Protection Board adopted the report on its 2025 coordinated enforcement action. The subject: the right to erasure. 32 supervisory authorities, 764 controllers examined — from one-person businesses to multinationals, private sector and public.

Two of the seven main findings are exactly the subject of this article: controllers struggle with determining retention periods, and they cannot get a grip on erasure in the context of backups. A third is more uncomfortable still: some rely on "inefficient anonymisation techniques" instead of actually deleting.

That matches what I see in consulting. And the underlying reason is rarely ignorance about deadlines. It is more mundane: most people don't know where their data actually lives. An application arriving through an online form almost never sits in one place. It sits in six.

This article covers both — the deadlines and the technology. It answers how long you may keep application documents and contact form enquiries, where those numbers come from, where the data ends up technically, and how to reliably get rid of it again. It closes with five worked scenarios on a timeline.

A note on jurisdiction and on what this is. This article describes German law (GDPR plus the German statutes that fill in the concrete periods: AGG, ArbGG, BDSG, HGB, AO). The GDPR principles apply across the EU, but almost every concrete retention period comes from national law — so if you operate outside Germany, treat the principles and the technical part as transferable and the numbers as not.

This is not legal advice. I am an IT consultant, not a lawyer, and I am not permitted to give legal advice — under the German Legal Services Act, advice on an individual case is reserved to lawyers. What you get here is prepared professional information: I trace every period back to its statute or to a supervisory authority publication, and I mark throughout what is law and what is my recommendation. For a binding assessment of your specific case you need a lawyer or your data protection officer. The technical part of this article, on the other hand, is squarely my field.

First: three statements that are everywhere and still wrong

"Application documents must be kept for six months"

This number appears in countless guides, often in the tone of a statutory command. It is not one.

There is no statutory retention period and no statutory erasure deadline for applicant data. The Data Protection Commissioner of Lower Saxony puts it unambiguously in his FAQ: there are "neither statutory retention nor erasure periods for applicant data".

The six months are a derivation — a good one, but you should know that you are deriving it rather than reading it off. It is made up of two periods and a buffer, and both periods really are in the statute:

  • Two months to assert a compensation claim in writing. Section 15(4) AGG: "A claim under subsection 1 or 2 must be asserted in writing within a period of two months." For an application, the period starts when the rejection is received.
  • Three months to bring the action. Section 61b(1) ArbGG: "An action for compensation under section 15 of the General Equal Treatment Act must be brought within three months of the claim having been asserted in writing." So this period starts not with the rejection, but only once the claim has been asserted in writing.
  • A buffer of up to a month, because you only learn of an action when it is served on you — and because someone may use the full two months right up to the last day.

Two plus three plus buffer makes six. The value is therefore well founded, and supervisory authorities broadly accept it. But the difference between "statutory period" and "derived ceiling" matters in practice, in both directions:

  • Upwards: six months is not permission to store for six months. It is the ceiling of a legal-defence purpose. If that purpose falls away earlier in your case, you must delete earlier.
  • Downwards: if a claim actually was asserted, nothing is over after six months. Proceedings are running, and the documents are evidence.

"Keep everything for ten years, just to be safe"

This was never right, and since 1 January 2025 it is doubly wrong. The Fourth Bureaucracy Relief Act shortened the retention period for accounting vouchers from ten to eight years. The statute now reads:

"The documents listed in subsection 1 number 1 are to be retained for ten years, the documents listed in subsection 1 number 4 for eight years, and the other documents listed in subsection 1 for six years." — Section 257(4) HGB, identically worded in section 147(3) AO

For our topic the third category matters most: commercial and business letters — six years. The statute defines them tersely: "commercial letters are only documents concerning a commercial transaction" (section 257(2) HGB). On the established reading that covers correspondence which prepares, concludes or reverses a transaction — and the medium is irrelevant: an email is caught just as much as a letter on paper. More on that shortly, because that is precisely the tipping point for contact forms.

Above all: a retention obligation for vouchers is not a retention right for everything attached to them. You must keep the invoice for eight years. That does not mean you may keep the sender's application photo for eight years.

"We anonymise the data, so we don't have to delete it"

The EDPB report lists "inefficient anonymisation techniques" as a finding in its own right. In practice, what businesses call anonymisation is almost always pseudonymisation: the name is replaced by an ID, but the mapping table still exists somewhere — or the remaining data is so specific that the person can be identified from it again.

Pseudonymous data is personal data. The erasure obligation applies to it unchanged. Genuine anonymisation is a high bar, and the honest rule of thumb is: if you could still restore the link should you need to, you have not anonymised.

The principle: deletion is the default state

The most common error is the direction of the question. Many ask: "How long may I keep this?" The Regulation asks the opposite: why do you still have it?

Article 5(1)(e) GDPR — storage limitation — permits storage in identifiable form only for as long as is necessary for the processing purpose. Once the purpose falls away, Article 17(1)(a) creates an erasure obligation without anyone having to request it. That is the point the 2025 EDPB exercise found across sectors: most organisations can delete on request. What they cannot do is delete on their own.

From this follows the structure of any workable erasure concept — three questions per data category:

  1. What do I have this data for? (purpose)
  2. How do I know the purpose is fulfilled? (the event that starts the clock — not the date of collection, but an event: rejection received, enquiry answered, contract ended)
  3. Does an obligation stand in the way of deletion? (retention duties under HGB, AO, SGB and others)

Only the combination produces a period. And question 2 is where it fails in practice: a period tied to an event that is recorded nowhere in the system cannot be automated by anyone.

Retention duties and erasure duties collide less often than people think

A widespread misunderstanding: "We have to keep this for ten years, so we may not delete." That is true for the voucher subject to the retention duty. It is not true for the whole record.

If someone requests erasure and documents subject to a retention duty are affected, the clean route is not "erasure refused", but: delete what is not subject to retention, and restrict the rest (Article 18 GDPR) — block it, take it out of operational access, keep it only for the retention purpose, and delete it when the period expires.

Applicant data

For applicant data, section 26 BDSG was cited reflexively for years. Applicants really are covered — section 26(8) BDSG makes clear that "applicants for an employment relationship and persons whose employment relationship has ended" count as employees.

The problem is that the provision has been shaky since the CJEU judgment of 30 March 2023 (C-34/21). The Court held, on a largely parallel provision of Hessian state law, that such a general clause is not a "more specific rule" within the meaning of Article 88 GDPR. Supervisory authorities responded: the Data Protection Commissioner of Baden-Württemberg writes in his FAQ that section 26(1) sentence 1 BDSG "is probably inapplicable" — pointing instead to Article 6(1) GDPR, depending on the constellation points (b), (c), (e) or (f).

The framing that the same authority supplies matters: as a rule this changes nothing about the lawfulness of the processing. What changes is the legal basis you name — in the privacy notice, in the record of processing activities and in the applicant information.

In practice that means: processing applicant data for the selection decision stands regardless — it is necessary for pre-contractual measures (Article 6(1)(b) GDPR). Retention after the rejection is something else: it serves your legal defence and rests on legitimate interests (Article 6(1)(f)). And a legitimate interest ends when the claims you want to defend against can no longer be asserted. That is exactly where the six months come from.

The three cases

Case 1 — rejection. Deletion once the legal-defence window has passed. My recommendation: six months from receipt of the rejection, not from receipt of the application. The rejection is the triggering event, and that date has to be in the system, otherwise you cannot automate the period.

Case 2 — hired. The documents change purpose and move into the personnel file. A different context applies, with its own periods. Important: not everything may come along. Documents not necessary for the employment relationship should be deleted for hires too.

Case 3 — talent pool. No derivation helps here; you need consent. Section 26(2) BDSG sets special requirements for whether consent is freely given in an employment context: account must be taken of "the dependency existing in the employment relationship" and of the circumstances; consent may be freely given in particular where the data subject obtains a legal or economic advantage. For a talent pool that advantage is easy to establish — the person stays in the running for future roles. Consent is generally to be obtained in written or electronic form, and the purpose and the right of withdrawal must be explained in text form.

The Lower Saxony Commissioner explicitly rejects open-ended stockpiling in his FAQ: storage purposes must be "clearly defined" and the retention period "limited in time". My recommendation: 12 months, with an active check-in before expiry and a withdrawal that works at any time. A talent pool nobody can leave is not a talent pool, it is an archive.

Special cases that extend the period — or shorten it

  • A claim was asserted. As soon as someone asserts a claim in writing within the two months, the standard period is void. Three months to bring an action now run, and if an action is brought, the documents are evidence until the proceedings are finally concluded. Your erasure job must therefore understand a legal hold — a flag that suspends automatic deletion. Without that mechanism, your automation destroys your own defence at the worst possible moment.
  • Documentation duties around the selection decision. In the public sector in particular, the selection decision may be reviewable in competitor proceedings; the Lower Saxony Commissioner refers to case law of the Federal Administrative Court and the Higher Administrative Court of Lüneburg. Longer retention of the selection documentation may be warranted here — which does not mean that all application documents of all applicants have to sit around longer.
  • Erasure request before the period expires. An applicant may request erasure at any time. That is legitimate and it happens. You may then weigh whether your legal-defence interest prevails — but you must actually perform and be able to justify that balancing, not merely point at "six months". Incidentally, someone requesting erasure is in practice giving up their own evidence, which noticeably weakens your defence interest.
  • The rejection never arrived. The two-month period runs from receipt of the rejection. If you never rejected — the classic case for unsolicited applications that quietly sink in a mailbox — the period never started. Your six months are not running. Sending a rejection is therefore not only a matter of courtesy; it is the starting gun for your retention period.

The genuinely hard part: applications by email

An application submitted through a form can be handled in a structured way. An application arriving as an email to info@ or straight to an individual is the same matter in data protection terms — but a completely different technical problem. Six months later it typically sits here:

  1. in the recipient's mailbox,
  2. in the mailbox of the colleague it was forwarded to,
  3. in the sent folder of both,
  4. in a local mail client on at least one machine, often with a full offline cache,
  5. as a downloaded PDF in a downloads folder or on a network share,
  6. in the server backups of all of the above,
  7. in the mail server logs — there, at least, usually only metadata.

Six of seven locations are unknown to your erasure routine. That is why I consider email applications the biggest practical weak point — not the deadlines.

What helps, in this order:

  • A dedicated mailbox jobs@ rather than info@, accessible only to the people who need access. That gives you a defined location instead of a diffuse set.
  • No forwarding — shared access instead. Every forward creates a new, uncontrolled copy. A shared mailbox with IMAP access creates none.
  • Server-side retention rather than client rules. A rule in a local Outlook does you no good when the laptop has been off for two weeks.
  • Store attachments centrally, not locally. A directory your erasure job can reach beats any downloads folder.
  • Steer applicants to the form in the job ad. The most effective lever is not making the unstructured channel attractive in the first place. If you accept applications by email, you must be able to delete emails.

Contact forms

Here the legal position is simpler and the practice sloppier.

There is no statutory period for contact form data, in either direction. The principle applies: the purpose is answering the enquiry. Once the enquiry is answered and the matter closed, the purpose falls away and the data is to be deleted.

"Closed" is an event, not a date — and it is uncomfortably fuzzy. A price enquiry is closed with the answer. A complaint is closed only when the matter is resolved. An enquiry that turned into a quotation is closed only when the quotation has been accepted or finally declined.

My recommendation — explicitly a recommendation, not the legal position:

  • Plain enquiry with no business dealings (a question, an appointment request, general information): delete once closed, at the latest 90 days after the last communication. The buffer covers follow-up questions without turning into an archive.
  • Enquiry with business dealings (quotation request, complaint, claim): delete once the matter is concluded, provided no tipping point has been reached — see below.
  • Spam and automated submissions: delete immediately. Spam entries too often contain genuine personal data of third parties whose addresses were abused.

The tipping point: when an enquiry becomes a business letter

This is where most erasure concepts fall silent. As soon as the correspondence concerns a commercial transaction — on the established reading, once it prepares, concludes or reverses one — it is a commercial or business letter, and therefore subject to six years' retention under section 257(1) nos. 2 and 3 HGB and section 147(1) AO. The period does not start with the matter but, under section 257(5) HGB and section 147(4) AO, at the end of the calendar year in which the letter was received or sent.

In practice: a quotation request of 3 February 2026 that turned into a quotation must be retained until 31 December 2032. Not 90 days.

So one and the same form produces two entirely different periods, depending on what it turned into substantively. You cannot guess that technically. What you need at this point is a human decision that lands in the system: a status field marking an enquiry as business-relevant and thereby taking it out of the 90-day erasure job. Without that field you have only two options, and both are wrong — delete everything too early, or keep everything too long.

And the reverse direction is readily forgotten: the retention duty for the business letter does not create a right to keep everything else for six years too. The sender's IP address, the user agent, the timestamp of the form submission, the spam score — none of that is part of the business letter.

Two neighbouring topics, cleanly separated

  • Newsletters. This is not a contact form but a separate processing operation based on consent. The data stays until withdrawal. The proof of consent (double opt-in log: time, IP, confirmed link) must outlive the consent, because you have to be able to demonstrate lawfulness even after withdrawal.
  • Abuse prevention. Storing IP addresses to fend off spam and attacks pursues a separate purpose with its own, short period. What you need for it, you need for a few days, not months — and usually truncated.

Retention table

The reference. The rightmost column is the important one: it tells you whether a number is in the statute or whether somebody derived it.

Data Period Starts Basis Status
Application, rejected 6 months receipt of rejection s. 15(4) AGG + s. 61b(1) ArbGG (2 + 3 months + buffer) Derived — no statutory period
Application, claim asserted until proceedings end written assertion s. 61b(1) ArbGG Statutory limitation period, retention derived
Application, hired personnel file rules start of contract separate purpose (employment) Change of purpose
Talent pool 12 months consent Art. 6(1)(a) GDPR, s. 26(2) BDSG Recommendation — period open, but must be limited
Contact enquiry, no business dealings until closed, max. 90 days last communication Art. 5(1)(e), Art. 17(1)(a) GDPR Recommendation — no statutory period
Commercial/business letter 6 years end of calendar year s. 257(1) nos. 2 and 3, (4), (5) HGB; s. 147(1), (3), (4) AO Statutory
Accounting voucher (e.g. invoice) 8 years end of calendar year s. 257(1) no. 4, (4) HGB; s. 147(3) AO Statutory — cut from 10 to 8 on 01.01.2025
Annual accounts, inventories, commercial books 10 years end of calendar year s. 257(1) no. 1, (4) HGB; s. 147(3) AO Statutory
Newsletter consent until withdrawal — Art. 6(1)(a) GDPR Purpose-dependent
Proof of consent beyond withdrawal withdrawal Art. 5(2), Art. 7(1) GDPR Recommendation — accountability
Server logs for abuse prevention days, not months access Art. 6(1)(f) GDPR Recommendation

Where the data really lives

Now the technical part — and it does not start with an erasure job but with an inventory. You cannot delete what you do not know about.

Take a single contact form on your site and follow one submission. On a typical WordPress installation with a form plugin, it ends up here:

Location Contains Does your erasure job know about it?
Plugin database table all field contents, often IP and user agent usually yes
Upload directory uploaded files (CV, references) often no
Notification email a full copy of every field almost never
Recipient's mailbox the same copy, permanently no
Mail queue / MTA logs metadata, sometimes the subject no
Web server access log IP, time, URL no
Backups of all of the above everything, repeatedly no
External service (form SaaS, mail delivery) everything not without a contract and configuration

Eight locations, of which a typical erasure function covers one. When the EDPB report names "difficulties determining retention periods" as a main finding, that is the polite way of putting it.

Do this inventory once for every form. It takes an hour and is the only foundation on which everything else makes sense. The result is a list with one row per storage location, each with an owner, a period and an erasure mechanism.

Technical implementation

Data minimisation is the cheapest measure

The record you do not collect does not have to be deleted, backed up, disclosed on request or reported in a breach. Before you build an erasure concept, strike fields:

  • Do you really need the phone number as a mandatory field? Usually not.
  • Do you need the date of birth in an application? For the selection decision, practically never — and it is a direct hook for age discrimination allegations.
  • Do you store IP address and user agent with every form submission? Many plugins do by default. Ask what for — and if the answer is "abuse prevention", that belongs in its own short period, not permanently attached to the record.
  • Does the submission need to go into the database at all? If the work happens by email anyway, the extra database copy is often pure ballast — and ballast is exactly what somebody finds five years later.

Uploads do not belong in the docroot

This is the mistake I see most often, and it is more serious than an exceeded deadline: application documents sit under wp-content/uploads/ and are therefore directly retrievable via a URL. Anyone who guesses the path or finds a directory listing downloads other people's CVs — no login, no trace.

Countermeasures, in descending order of effectiveness:

  1. Upload directory outside the docroot. This is the only solution that still holds when a web server configuration gets lost. For Contact Form 7 I solved this in a plugin of my own — the guide to jpkcom-cf7-upload-path describes the setup.
  2. Random file names. application-miller-cv.pdf is guessable, a random name is not. This does not replace access control, but it defeats the simplest hits.
  3. Directory listing off. Obvious — and still regularly switched on.
  4. Restrict file types and size. An upload field that accepts anything is also a malware entry point.

Periods belong on the data, not in a calendar

This is the EDPB report's second main finding and the most important conceptual point in this article: without a machine-readable deletion marker on the data there is no reliable deletion.

A period held in someone's head, on a wiki page or in an annual calendar entry is not a period, it is an intention. What you need on every record is:

  • a triggering event with a date (not "created on", but "rejected on", "closed on", "contract ended on"),
  • a period class (which rule applies to this record),
  • a legal hold (boolean: deletion suspended because proceedings are running or a retention duty applies),
  • an erasure log entry once deletion has happened.

With those four fields, deletion becomes a query. Without them it stays manual work — and manual work reliably does not get done at forty applications a month.

The erasure job has to reach every location

An erasure run that only removes the database row leaves orphaned uploads behind — the CV stays on disk, only now nobody finds it in the back end. That is the worst of all worlds: the data is still there, but you no longer know it.

A serviceable job works in this order:

  1. identify candidates (period expired and no legal hold),
  2. delete the associated files in the upload directory,
  3. delete the database row,
  4. write a log entry — without logging the deleted content; an erasure log that contains the deleted data is not an erasure log,
  5. report failures loudly. An erasure job that fails silently is more dangerous than none, because it creates a false sense of security.

On execution: WP-Cron is the weaker choice for erasure jobs. It only runs when someone visits the site, and on a low-traffic site it can go missing for days. A real system cron or a systemd timer calling WP-CLI is dependable — and your period is exactly as dependable as its trigger.

Mailboxes

The same principle applies to the email channel, only with worse tools. What works:

  • Server-side retention policies on the dedicated applications mailbox — messages older than X are deleted regardless of whether a client is running.
  • Transport encryption is mandatory, content encryption is the bonus. If you accept applications by email, you should at least state that the route is unencrypted — or offer an encrypted alternative.
  • Do not mirror applicant data into ticket systems that nobody has included in the retention logic.

Backups: the part where you have to be honest

The EDPB report lists erasure in the backup context as a finding of its own. Rightly so, because there is a genuine conflict of objectives here, and most privacy notices claim something at this point that is technically untrue.

The uncomfortable truth: a single record practically cannot be deleted out of a consistent, possibly encrypted full backup. Anyone who tries anyway destroys the integrity of the backup — and with it its purpose.

The workable route has three parts:

  1. Limited retention of the backups themselves. A backup set that rotates after 30 or 90 days deletes the data along with it — delayed, but reliably. A "full backup forever" is the actual mistake.
  2. A documented restore process. When a backup is restored, the deletions that fell due in the meantime must be run again. That belongs as a step in the restore runbook, not in the administrator's memory.
  3. Honest wording externally. Do not write "your data is deleted immediately and completely" when it sits in a backup for another 90 days. Write that deletion in the production system is immediate and that backup copies are overwritten in rotation within X days. That is accurate, comprehensible and far more defensible than a claim that will not survive scrutiny.

Processors

Form SaaS, applicant tracking systems, mail delivery services, backup providers: each of them processes on your behalf, and you need not just a contract under Article 28 GDPR but the answer to a very practical question: does this service actually delete when you delete — and within what period? For many providers the answer is in the terms, and it often reads "after 30 days from backups". That is fine. It just has to be in your erasure concept.

Five worked scenarios

Scenario 1: rejection after an online application

An application arrives on 3 March through the form, with a PDF attachment. Rejection on 20 March, delivered the same day.

Point in time What happens
3 March record in the database, PDF in the upload directory, notification email to jobs@
20 March rejection sent, the "rejected on" field is set — that is the anchor for the period
20 September erasure job runs: PDF deleted, database row deleted, log entry written
by 20 December backups rotate through; after that nothing remains there either

The decisive step is the second one. If the rejection date is not recorded, the erasure job has no anchor and falls back to counting from receipt — which in this case deletes 17 days too early, and in other cases, with long processes, months too early.

Scenario 2: unsolicited application to info@

No vacancy advertised, no process, no form. The mail sits in a shared mailbox.

Because no rejection was ever sent, the AGG period never started — the derivation of the six months does not carry here. The purpose "assessing possible cooperation" is fulfilled once you have read it.

Recommendation: send a brief rejection (that starts the period cleanly and is better practice anyway) or, if you want to keep the person in mind, actively ask for consent for the talent pool. What does not work is the third variant, which dominates in practice: leave it lying and decide nothing.

Scenario 3: a contact form turns into an order

Enquiry on 3 February 2026 through the contact form. A quotation, an order and an invoice follow.

Component Period Ends
Form record with IP and user agent 90 days (recommendation) early May 2026
Email correspondence on the quotation (business letter) 6 years from year end 31.12.2032
Invoice (accounting voucher) 8 years from year end 31.12.2034

One matter, three periods, three different endings. That is precisely why a blanket "we delete after a year" is not enough — it is too long for the IP address and too short for the invoice.

Scenario 4: an erasure request meets a retention duty

A customer requests erasure of all data in May 2027. The 2026 invoice is subject to the eight-year period.

Wrong answer: "erasure not possible."

Correct approach: split it. Marketing profile, newsletter membership, form record, website tracking — delete. Invoice and the associated business correspondence — do not delete, but restrict processing under Article 18 GDPR: take it out of operational access, keep it only for the tax purpose, set the deletion date to 31 December 2034. And tell the person exactly that, with the period and the reason. A reasoned partial erasure is a good answer. A blanket no is not.

Scenario 5: an access request after eight months

A rejected applicant requests access under Article 15 GDPR in November concerning the application she submitted in March.

If your erasure concept worked, the answer is simple and good: the data was deleted on schedule in September, here is the legal basis, here is the date. That is not an admission — it is evidence of a functioning process.

If the data is still there, you have two problems instead of one: the access request and storage for which you currently lack a justification. And you have put it in writing to the person asking.

That is why the value of an erasure concept does not lie in the deleting. It lies in having a demonstrable answer when it counts.

An erasure concept in a day

An erasure concept to DIN 66398 is a substantial undertaking. For a small business the 80-per-cent version is doable in a day and is orders of magnitude better than nothing:

  1. List data categories. Not systems, but categories: applications, contact enquiries, customer master data, invoices, newsletter, logs. In most businesses that is fewer than fifteen.
  2. Answer the three questions for each. Purpose, triggering event, conflicting obligation. The triggering event is the part that starts arguments — which is exactly the point.
  3. Form period classes. Fifteen data categories typically collapse into four or five classes. Fewer classes means fewer special cases means more actually gets implemented.
  4. Add storage locations per category — the inventory from above.
  5. Enter ownership. One person per row. Not "IT".
  6. Mark the implementation: automated, semi-automated, manual. Everything manual is a candidate for automation; everything automated needs a check.
  7. Review once a year — and the change to the voucher period on 1 January 2025 is the best illustration of why: anyone who has not touched their concept since 2024 is keeping vouchers two years too long.

Common mistakes

  • Counting from collection instead of from the event. The most common design flaw. An application that spent four months in the process otherwise gets deleted two months after the rejection — in the middle of the legal-defence window.
  • No legal hold. The erasure job destroys the documents you need in the pending AGG proceedings.
  • Orphaned uploads. Database row gone, file still there. The classic.
  • An erasure log with content. If you log what was deleted, you have not deleted it.
  • Privacy notice and reality diverge. A notice saying "30 days" while the job is set to 90 is worse than one that says 90. The notice is a commitment.
  • External services not considered. The applicant tracking system deletes by its own rules, not yours.
  • No information about the retention period. Article 13(2)(a) GDPR requires the retention period, or the criteria used to determine it, to be given at the point of collection. "We store data as long as necessary" does not satisfy that.

The essentials in five sentences

  1. There is no statutory period for applicant data — the six months are derived from section 15(4) AGG and section 61b(1) ArbGG, and the clock starts on receipt of the rejection, not on receipt of the application.
  2. There is likewise no statutory period for contact forms, but there is a hard tipping point: once the correspondence becomes a business letter, it is six years from the end of the year.
  3. Accounting vouchers have been subject to eight years since 1 January 2025, not ten — check your erasure concept for it.
  4. Periods must sit on the data, machine-readable, with a triggering event and a legal hold. Anything else is an intention.
  5. And the sentence I say most often: the data you do not collect creates no work.

If you take away one thing from this article, make it the inventory: take one form and find out how many places a single submission actually lands in. The number is almost always higher than expected — and everything else follows from it.

Sources

Every period in this article has been checked against the primary source.