Zweckbindung und Maskierung — Sensible HR-Attribute kontrolliert nutzen
Zweck vor Feld: Klassifikation, Maskierungsstufen, Rollen- und Regionsbindung sowie Nachweise für Vergütung, Gesundheit und Performance-Daten.
Ein sauberer Worker-Contract macht Daten vergleichbar — nicht automatisch zulässig. Vergütung, Performance-Ratings, Abwesenheitsgründe, Behinderungsstatus und Disziplinarvorgänge sind technisch nur weitere Spalten. Rechtlich und kulturell sind sie es nicht. Der Unterschied entsteht nicht in der Pipeline, sondern im dokumentierten Zweck und in der durchgesetzten Maskierung.
Dieser Teil bindet jedes sensible HR-Feld an eine Entscheidung, eine Rolle und eine Sichtbarkeitsstufe.
Vorher: Employee- und Org-Contracts. Weiter: Analytics-Allowlist.
Ansatz
Jedes sensible HR-Attribut erhält vor Nutzung außerhalb des Quellsystems:
- ein Purpose-Statement (konkrete Entscheidung, Nutzergruppe, Population, Aufbewahrung);
- eine Sensitivitätsklasse (Standard, sensibel, besonders geschützt);
- eine Maskierungsregel je Rolle (Klartext, maskiert, nur aggregiert, kein Zugriff);
- eine Rechts- und Mitbestimmungsprüfung (Rechtsgrundlage, lokale Regeln, Arbeitnehmervertretung);
- eine Owner-Freigabe mit Evidence und Review-Datum.
Kein sensibles Feld verlässt das Quellsystem ohne diese fünf.
Zweck-Workflow
1. Zweck benennen
„People Analytics“ ist kein Zweck. Der Owner formuliert die Entscheidung, die getroffen werden soll, und die Felder, die sie tatsächlich erfordert. Felder ohne Entscheidungsbezug fallen aus dem Scope.
2. Felder klassifizieren
Steward klassifiziert je Feld und dokumentiert die Begründung. Der PII Policy Generator erzeugt die Klassifikations- und Maskierungsmatrix als betreibbares Artefakt statt als Foliensatz.
3. Maskierungsstufe wählen
Die Stufe ergibt sich aus Klasse, Rolle und Zweck. Typische Muster: Vergütung nur als Band oder Aggregat, Abwesenheit nur als Status und Dauer ohne Grund, Performance-Rating nur für die entscheidende Rolle im laufenden Prozess.
4. Rollen und Regionen binden
Zugriff hängt nicht an der Hierarchie allein. Führungskraft, HR Business Partner, Compensation und Analytics erhalten unterschiedliche Sichten. Lokale Regeln können strenger sein und müssen im Contract sichtbar bleiben.
5. Nachweisen und Reviewen
Freigabe, Klassifikation, Maskierungsregel und Review-Datum liegen an einem Ort. Ohne Review verfällt die Freigabe — sie verlängert sich nicht stillschweigend.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| HR Owner | Steward | Purpose-Statement + Feldbedarf |
| Steward | Privacy / Legal | Klassifikation + Rechtsgrundlage |
| Owner | Arbeitnehmervertretung | Zweck, Population und Wirkung |
| Steward | Custodian / Engineering | Maskierungsregeln je Rolle und Region |
| Owner | Consumer | Freigegebene Sicht + Nutzungsgrenzen |
Anti-Patterns
- Hashing als Anonymisierung deklarieren
- Sensible Felder „vorsorglich“ laden und später einschränken wollen
- Maskierung nur im BI-Layer, nicht im Auswertungstabelle und nicht im Export
- Pauschalzugriff für Führungskräfte auf die gesamte Reporting Line
- Freitextfelder und Anhänge ohne Einzelprüfung übernehmen
Erster Umsetzungsschnitt
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- Zehn sensible Felder je Quellsystem listen und gegen benannte Entscheidungen prüfen.
- Klassifikations- und Maskierungsmatrix erzeugen und mit Privacy gegenlesen.
- Eine Maskierungsregel technisch durchsetzen und im Export testen.
- Zwei Felder ohne Zweckbezug aus dem Default-Scope entfernen.
Governing HR landscapes
Part 3 of 5
View series