Personaldaten Aufbewahrung ist die Disziplin, für jede Art von Personaldatensatz zu entscheiden, wie lange er existieren soll, und das System dann dazu zu bringen, es tatsächlich zu tun. Sie ist aus einem Grund schwierig, der nichts mit Technik zu tun hat: Die Antwort ist in jeder Rechtsordnung und für jede Kategorie von Datensatz eine andere, und keine einzelne Zahl kann überall richtig sein.
Dieser Artikel legt dar, warum es keine einheitliche Frist gibt, wie sich Personaldatensätze in Gruppen mit unterschiedlichen Uhren teilen, welche Grundsätze die Entscheidung leiten und was eine Löschung abdecken muss, um etwas zu bedeuten.
Warum gibt es keine einheitliche Aufbewahrungsfrist?
Weil die Frist von demjenigen gesetzt wird, der die Verfügungsgewalt über den Datensatz hat, und das variiert nach Rechtsordnung und oft nach der Art des Datensatzes innerhalb einer einzigen Rechtsordnung.
Manche Fristen existieren, weil ein Anspruch so lange noch geltend gemacht werden kann und die Frist so gesetzt ist, dass die Beweise den Anspruch überleben. Manche existieren, weil eine Aufsichtsbehörde den Datensatz zur Prüfung verlangt. Manche existieren, um der Person zu dienen, um die es geht, damit sie Jahre später ein Zeugnis erhalten oder eine Beschäftigungsdauer belegen kann. Und manche existieren allein deshalb, weil dem System nie gesagt wurde, dass es aufhören soll, sie zu behalten – was gar keine Regel ist, sondern deren Abwesenheit.
Die praktische Folge ist, dass jeder, der Aufbewahrung entwirft, die Frist als Konfiguration behandeln sollte, die der Betreiber für seine eigene Rechtsordnung liefert, und nicht als Konstante, die der Entwickler wählt. Eine fest verdrahtete Dauer ist an den meisten Orten falsch, an denen sie laufen wird, und sie ist still falsch, weil nichts im System prüft, ob die Zahl noch gilt. Wo eine Frist konfigurierbar ist, kann der Betreiber für sie einstehen; wo sie einbetoniert ist, kann es niemand.
Wie teilen sich Personalakten nach Zweck?
Nach dem, wofür der Datensatz da ist, denn das bestimmt seine Uhr. Vier Gruppen decken das meiste ab, was ein Bewerbungssystem hält.
| Gruppe | Wofür sie da ist | Warum ihre Uhr anders läuft |
|---|---|---|
| Datensätze aktiver Beschäftigter | Verwaltung des Beschäftigungsverhältnisses | Bleiben, solange das Verhältnis dauert, und meist darüber hinaus |
| Datensätze ehemaliger Beschäftigter | Zeugnisse, Ansprüche und gesetzliche Pflichten | Bleiben für eine Frist nach dem Ende des Verhältnisses, gesetzt vom Betreiber |
| Material abgelehnter Bewerber | Belege über eine Entscheidung | Meist die kurzlebigste Gruppe, weil die Entscheidung abgeschlossen ist |
| Gesprächsnotizen und Beurteilungen | Die Begründung hinter einer Entscheidung | Häufig übersehen, und die Gruppe, die am oftesten formlos behalten wird |
Die letzten beiden Gruppen verursachen die meisten Schwierigkeiten, und aus demselben Grund: Sie entstehen mitten in einem Verfahren, durch Menschen, die nicht an ein Aktenregime denken, und sie leben oft außerhalb des Systems, das alles andere verwaltet. Notizen aus einem Gespräch, Nachrichten zwischen Gesprächspartnern und eine Tabelle zum Vergleich von Kandidatinnen sind sämtlich Personaldatensätze. Eine Aufbewahrungsrichtlinie, die nur das Bewerberverwaltungssystem abdeckt, deckt einen Teil des Bildes ab.
Alle vier Gruppen als einen Datensatz mit einem Ablaufdatum zu behandeln, ist der häufigste Entwurfsfehler. Er erzeugt das Schlechteste beider Ausgänge: Bewerbermaterial, das weit länger behalten wird als die Entscheidung erfordert, und Beschäftigungsdatensätze, die früher ablaufen, als die Pflichten des Betreibers erlauben.
Welche Grundsätze sollten die Entscheidung leiten?
Sechs, und es sind die gewöhnlichen Grundsätze für personenbezogene Informationen, angewandt auf einen Bewerbungskontext.
- Zweckbindung – den Datensatz für einen benannten Zweck erheben und ihn später nicht umwidmen, nur weil er gerade da ist.
- Datenminimierung – halten, was der Zweck erfordert, und nichts, was lediglich nützlich sein könnte.
- Richtigkeit – den Datensatz korrekt halten und der Person einen Weg geben, ihn berichtigen zu lassen.
- Speicherbegrenzung – festlegen, wie lange jeder Datensatz lebt, und es durchsetzen statt es anzunehmen.
- Integrität und Vertraulichkeit – begrenzen, wer den Datensatz erreichen kann, und wissen, wer es getan hat.
- Rechenschaft – zeigen können, dass die ersten fünf tatsächlich geschehen.
Zwei davon werden häufig behauptet und selten umgesetzt. Die Speicherbegrenzung existiert meist als geschriebene Richtlinie ohne Mechanismus dahinter, sodass Datensätze ihre Frist überleben und niemand es erfährt. Rechenschaft bedeutet meist ein Dokument statt einer Praxis, sodass es keine Möglichkeit gibt, eine Frage danach zu beantworten, was wann gelöscht wurde.
Die Datenminimierung verdient im Bewerbungskontext eine ausdrückliche Warnung, weil die Versuchung in die andere Richtung läuft. Zusätzliche Informationen wirken zum Zeitpunkt der Erhebung harmlos und sind genau das Material, das später eine Angriffsfläche schafft. Ein Feld, das für die Entscheidung nicht nötig ist, ist keine neutrale Ergänzung; es ist eine Verbindlichkeit mit angehängter Aufbewahrungsuhr.
Was muss eine Löschung abdecken?
Alles, was der Datensatz berührt hat, und das ist fast nie eine einzelne Tabelle.
Das Leben eines Datensatzes hinterlässt Spuren an den Orten, die er durchlaufen hat, und jeder dieser Orte braucht eine Regel. Aktiver Speicher, Sicherungen und Archive, für Berichte erstellte Exporte, Protokolleinträge, die Feldwerte enthalten, aus dem Datensatz gebaute Suchindizes, zwischengespeicherte Kopien einer Anbindung und jede Kopie, die eine Person auf ein lokales Gerät geladen hat. Die Zeile zu löschen und dort aufzuhören ist eine häufige und ernste Untererfassung.
Drei Unterscheidungen machen den Entwurf handhabbar. Trennen Sie Löschung von Anonymisierung und seien Sie ehrlich, welche von beiden geschieht – die Verbindung zu einer Person zu entfernen ist nicht dasselbe wie den Datensatz zu entfernen, und ein anonymisierter Datensatz, der wieder verknüpft werden kann, ist nicht anonymisiert. Trennen Sie Ablauf von angeforderter Löschung, da die eine nach Zeitplan läuft und die andere zu einem beliebigen Zeitpunkt eintrifft und sich durch dieselben Orte fortpflanzen muss. Und trennen Sie den Datensatz vom Nachweis, dass die Löschung geschah, der die Löschung normalerweise selbst überleben muss.
Sicherungen sind der Teil, der sich all dem widersetzt, weil der gewöhnliche Mechanismus zur Wiederherstellung des letzten Zustands derselbe ist, der den gelöschten Datensatz bewahrt. Die übliche abgestimmte Position ist, dass Sicherungen von der sofortigen Löschung ausgenommen sind, aber von einer Frist erfasst werden müssen, die sie irgendwann erreicht, und dass eine wiederhergestellte Sicherung die seit ihrer Erstellung vorgenommenen Löschungen erneut anwendet. Welche Position auch eingenommen wird, sie sollte eine aufgeschriebene Entscheidung sein und keine Auslassung, die niemand bemerkt hat.
Für Entwickler: Aufbewahrung als Konfiguration und Löschlauf
Behandeln Sie die Frist als Daten. Geben Sie jeder Kategorie von Datensatz ihre eigene konfigurierte Frist, geliefert vom Betreiber, und lassen Sie das System durchsetzen, was ihm gesagt wird, statt eine eigene Meinung mitzuführen.
Fünf Gewohnheiten machen den Unterschied. Kennzeichnen Sie jeden Datensatz mit der Kategorie, die seine Uhr bestimmt, damit ein Löschlauf Datensätze nach Regel finden kann und nicht über eine von Hand gepflegte Liste. Hängen Sie die Uhr an die Kategorie statt an die Tabelle, weil dieselbe Tabelle Datensätze mehrerer Arten hält. Protokollieren Sie den Löschlauf selbst – wann er lief, was er traf und was er löschte – und bewahren Sie dieses Protokoll dort auf, wo der Löschlauf es nicht entfernen kann. Machen Sie die Felder, die Sie erheben, zu denen, die Ihr dokumentierter Zweck braucht, damit Datenminimierung eine Eigenschaft des Schemas ist und kein Versprechen. Und geben Sie jeder Umgebung, die Personaldaten hält, einschließlich Test- und Vorführumgebungen, dasselbe Regime, denn eine Kopie in einer Testumgebung ist eine Kopie.
Der letzte Punkt ist der, bei dem zuerst zu handeln ist. Personaldaten sollten überhaupt nicht verwendet werden, um Testumgebungen zu befüllen. Beispieldatensätze sollten für den Zweck konstruiert werden, und wo eine Kopie echter Daten für eine bestimmte Untersuchung unvermeidbar ist, sollte sie behandelt werden, als wäre sie der Produktivbetrieb. Alles auf dieser Seite ist für Tests und Vorführungen erzeugt, und die Personaldatensätze, die sie hervorbringt, sollen echte in genau diesen Umgebungen ersetzen und sie niemals ergänzen.
Nächste Schritte
Finden Sie heraus, ob Ihre Systeme eine Frage beantworten können: Welche Bewerberdatensätze von vor zwei Jahren haben keinen Zweck mehr, und was hält sie noch. Die Antwort ist meist eine Liste von Orten, an die niemand gedacht hat, und sie ist ein besserer Ausgangspunkt als ein Richtliniendokument. Wie ein synthetischer Karrieredatensatz überhaupt zusammengesetzt wird, ist in den Karriereprofil-Testdaten behandelt, und eines der sensibelsten Felder eines solchen Datensatzes ist gesondert unter Gehalt, Währung und Zeitraum behandelt. Das Karriereprofil-Werkzeug erzeugt Datensätze für Test- und Vorführzwecke und nicht für den Produktivbetrieb.