EU Data Governance Act for SaaS Developers: Are You a Data Intermediary?

Post #852 in the sota.io EU Compliance Series

The EU Data Governance Act (DGA, Regulation 2022/868) became applicable on September 24, 2023. Unlike the GDPR, the DGA is not primarily about protecting personal data — it is about enabling trusted data sharing in Europe. But for SaaS developers, the DGA contains a hidden trip wire: if your platform facilitates data exchange between organizations or between individuals and companies, you may be classified as a data intermediary service provider under Article 10.

That classification triggers registration obligations, neutrality requirements, and a code of conduct — all before you can legally offer your service in the EU.

Most SaaS developers have never heard of the DGA. This guide changes that.

What the DGA Actually Regulates

The DGA has four main chapters, but only one is directly relevant to most SaaS developers.

Chapter II (Articles 3–9) covers the re-use of public sector data — data held by government bodies that is protected by privacy, intellectual property, or confidentiality rules. If your SaaS ingests or redistributes public sector data (e.g., health data, mobility data, environmental sensors), Chapter II applies. You need a specific authorization from the public body and must use the data only for the declared purpose.

Chapter III (Articles 10–15) covers data intermediary services — the most commonly overlooked DGA obligation for SaaS builders.

Chapter IV (Articles 16–26) covers data altruism organizations — entities that collect and make available data volunteered by individuals or companies for general interest purposes (research, public health, climate). If your platform runs a data donation program or collective intelligence feature, Chapter IV may apply.

Chapter V establishes the EU Data Innovation Board, a cross-border coordination body.

For most SaaS developers, Chapter III is the one that matters.

The Three-Part Test: Are You a Data Intermediary?

Article 2(11) defines a "data intermediary service" as a service that aims to establish commercial relationships for the purposes of data sharing between data subjects or data holders on the one hand, and data users on the other.

That sounds abstract. The practical test has three parts:

Test 1: Do You Facilitate Data Exchange Between Third Parties?

A data intermediary stands between data holders and data users. It is not a company that simply collects data for its own use (that is a data processor or controller under GDPR). It is a platform that connects parties who each retain their own relationship with the data.

Examples that likely qualify:

• A B2B data marketplace where companies list datasets for other companies to license
• A personal data wallet where individuals share health, mobility, or financial data with third-party apps (MyData-style architecture)
• An IoT data exchange platform where device manufacturers make sensor data available to analytics firms
• A federated data space connector (e.g., GAIA-X or Catena-X-style node) that routes data between organizations without centralizing it

Examples that likely do not qualify:

• A SaaS that collects user data for its own analytics or product features
• A B2B SaaS that processes customer data on behalf of its customers (that is standard data processing under GDPR Art. 28)
• A data analytics tool that ingests external data solely for its own model training

Test 2: Is the Matching or Exchange the Core Service?

The DGA targets services where the data intermediation is the primary value proposition, not an incidental feature. If your platform's core function is to match data holders with data users, you are a data intermediary. If data sharing is a secondary feature of a broader SaaS product, the classification is less clear.

The European Commission's guidance notes that services offering technical infrastructure (APIs, connectors) without controlling the terms of the data exchange occupy a grey zone. The safest approach: assume DGA applies and seek legal advice if your SaaS generates revenue from facilitating data access.

Test 3: Do You Operate Commercially in the EU?

The DGA applies to data intermediary services offered in the EU, regardless of where the provider is established. A US-based SaaS targeting EU businesses with a data exchange feature is within scope (similar to GDPR's Article 3 territorial reach).

If all three conditions are met: you are a data intermediary under the DGA.

What Happens If You Qualify: The Article 11 Registration Requirement

Data intermediary service providers must notify the competent authority in their EU Member State (or, if established outside the EU, the competent authority in the Member State where they intend to offer their service first) before they start operating.

Article 11 notification requirements include:

The notification is not a license — the authority has 12 weeks to respond and can only prevent operation if the notification is incomplete or the service manifestly violates DGA requirements. But you cannot legally offer the service without completing it.

There is no EU-wide single registration. You notify the competent authority in one Member State, and that authority coordinates with others through the EU Data Innovation Board. In Germany, the relevant authority is the Federal Network Agency (Bundesnetzagentur). In France, it is CNIL (for personal data-related intermediaries) or a sector-specific body.

The Article 12 Conditions: What a Data Intermediary Must Do

Article 12 sets out nine conditions that all data intermediary service providers must meet. These are not aspirational — they are legal requirements that the competent authority can enforce.

1. Neutrality (Article 12(a))

You must not use data for purposes other than making it available to data users. You cannot use data shared through your platform for your own analytics, product improvements, or third-party offers. This is a hard rule that many data marketplace SaaS products violate implicitly by using aggregated sharing data to train recommendation models.

2. Fair, transparent, non-discriminatory terms (Article 12(b))

Data holders and data users must be offered equivalent terms. You cannot offer better API access, lower fees, or faster processing to affiliated companies or preferred partners without extending the same to all similarly situated parties.

3. No exclusivity requirements (Article 12(c))

You cannot contractually require data holders or data users to use your platform exclusively. Lock-in clauses that prevent a data holder from sharing the same data through a competing intermediary are prohibited.

4. Separation from other services (Article 12(d))

If your company offers other services in addition to data intermediation, you must operationally and legally separate the intermediary function. The data collected through intermediation cannot be shared internally with your other business units. This often requires organizational firewalls and separate storage systems.

5. Personal data handling under GDPR (Article 12(e))

If your data intermediary service handles personal data (most do), you must comply with GDPR in addition to the DGA. Data subjects must be able to exercise their rights (access, erasure, portability) independently of the data-sharing arrangement.

6. Data security (Article 12(f))

You must implement appropriate technical and organizational security measures — essentially the GDPR Article 32 standard, applied to all data flowing through the intermediary regardless of whether it is personal data.

7. Transparent pricing (Article 12(g))

Fees for using the intermediary service must be disclosed in advance and applied consistently. Hidden charges, revenue-sharing arrangements that are not disclosed to data holders, or retroactive fee changes are prohibited.

8. Data portability tools (Article 12(h))

You must give data holders easy access to the data they have shared through your platform, in a machine-readable format, to enable them to switch to another intermediary or withdraw from sharing arrangements.

9. Complaint and dispute resolution (Article 12(i))

You must put in place a procedure for handling complaints from data holders and data users, with clear timelines and escalation paths.

The DGA and GDPR Intersection

For most data intermediary services, the DGA does not replace GDPR — it adds to it. If the data flowing through your platform includes personal data (which it usually does, even in B2B contexts), both regulations apply simultaneously.

The key interaction points:

Data subject rights: A person who shares their health or financial data through a data wallet has both GDPR rights (access, erasure, portability) and DGA rights (the ability to grant, modify, or withdraw consent for data sharing). You need technical mechanisms for both.

Lawful basis: Under GDPR, data sharing requires a lawful basis. Under the DGA, you are the facilitator of that sharing — but the data holder and data user still need their own GDPR lawful bases. Your platform needs to record and enforce those bases without substituting its own judgment.

Data minimization: The DGA's neutrality principle reinforces GDPR's minimization principle. Using data shared through your platform for secondary purposes is both a DGA violation and a GDPR Article 5(1)(b) violation.

Cross-border transfers: If your data intermediary service involves personal data flowing to non-EEA data users, the standard GDPR transfer rules (Chapter V) apply. Your platform must technically enforce transfer restrictions — not just contractually disclaim them.

Infrastructure Implications: Why EU-Native Matters for Data Intermediaries

The Article 12 conditions create specific infrastructure requirements that are easier to satisfy with EU-native deployment:

Neutrality enforcement requires storage isolation. Article 12(d)'s separation requirement means the data flowing through your intermediary service cannot reside in the same storage layer as data from your other business lines. EU-native infrastructure providers that offer dedicated tenant isolation without cross-customer data visibility are structurally better aligned than hyperscaler environments where data co-mingling is the default.

CLOUD Act exposure undermines data holder trust. If a data holder shares commercially sensitive data through your intermediary, and your infrastructure is operated by a US parent company, the CLOUD Act creates a latent disclosure risk. The EU CLOUD Act Blocking Statute (Regulation 2023/2801) offers some protection, but it is not absolute. EU-native providers without US ownership eliminate this risk category.

Data portability requires controlled export. The Article 12(h) portability obligation requires you to generate machine-readable exports of data that data holders have shared. This is an operational function that must work reliably across your entire infrastructure stack — not just at the API layer.

Audit trails for competent authority oversight. Competent authorities under Article 14 can request information from data intermediary service providers. You need complete, tamper-evident logs of data-sharing transactions. EU-native infrastructure with clear data residency guarantees makes this easier to demonstrate.

The Data Altruism Track: A Different Obligation Set

If your SaaS enables voluntary data sharing for general interest purposes (scientific research, public health monitoring, improving public services), you might qualify for or want to register as a data altruism organisation under Chapter IV.

Data altruism organizations must:

• Be non-profit entities (or have a separate non-profit entity handle the altruism function)
• Register with a competent authority in an EU Member State
• Comply with a code of conduct published by the European Commission
• Publish an annual activity report detailing what data was collected, for what purposes, and what measures were taken to prevent misuse

The data altruism track is primarily relevant for research platforms, health data initiatives, and smart city projects — not typical commercial SaaS. But if your platform has a "contribute your data to public good" feature, you need to assess whether that feature triggers Chapter IV obligations.

Enforcement Status: What Has Actually Happened

The DGA has been applicable since September 2023. As of 2026, enforcement is still in early stages. Most Member States have designated their competent authorities, but few have publicly announced formal enforcement actions specifically targeting data intermediary service providers.

However, the EDIB (EU Data Innovation Board) has been active in developing guidance, and several Member States have issued clarifications on which services qualify as data intermediaries. Germany, France, and the Netherlands have the most developed enforcement frameworks.

The pattern of EU regulatory enforcement suggests that the first major cases will involve obvious violations — a platform operating as a data marketplace without any DGA notification, or a data intermediary caught using shared data for its own analytics. If your SaaS falls within scope, registering and complying now is significantly lower-risk than waiting for an enforcement signal.

Fines under the DGA are set by Member States (Article 34), not at EU level. Member States must set penalties that are "effective, proportionate and dissuasive" — the same language used in GDPR before Member States set fines up to 4% of global annual turnover.

The EU Data Act vs. The EU Data Governance Act: Not the Same Thing

This confusion appears frequently in developer discussions. They are two different regulations:

EU Data Governance Act (DGA, Regulation 2022/868):

• Applicable since September 24, 2023
• Focus: Rules for how data sharing is organized — trusted intermediaries, public sector data re-use, data altruism
• Who it affects: Data intermediary service providers, public bodies making protected data available for re-use, data altruism organizations

EU Data Act (Regulation 2023/2854):

• Applicable since September 12, 2025
• Focus: Rules for who has rights to access data — especially IoT-generated data, B2B data access rights, cloud switching
• Who it affects: IoT manufacturers, data processors, cloud service providers (switching API obligations), any company that collects IoT-generated data

A SaaS that aggregates IoT sensor data and makes it available to third-party analytics companies could be subject to both: the Data Act for the IoT data access rights, and the DGA for operating a data intermediary service.

Three Developer Action Items

1. Run the three-part test against your product features. Does your SaaS facilitate data exchange between third parties as a core function? If yes, DGA Chapter III likely applies. Document your analysis.

2. Check your Member State's competent authority. If you determine the DGA applies, identify the correct notification authority in your jurisdiction. Most national authorities have published guidance and registration portals. The notification process itself is administrative — the legal work is in ensuring your product meets the Article 12 conditions before you notify.

3. Audit your data architecture for neutrality compliance. Article 12(a)'s prohibition on using intermediary data for your own purposes is the condition most likely to require technical changes. If your SaaS logs, aggregates, or analyzes data flowing through the intermediary function for any internal purpose, you need architectural separation — not just a policy statement.

The DGA has been in force for over two years. Most SaaS developers who operate within scope are not compliant — not because they chose to ignore it, but because the regulation received far less developer attention than GDPR or the AI Act. That gap is closing as Member State enforcement frameworks mature.

If your SaaS facilitates data sharing between organizations, the time to assess DGA applicability is now — not after your first request from a competent authority.

Running a data intermediary service on EU-native infrastructure? sota.io provides GDPR-compliant, EU-sovereign deployment with no US parent company exposure — structurally aligned with DGA Article 12 neutrality and data security requirements.