Analytics-Allowlist — Welche HR-Felder in BI gehören
Default-Deny für sensible Attribute: Feld-Allowlist je Analytics-Produkt, Mindestgruppengrößen, Ausnahmepfad und Drift-Review für Workforce-Reporting.
Maskierung im Kern hilft wenig, wenn das Analytics-Modell weiterhin alles anbietet, was technisch verfügbar ist. Ein Self-Service-Datensatz mit „allen Worker-Attributen“ verschiebt die Zweckentscheidung an die Person, die gerade ein Feld in eine Zeile zieht. Das ist keine Governance, das ist Zufall.
Dieser Teil dreht die Logik um: Der Default ist Deny, die Allowlist ist der Vertrag.
Vorher: Zweckbindung und Maskierung. Weiter: DSDR und Workforce-Exporte.
Ansatz
Jedes HR-Analytics-Produkt erhält vor Veröffentlichung:
- eine Feld-Allowlist (Feld, Sensitivitätsklasse, Zweck, Zielrolle);
- eine Default-Deny-Regel für alles außerhalb der Allowlist, insbesondere sensible Attribute;
- eine Mindestgruppengröße mit Suppression-Verhalten für kleine Populationen;
- einen Export-Contract (zulässige Formate, Empfängerkreis, Gültigkeitsdauer);
- eine Owner-Freigabe je Allowlist-Version.
Kein Self-Service-Datensatz und kein geteiltes Workforce-Dashboard ohne diese fünf.
Allowlist-Workflow
1. Allowlist je Produkt bauen
Die Allowlist entsteht aus den freigegebenen Zwecken, nicht aus dem Quellschema. Jedes Feld trägt seinen Zweck. Felder ohne Eintrag existieren im Analytics-Layer nicht.
2. Default-BI-Layer schneiden
Sensible Attribute wie Vergütungsdetails, Abwesenheitsgründe, Performance-Ratings und Gesundheitsbezug gehören nicht in den allgemeinen Workforce-Datensatz. Sie erhalten eigene, eng freigegebene Produkte mit eigenem Zugriffspfad.
3. Aggregation absichern
Mindestgruppengrößen gelten je Dimension und Kombination. Suppression muss auch bei Drill-down, Filterwechsel und Differenzbildung halten — sonst rekonstruiert der Consumer die kleine Gruppe in zwei Klicks.
4. Ausnahmepfad definieren
Eine Ausnahme braucht Zweck, Zeitraum, Empfänger, Owner-Freigabe und ein Ablaufdatum. Ausnahmen sind befristete Verträge, keine dauerhaften Zusatzspalten.
5. Drift regelmäßig prüfen
Neue Quellfelder, neue Berechnungen und neue Dashboards weichen die Allowlist auf. Der Review vergleicht das ausgelieferte Modell gegen die freigegebene Version und entfernt stille Zuwächse.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| HR Owner | Steward | Freigegebene Zwecke je Analytics-Produkt |
| Steward | Analytics Engineering | Allowlist + Suppression-Regeln |
| Owner | BI Consumer | Freigegebener Datensatz + Nutzungsgrenzen |
| Steward | Privacy | Ausnahmen mit Ablaufdatum |
| Steward | Owner | Drift-Report gegen Allowlist-Version |
Anti-Patterns
- „Alle Worker-Attribute“ als Self-Service-Datensatz veröffentlichen
- Mindestgruppengröße nur in der Standardansicht, nicht im Drill-down
- Ausnahmen ohne Ablaufdatum
- Sensible Felder im Modell verstecken statt weglassen
- Freigabeliste als Dokument pflegen, ohne sie technisch durchzusetzen
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.
- Ein breit genutztes Workforce-Dashboard gegen eine explizite Allowlist prüfen.
- Felder ohne Zweckbezug aus dem Default-Modell entfernen.
- Mindestgruppengröße im Drill-down und in Differenzsichten testen.
- Ausnahmen inventarisieren und mit Ablaufdaten versehen.
Governing HR landscapes
Part 4 of 5
View series