Data retention & deletion: what is deleted when?
Short answer
Section titled “Short answer”Notory never deletes anything silently in the background. There are exactly three mechanisms, each of them traceable:
- Trash for assets, records and recurring absences - first restorable, then permanently removed after a configurable retention period.
- Deleting a user means anonymising them (GDPR Art. 17): personal data is overwritten and sign-in is made impossible, while the account row and the audit log are kept for integrity.
- Log retention: the audit log and journal are cleaned up after a configurable period.
Important: working-time and leave data are NOT deleted - they are subject to a statutory retention obligation (e.g. Sec. 16(2) ArbZG, two years) and a tamper-evident monthly seal. A per-data-class configurable retention is in preparation.
Prerequisites
Section titled “Prerequisites”What exactly happens on each kind of deletion
Section titled “What exactly happens on each kind of deletion”1. Trash (assets, records, recurring absences)
Section titled “1. Trash (assets, records, recurring absences)”When deleted, these objects first move to the trash (soft delete): they disappear from the normal
lists but remain restorable. They are permanently removed only once the trash retention period
has elapsed (see What is configurable). With a period of 0 they stay until
the trash is emptied manually.
2. Deleting a user = anonymisation (GDPR Art. 17)
Section titled “2. Deleting a user = anonymisation (GDPR Art. 17)”A user is pseudonymised, not removed as a database row. Specifically:
- Overwritten: email (to an undeliverable
...@deleted.invalidaddress), username, full name (Erased user) and the language setting. - The account is deactivated and the password replaced by an unusable random value - sign-in becomes impossible.
- Permanently deleted: the authentication artefacts - 2FA devices (TOTP), API tokens and password-reset tokens.
- Deliberately kept: the (now anonymous) account row and the audit log - so traceability and the log’s hash chain stay intact; the log then references an anonymised subject.
Note: this step is irreversible. Business data the user created (e.g. assets) remains and points to the anonymised account - so neither history nor inventory is lost.
3. Logs: audit log and journal
Section titled “3. Logs: audit log and journal”The audit log and journal contain some personal fields (e.g. IP addresses). They are cleaned up automatically after the configured retention period. Without a period set, they are kept. The cleanup continues the hash chain cleanly, so tamper-evidence is preserved.
4. Working time & leave - NOT deleted
Section titled “4. Working time & leave - NOT deleted”Working-time bookings and leave/absence data do not go to the trash and are not removed automatically. Reason: the statutory retention obligation (e.g. Sec. 16(2) ArbZG / Sec. 17(2) MiLoG, at least two years) and the audit-proof monthly seal. Their lawful deletion after the period expires will be handled by the upcoming configurable retention.
5. Attachments and sick notes
Section titled “5. Attachments and sick notes”File attachments (including Art. 9-protected sick notes) are deleted or cleaned up together with their object and, during operation, are subject to the same access restrictions as the object itself.
What is configurable
Section titled “What is configurable”Available in the administration area (instance / tenant configuration):
- Trash on/off and the trash retention in days (
0= until emptied manually). - Audit-log retention (days) and journal retention (days) - each empty = unlimited.
Periods can always be extended. A per-data-class retention with statutory minimums is in preparation.
What to keep in mind
Section titled “What to keep in mind”- No silent background deletion. Every permanent removal follows either your action (empty the trash, anonymise a user) or a period you configured.
- Anonymising is final. The overwritten personal data cannot be recovered.
- Statutory retention comes first. You cannot delete working-time and leave data early - this protects you during audits (customs/FKS, labour inspectorate) and pay disputes.
- Wages/salaries are not handled by Notory; payroll accounts and pay records with their periods live in the connected payroll solution (e.g. DATEV), not in Notory.
- Tenant separation. Deletions only ever affect your own tenant (enforced by row-level security).
In preparation: configurable retention per data class
Section titled “In preparation: configurable retention per data class”A retention/deletion engine is planned (not yet available). It will offer:
- Periods per data class (working time, leave, sickness) - global or per tenant, with the statutory minimum as the default and a clear warning if a value falls below the statutory minimum.
- A four-state model (Active → Deactivated → Archived/Blocked → Deleted/Anonymised) with deletion per data class instead of a single blanket per-user date.
- An immutable, sealed archive and a tamper-proof deletion log.
- A legal hold that stops any deletion during an ongoing dispute.
Because it concerns legally sound retention periods, the engine will only go live after a lawyer/DPO confirms the periods. Until then, the behaviour described above applies.