Expert knowledge for digital decisions

How to Implement Deletion Periods in CRM Practically?

Short answer

With a deletion concept that defines a period and a trigger event for each type of data, and an automatic implementation in the system. A concept in a folder is not enough – it will be checked whether deletion actually occurs. Retention obligations take precedence but do not allow further use.

The Structure of a Deletion Concept

For each type of data, three specifications:

Data Type	Period	Starts with
Prospect without business	e.g. 2 years	last contact
Customer, contract data	tax period	end of the year
Newsletter consent	until revoked	–
Application data	e.g. 6 months	rejection

The specific periods depend on the individual case and should be coordinated with data protection and tax consulting.

Deleting or Blocking

Invoice-relevant data cannot be deleted due to retention obligations. In this case, the rule is: restrict instead of delete. The record remains for tax purposes but is blocked for sales and marketing and will no longer appear in evaluations or campaigns.

This distinction is the practically most important point and is missing in most implementations.

Automatically Instead of Manually

A monthly run that processes due records and logs it. It does not happen manually – not out of negligence, but because no one checks deadlines daily.

What Should Be Logged

What was deleted or blocked when, and on what basis. Without a log, implementation cannot be proven.

The Most Common Mistake

Deletion periods only for the main data. Attachments, email threads, logs, and backups are often forgotten. For backups, deletion in the ongoing inventory is common, along with the exclusion of reuse.

This text does not replace legal advice.

Key facts

For each type of data: Define period and trigger event
In case of retention obligation: Restrict instead of delete
Implementation: Automatic run with log