Governance scheitert selten an Regeln. Sie scheitert an Bürokratie. Wenn dein Data-Katalog nach drei Monaten niemand mehr pflegt, hast du kein Regel-Problem, sondern ein Anreiz-Problem. Dieser Artikel beschreibt ein Framework, das ich seit Jahren in der Praxis nutze: vier Säulen, nicht zwanzig Regeln. Und er beantwortet die zentrale Entscheidung, vor der du irgendwann stehst: zentrale oder federierte Governance?
Was Data Governance ist — und was ausdrücklich nicht
Arbeits-Definition: Verbindliche Regeln, Rollen und Prozesse für den Umgang mit Daten. Das klingt trocken, ist aber präzise: Ohne Verbindlichkeit sind es Empfehlungen, ohne Rollen sind es Zitate, ohne Prozesse sind es Meinungen.
Was Governance nicht ist:
- Reporting (das ist BI).
- Security-Tooling (das ist IT-Security).
- Ein Datenschutzbeauftragter (das ist Privacy-Compliance, Teil der Säule 3).
Warum der Begriff in deutschen Firmen verbrannt klingt: Viele haben Governance als bürokratische Belastung erlebt — Regeln, die von außen auferlegt wurden, ohne Nutzen im Alltag. Wenn du Governance neu einführst, musst du den Begriff neu laden. Einige CDOs vermeiden das Wort komplett und nennen es „Data Trust Framework" oder „Datenordnung". Politischer Trick, der funktionieren kann.
Säule 1 — Quality: ohne Vertrauen kein Nutzen
Datenqualität ist nicht „die Daten müssen stimmen". Das ist ein Wunsch, keine Säule. Quality im Governance-Sinn heißt:
Kernmetriken: Accuracy, Completeness, Timeliness, Consistency. Jede wird gemessen, Soll-Werte sind definiert, Abweichungen werden gemeldet und behoben.
Stammdaten-Management als Basis: Kundendaten, Produktdaten, Lieferantendaten — die Daten-Objekte, auf denen alles andere aufsetzt. Ohne sauberes Stammdaten-Management keine saubere Quality-Messung.
Der kritische Punkt: Quality ist ein Prozess, kein Projekt. Jede Firma, die Quality als einmaliges Projekt denkt, hat nach 12 Monaten wieder dasselbe Problem. Quality ist Dauerlauf, nicht Sprint.
Säule 2 — Security: das Offensichtliche nicht übersehen
Security ist oft die am weitesten ausgebaute Säule, weil IT-Security institutionell verankert ist. Verschlüsselung, Backups, Audit-Trails — das machen die meisten ordentlich.
Der Knackpunkt ist die Schnittstelle zur IT-Security. Wer macht was? Die Faustregel: IT-Security verantwortet die Infrastruktur, Data Governance verantwortet den Lebenszyklus der Daten. Das klingt nach Abgrenzungs-Gedöns, ist aber wichtig — ohne klare Aufteilung bekommst du entweder Doppel-Governance oder Lücken.
Praktischer Test: Wenn ein Fachbereich eine neue Datenquelle integrieren will — wer entscheidet, ob das Security-Niveau ausreicht? Wenn die Antwort „IT-Security und Data Governance gemeinsam" lautet, ist das oft schon zu langsam. Klare Verantwortung mit Eskalationspfad ist schneller.
Säule 3 — Privacy: DSGVO pragmatisch
DSGVO ist seit 2018 Realität. EU AI Act ist seit 2024 in Kraft und wird bis 2027 voll scharf. Privacy ist nicht optional.
Datenminimierung und Zweckbindung in der Praxis. Das ist die Säule, an der die meisten Daten-Initiativen stolpern — weil der Impuls „wir sammeln erstmal alles" strukturell gegen Datenminimierung läuft. Wer das ernst meint, baut Retention-Regeln in die Pipeline ein, nicht nachträglich in Reports.
Consent als Datenfeld, nicht als Fußnote. Wenn euer Consent-Management isoliert vom CDP oder Warehouse läuft, habt ihr einen strukturellen Compliance-Fehler. Siehe auch den CDP-Pillar für die CDP-spezifische Umsetzung.
Pseudonymisierung vs. Anonymisierung. Zwei verschiedene Dinge. Pseudonymisierung ist reversibel (Mapping-Tabelle existiert), Anonymisierung ist irreversibel. Verwechslung ist der häufigste Punkt in Datenschutz-Audits.
Die KI-Compliance-Dimension findest du im KI-Cluster.
Säule 4 — Access: wer darf was
Rollen-basiert vs. attribut-basiert. RBAC (Role-Based Access Control) ist der Klassiker: Rolle bestimmt Zugriff. ABAC (Attribute-Based) ist feiner: Zugriff hängt von Attributen ab (Abteilung, Standort, Datenklasse). Für die meisten Mittelständler ist RBAC mit sauberen Rollen erst mal genug.
Data-Product-Thinking: Zugang ist ein SLA, kein Gefallen. Wenn ein Fachbereich eine neue Auswertung braucht, darf das nicht vom Wohlwollen einer Person abhängen. Es braucht einen dokumentierten Prozess mit Bearbeitungszeit und klarem Outcome.
Central vs. Federated Governance — welches Modell passt
Die strategisch wichtigste Entscheidung in der Governance-Architektur. Hier die Entscheidungsmatrix:
| Kriterium | Central Office | Federated Model | |---|---|---| | Unternehmensgröße | < 1.000 MA oder stark zentral geführt | ab 1.000 MA oder mehrere Domänen | | Reifegrad | Stufe 2–3 | Stufe 3–5 | | Governance-Budget | Zentral konzentriert | Verteilt auf Domänen + dünnes Kernteam | | Daten-Plattform | Data Warehouse / Lakehouse zentral | Data Mesh / Domain Data Products | | Risiko | Engstelle, wird als Bremsklotz gesehen | Auseinanderdriften der Standards |
Central Office ist der Klassiker: Ein Governance-Team hält die Regeln. Schnell entschieden, oft als Engstelle wahrgenommen. Federated Model verteilt die Verantwortung auf Domain-Owner, mit zentralen Leitplanken — das funktioniert erst ab einer gewissen Reife und Größe.
<JonasTake number={1}> „Wir machen Data Mesh" ist in 7 von 10 Fällen, die ich sehe, die politisch korrekte Formulierung für „wir schaffen Governance ab, weil sie uns zu anstrengend geworden ist". Data Mesh ist ein starkes Konzept — aber es ist mehr Governance, nicht weniger. Verteilt, aber sichtbarer und verbindlicher als vorher. Wer Data Mesh einführt, um Governance zu umgehen, baut in 18 Monaten Chaos auf. Wenn jemand dir Data Mesh als „leichtere Governance" verkauft, ist das ein Warnsignal, kein Verkaufsargument. </JonasTake>
Zur Vertiefung: Data Mesh Einführung und Data Products als Governance-Objekt.
90-Tage-Aufbauplan
Tage 1–30: Inventur + Pain-Points. Datenquellen listen, Pain-Points mit Fachbereichen sammeln, Governance-Ist-Zustand dokumentieren. Erwartung: Du wirst Datenquellen finden, von denen niemand wusste.
Tage 31–60: Säulen-Prioritäten + Rollen. Welche der vier Säulen hat akut den größten Schmerz? Priorisieren, nicht alles gleichzeitig angehen. Rollen benennen: Data Owner in Fachbereichen, Data Steward operativ, Governance Lead zentral.
Tage 61–90: Erste Policies + Catalog-MVP + Messsystem. Drei bis fünf Policies, die das akute Problem adressieren — nicht ein 50-Seiten-Handbuch. Ein minimaler Datenkatalog (kann Confluence oder Notion sein, muss nicht sofort ein Enterprise-Tool werden). Ein simples Messsystem pro Säule.
Das Ziel nach 90 Tagen ist nicht „Governance fertig". Das Ziel ist: Es gibt eine Basis, auf der du in den nächsten 18 Monaten ausbauen kannst.
Werkzeuge — was du wirklich brauchst
Kategorien, nicht Anbieter:
- Data Catalog (Suche, Dokumentation, Metadaten).
- Data Lineage (woher kommen Daten, wohin gehen sie).
- Access Management (wer darf was, Audit-Trail).
- Quality Monitoring (automatisierte Checks, Alerts).
Warum der Tool-Kauf vor dem Rollen-Setup fast immer scheitert: Tools helfen, wenn es Prozesse gibt, die sie unterstützen. Ohne Prozesse wird der Data Catalog zur schönen, leeren Datenbank. Das kostet Geld und produziert Frust.
Häufig gestellte Fragen
<FAQ />
Weiterhören im Podcast
<WeiterhoerenBlock topic="Data Governance" categories={["data_strategy"]} limit={3} />
<CTA> Unsicher, ob Central oder Federated zu euch passt? 60 Minuten Sparring, in denen wir anhand eurer Reife und Größe das passende Modell entscheiden. Beratung anfragen → </CTA>
Dieser Artikel ist Teil meines Leitfadens zur datengetriebenen Transformation.