Data Governance Act: Was KMU und DevOps-Teams wissen müssen

Der Data Governance Act ist seit September 2023 in der EU verbindlich, aber anders als die DSGVO erzeugt er kaum Aufmerksamkeit in technischen Teams. Das ist ein Fehler. Denn der DGA hat direkte Auswirkungen darauf, wie Unternehmen Daten teilen, verwalten und in ihrer Infrastruktur halten dürfen. Wer das ignoriert, riskiert nicht nur Compliance-Probleme, sondern trifft Architekturentscheidungen, die später teuer zu korrigieren sind.

Was der Data Governance Act regelt und was nicht

Der DGA ist kein Datenschutzgesetz. Er ergänzt die DSGVO, überschreibt sie aber nicht. Während die DSGVO den Schutz personenbezogener Daten regelt, geht es beim DGA um etwas anderes: Er schafft die rechtlichen und organisatorischen Rahmenbedingungen für den Datenaustausch zwischen Unternehmen, Behörden und Einzelpersonen in der EU.

Konkret definiert der DGA drei zentrale Bereiche:

• Wiederverwendung von Daten des öffentlichen Sektors – unter welchen Bedingungen staatliche Daten für kommerzielle oder wissenschaftliche Zwecke genutzt werden dürfen
• Datenvermittlungsdienste – neutrale Intermediäre, die Daten zwischen Anbietern und Nutzern vermitteln, ohne selbst wirtschaftliche Interessen an den Daten zu haben
• Datenaltruismus – Organisationen, die Daten zum Gemeinwohl sammeln und bereitstellen

Das klingt abstrakt, hat aber handfeste Konsequenzen, sobald dein Unternehmen Daten mit Partnern teilt, externe Datendienste nutzt oder selbst als Datenvermittler auftritt.

Abgrenzung zum Data Act

Ein häufiger Irrtum: Data Governance Act und Data Act werden oft in einem Atemzug genannt, sind aber grundlegend verschieden. Der DGA regelt die Strukturen: wer darf Daten teilen und unter welchen Bedingungen. Der Data Act regelt die Rechte: wer hat Anspruch auf Zugang zu Daten, die durch die Nutzung von Produkten und Diensten entstehen.

Vereinfacht gesagt: Der DGA baut die Straße, der Data Act legt fest, wer darauf fahren darf. Beide Regelwerke müssen zusammen gedacht werden – auf den EU Data Act und seine Implikationen wird in einem separaten Artikel eingegangen.

Wen der Data Governance Act direkt betrifft

Auf den ersten Blick klingt der DGA nach einem Thema für Behörden und große Datenvermittlungsplattformen. Das stimmt nur teilweise. Direkt betroffen sind:

• Öffentliche Stellen, die geschützte Daten (z. B. Gesundheits-, Mobilitäts- oder Finanzdaten) für die Weiterverwendung zugänglich machen
• Datenvermittlungsdienste, die als neutrale Marktplätze zwischen Datenanbieter und -nutzer agieren – sie müssen sich bei nationalen Behörden registrieren
• Datenaltruismus-Organisationen, die Daten für gemeinnützige Zwecke sammeln

Für KMU und DevOps-Teams greift der DGA indirekt, aber trotzdem spürbar: Wer Daten über einen zertifizierten Datenvermittler bezieht oder teilt, muss die technischen und vertraglichen Anforderungen dieser Intermediäre erfüllen. Und wer eigene Dienste auf einer Infrastruktur betreibt, die als Datenvermittler eingestuft werden könnte, sollte genau hinschauen, ob eine Registrierungspflicht entsteht.

Data Governance Act und Deployment: Was sich für DevOps ändert

Die technische Dimension des DGA wird oft übersehen. Dabei ist sie für DevOps-Teams besonders relevant, weil sie sich direkt auf Architekturentscheidungen auswirkt.

Der Kerngedanke: Wer Daten im Sinne des DGA verwaltet oder vermittelt, muss nachweisen können, wo diese Daten liegen, wer darauf zugreift und wie sie geschützt sind. Das ist kein neues Konzept, aber der DGA gibt ihm einen neuen regulatorischen Rahmen mit Konsequenzen für Kubernetes-Deployments.

Datensouveränität technisch umsetzen

Datenklassifizierung im Cluster ist der erste Schritt. Welche Workloads verarbeiten Daten, die unter den DGA fallen könnten? Das können Daten aus öffentlichen Quellen sein, Daten von Partnern über einen Datenvermittler oder eigene Daten, die du über einen solchen Dienst teilst.

Konkrete technische Maßnahmen, die in diesem Kontext relevant werden:

Namespace-Trennung: Sensitive Workloads gehören in dedizierte Namespaces mit klaren RBAC-Regeln. Das ist kein Hexenwerk, aber viele Teams machen es nicht konsequent.

kubectl create namespace data-regulated
kubectl apply -f rbac-data-regulated.yaml

Netzwerkpolicies: Standardmäßig kommunizieren alle Pods in einem Kubernetes-Cluster miteinander. Das ist für regulierte Daten ein Problem. Eine explizite Default-Deny-Policy, kombiniert mit erlaubten Ausnahmen, ist Pflicht:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: data-regulated
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Audit-Logging: Für die Nachvollziehbarkeit von Datenzugriffen braucht es zentrales Logging auf API-Server-Ebene. Wer das noch nicht hat, sollte es einrichten, nicht nur wegen des DGA, sondern generell.

Infrastrukturwahl: Läuft dein Cluster bei einem US-amerikanischen Hyperscaler, hast du ein strukturelles Problem. US-Anbieter unterliegen dem CLOUD Act, der amerikanischen Behörden potenziell Zugriff auf Daten ermöglicht, unabhängig davon, ob die Server physisch in der EU stehen. Für Deployments, die unter den DGA fallen, ist eine europäische Infrastruktur mit klarer Rechtssouveränität keine Option, sondern ein Muss.

Data Governance Act für KMU: Pflichten und Chancen

KMU stehen vor einer Besonderheit: Sie haben weniger Ressourcen für Compliance, sind aber genauso betroffen wie größere Unternehmen. Der DGA ist in dieser Hinsicht kein Sonderfall, schreibt keine expliziten KMU-Ausnahmen vor.

Was KMU konkret tun sollten:

Bestandsaufnahme der Datenflüsse: Welche Daten kommen von außen, gehen nach außen, und über welche Dienste? Viele KMU haben hier keine Übersicht – das ist das erste Problem, das gelöst werden muss.

Einordnung der genutzten Dienste: Handelt es sich bei externen Datenquellen oder -diensten um registrierte Datenvermittler im Sinne des DGA? Das hat Auswirkungen auf die Vertragsgestaltung.

Technische Umsetzung: Nicht jedes KMU betreibt Kubernetes. Aber wer cloudbasierte Dienste nutzt, sollte verstehen, wo die Daten liegen und welche Kontrolle er darüber hat. Eine Plattform, die von Haus aus in souveräner EU-Infrastruktur betrieben wird, nimmt einem einen großen Teil dieser Aufgabe ab.

Auf der anderen Seite entstehen durch den DGA auch Chancen. Die EU baut European Data Spaces auf: sektorale Datenräume für Gesundheit, Mobilität, Energie und andere Bereiche. KMU, die sich frühzeitig positionieren, können auf Datenpools zugreifen, die bisher nicht zugänglich waren.

Erste Schritte zur DGA-Compliance in der Praxis

Kein Unternehmen muss von heute auf morgen alles umbauen. Aber ein klarer Ausgangspunkt hilft:

1. Datenflüsse dokumentieren – Welche Systeme verarbeiten welche Daten? Woher kommen sie, wohin gehen sie?
2. Externe Dienste prüfen – Sind genutzte Datenvermittlungs- oder Datenaltruismus-Dienste DGA-konform registriert?
3. Infrastruktur bewerten – Wo laufen die Workloads, die regulierte Daten verarbeiten? Ist der Standort rechtssouverän?
4. Technische Absicherung im Cluster – Netzwerkpolicies, RBAC, Audit-Logging als Baseline einrichten
5. Verträge anpassen – Mit Datenlieferanten und -abnehmern klären, welche DGA-Pflichten sich aus der Zusammenarbeit ergeben

Das ist kein Mammutprojekt, wenn man es schrittweise angeht. Der größte Fehler wäre, das Thema komplett zu ignorieren, weil es noch keine Bußgeldwelle gibt.

lowcloud betreibt Kubernetes-Infrastruktur ausschließlich in souveränen europäischen Rechenzentren – ohne US-amerikanische Hyperscaler im Stack. Für Teams, die DGA-konforme Deployments brauchen, ohne selbst eine komplette Infrastruktur aufzubauen, ist das ein sinnvoller Ausgangspunkt.