Data Governance: Daten als Unternehmensasset systematisch verwalten

Daten sind das wertvollste Asset moderner Unternehmen - und gleichzeitig die größte Haftungsquelle. Ohne strukturierte Data Governance verletzt man unwissentlich DSGVO-Anforderungen, verliert den Überblick über sensitives Material und kann bei einem Sicherheitsvorfall nicht nachweisen, wer Zugang zu welchen Daten hatte.

Was ist Data Governance?

Data Governance Framework - Überblick:

Data Governance:
  → Wer darf was mit welchen Daten tun?
  → Welche Daten existieren wo?
  → Wie lange werden Daten aufbewahrt?
  → Wer ist verantwortlich?

Data Governance ≠ Datenverwaltung (Data Management)
  Data Management:  technische Speicherung, Backup, Performance
  Data Governance:  Richtlinien, Rollen, Compliance, Qualität

---

Warum Data Governance jetzt?

Regulatorischer Druck:
  → DSGVO Art. 5: Zweckbindung, Datenminimierung, Speicherbegrenzung
  → DSGVO Art. 30: Verzeichnis der Verarbeitungstätigkeiten (VVT)
  → ISO 27001 A.5.12/5.13: Informationsklassifizierung
  → NIS2 Art. 21: Richtlinien für Zugang zu Netz und Informationssystemen
  → DORA (Finanzsektor): Data Asset Inventory

Datenpannen ohne Governance:
  → Mitarbeiter weiß nicht: "Darf ich das nach SharePoint hochladen?"
  → Audit: "Zeigen Sie alle Datenübermittlungen nach USA" → unmöglich
  → Ransomware: "Welche Daten wurden verschlüsselt?" → unklar

Typische Aussagen ohne Data Governance:
  "Wir wissen nicht genau, was wir alles haben"
  "Irgendein Entwickler hat eine Kopie gemacht"
  "Das ist von der Altabteilung, die gibt es nicht mehr"

Rollen im Data Governance Framework

Data Governance Rollen:

1. Chief Data Officer (CDO) / Data Governance Officer:
   → Gesamtverantwortung für Data Governance Programm
   → Sponsor auf C-Level (alternativ: CIO oder CISO)
   → Strategie, Budget, Eskalationsinstanz
   → In KMU: oft CISO oder IT-Leiter übernimmt diese Rolle

2. Data Owner (Dateneigentümer):
   → Fachbereichsleiter, verantwortlich für Datenbestand seines Bereichs
   → Entscheidet: Klassifizierungsstufe, Zugriffsberechtigung, Aufbewahrung
   → Verantwortlichkeiten:
     - Gibt Zugriffsrechte frei (nicht IT-Abteilung!)
     - Bestätigt Korrektheit und Aktualität der Daten
     - Entscheidet über Löschung
   → Beispiel: Vertriebsleiter = Data Owner für Kundendaten

3. Data Steward (Datenpfleger):
   → Fachlicher Experte, kümmert sich täglich um Datenpflege
   → Unter dem Data Owner angesiedelt
   → Verantwortlichkeiten:
     - Sicherstellt Datenqualität (Vollständigkeit, Korrektheit, Aktualität)
     - Pflegt Metadaten im Datenkatalog
     - Meldet Qualitätsprobleme an Data Owner
   → Beispiel: CRM-Spezialist im Vertriebsteam

4. Data Custodian (Datenwächter/IT):
   → IT-Abteilung, technische Verwaltung der Daten
   → Verantwortlichkeiten:
     - Backup, Verschlüsselung, Zugriffssteuerung (technisch)
     - Implementiert was Data Owner entschieden hat
     - Kein Entscheidungsrecht über Inhalte
   → Beispiel: DBA, der Berechtigungen in der Datenbank setzt

5. Data Consumer (Datennutzer):
   → Mitarbeiter die Daten nutzen
   → Pflichten: nur zugelassene Nutzung, Qualitätsprobleme melden

6. Data Privacy Officer (Datenschutzbeauftragter):
   → DSGVO-Konformität, Verzeichnis der Verarbeitungstätigkeiten
   → Berät bei Klassifizierung personenbezogener Daten
   → Ansprechpartner für Betroffenenrechte

---

Verantwortungsmatrix (RACI):
  Aktivität                | Owner | Steward | Custodian | DPO
  Klassifizierung festlegen|  R/A  |    C    |     -     |  C
  Zugriff freigeben        |  A    |    C    |     R     |  -
  Datenqualität sichern    |  A    |    R    |     C     |  -
  Technische Verschlüss.   |  -    |    -    |    R/A    |  -
  DSGVO-Prüfung            |  C    |    C    |     C     | R/A
  Löschentscheidung        |  R/A  |    C    |     R     |  C

Datenklassifizierung im Framework

Klassifizierungsschema (4 Stufen):

Stufe 1: ÖFFENTLICH
  → Für jedermann zugänglich, kein Schaden bei Offenlegung
  → Beispiele: Marketingmaterial, Pressemitteilungen, öffentl. Preislisten
  → Handhabung: Keine Einschränkungen
  → Kennzeichnung: Nicht notwendig

Stufe 2: INTERN
  → Für Mitarbeiter, kein öffentlicher Schaden bei Offenlegung
  → Beispiele: interne Richtlinien, Organigramme, interne Berichte
  → Handhabung: Nicht öffentlich teilen, Grundverschlüsselung bei Transit
  → Kennzeichnung: "Intern" in Dokumenten-Header/Footer

Stufe 3: VERTRAULICH
  → Ernsthafter Schaden bei unberechtigter Offenlegung
  → Beispiele: Kundendaten, Geschäftszahlen, Personalakten, Verträge
  → Handhabung:
    - Verschlüsselung at rest + in transit
    - Need-to-Know-Prinzip
    - Keine Weiterleitung ohne explizite Erlaubnis
    - Sicheres Löschen
  → Kennzeichnung: "Vertraulich" in jedem Dokument sichtbar

Stufe 4: STRENG VERTRAULICH
  → Katastrophaler Schaden (M&A-Daten, Kryptoschlüssel, Whistleblower)
  → Beispiele: Vorstandsentscheidungen, Akquisitionspläne, Sicherheitslücken
  → Handhabung:
    - HSM oder separater verschlüsselter Storage
    - Individuell protokollierter Zugriff
    - Nur auf Need-to-Know Einzelpersonenbasis
    - Physische Sicherheit wenn gedruckt
  → Kennzeichnung: "Streng Vertraulich / Nur für Empfänger"

---

Microsoft Purview Klassifizierung (Automatisierung):

Sensitivity Labels konfigurieren (PowerShell):
  Install-Module -Name ExchangeOnlineManagement
  Connect-IPPSSession

  New-Label -Name "Vertraulich" `
    -DisplayName "Vertraulich" `
    -EncryptionEnabled $true `
    -EncryptionEncryptOnly $false `
    -EncryptionRightsDefinitions "view@firma.de:VIEW;edit@firma.de:EDIT" `
    -ContentMarkingUpHeaderEnabled $true `
    -ContentMarkingUpHeaderText "VERTRAULICH - NUR FÜR INTERNEN GEBRAUCH"

  Auto-Labeling Policy:
  New-AutoSensitivityLabelPolicy `
    -Name "Auto-Klassifizierung-PII" `
    -ExchangeLocation All `
    -SharePointLocation All `
    -Labels "Vertraulich"

  Auto-Labeling Regeln (Sensitive Info Types):
  New-AutoSensitivityLabelRule `
    -Policy "Auto-Klassifizierung-PII" `
    -Name "IBAN-Erkennung" `
    -SensitiveInfoTypes "IBAN"

  Ergebnis: E-Mails mit IBANs werden automatisch als "Vertraulich" klassifiziert!

Datenkatalog und Datenlineage

Datenkatalog - das "Telefonbuch" aller Datenbestände:

Was gehört in einen Datenkatalog?
  Für jedes Daten-Asset:
  □ Name und eindeutige ID
  □ Beschreibung (was enthält dieser Datensatz?)
  □ Data Owner (Fachbereich + Person)
  □ Klassifizierungsstufe
  □ Speicherort (System, Pfad/Tabelle)
  □ Datenformat (SQL, CSV, JSON, PDF, etc.)
  □ Erstellungsdatum + Letzte Änderung
  □ Aufbewahrungsfrist + Löschdatum
  □ Personenbezogen? (DSGVO-relevant?)
  □ Empfänger/Systeme die Zugriff haben
  □ Datenqualitäts-Score

Open-Source Datenkatalog-Tools:
  Apache Atlas:      Enterprise-Grade, Hadoop-Integration
  OpenMetadata:      Modern, REST API, umfangreiche Konnektoren
  DataHub (LinkedIn): Open Source, LinkedIn-bewährt, aktive Community
  Amundsen (Lyft):   Gut für Analytics-Teams

  OpenMetadata Connector für PostgreSQL:
  # openmetadata-connector.yaml
  source:
    type: postgres
    serviceName: production-db
    serviceConnection:
      config:
        hostPort: postgresql.firma.de:5432
        username: openmetadata_user
        password: <vault-secret>
        database: production
    sourceConfig:
      config:
        markDeletedTables: true
        includeTables: true
        includeViews: true

---

Data Lineage (Datenherkunft):

Warum wichtig?
  "Wo kommen diese Daten her?" → Compliance-Nachweis
  "Welche Systeme nutzen diese Tabelle?" → Impact Analysis bei Änderungen
  "Wer hat die Daten transformiert?" → Audit Trail

Lineage-Darstellung:
  Quellsystem  →  ETL-Prozess  →  Data Warehouse  →  Report
  CRM (Salesforce) → Fivetran → Snowflake.customers → Tableau Dashboard

  Automatische Lineage via:
  → OpenLineage API-Standard (Marquez als Server)
  → dbt: generiert Lineage automatisch bei Transformationen
  → Apache Airflow: Lineage-Plugin für DAG-basierte Pipelines

  dbt Lineage (Beispiel):
  -- models/customers_enriched.sql
  -- Lineage: raw.salesforce_contacts → int.customers → customers_enriched
  SELECT
    c.id,
    c.email,
    o.order_count
  FROM {{ ref('int_customers') }} c
  LEFT JOIN {{ ref('int_orders') }} o ON c.id = o.customer_id

Datenqualität und Retention

Datenqualitätsdimensionen (DAMA):

  1. Vollständigkeit: Pflichtfelder gefüllt?
     SQL Check: SELECT COUNT(*) FROM customers WHERE email IS NULL;

  2. Genauigkeit: Entsprechen Daten der Realität?
     Validierung: E-Mail-Format, PLZ-Muster, Telefonnummer-Format

  3. Konsistenz: Widersprüche zwischen Systemen?
     CRM: Kunde "Mustermann, Max" | ERP: Kunde "Max Mustermann GmbH"
     → Golden Record Prozess nötig

  4. Aktualität: Sind Daten aktuell?
     Veraltete Lieferantenadressen, gelöschte Mitarbeiter noch in Systemen

  5. Einzigartigkeit: Dubletten?
     SELECT email, COUNT(*) FROM customers GROUP BY email HAVING COUNT(*) > 1

  6. Konformität: Entsprechen Daten definierten Standards?
     ISO-Ländercodes, IBAN-Format, interne Nomenklaturen

---

Data Retention (Aufbewahrungsfristen):

Rechtliche Fristen (Deutschland):
  Handelsrelevante Unterlagen (HGB §257):    10 Jahre
  Buchungsbelege, Jahresabschlüsse:          10 Jahre
  Geschäftsbriefe (Ein- und Ausgang):         6 Jahre
  Lohnunterlagen:                             6 Jahre
  Bewerbungsunterlagen (abgelehnt):           6 Monate (DSGVO)
  Personalakten (nach Austritt):              3 Jahre (Verjährung)
  Kreditkartendaten (PCI DSS):               nicht länger als nötig
  CCTV-Aufnahmen:                            72 Stunden (BSI-Empfehlung)
  IP-Adressen (Sicherheitslogs):             7 Tage (EuGH-Linie)
  Audit Logs für ISMS:                       1-3 Jahre

Retention Policy in SharePoint (PowerShell):
  New-RetentionCompliancePolicy `
    -Name "Finanzdaten 10 Jahre" `
    -SharePointLocation "https://firma.sharepoint.com/sites/finanzen" `
    -RetentionDuration 3650 `
    -RetentionAction KeepAndDelete

  After 3650 days: Dokument geht in "Preservation Hold Library" → nach Review: Delete

DSGVO-Integration

Data Governance + DSGVO (Praktisch):

Verzeichnis der Verarbeitungstätigkeiten (Art. 30):

Datenkatalog-Eintrag wird zum VVT-Eintrag:
  □ Name der Verarbeitung: "Kundenrechnungen"
  □ Zweck: Buchführung, Steuerrecht
  □ Kategorien betroffener Personen: Privatkunden
  □ Kategorien personenbezogener Daten: Name, Adresse, Bankdaten
  □ Empfänger: Steuerberater, Finanzamt
  □ Drittlandübermittlung: nein (oder: ja, AWS EU-West-1 Frankfurt)
  □ Löschfrist: 10 Jahre (HGB)
  □ Technische Maßnahmen: AES-256 Verschlüsselung, Zugriff via IAM

Betroffenenrechte (Art. 15-22) - Data Governance macht es möglich:
  Auskunft (Art. 15): Ohne Datenkatalog: Stunden suchen. Mit Katalog: Minuten
  Löschung (Art. 17): Wo liegen die Daten? Katalog gibt Antwort
  Datenportabilität (Art. 20): Strukturierter Export dank Datenmodell-Dokumentation

Tools für DSGVO-Data-Governance-Integration:
  OneTrust:         Marktführer, deckt VVT + DSGVO + Cookies ab
  DataGrail:        Spezialisiert auf Betroffenenrechte-Automatisierung
  Privacera:        Open-Source-basiert (Apache Ranger), Cloud-nativ
  Collibra:         Enterprise Data Catalog + Privacy Modul

---

Praktische Umsetzungs-Roadmap:

Phase 1 (Monate 1-2): Bestandsaufnahme
  □ High-Level Inventar aller Datenspeicher (20-80er-Regel: 80% im Hauptsystem)
  □ Kritische Datenbestände identifizieren (Kundendaten, Finanzdata)
  □ Data Owner pro Fachbereich benennen
  □ Klassifizierungsschema definieren und kommunizieren

Phase 2 (Monate 3-4): Fundament
  □ Datenkatalog-Tool einführen (OpenMetadata, DataHub, oder Microsoft Purview)
  □ Kritische Datenbestände klassifizieren
  □ Retention Policies in den Hauptsystemen konfigurieren
  □ DSGVO-VVT aus Datenkatalog ableiten

Phase 3 (Monate 5-6): Automatisierung
  □ Auto-Klassifizierung via Microsoft Purview / DLP-Regeln
  □ Data Lineage für kritische Geschäftsprozesse
  □ Datenqualitäts-Monitoring (Alerts bei Qualitätsproblemen)
  □ Self-Service-Zugriffsprozess (Data Owner muss Zugriff freigeben)

Phase 4: Kontinuierlich
  □ Quartalsweise: Klassifizierungen überprüfen
  □ Jährlich: Data Governance Policy aktualisieren
  □ Bei Systemänderungen: Datenkatalog aktualisieren