Aufbewahrungsfristen
Diese Seite beschreibt, wie lange HERA personenbezogene und personenbeziehbare Daten aufbewahrt und welche Daten automatisch gelöscht werden. Sie ergänzt die Datenschutzerklärung und das Einwilligungsmanagement.
Grundsätze:
- Datenminimierung: Daten werden nur so lange aufbewahrt, wie sie für den Zweck erforderlich sind.
- Automatische Bereinigung: Wo möglich, erfolgt die Löschung durch zeitgesteuerte Hintergrund-Jobs (siehe Abschnitt Technische Umsetzung).
- Manuelle Löschung: Daten ohne automatische Frist können jederzeit über die jeweilige Verwaltungsoberfläche entfernt werden.
Übersicht der Aufbewahrungsfristen
Legende:
- ✅ Geregelt – automatischer Cleanup-Job ist aktiv.
- ⚠️ Teilweise geregelt – nur bei bestimmten Ereignissen (z. B. Account-Löschung) bereinigt.
- ❌ Nicht geregelt – keine automatische zeitliche Begrenzung; nur manuelle oder kaskadierte Löschung.
Benachrichtigungen und Versand-Protokoll
| Datenkategorie |
Tabelle |
Frist |
Status |
Anmerkung |
| Gelesene Benachrichtigungen |
notifications |
7 Tage nach read_at |
✅ |
Hard-Delete; gilt auch für vom Nutzer per Soft-Delete entfernte gelesene Einträge. |
| Ungelesene Benachrichtigungen |
notifications |
30 Tage nach inserted_at |
✅ |
Hard-Delete. |
| Versand-Protokoll |
notification_deliveries |
30 Tage nach inserted_at |
✅ |
Dient der Auswertung von Push-/E-Mail-Zustellungen. |
Kalender und Termine
| Datenkategorie |
Tabelle |
Frist |
Status |
Anmerkung |
| Gelöschte Kalendereinträge |
calendar_entries |
7 Tage nach deleted_at |
✅ |
Hard-Delete inklusive Anhängen, Teilnehmenden, Fahrzeug-/Orts-Verknüpfungen, Einladungen mit Zu-/Absagen, Dienstzeit-Buchungen und Themenplan-Verknüpfungen. |
| Verwaiste Anhänge (kein zugehöriger Kalendereintrag) |
calendar_entry_attachments |
24 Stunden nach inserted_at |
✅ |
Garbage Collector für Upload-Reste, die keinem Eintrag zugeordnet wurden. |
| Aktive (nicht gelöschte) Kalendereinträge |
calendar_entries |
– |
⚠️ |
Werden bis zur manuellen Löschung oder bis zum Ende des Ortsverbands aufbewahrt. Keine automatische Frist nach Termindatum. |
| Antworten zu Einladungen (Zu-/Absagen) |
calendar_entry_invitations |
– |
⚠️ |
Werden mit dem zugehörigen Kalendereintrag gelöscht (Cascade). Solange der Eintrag besteht, bleiben die Antworten erhalten. |
Mitglieder und Stammdaten
| Datenkategorie |
Tabelle |
Frist |
Status |
Anmerkung |
| Abwesenheiten von Mitgliedern |
member_absences |
7 Tage nach end_date |
✅ |
Hard-Delete; Grund und Kommentar gehen verloren. |
| Soft-gelöschte Mitglieder (Anonymisierung) |
members |
7 Tage nach deleted_at |
✅ |
Personenbezogene Felder werden anonymisiert; statistische Spuren in Audit-Events bleiben pseudonymisiert. |
| Aktive Mitgliedsdatensätze |
members |
– |
⚠️ |
Bleiben bis zum manuellen Löschen oder OV-Reset erhalten. |
| Member-Health-Daten / Gesundheitsdaten |
members.encrypted_data["health"], member_healths (jeweils verschlüsselt) |
bei jedem THWin-Import |
✅ |
Bei jedem THWin-Gesundheitsdatenimport wird der Bestand verworfen und ausschließlich durch die importierten Datensätze ersetzt; eine Historie wird nicht gespeichert. Mitglieder, die nicht im aktuellen Import enthalten sind (inklusive soft-gelöschter und ausgetretener Mitglieder), verlieren ihre Gesundheitsdaten unwiderruflich. Beim Soft-Delete eines Mitglieds bleiben die Daten bis zum nächsten Import bestehen, beim Hard-Delete bzw. OV-Reset werden sie per FK-Cascade entfernt. |
Importe
| Datenkategorie |
Tabelle |
Frist |
Status |
Anmerkung |
| Importstatistik (letzte 10 pro Typ und OV) |
imports |
– (Kontingent) |
✅ |
Nur die letzten 10 Vorgänge je Typ werden vorgehalten. |
| Detaillierte Fehlerprotokoll-Einträge |
import_log_entries |
24 Stunden nach inserted_at oder beim nächsten Import desselben Typs |
✅ |
Dienen ausschließlich der Fehleranalyse. |
Erste-Hilfe-Verbandbuch
| Datenkategorie |
Tabelle |
Frist |
Status |
Anmerkung |
Verbandbuch-Entwürfe (Status draft) |
first_aid_log_entries |
24 Stunden nach inserted_at |
✅ |
Stündlicher Cleanup-Job. |
Eingereichte Verbandbuch-Einträge (submitted/acknowledged/closed) |
first_aid_log_entries |
5 Jahre nach submitted_at |
✅ |
Beim Einreichen wird das Feld retention_until = submitted_at + 5 Jahre gesetzt (DGUV-Aufbewahrungsfrist). Tägliche Prüfung; abgelaufene Einträge werden hard-gelöscht. Für Altdaten ohne retention_until gilt ersatzweise submitted_at als Stichtag. |
DSGVO-Datenexporte
| Datenkategorie |
Tabelle |
Frist |
Status |
Anmerkung |
| Exportdateien für betroffene Personen |
data_exports (Dateien auf Festplatte) |
bis expires_at (siehe Export-Dialog) |
✅ |
Stündlicher Cleanup; Dateien werden samt DB-Datensatz entfernt. |
Anmeldungen, Sitzungen und Konten
| Datenkategorie |
Tabelle |
Frist |
Status |
Anmerkung |
| Sitzungs-Tokens |
users_tokens (Kontext session) |
14 Tage ab Erstellung |
✅ |
Bei aktiver Nutzung wird das Token automatisch alle 7 Tage durch ein neues ersetzt; eine aktive Sitzung läuft daher praktisch nicht ab. Inaktive Sitzungen werden nach 14 Tagen verworfen und der Datenbankeintrag durch den stündlichen Cleanup hard-gelöscht. |
| Magic-Link-Token |
users_tokens (Kontext login) |
20 Minuten ab Erstellung |
✅ |
Validitätsprüfung; abgelaufene Tokens werden stündlich aus der Datenbank entfernt. |
| Pending-2FA-Tokens |
users_tokens (Kontext pending_2fa) |
5 Minuten ab Erstellung |
✅ |
Wie oben. |
| E-Mail-Wechsel-Tokens |
users_tokens (Kontext change:*) |
7 Tage ab Erstellung |
✅ |
Wie oben. |
| Onboarding-Bestätigungs-Tokens |
users_tokens (Kontext onboarding_confirmation) |
7 Tage ab Erstellung |
✅ |
Wie oben. |
| OV-Beanspruchungs-Tokens |
users_tokens (Kontext organization_claim) |
7 Tage ab Erstellung |
✅ |
Wie oben. |
| OV-Setup-Bestätigungs-Tokens |
users_tokens (Kontext setup_confirmation) |
7 Tage ab Erstellung |
✅ |
Wie oben. |
Audit- und Sicherheitsereignisse
| Datenkategorie |
Tabelle |
Frist |
Status |
Anmerkung |
| Sicherheitsrelevante Ereignisse (Login, 2FA, Magic-Link, Konsens, Datenexport, …) |
audit_events |
90 Tage nach inserted_at |
✅ |
Hard-Delete; tägliche Prüfung. Sicherheitsereignisse werden ausreichend lange für Nachweis und Auswertung vorgehalten und anschließend konsequent gelöscht. |
| Importprotokolle der Verwaltung (Audit-Sicht) |
– |
– |
⚠️ |
Hängen am imports-Datensatz; siehe oben. |
Bewerbermanagement
| Datenkategorie |
Tabelle |
Frist |
Status |
Anmerkung |
| Bewerbungsdaten (Interessenten, Kontaktinformationen) |
users, members, membership_admission_documents |
7 Tage nach Storno bzw. Ablehnung |
✅ |
Storniert ein:e Bewerber:in den Vorgang selbst (onboarding_status :cancelled) oder lehnt das OV die Bewerbung ab (:declined), werden Bewerber-Account, Stammdaten und alle hochgeladenen Aufnahmeantrags-PDFs (inkl. Datei auf Disk) sieben Tage später automatisch gelöscht (täglicher Job, 04:15 Europe/Berlin). |
| Onboarding-Historie |
onboarding_history |
7 Tage nach Storno bzw. Ablehnung |
✅ |
Folgt der Bewerber-Löschung per FK-Cascade (on_delete: :delete_all). |
| Nachrichten an Bewerber |
onboarding_messages |
7 Tage nach Storno, Ablehnung oder Mitgliedsende |
✅ |
Bei Storno/Ablehnung werden die Nachrichten gemeinsam mit dem Bewerber-Account per FK-Cascade gelöscht. Bei aufgenommenen Mitgliedern bleiben die Nachrichten für die Dauer der Mitgliedschaft erhalten und werden 7 Tage nach Beendigung der Mitgliedschaft (Stichtag: users.deleted_at) durch den täglichen Job (04:30 Europe/Berlin) hard-gelöscht. |
Sonstige Bereiche
| Datenkategorie |
Tabelle |
Frist |
Status |
Anmerkung |
| Bekleidungsbestellungen, Inventar, Schadenmeldungen |
diverse |
– |
⚠️ |
Sachdaten ohne kritischen Personenbezug; Löschung bei Mitgliederlöschung über FK-Cascade oder OV-Reset. |
| Aufgaben, Aufgabensammlungen |
tasks, task_collections |
– |
⚠️ |
Personenbezug nur über Zuweisung; Cascade bei Account-Löschung. |
| Belehrungen, Bescheinigungen, Zertifizierungen |
member_certifications, member_certification_attachments |
bei Import bzw. Mitgliedsende |
✅ |
Werden bei jedem THWin-Berechtigungsimport aktualisiert; im Import nicht mehr enthaltene Einträge werden gelöscht (mit Anhang verbleiben sie soft-gelöscht zur manuellen Prüfung in der Verwaltung). Beim Soft-Delete eines Mitglieds (Mitgliedsende) werden alle Berechtigungs-/Belehrungs-Einträge inkl. hochgeladener Bescheinigungen sofort hard-gelöscht. Beim Hard-Delete und OV-Reset zusätzlich per FK-Cascade. |
Lücken und offene Regelungsbedarfe
Folgende Bereiche haben aktuell keine automatische Aufbewahrungsfrist und sollten geprüft werden:
- Aktive Kalendereinträge in der weiten Vergangenheit: Termine bleiben unbegrenzt sichtbar. Eine optionale Frist (z. B. „Termine älter als 5 Jahre archivieren") könnte die Datenmenge reduzieren.
Technische Umsetzung
Die automatische Bereinigung erfolgt durch periodische Hintergrund-Jobs unter lib/hera/scheduling/jobs/ und Worker unter lib/hera/. Sie werden im Application-Supervisor (lib/hera/application.ex) gestartet.
| Job / Worker |
Intervall |
Zuständig für |
Hera.Scheduling.Jobs.NotificationCleanup |
stündlich |
Benachrichtigungen (gelesen 7 d, ungelesen 30 d) und notification_deliveries (30 d) |
Hera.Scheduling.Jobs.UserTokenCleanup |
stündlich |
Abgelaufene Einträge in users_tokens (Sitzung 14 d, Magic-Link 20 min, Pending-2FA 5 min, Bestätigungs-Tokens 7 d) |
Hera.Calendar.DeletedEntriesCleanup |
stündlich |
Soft-gelöschte Kalendereinträge nach 7 Tagen |
Hera.Calendar.Attachments.GarbageCollector |
stündlich |
Verwaiste Kalender-Anhänge nach 24 h |
Hera.Scheduling.Jobs.MemberAbsenceCleanup |
alle 6 h |
Abwesenheiten 7 Tage nach end_date |
Hera.Scheduling.Jobs.MemberAnonymizationDaily |
täglich (03:30) |
Anonymisierung soft-gelöschter Mitglieder nach 7 Tagen |
Hera.Scheduling.Jobs.ImportLogEntryCleanup |
stündlich |
Importprotokolleinträge nach 24 h |
Hera.Scheduling.Jobs.FirstAidDraftEntryCleanup |
alle 30 min |
Verbandbuch-Entwürfe nach 24 h |
Hera.Scheduling.Jobs.FirstAidLogEntryRetention |
täglich (03:45) |
Eingereichte Verbandbuch-Einträge nach 5 Jahren (DGUV) |
Hera.Scheduling.Jobs.AuditEventCleanup |
täglich (04:00) |
Audit-Events (audit_events) nach 90 Tagen |
Hera.Scheduling.Jobs.RecruitmentApplicantCleanup |
täglich (04:15) |
Bewerbungsdaten 7 Tage nach Storno (:cancelled) oder Ablehnung (:declined) inkl. PDFs auf Disk |
Hera.Scheduling.Jobs.RecruitmentMessageCleanup |
täglich (04:30) |
Onboarding-Nachrichten an Bewerber 7 Tage nach Auflösung des Benutzerkontos (users.deleted_at) – greift insbesondere bei aufgenommenen Mitgliedern, deren Mitgliedschaft endet |
Hera.Scheduling.Jobs.DataExportCleanup |
stündlich |
Abgelaufene Datenexporte |
Hera.Scheduling.Jobs.OvResetDeletes |
alle 30 min |
Fällige OV-Löschungen (24-h-Widerrufsfrist) |
Alle Jobs implementieren das Verhalten Hera.Scheduling.BatchJob. Fehler beim Verarbeiten eines einzelnen Elements brechen den Lauf nicht ab; sie werden über das Logging und Telemetry sichtbar.
Zusätzlich gibt es ereignisgesteuerte Bereinigungen, die keinen periodischen Job benötigen, weil sie Bestandteil eines anderen Vorgangs sind:
- Gesundheitsdaten-Import (
Hera.Imports.Importers.Gesundheitsdaten): Nach jedem erfolgreichen THWin-Gesundheitsimport ruft der Importer Hera.Members.clear_health_for_members_outside/2 innerhalb derselben Transaktion auf. Mitglieder, die nicht in der Importdatei enthalten sind (inkl. soft-gelöschter Mitglieder), verlieren dadurch ihre vorhandenen Gesundheitsdaten und ihren eb-Status.
- Berechtigungs-/Zertifizierungsimporte: Vergleichbare Logik im jeweiligen Importer (siehe entsprechende Module unter
lib/hera/imports/importers/).
Verwandte Dokumentation