"We delete personal data when we no longer need it." Many companies say this. The GDPR then asks: When do you no longer need it - and can you prove it? Very few have a documented answer to both questions.
The situation is getting worse for production companies: production systems collect personal data in quantities that hardly anyone can keep track of. Machine operator IDs in production logs. User accounts in MES systems. Access data in quality software. Photos of ID documents in plant access systems. Customer data in ERP order histories. All of this is subject to the GDPR - and all of it must be deleted according to a clear concept.
This article explains what a GDPR-compliant deletion concept contains, how the conflict with retention periods under commercial law is resolved, which deletion methods are permitted and when - and how CHRONOS automates the entire process and documents it in an audit-proof manner.
|
THE MOST IMPORTANT POINTS IN BRIEF
|
|
IN A NUTSHELL
|
What the GDPR specifically requires for erasure
The GDPR contains several standards that establish erasure obligations. The best known is the right to erasure under Art. 17 - the so-called 'right to be forgotten'. But this is only one of several legal bases.
THE FOUR DSGVO OBLIGATIONS RELATING TO ERASURE
-
Art. 5 para. 1 lit. e - Storage limitation: Personal data may only be stored for as long as is necessary for the purpose of processing. This is not an optional rule - it is an obligation to actively delete data.
-
Art. 17 - Right to erasure (right to be forgotten): Data subjects can request erasure. The company then typically has 30 days to delete and inform the data subject.
-
Art. 25 - Data protection by design (Privacy by Design): Deletion periods do not have to be implemented manually - they must be technically embedded. A system without automatic deletion routines does not fulfill Art. 25.
-
Art. 5 para. 2 - Accountability: The company must be able to prove that data has been properly erased. This proof is not possible without an erasure log.
|
up to € 20 million GDPR fine max. Art. 83 para. 5 GDPR |
30 days Time limit for erasure request Art. 17 GDPR |
Art. 5 Obligation to limit storage GDPR principles |
100% Obligation to erase all systems Data protection authorities |
What a deletion concept must contain - the 7 mandatory components
A deletion concept is not an optional document. Data protection authorities expect it as part of the verification process in accordance with Art. 5 para. 2 GDPR (accountability). The following framework corresponds to the standard of the Data Protection Conference (DSK) and the ULD guidelines on erasure concepts.
|
STEP 1 Processing directory as a basis |
Processing directory as a basis Objective: Complete overview of all data processing operations involving personal data
Result: Complete processing directory in accordance with Art. 30 GDPR |
|
STEP 2 Define data classes and deletion periods
|
Define data classes and erasure periods Objective: Assign a specific deletion period and legal basis to each data category
Result: Deletion period matrix: Data category → Deadline → Legal basis → Responsible system |
|
STEP 3 Determine technical erasure methods
|
Define technical erasure methods Goal : Define the appropriate deletion method for each data category and system type
Result: Technical deletion concept per system category |
|
STEP 4 Define responsibilities and processes
|
Define responsibilities and processes Objective: Who deletes what - and how is this triggered?
Result: Documented deletion process with responsibility matrix |
|
STEP 5 Set up deletion log
|
Set up deletion log Goal: Document proof of all deletion processes in an audit-proof manner
Result: Audit-proof deletion log as proof of compliance |
|
STEP 6 Document exceptions and conflicts
|
Document exceptions and conflicts Goal: Transparently document cases in which deletion must be postponed
Result: Documented list of exceptions with justifications |
|
STEP 7 Regular review and update
|
Regular review and update Objective: Deletion concept is not a static document - it must be kept up to date
Result: Current, approved deletion concept with version history |
Deletion periods by data category - the reference table
The following table shows retention periods (minimum duration from HGB/AO) and GDPR deletion periods (maximum duration) in direct comparison - for the most common data categories in production companies.
|
Data category |
Retention period |
GDPR deletion period |
Deletion trigger |
Special feature |
|---|---|---|---|---|
|
Customer master data |
10 J. (for tax purposes) |
After end of contract + tax deadline |
End of contract + 10 yrs. |
Retain for tax purposes, block for marketing |
|
Order history / invoices |
10 J. (AO §147) |
Expiry of retention obligation |
10 years from invoice date |
Delete personal data components after 10 years |
|
Employee master data |
10 J. (for tax purposes) |
Departure + deadlines |
Resignation + 10 years for tax purposes |
Applicant data: 6 months after rejection |
|
Wage documents |
up to 30 years (SV) |
Expiry of pension entitlement |
Individual |
Check pension notification date as trigger |
|
MES logs (without personal reference) |
5-10 J. |
No DSGVO obligation |
Depending on product liability |
As soon as no personal reference: no GDPR problem |
|
MES logs (with machine operator ID) |
5-10 J. (product liability) |
Purpose not applicable |
Pseudonymize after quality check |
Pseudonymization as an alternative to deletion |
|
Access system / time recording |
2-3 yrs (disputes) |
Max. 6 months to 2 yrs. |
Company agreement |
BetrVG §87 - Involve works council |
|
Video surveillance |
72 hours (BDSG §4) |
72 h, max. 10 days |
Automatically after 72 h |
In the event of incidents: Save and document a copy |
|
E-mail inboxes (employees who have left the company) |
6 yrs (commercial letters) |
30 days after leaving |
Departure + 30 days forwarding |
Thereafter: Delete or archive and block |
|
Quality data (without personal reference) |
10-15 yrs (product liability) |
No DSGVO obligation |
Depending on industry |
In case of doubt, check personal reference |
|
Supplier master data |
6-10 J. |
End of contract + deadline |
End of contract + 10 yrs. |
Check contact person data separately |
|
Applicant data |
No legal obligation |
6 months after rejection |
Date of rejection |
Consent allows longer storage |
GDPR vs. HGB: Conflicts of standards and how production companies resolve them
The most common mistake when dealing with data protection and retention law is to view both standards in isolation. This leads either to GDPR violations (stored for too long) or to tax law risks (deleted too early). The solution lies in a dedicated archiving concept.
NORM CONFLICT: Invoices to private customers
|
AO §147 / HGB §257 Retention obligation 10 years - even if customer contains personal data |
GDPR Art. 17 Deletion as soon as contractual purpose fulfilled and no other reason for processing exists |
|
SOLUTION: Earmarked archiving: Archive data for tax purposes for 10 years - at the same time technically block for all other purposes (marketing, CRM, product recommendations). |
|
NORMAL CONFLICT: Employee data after termination
|
AO §147 / Wage law Retain payroll documents and tax-relevant data for up to 30 years |
DSGVO Art. 5 Personal data only as long as absolutely necessary - storage should be minimal after resignation |
|
SOLUTION: Staged archiving: immediate blocking for operational systems (HR, Active Directory) after leaving. Archive tax-relevant payroll documents separately with access only for the tax/payroll department. Delete non-tax-related data completely. |
|
NORMAL CONFLICT: Supplier data after the end of the contract
|
HGB §257 Retain contract-related documents for 6-10 years after the end of the contract |
DSGVO Art. 17 Delete personal contact data after the end of the contract - no longer an active processing purpose |
|
SOLUTION: Data separation: Retain company data (supplier GmbH) in accordance with HGB. Delete personal contact data (name, e-mail, telephone of natural persons) after the end of the contract and a reasonable follow-up period |
|
NORM CONFLICT: MES logs with employee IDs
|
Product liability law Retain production logs for 5-15 years for product liability evidence |
GDPR Employee IDs in logs are personal data - processing purpose ends with production completion |
|
SOLUTION: Pseudonymization: Replace employee IDs with pseudonymous codes after quality inspection completion. The original mapping is stored separately and can only be decrypted if necessary (legal dispute). Protocol remains usable for product liability. |
|
Special features for production companies: This data is often overlooked
Production companies process personal data in systems that do not appear to be 'data protection systems' at first glance. This is precisely where the most dangerous compliance gaps arise - because no responsibility is clear.
|
System |
Personal data |
GDPR relevance |
Recommended measure |
|---|---|---|---|
|
MES / production SW |
Machine operator IDs, shift assignments, performance data |
High - direct personal reference |
Pseudonymization after quality approval; define deletion period |
|
Access system / locks |
Biometrics (fingerprint), access time stamp, photos |
Very high - special data category according to Art. 9 |
Company agreement required; deletion after 72h to 6 months |
|
Video surveillance |
Personal recordings, movement profiles |
High - special sensitivity |
Max. 10 days, secured copy with log in the event of incidents |
|
Quality management system |
Inspector IDs, signatures, release logs |
Medium - with full traceability High |
Pseudonymization possible; product liability has priority |
|
Time recording system |
Working hours, breaks, sick notes |
High - particularly in need of protection |
Observe BetrVG §87; deletion period 2-3 years after works council agreement |
|
ERP system |
Customer data, supplier AP, employee data |
High - central data storage |
Earmarked archiving; blocking/deletion logic per data category |
|
E-mail archive |
Communication with customers, employees, authorities |
Medium to high |
6 years Commercial letters; delete personal content after expiry of deadline |
|
SCADA / IoT systems |
Sensor data with operator ID, remote access protocols |
Low to medium |
Check personal reference; for operator IDs: GDPR-relevant |
Deletion methods: What 'really deleted' technically means
Erasure in the GDPR sense means that the personal data can no longer be processed and cannot be reconstructed. 'Deleting' a database entry using a DELETE statement is often not enough - the data may still exist in backups, archives, test environments and transaction logs.
|
Method |
Secure? |
Verifiable? |
Suitable for |
Weakness |
|---|---|---|---|---|
|
Logical deletion (DELETE) |
No |
Conditional |
Simple databases without backup requirement |
Data often still available in backups/logs |
|
Overwrite (DoD 5220.22-M) |
Yes |
Conditional |
HDDs, magnetic tapes |
Not suitable for SSDs and flash memory |
|
Cryptographic erasure |
Yes |
Yes |
Cloud data, encrypted archives |
Prerequisite: Encryption from the start |
|
Physical destruction |
Yes (100%) |
Yes |
Defective data carriers, end-of-life |
Not scalable; observe DIN 66399 |
|
Anonymization |
Yes* |
Yes |
Statistical data, log data |
Only if tracing back to a person is really impossible |
|
Pseudonymization |
No (subject to GDPR) |
Conditionally |
Production logs, MES data |
Reduces risk - does not completely replace deletion |
|
Selective database archive deletion |
Yes |
Yes |
CHRONOS archive, audit-proof system |
Requires archiving system with deletion function |
ATTENTION: THE BACKUP TRAP
The most common technical problem: data is deleted from the production system - but the backup that was created 24 hours earlier still contains it.
-
GDPR compliance requires: Deletion from ALL systems - production system, backups, archives, test environments and staging systems.
-
Practical solution: Specify a defined cycle for backup systems, after which the backup is also deleted. Document this cycle in the deletion concept.
-
For archive data: CHRONOS enables the selective deletion of individual data records from the archive - with an audit-proof log. This is the only way to comply with the archiving obligation and GDPR at the same time.
CHRONOS: Automated deletion management for production companies
CHRONOS was developed for precisely this challenge: Complying with retention obligations and deletion obligations at the same time - audit-proof, manufacturer-independent and without manual effort. The platform enables what many companies consider impossible: selective deletion of individual data records from an audit-proof archive - with a complete log.
Many IT managers think that a deletion concept is a Word document. It is a technical system. Without automation, GDPR-compliant erasure cannot realistically be implemented in production companies.
- Korbinian Hermann Managing Director, CSP Intelligence GmbH
Frequently asked questions about the erasure concept and GDPR
