Data Governance Act: What SMBs and DevOps Teams Need to Know

The Data Governance Act has been binding across the EU since September 2023, yet unlike the GDPR, it barely registers on the radar of technical teams. That's a mistake. The DGA has direct implications for how companies share, manage, and retain data within their infrastructure. Ignoring it doesn't just risk compliance issues — it leads to architecture decisions that become expensive to reverse later on.

What the Data Governance Act Covers — and What It Doesn't

The DGA is not a data protection law. It complements the GDPR but doesn't override it. While the GDPR governs the protection of personal data, the DGA addresses something different: it creates the legal and organizational framework for data sharing between companies, public bodies, and individuals across the EU.

Specifically, the DGA defines three core areas:

• Re-use of public sector data — under what conditions government-held data can be used for commercial or scientific purposes
• Data intermediation services — neutral intermediaries that facilitate data exchange between providers and users without having their own economic interest in the data
• Data altruism — organizations that collect and make data available for the common good

This sounds abstract, but it has tangible consequences the moment your company shares data with partners, uses external data services, or acts as a data intermediary itself.

How It Differs from the Data Act

A common misconception: the Data Governance Act and the Data Act are often mentioned together but are fundamentally different. The DGA governs the structures — who is allowed to share data and under what conditions. The Data Act governs the rights — who is entitled to access data generated through the use of products and services.

Put simply: the DGA builds the road, the Data Act determines who gets to drive on it. Both frameworks need to be considered together — the Data Act and its implications for DevOps are covered in a separate article.

Who the Data Governance Act Directly Affects

At first glance, the DGA seems like a topic for public authorities and large data intermediation platforms. That's only partly true. Directly affected are:

• Public bodies that make protected data (e.g., health, mobility, or financial data) available for re-use
• Data intermediation services that act as neutral marketplaces between data providers and users — they must register with national authorities
• Data altruism organizations that collect data for public interest purposes

For SMBs and DevOps teams, the DGA applies indirectly but still noticeably: anyone sourcing or sharing data through a certified data intermediary must meet the technical and contractual requirements of these intermediaries. And anyone running their own services on infrastructure that could be classified as a data intermediary should take a close look at whether a registration obligation applies.

Data Governance Act and Deployment: What Changes for DevOps

The technical dimension of the DGA is often overlooked. Yet it's particularly relevant for DevOps teams because it directly impacts architecture decisions.

The core principle: anyone managing or intermediating data under the DGA must be able to demonstrate where that data resides, who accesses it, and how it's protected. This isn't a new concept, but the DGA gives it a new regulatory framework — with consequences for Kubernetes deployments.

Implementing Data Sovereignty in Practice

Data classification within the cluster is the first step. Which workloads process data that could fall under the DGA? This might include data from public sources, data from partners via a data intermediary, or your own data that you share through such a service.

Concrete technical measures that become relevant in this context:

Namespace isolation: Sensitive workloads belong in dedicated namespaces with clear RBAC rules. It's not rocket science, but many teams don't do it consistently.

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

Network policies: By default, all pods in a Kubernetes cluster can communicate with each other. For regulated data, that's a problem. An explicit default-deny policy combined with allowed exceptions is mandatory:

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

Audit logging: To ensure traceability of data access, you need centralized logging at the API server level. If you don't have this in place yet, set it up — not just because of the DGA, but as a general best practice.

Infrastructure choice: If your cluster runs on a US hyperscaler, you have a structural problem. US providers are subject to the CLOUD Act, which potentially grants American authorities access to data regardless of whether the servers are physically located in the EU. For deployments falling under the DGA, European infrastructure with clear legal sovereignty isn't optional — it's a must. For why this requires board-level cloud governance, not just technical fixes, see our dedicated analysis.

Data Governance Act for SMBs: Obligations and Opportunities

SMBs face a particular challenge: they have fewer resources for compliance but are affected just as much as larger companies. The DGA makes no exception here — there are no explicit SMB exemptions.

What SMBs should do:

Map your data flows: What data comes in from outside, goes out, and through which services? Many SMBs don't have this overview — that's the first problem to solve.

Classify the services you use: Are external data sources or services registered data intermediaries under the DGA? This affects how contracts need to be structured.

Technical implementation: Not every SMB runs Kubernetes. But anyone using cloud-based services should understand where their data resides and what control they have over it. A platform that operates natively on sovereign EU infrastructure takes a large part of this burden off your shoulders.

On the flip side, the DGA also creates opportunities. The EU is building European Data Spaces — sector-specific data ecosystems for health, mobility, energy, and other domains. SMBs that position themselves early can access data pools that were previously out of reach.

First Steps Toward DGA Compliance in Practice

No company needs to overhaul everything overnight. But having a clear starting point helps:

1. Document data flows — Which systems process what data? Where does it come from, where does it go?
2. Audit external services — Are the data intermediation or data altruism services you use registered in compliance with the DGA?
3. Evaluate your infrastructure — Where do the workloads that process regulated data run? Is the location legally sovereign?
4. Establish technical baselines — Set up network policies, RBAC, and audit logging as a foundation
5. Review contracts — Clarify with data suppliers and recipients what DGA obligations arise from the collaboration

This isn't a massive project if you approach it step by step. The biggest mistake would be to ignore the topic entirely just because there's no wave of fines yet.

lowcloud operates Kubernetes infrastructure exclusively in sovereign European data centers — with no US hyperscalers in the stack. For teams that need DGA-compliant deployments without building an entire infrastructure themselves, it's a practical starting point.