Data Governance Framework: Praktischer Guide für Data-Teams

TL;DR: Data Governance läuft auf drei Fragen pro Datensatz hinaus: Wer besitzt sie? Welche Regeln gelten? Wie setzen wir die durch? Alles andere ist Implementierungsdetail. Starte mit 10 Tabellen, nicht mit 1.000 — und kauf erst Tools, wenn Ownership und Policies stehen.

Du kennst die Szene: Ein Stakeholder fragt, woher eine Zahl kommt, und drei Leute geben drei verschiedene Antworten. Oder jemand entdeckt, dass die "customer"-Tabelle im Warehouse vier verschiedene Definitionen über Teams hinweg hat. Oder eine DSGVO-Anfrage kommt rein, und niemand weiß, welche Systeme PII halten.

Ein Data Governance Framework löst diese Probleme — nicht mit Bürokratie, sondern mit klarer Eigentümerschaft, geteilten Definitionen und Tooling, das die Regeln durchsetzt. Dieser Guide zeigt dir, wie du eines baust, das wirklich funktioniert.

Was Data Governance wirklich heißt

Data Governance ist das System aus Entscheidungsrechten, Policies und Prozessen, das festlegt, wie Daten in einer Organisation gesammelt, gespeichert, genutzt und stillgelegt werden. Streich das Beratungs-Vokabular, und es läuft auf drei Fragen hinaus:

1. Wer besitzt diese Daten? (Accountability)
2. Was sind die Regeln? (Policies)
3. Wie setzen wir sie durch? (Prozesse + Tooling)

Wenn du diese drei Fragen für jeden Datensatz deiner Organisation beantworten kannst, hast du Governance. Alles andere ist Umsetzungsdetail.

Was Governance NICHT ist

Die vier Säulen eines Data-Governance-Frameworks

Jedes wirksame Governance-Framework ruht auf vier Säulen. Lass eine weg, und das Ganze wackelt.

1. Data Ownership & Stewardship

Für jeden Datensatz muss jemand verantwortlich sein. Nicht "das Data-Team" — eine konkrete Person.

Rollen, die du wirklich brauchst:

Der zentrale Insight: Ownership liegt im Business, nicht in der IT. Das Finance-Team besitzt Finanzdaten. Das Marketing-Team besitzt Kampagnendaten. Engineers bauen die Infrastruktur; sie definieren nicht, was "active customer" bedeutet.

2. Policies & Standards

Policies sind die Regeln. Standards sind, wie du sie umsetzt. Beide kurz und durchsetzbar halten.

Kern-Policies, die jedes Team braucht:

• Data Classification Policy — Welche Sensitivitätsstufen es gibt (public, internal, confidential, restricted) und wie sie behandelt werden
• Access Policy — Wer was sehen darf, wie Zugriff beantragt und widerrufen wird
• Retention Policy — Wie lange Daten gehalten werden und wann sie gelöscht werden — in der DACH-Region oft direkt an die DSGVO-Aufbewahrungsgrenzen gekoppelt
• Quality Policy — Welche Qualitäts-Schwellen es gibt und was passiert, wenn sie verletzt werden
• Lineage Policy — Wie Upstream-/Downstream-Abhängigkeiten getrackt werden

Hier ein praktisches Beispiel eines Data-Classification-Standards, umgesetzt als SQL-Comment-Convention:

-- PostgreSQL: Column-level classification using COMMENT
COMMENT ON COLUMN customers.email IS 'classification:confidential;pii:true;retention:3y';
COMMENT ON COLUMN customers.country IS 'classification:internal;pii:false;retention:indefinite';
COMMENT ON COLUMN orders.total_amount IS 'classification:internal;pii:false;retention:7y';

Schlank, aber maschinenlesbar. Ein Downstream-Scanner kann diese Comments parsen und Access-Regeln automatisch durchsetzen.

3. Datenqualität

Governance ohne Quality-Enforcement ist nur Dokumentation. Du brauchst automatisierte Checks, die in deinen Pipelines laufen.

Die fünf Dimensionen der Datenqualität:

So setzt du Basis-Quality-Checks in einem dbt-Projekt um:

# dbt schema.yml — Data quality tests
version: 2

models:
  - name: dim_customers
    description: "Customer dimension — owned by Sales team"
    meta:
      owner: "sales-team"
      classification: "confidential"
      contains_pii: true
    columns:
      - name: customer_id
        description: "Unique customer identifier"
        tests:
          - unique
          - not_null
      - name: email
        description: "Customer email — PII, confidential"
        tests:
          - not_null
          - unique
      - name: created_at
        tests:
          - not_null
          - dbt_utils.expression_is_true:
              expression: "created_at <= current_timestamp"
      - name: country_code
        tests:
          - not_null
          - accepted_values:
              values: ['DE', 'US', 'GB', 'FR', 'NL', 'AT', 'CH']
              config:
                severity: warn

Das bettet Governance direkt in deinen Transformations-Layer ein. Schlägt ein Test fehl, stoppt die Pipeline — keine schlechten Daten erreichen Dashboards.

4. Metadaten & Data Catalog

Ein Data Catalog ist die zentrale Sicht, in der Menschen Daten finden, verstehen und ihnen vertrauen. Ohne Catalog lebt Governance in Wikis, die keiner liest.

Was dein Katalog erfassen muss:

• Technische Metadaten — Tabellennamen, Spaltentypen, Row Counts, Aktualität
• Business-Metadaten — Klartext-Beschreibungen, Ownership, Klassifizierung
• Lineage-Metadaten — woher die Daten kommen, welche Transformationen sie durchlaufen, was von ihnen abhängt
• Usage-Metadaten — wer fragt es ab, wie oft, wofür

Beliebte Catalog-Tools:

Roadmap: Von Null zu Governed

Versuch nicht, alles auf einmal zu governen. Klein anfangen, Wert beweisen, expandieren.

Phase 1: Foundation (Woche 1–4)

Ziel: Ownership für die wichtigsten Datasets etablieren.

1. Die Top-10-meistgenutzten Datasets identifizieren (Query-Logs checken)
2. Pro Dataset Owner und Steward zuweisen
3. Einen-Absatz-Beschreibungen pro Dataset schreiben
4. Bekannte Qualitätsprobleme dokumentieren — noch nicht fixen, nur anerkennen

Deliverable: Ein einfaches Spreadsheet oder Catalog-Einträge für 10 Datasets mit Ownern.

Phase 2: Policies & Quality (Woche 5–8)

Ziel: Regeln definieren und anfangen, sie durchzusetzen.

1. Data-Classification-Policy schreiben (eine Seite max.)
2. Top-10-Datasets klassifizieren
3. Automatisierte Quality-Tests für kritische Pipelines (Start mit dbt-Tests oder Great Expectations)
4. Wöchentliches 30-Min-"Data-Quality-Standup" mit Stewards aufsetzen

Deliverable: Classification-Policy, Quality-Tests in CI/CD, erstes Quality-Metriken-Dashboard.

Phase 3: Scale & Automate (Woche 9–16)

Ziel: Governance auf alle produktiven Datasets ausweiten.

1. Ownership für alle produktiven Datasets ausrollen
2. Data Catalog deployen (oder den bestehenden ausbauen)
3. Automatisches Lineage-Tracking einführen
4. Access-Request-Workflows aufsetzen
5. Onboarding-Docs für neue Team-Mitglieder erstellen

Deliverable: Volle Catalog-Coverage, automatisches Lineage, Self-Service-Access-Requests.

Phase 4: Continuous Improvement (laufend)

Ziel: Governance zur Gewohnheit machen, nicht zum Projekt.

1. Monatliches Governance-Review — werden Policies gelebt?
2. Quartalsweise Ownership-Audit — haben sich Verantwortlichkeiten verschoben?
3. Governance-KPIs tracken (Catalog-Coverage, Quality-Score-Trends, Time-to-Access)
4. Policies iterieren basierend auf realer Friktion

Governance-KPIs: Was wirklich zählt

Du kannst nicht managen, was du nicht misst. Diese Metriken monatlich tracken:

Wenn Governance scheitert: häufige Anti-Patterns

Die Komitee-Falle: Ein "Data Governance Council" einrichten, das monatlich tagt, Slide-Decks produziert, aber nichts liefert. Governance muss in den Tages-Workflow eingebettet sein, nicht an ein Komitee delegiert.

Die Tool-First-Falle: Ein teures Catalog-Tool kaufen, bevor Ownership oder Policies definiert sind. Das Tool wird leer stehen. Erst Menschen, dann Prozesse, dann Tools.

Die Boil-the-Ocean-Falle: Versuchen, jeden Datensatz vom ersten Tag an zu governen. Du brennst aus und gibst auf. Starte mit den 10 wichtigsten Tabellen und expandiere.

Die Compliance-Only-Falle: Governance nur als DSGVO-/SOX-Checkbox behandeln. Compliance ist ein Nebenprodukt guter Governance, nicht ihr Zweck. Der Zweck ist: Daten vertrauenswürdig und zugänglich machen.

Governance für kleine Teams

Du brauchst kein dediziertes Governance-Team, um anzufangen. Aus meiner Erfahrung können Teams von 3–10 Data-Professionals wirksame Governance mit diesen Anpassungen umsetzen:

• Rollen kombinieren: Der Data Engineer, der die Pipeline baut, ist auch der Steward. Der Analytics-Lead ist auch der Owner.
• dbt als Catalog nutzen: schema.yml mit Descriptions, Tests und Meta-Tags deckt 80 % der Catalog-Bedürfnisse kostenlos ab.
• Aggressiv automatisieren: Jeder manuelle Governance-Schritt ist ein Schritt, der nicht konsistent passiert. CI/CD für Quality-Tests, automatisches Freshness-Monitoring, Git-basierte Policy-Versionierung.
• Heavyweight-Tools weglassen: Ein gut gepflegtes dbt-Projekt + eine Notion-Seite mit Ownership-Mappings schlägt jedes Mal eine leere Atlan-Instanz.

Wenn du ein kleines Team führst, das Daten aus mehreren Quellen erkundet — APIs, CSVs, Datenbanken — lassen Tools wie Harbinger Explorer dich diese Quellen direkt im Browser mit DuckDB WASM abfragen und katalogisieren, was als schlanker Data-Exploration-Layer dienen kann, während du Governance um dein Kern-Warehouse herum aufbaust.

FAQ

Was ist der Unterschied zwischen Data Governance und Data Management?

Data Management ist das Wie — Pipelines, Storage, Quality. Data Governance ist das Wer entscheidet was — Ownership, Policies, Entscheidungsrechte. In der Praxis überlappen sie sich, aber Governance setzt den Rahmen, in dem Management operiert.

Wer sollte für Data Governance verantwortlich sein?

Idealerweise eine benannte Person mit der Rolle "Data Governance Lead" oder ein Data-Platform-Team. In kleinen Teams (< 10) übernimmt das oft der Senior Data Engineer oder Analytics Lead in Personalunion.

Wie passt DSGVO in ein Governance-Framework?

DSGVO-Anforderungen (Right-to-be-Forgotten, Auskunftsrecht, Datenminimierung) werden über die Säulen Klassifizierung (welche Spalten sind PII) und Retention (wann wird gelöscht) abgedeckt. Compliance ist ein Output der Governance, kein eigenes Projekt.

Brauche ich einen Data Catalog?

Ab 50+ Tabellen oder 5+ aktive Konsumenten pro Tabelle: ja. Davor: ein Markdown-Repo oder dbt-Docs reichen oft. Tool-Wahl erst, wenn die Ownership-Frage gelöst ist.

Wie lange dauert ein realistisches Governance-Setup?

Phase 1 (Foundation) in 4 Wochen. Phase 2 (Quality) in weiteren 4. Phase 3 (Scale) in 8. Realistisch 4–6 Monate für ein nutzbares Setup, dann laufende Iteration.

Morgen starten

Was du sofort tun kannst, vor jeder formalen Initiative:

1. Die drei wichtigsten Tabellen wählen. Die, die in jedem Dashboard und jeder Stakeholder-Frage auftauchen.
2. Einen Satz Beschreibung pro Tabelle schreiben. Posten, wo dein Team kommuniziert.
3. Einen Quality-Test pro Tabelle ergänzen. Ein NOT NULL-Check auf dem Primary Key zählt. In Produktion deployen.
4. Pro Tabelle einen Owner benennen. Schick ihnen eine Nachricht: "Du besitzt diese Tabelle. Wenn was kaputt geht, bist du der erste Anruf."

Das ist Governance. Alles andere ist hochskalieren.

Weiterlesen

• Was ist dbt?
• Data Lakehouse Architektur erklärt
• Data Catalog Best Practices

[PRICING-CHECK] Atlan- und Alation-Pricing-Zahlen sind Schätzungen basierend auf öffentlichen Quellen — verifiziere mit den Vendoren für aktuelle Raten.

Stand: 14. Mai 2026.