Why does an organisation need a data deletion concept?
Personal data may only be processed for as long as the purpose requires. The GDPR also requires organisations to be able to demonstrate compliance with these principles (Art. 5 para. 2 GDPR). Without a concept, it remains unclear what should be deleted when – and nobody can prove it.
A data deletion concept also pays off beyond the legal department: less data means less damage in the event of a data breach, faster responses to access requests and lower storage and migration costs.
How is a data deletion concept structured?
The building blocks have proven themselves since DIN 66398 and are carried over into ISO/IEC 27555:
| Building block | Content |
|---|---|
| Data types | Groups of data with the same purpose and the same period, such as contract data or job application documents. |
| Deletion period | How long the data is retained, with justification and legal basis. |
| Starting point | The event from which the period runs, such as the end of a contract or the closure of a case. |
| Deletion classes | Combinations of period and starting point; several data types share one class. |
| Exceptions | When deletions are put on hold, for example in the event of litigation or an investigation (legal hold). |
| Responsibility | Who defines, approves, implements and monitors retention periods. |
| Implementation per system | How data is deleted, anonymised or archived in each system. |
What changes with ISO/IEC 27555?
The method stays the same: data types, deletion classes and standard deletion periods, i.e. the default period for each deletion class. What is new is the international framework. ISO/IEC 27555 belongs to the ISO/IEC 27000 family of standards and can therefore be integrated into existing management systems for information security and data protection.
If you already have a data deletion concept under DIN 66398, you do not need to start over. It is worth switching the terms and references to the new standard at the next review.
Why do data deletion concepts fail in practice?
Rarely because of the method, mostly because of the implementation:
- The concept exists as a document, but the systems do not delete.
- Dependencies between applications are overlooked: a customer is deleted in one system but still linked in another.
- Nobody receives confirmation of whether data was actually deleted.
- Retention periods change, but the systems are not updated.
- Exceptions are managed by email and fall into oblivion.
From concept to proven deletion
A data deletion concept becomes effective when it is connected to the systems:
- 1Maintain and approve retention periods with justification and legal basis in a retention schedule.
- 2Hand over approved retention periods and deletion holds to a central deletion orchestration.
- 3The applications report which records have reached the end of their period.
- 4Deletion takes place in the right order, with checks and – where necessary – approvals.
- 5Each application reports back what it has deleted. This produces the proof.