Zum Inhalt springen

Services, Wiki-Artikel, Blog-Beiträge und Glossar-Einträge durchsuchen

↑↓NavigierenEnterÖffnenESCSchließen

Data Governance: Daten als Unternehmensasset systematisch verwalten

Data Governance ist der organisatorische und technische Rahmen für den sicheren, regelkonformen und wertschöpfenden Umgang mit Unternehmensdaten. Dieser Artikel erklärt das Data Governance Framework, Rollen (Data Owner, Steward, Custodian), Datenklassifizierung, Datenkatalog, Datenqualität, Lineage und Compliance-Integration (DSGVO, ISO 27001).

Inhaltsverzeichnis (6 Abschnitte)

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 ist der Rahmen, der definiert: Wer darf was mit welchen Daten tun? Welche Daten existieren wo? Wie lange werden Daten aufbewahrt? Wer ist verantwortlich?

Data Governance ist nicht gleichzusetzen mit Datenverwaltung (Data Management). Data Management befasst sich mit technischer Speicherung, Backup und Performance. Data Governance hingegen umfasst Richtlinien, Rollen, Compliance und Datenqualität.

Der regulatorische Druck macht Data Governance heute unverzichtbar. DSGVO Art. 5 fordert Zweckbindung, Datenminimierung und Speicherbegrenzung. Art. 30 verlangt ein Verzeichnis der Verarbeitungstätigkeiten (VVT). ISO 27001 A.5.12/5.13 regelt Informationsklassifizierung. NIS2 Art. 21 schreibt Richtlinien für den Zugang zu Informationssystemen vor. Im Finanzsektor fordert DORA ein Data Asset Inventory.

Ohne Data Governance entstehen typische Probleme: Mitarbeitende wissen nicht, ob Dateien auf SharePoint hochgeladen werden dürfen. Audits können keine vollständige Übersicht über Datenübermittlungen in Drittländer liefern. Nach einem Ransomware-Angriff ist unklar, welche Daten verschlüsselt wurden.

Rollen im Data Governance Framework

Chief Data Officer (CDO) / Data Governance Officer trägt die Gesamtverantwortung für das Data Governance Programm und fungiert als C-Level-Sponsor (alternativ: CIO oder CISO). In KMU übernimmt oft der CISO oder IT-Leiter diese Rolle.

Data Owner (Dateneigentümer) ist typischerweise ein Fachbereichsleiter, verantwortlich für den Datenbestand seines Bereichs. Er entscheidet über Klassifizierungsstufe, Zugriffsberechtigungen und Aufbewahrungsdauer, gibt Zugriffsrechte frei (nicht die IT-Abteilung), bestätigt Korrektheit und Aktualität der Daten und entscheidet über Löschung. Beispiel: Der Vertriebsleiter ist Data Owner für Kundendaten.

Data Steward (Datenpfleger) ist ein fachlicher Experte, der täglich für die Datenpflege zuständig ist und unter dem Data Owner angesiedelt ist. Er stellt Datenqualität sicher (Vollständigkeit, Korrektheit, Aktualität), pflegt Metadaten im Datenkatalog und meldet Qualitätsprobleme an den Data Owner. Beispiel: Ein CRM-Spezialist im Vertriebsteam.

Data Custodian (Datenwächter/IT) ist die IT-Abteilung, die technische Verwaltung der Daten übernimmt. Sie setzt Backup, Verschlüsselung und Zugriffssteuerung technisch um, implementiert was der Data Owner entschieden hat, und hat kein Entscheidungsrecht über Inhalte. Beispiel: Ein DBA, der Berechtigungen in der Datenbank setzt.

Data Consumer (Datennutzer) sind Mitarbeitende, die Daten nutzen. Ihre Pflichten umfassen nur zugelassene Nutzung und das Melden von Qualitätsproblemen.

Data Privacy Officer (Datenschutzbeauftragter) stellt die DSGVO-Konformität sicher, führt das Verzeichnis der Verarbeitungstätigkeiten, berät bei der Klassifizierung personenbezogener Daten und ist Ansprechpartner für Betroffenenrechte.

Die Verantwortlichkeiten lassen sich in einer RACI-Matrix abbilden:

AktivitätOwnerStewardCustodianDPO
Klassifizierung festlegenR/AC-C
Zugriff freigebenACR-
Datenqualität sichernARC-
Technische Verschlüsselung--R/A-
DSGVO-PrüfungCCCR/A
LöschentscheidungR/ACRC

Datenklassifizierung im Framework

Ein bewährtes Klassifizierungsschema mit vier Stufen:

Stufe 1: ÖFFENTLICH - Für jedermann zugänglich, kein Schaden bei Offenlegung. Beispiele: Marketingmaterial, Pressemitteilungen, öffentliche Preislisten. Keine Einschränkungen, keine Kennzeichnung nötig.

Stufe 2: INTERN - Für Mitarbeitende, kein öffentlicher Schaden bei Offenlegung. Beispiele: interne Richtlinien, Organigramme, interne Berichte. 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. Verschlüsselung at rest und 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öglich (M&A-Daten, Kryptoschlüssel, Whistleblower). Beispiele: Vorstandsentscheidungen, Akquisitionspläne, Sicherheitslücken. 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".

Für die Automatisierung der Klassifizierung bietet sich Microsoft Purview mit Sensitivity Labels an:

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"

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

New-AutoSensitivityLabelRule `
  -Policy "Auto-Klassifizierung-PII" `
  -Name "IBAN-Erkennung" `
  -SensitiveInfoTypes "IBAN"

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

Datenkatalog und Datenlineage

Ein Datenkatalog ist das "Telefonbuch" aller Datenbestände. Für jedes Daten-Asset sollte er folgende Informationen enthalten: Name und eindeutige ID, Beschreibung, Data Owner (Fachbereich und Person), Klassifizierungsstufe, Speicherort (System, Pfad/Tabelle), Datenformat, Erstellungsdatum und letzte Änderung, Aufbewahrungsfrist und Löschdatum, DSGVO-Relevanz, Empfänger und zugreifende Systeme sowie einen Datenqualitäts-Score.

Open-Source-Datenkatalog-Tools umfassen Apache Atlas (Enterprise-Grade mit Hadoop-Integration), OpenMetadata (modern, REST API, umfangreiche Konnektoren), DataHub von LinkedIn (bewährt, aktive Community) und Amundsen von Lyft (gut für Analytics-Teams). Die Konnektorkonfiguration für OpenMetadata erfolgt über YAML:

# 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) beantwortet Compliance-Fragen ("Wo kommen diese Daten her?"), ermöglicht Impact-Analysen bei Änderungen ("Welche Systeme nutzen diese Tabelle?") und liefert den Audit Trail ("Wer hat die Daten transformiert?"). Eine typische Lineage sieht aus wie: CRM (Salesforce) → Fivetran → Snowflake.customers → Tableau Dashboard. Tools wie dbt generieren Lineage automatisch bei Transformationen, Apache Airflow bietet ein Lineage-Plugin für DAG-basierte Pipelines, und OpenLineage/Marquez implementiert den API-Standard.

Datenqualität und Retention

Die sechs DAMA-Datenqualitätsdimensionen sind: Vollständigkeit (Pflichtfelder gefüllt?), Genauigkeit (entsprechen Daten der Realität?), Konsistenz (Widersprüche zwischen Systemen? - erfordert Golden-Record-Prozesse), Aktualität (sind Daten aktuell?), Einzigartigkeit (Dubletten?) und Konformität (entsprechen Daten definierten Standards wie ISO-Ländercodes oder IBAN-Format?).

Für Deutschland gelten folgende Aufbewahrungsfristen: Handelsrelevante Unterlagen nach HGB §257 und Buchungsbelege 10 Jahre, Geschäftsbriefe und Lohnunterlagen 6 Jahre, Bewerbungsunterlagen (abgelehnt) 6 Monate nach DSGVO, Personalakten nach Austritt 3 Jahre (Verjährung), Kreditkartendaten nach PCI DSS nur so lange wie nötig, CCTV-Aufnahmen 72 Stunden nach BSI-Empfehlung, IP-Adressen in Sicherheitslogs 7 Tage nach EuGH-Linie sowie Audit Logs für ISMS 1-3 Jahre.

Retention Policies lassen sich in SharePoint über PowerShell konfigurieren:

New-RetentionCompliancePolicy `
  -Name "Finanzdaten 10 Jahre" `
  -SharePointLocation "https://firma.sharepoint.com/sites/finanzen" `
  -RetentionDuration 3650 `
  -RetentionAction KeepAndDelete

Nach 3650 Tagen geht das Dokument in die "Preservation Hold Library" und wird nach Review gelöscht.

DSGVO-Integration

Der Datenkatalog-Eintrag wird direkt zum VVT-Eintrag nach Art. 30 DSGVO. Für jede Verarbeitung (z. B. "Kundenrechnungen") werden Name, Zweck (Buchführung, Steuerrecht), Kategorien betroffener Personen, Kategorien personenbezogener Daten, Empfänger, Drittlandübermittlungen, Löschfrist und technische Maßnahmen dokumentiert.

Betroffenenrechte nach Art. 15-22 werden durch Data Governance erheblich vereinfacht: Auskunftsanfragen (Art. 15) können mit Datenkatalog in Minuten statt Stunden beantwortet werden, Löschanfragen (Art. 17) lassen sich gezielt umsetzen weil der Speicherort bekannt ist, und Datenportabilität (Art. 20) wird durch dokumentierte Datenmodelle ermöglicht.

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

Praktische Umsetzungs-Roadmap:

Phase 1 (Monate 1-2) - Bestandsaufnahme: High-Level-Inventar aller Datenspeicher, kritische Datenbestände identifizieren, Data Owner pro Fachbereich benennen und Klassifizierungsschema definieren.

Phase 2 (Monate 3-4) - Fundament: Datenkatalog-Tool einführen, kritische Datenbestände klassifizieren, Retention Policies konfigurieren und DSGVO-VVT aus Datenkatalog ableiten.

Phase 3 (Monate 5-6) - Automatisierung: Auto-Klassifizierung via Microsoft Purview oder DLP-Regeln, Data Lineage für kritische Geschäftsprozesse, Datenqualitäts-Monitoring und Self-Service-Zugriffsprozess einrichten.

Phase 4 - Kontinuierlich: Quartalsweise Klassifizierungen überprüfen, jährliche Aktualisierung der Data Governance Policy und Datenkatalog bei Systemänderungen aktualisieren.

Fragen zu diesem Thema?

Unsere Experten beraten Sie kostenlos und unverbindlich.

Erstberatung

Über den Autor

Oskar Braun
Oskar Braun

Abteilungsleiter Information Security Consulting

E-Mail

Dipl.-Math. (WWU Münster) und Promovend am Promotionskolleg NRW (Hochschule Rhein-Waal) mit Forschungsschwerpunkt Phishing-Awareness, Behavioral Security und Nudging in der IT-Sicherheit. Verantwortet den Aufbau und die Pflege von ISMS, leitet interne Audits nach ISO/IEC 27001:2022 und berät als externer ISB in KRITIS-Branchen. Lehrbeauftragter für Communication Security an der Hochschule Rhein-Waal und NIS2-Schulungsleiter bei der isits AG.

ISO 27001 Lead Auditor (IRCA) ISB (TÜV)
Dieser Artikel wurde zuletzt am 04.03.2026 bearbeitet. Verantwortlich: Oskar Braun, Abteilungsleiter Information Security Consulting bei AWARE7 GmbH. Lizenz: CC BY 4.0 - freie Nutzung mit Namensnennung: „AWARE7 GmbH, https://a7.de