Experten beraten, Owner entscheiden
Fach-Experten, Privacy, Legal und BI bilden ein Betriebsnetz — kein Komitee-Thron. Der DSB ist Experte der Richtlinie, nicht automatisch der Löschung oder Anonymisierung.
Begriffe vor dem Lesen
- Datenschutz-Folgenabschätzung / DSFA — Datenschutz-Folgenabschätzung: Prüfung für Verarbeitungen, die ein hohes Risiko für betroffene Personen haben können.
- BDSG — Bundesdatenschutzgesetz: deutsches Datenschutzgesetz ergänzend zur DSGVO, besonders wichtig bei Beschäftigtendaten.
Governance ist breit. Deshalb braucht jeder Bereich Experten, die Teamplayer sind. Gemeinsam bilden sie ein Betriebsnetz: übersetzen, vorbereiten, eskalieren. Sie bilden kein gemeinsames A. Der interne Datenschutzbeauftragte ist oft der beste erste Kontakt zur DSGVO — Experte der Richtlinie, nicht automatisch Experte des Löschjobs oder der Anonymisierung.
Die Formel aus Teil 1 gilt hier konkret: Vertrauen und Transparenz, ohne Rechte eines Einzelnen zu verletzen. „Einzelner“ ist die betroffene Person — und die mandatierte Rolle, deren Stuhl niemand einnimmt.
Herausforderung
Der gut gemeinte Satz „wir sind ein übergreifendes Fachbereichs-Team“ klingt nach Zusammenarbeit. Operativ wird er zum Thron: wer im Team sitzt, will mitentscheiden. Dasselbe gilt, wenn der DSB jedes Vorhaben mitzeichnen oder selbst löschen soll. Unabhängigkeit (Art. 38/39 DSGVO) und Haftung des Verantwortlichen geraten durcheinander. Landscape-Playbooks sagen es hart: der DSB berät, entscheidet nicht — z. B. Governance in Healthcare.
Vier oft vermischte Hüte:
| Rolle | Beitrag | Nicht |
|---|---|---|
| DSB | Beratung zu Richtlinie, Rechtsgrund, DPIA, ob Anonymisierung die Schwelle erfüllt | A für fachliche Bedeutung, Löschjobs, Warehouse-Pfade |
| Privacy Control Owner | Kontrolldesign, Evidenz, Ausnahmen | Semantik von Umsatz oder Pipeline |
| Business/Data Owner | Zweck, Nutzung, fachliche Freigabe | IAM-Betrieb oder Rechtsauslegung allein |
| Custodian / Architect | Wirksame Löschung, Backups, Ableitungen, Anonymisierungsverfahren mit Nachweis | Die Richtlinie neu schreiben |
Legal ist nicht der DSB. Der Betriebsrat ist nicht der DSB. Drei Experten, drei Mandate — ein A je Konfliktzeile. Beschäftigtendaten: BDSG und Betriebsrat. Kontrollhüte: Custodian vs. Control Owner.
Ansatz
- Netz, nicht Komitee. Finance-Steward, Sales-Steward, HR-Steward, Privacy, BI-Custodian, DSB — gemeinsame Artefakte und Eskalation, kein gemeinsames A.
- DSB immer C bei Personenbezug. Pflichtperspektive, kein Vetorecht ohne Gate-Schnitt.
- Gates sind Türen, keine Throne. Maskierung, Löschung, Hold dürfen blocken; sie schreiben Sales-KPIs nicht um.
- Consulted mit Timeout. Schweigen braucht eine vorab festgelegte Bedeutung.
- Nachbar-Owner bleibt C, keine zweite Accountable-Rolle. Finance hört Sales-KPIs, wenn das Pack betroffen ist — überschreibt Pipeline nicht.
- Richtlinie ≠ Löschpfad. DSB berät, ob das Verfahren die Richtlinie erfüllt; Custodian setzt Jobs, Backups und Ableitungen um.
PII-Betrieb bleibt in PII & Privacy Governance. Wirksame Betroffenenrechte: DSDR, Betroffenenrechte als Betriebsvertrag.
Sizing
| Größe | Netz ohne Thron |
|---|---|
| SMB | DSB und IT-Lead als markierte Hüte; ein Löschpfad mit Evidence |
| Mid | Control Owner getrennt vom DSB; Custodian für Mart und Backup |
| Enterprise | Formale SoD; Assurance stichprobenartig unabhängig |
Anwendungsbeispiel: Löschantrag trifft den Finance-Mart
Lehrfall, keine Kundendaten. Ein Betroffenenantrag verlangt Löschung. Der Datensatz sitzt im Finance-Mart, in Warehouse-Snapshots und in einem BI-Extract. Der DSB bestätigt Rechtsgrund, Frist und dass Anonymisierung nur zählt, wenn Re-Identifikation ausgeschlossen ist. Er kennt den Warehouse-Job, die Backup-Kopien und die BI-Extracts nicht.
Schnitt der Zeilen:
- Richtlinie / Rechtsfolge: DSB C (Beratung). Privacy kontrollverantwortliche Person A für Kontrolldesign. Business Owner A für den Verarbeitungszweck.
- Löschung wirksam machen: technischer Betreiber A für technische Ausführung (Jobs, Backups, Ableitungen). Steward triagiert den Identifier-Kreis.
- Anonymisierung vs. Pseudonymisierung: Architect/technischer Betreiber R für Verfahren und Nachweis. DSB C, ob das Verfahren die Richtlinie erfüllt — er erfindet das Verfahren nicht.
Kein „Der DSB löscht“. Kein „Legal anonymisiert in Excel“. Transparenz ohne wirksame Löschung verletzt Rechte der betroffenen Person — Tiefe in der DSDR-Säule, nicht hier.
Mini-Fall: Kunden-PII im Finance-Report
Finance will Kundenname im Close-Kommentar. Der DSB rät zu Minimierung. BI kann unmaskiert liefern. Sales will denselben Extract für Forecast.
Schnitt: Zweck und Minimierung — Finance Owner A, DSB C, Privacy Control Owner Gate. Sales-Extract — eigene Entscheidung, eigenes A. BI — R für Maskierung und Deploy, nicht A für „darf der Name bleiben“.
Kein gemeinsames Team-Votum. Ein Decision Record plus Beratung des DSB.
Betriebsablauf (nummeriert)
- Personenbezug und Zweck benennen; DSB als C anfordern.
- Zeilen schneiden: Semantik, Zweck/Minimierung, Kontrolle, technische Wirksamkeit.
- Genau ein A je Zeile; Timeout für Consulted.
- Lösch- oder Anonymisierungspfad dem Custodian übergeben — Population, Ableitungen, Evidence.
- DSB dokumentiert Beratung; Owner die Nutzungs- oder Zweckentscheidung.
Handoffs
| Von | An | Artefakt | Erfolgskriterium |
|---|---|---|---|
| Steward | DSB / Legal | Zweck, Population, Risiko | Beratung ist dokumentiert |
| DSB | Owner | Beratung, nicht Freigabe | Owner trifft die Nutzungsentscheidung |
| Control Owner | Custodian | freigegebenes Design | Kontrolle ist ausführbar |
| Custodian | Control Owner | Lösch-/Anonymisierungsnachweis | Population und Ableitungen sind vollständig |
| Nachbar-Owner | Owner | Impact als C | Keine zweite Accountable-Rolle auf derselben Zeile |
Anti-Patterns (und warum sie scheitern)
- DSB als Mit-verantwortliche Person. Scheitert, weil Unabhängigkeit und Selbstprüfung kollidieren.
- Der DSB löscht. Scheitert, weil Richtlinie-Expertise kein Betriebsmandat für Pipelines ist.
- Legal anonymisiert in Excel. Scheitert, weil Re-Identifikation und Ableitungen unsichtbar bleiben.
- DSB immer im Raum. Scheitert als Engpass und erzeugt Schattenwege.
- Privacy überschreibt Semantik. Scheitert, weil ein Prüfpunkt kein Definitionsmandat hat.
- Expertennetz als Council-Default. Scheitert, weil Standardfälle auf das Forum warten.
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.
Erster Schritt: Expertenliste je Domain. Eine personenbezogene Entscheidung: DSB C, Owner A, Custodian R. Ein Lösch- oder Anonymisierungspfad mit Population. Timeout für Consulted. Stance Map um Gates ergänzen.
Ausbau: Ein echter Antrag hat Evidence auf Mart, Snapshot und Extract. Der DSB hat beraten, nicht den Job gedrückt.
Checkliste
- DSB ist C bei Personenbezug, nicht A für Bedeutung oder für den Löschjob.
- Privacy- und Security-Gates sind als eigene Zeilen geschnitten.
- Löschung/Anonymisierung hat technischer Betreiber, Grundgesamtheit und Ableitungsliste.
- Expertennetz hat Artefakte und Eskalation, kein gemeinsames A.
- Consulted-Frist und Bedeutung von Schweigen sind festgelegt.
Artefakt
Stance Map (Seite 4 — Consulted-Gates): Wer berät, welches Gate blocken darf, Timeout, was kein Veto ist, wer Löschung/Anonymisierung ausführt.
Tools
Governance as a shared standard
Part 4 of 6
View series