Why Your Data Governance Program Doesn't Cover the EU Data Act

Here is a question worth asking your compliance team this quarter: which of your obligations under the EU Data Act are currently covered by your data governance program?

If the answer is "the Data Act is a privacy thing, GDPR has it," you have a structural gap. Not a small one. A whole regulation's worth.

The reflex is understandable. For most organizations, "data governance" was built around one regulation: the GDPR. Lawful basis, data subject rights, retention, transfers, DPIAs. The entire apparatus is oriented toward personal data and the rights of natural persons. That is the surface it was designed to cover.

The EU Data Act regulates a different surface. It is not a privacy law. It governs who gets access to the data your products and services generate, on what terms you can share it business-to-business, and whether your customers can leave your cloud. Its scope is personal and non-personal data, and the obligations it creates do not live in the GDPR's vocabulary at all.

So a program optimized for the GDPR can pass every privacy audit and still be exposed across an entire regulation that is already in force.

What is the EU Data Act, and why isn't it just another privacy law?

The Data Act is Regulation (EU) 2023/2854. Article 1 lays out what it actually governs, and reading it is the fastest way to see why a privacy program does not reach it.

It sets harmonised rules on six distinct things: making product and related-service data available to the user of a connected product; making data available by data holders to data recipients; making data available to public sector bodies where there is an exceptional need; facilitating switching between data processing services; safeguards against unlawful third-party access to non-personal data; and the development of interoperability standards.

Notice what is and is not on that list. There is no "lawful basis." No "data subject rights." No "purpose limitation." Those are GDPR concepts. The Data Act's organizing concepts are user, data holder, data recipient, and data processing service provider. Different roles, different obligations.

Article 1 is also explicit that the Regulation covers both personal and non-personal data. Your sensor telemetry, your machine logs, your usage metrics, the operational exhaust your connected products throw off every second: most of that is non-personal, which means GDPR never touched it, and the Data Act now does.

The Regulation does state that it is without prejudice to EU and national law on the protection of personal data, and that in the event of a conflict, the data protection law prevails. That clause is exactly what lulls privacy teams into thinking the two overlap. They do not. The Data Act sits beside the GDPR and complements the access and portability rights under Articles 15 and 20 of the GDPR. Complement, not duplicate.

Why do GDPR-built data governance programs miss the Data Act entirely?

The miss is structural, not careless. A GDPR program is built around a specific actor and a specific asset: the data subject and their personal data. Every control flows from that. Consent management protects the data subject. Retention schedules protect the data subject. Transfer impact assessments protect the data subject.

The Data Act's actors are commercial. The user of a connected product, who has a right to the data it generates. The data holder, who is obliged to make that data available. The data recipient, a business the user nominates to receive it. None of these map cleanly onto controller, processor, or data subject.

This means the question a GDPR program is built to answer ("are we processing personal data lawfully?") is the wrong question for the Data Act. The Data Act asks: are you designing products so data is accessible by default? Are your B2B data contracts fair? Can your cloud customers actually leave? A privacy control inventory has no row for any of those.

That is the diagnosis. The program is not weak. It is pointed at the wrong target. And because the obligations are denominated in non-personal data and commercial relationships, they do not trip any of the alarms a privacy program is wired to.

What does the Data Act require for connected-product and related-service data?

This is Chapter II, and it is where most product companies will feel the Data Act first.

Article 3(1) sets a design obligation. Connected products must be designed and manufactured, and related services designed and provided, so that product data and related service data, including the metadata needed to interpret it, are by default easily, securely, free of charge, in a structured, commonly used, machine-readable format, and where technically feasible directly accessible to the user. This is access-by-design, and it is a manufacturing requirement, not a paperwork one.

Article 3 also requires pre-contract disclosure. Before a user buys, rents, or leases a connected product, the seller must tell them, in clear terms, what data the product generates, whether it does so continuously and in real time, where it is stored and for how long, and how the user can access, retrieve, or erase it.

Article 4 covers what happens when the user cannot get the data directly. The data holder must make readily available data accessible to the user without undue delay, of the same quality the holder has, free of charge, in a machine-readable format, and where technically feasible continuously and in real time, on a simple electronic request. Article 4 also forbids dark patterns: a data holder must not make exercising these rights unduly difficult through non-neutral interface design.

Article 5 gives the user the right to direct that data to a third party of their choosing. The data holder must then make it available to that third party, again without undue delay and free of charge to the user. And Article 5(3) carves out one category explicitly: an undertaking designated as a gatekeeper under the Digital Markets Act cannot be an eligible third party. The biggest platforms are walled off from receiving data through this channel.

If your business makes connected products or provides related services, every one of these is an obligation your privacy program does not track.

How does the Data Act reshape B2B data sharing and contract terms?

Chapter III governs the terms on which data holders make data available. Article 8(1) requires that where a data holder is obliged to make data available to a data recipient, it does so under fair, reasonable and non-discriminatory terms, in a transparent manner. FRAND, applied to data sharing. Article 8(3) adds a non-discrimination duty between comparable categories of recipients, and on a reasoned request the data holder must demonstrate it has not discriminated.

Then there is Chapter IV, which is the part that should make every commercial counsel sit up. Article 13 makes an unfair contractual term that has been unilaterally imposed by one enterprise on another non-binding on the party it was imposed on.

The Article does not leave "unfair" to interpretation. Article 13(3) sets the general standard: a term is unfair if it grossly deviates from good commercial practice in data access and use, contrary to good faith and fair dealing. Article 13(4) is a blacklist of terms that are unfair, including any term that excludes liability for intentional acts or gross negligence. Article 13(5) is a greylist of terms presumed unfair, including ones that let the imposing party access and use the other party's data in a manner significantly detrimental to its legitimate interests, particularly where that data is commercially sensitive or protected by trade secrets.

And Article 13(6) flips the burden of proof. The party that supplied the term carries the burden of proving it was not unilaterally imposed. Your existing data-sharing agreements were not written against this standard. They predate it. That is the exposure.

What do the cloud-switching and portability rules demand of providers and customers?

Chapter VI is the one that surprises people most, because it has nothing to do with data subjects and everything to do with cloud lock-in.

Article 23 requires providers of data processing services to remove the obstacles that inhibit customers from switching to another provider, to on-premises infrastructure, or to using several providers at once. It names them: pre-commercial, commercial, technical, contractual and organisational obstacles, all to be removed.

Article 25 puts hard numbers on it. The switching contract must allow the customer to switch or port all exportable data and digital assets within a mandatory maximum transitional period of 30 calendar days, after a maximum notice period that cannot exceed two months. The provider must maintain business continuity and a high level of security throughout. There is a minimum data-retrieval period of at least 30 calendar days after termination.

Article 29 is the headline most CIOs will care about: from 12 January 2027, providers of data processing services shall not impose any switching charges on the customer. Egress fees as a retention tactic stop being legal. Between 11 January 2024 and that date, only reduced charges capped at the costs directly linked to switching are permitted.

Article 30 sets the technical floor. Providers must make open interfaces available free of charge, with enough information to develop software to communicate with the service, for data portability and interoperability. For infrastructure-type services, the obligation is to facilitate functional equivalence in the destination environment.

If you sell a data processing service, this is a redesign of your product and your contracts. If you buy one, this is leverage you did not have before. Either way, it is not a privacy obligation.

How do trade-secret and international-access safeguards change the obligation map?

The Data Act does not pretend that opening up data access comes for free. It builds in safeguards, and those safeguards are themselves obligations you have to operate.

On trade secrets, Article 4(6) requires that trade secrets be preserved and disclosed only where the holder and the user have taken all necessary measures to protect confidentiality, with the protected data identified in the metadata. Article 4(7) lets the data holder withhold or suspend sharing where measures are not agreed or are breached, with written justification and notification to the competent authority. Article 4(8) goes further: in exceptional circumstances, where the holder can demonstrate it is highly likely to suffer serious economic damage, it may refuse a specific request on a case-by-case basis. Article 5(9) to 5(11) mirror these protections for third-party sharing. The switching rules respect this too: Article 8(6) confirms that an obligation to make data available does not, as a rule, oblige disclosure of trade secrets.

On international access, Article 32 obliges providers of data processing services to take adequate technical, organisational and legal measures to prevent third-country governmental access and transfer of non-personal data held in the Union where that would conflict with EU or Member State law. A third-country court order is only recognisable if grounded in an international agreement such as a mutual legal assistance treaty, and absent one, access is permitted only under narrow conditions. This is the non-personal-data analogue to the GDPR's transfer regime, and your privacy program's transfer controls do not extend to it because they were scoped to personal data.

These are not exemptions you claim once. They are processes you have to be able to run, document, and defend.

Which Data Act deadlines are already live, and which are still coming?

The timeline matters because part of the Data Act is not a future project. It is current law.

Article 50 sets the dates. The Regulation applies from 12 September 2025. That date has passed. The general obligations are live now.

The Article 3(1) access-by-design obligation applies to connected products and their related services placed on the market after 12 September 2026. So newly launched products carry the design requirement on a slightly later clock.

Chapter IV, the unfair-terms regime, applies to contracts concluded after 12 September 2025, and from 12 September 2027 it reaches back to contracts concluded on or before that date where they are of indefinite duration or due to expire at least ten years from 11 January 2024. Your long-running data contracts get pulled in even if they were signed years ago.

And the switching-charge prohibition under Article 29 lands on 12 January 2027.

Read together, this is not a "watch this space" regulation. The core applies today, and the remaining triggers are close enough that mapping them now is the only responsible posture.

How do you build a governance model that covers both privacy and the Data Act's data-access surface?

The instinct will be to spin up a Data Act workstream next to the privacy one. Resist it. That is how you end up with framework sprawl: two programs, two sets of mappings, two evidence collections, and obligations double-counted or, worse, dropped in the gap between them.

The Data Act and the GDPR are not the same regulation, but they touch the same assets and the same systems. Article 5 third-party sharing intersects with GDPR Article 20 portability. The Data Act's trade-secret safeguards run alongside the GDPR's special-category protections. Article 32's non-personal-data transfer regime sits parallel to the GDPR's transfer rules. The right model treats these as overlapping obligations on shared infrastructure, not as separate silos.

That is the case for treating compliance as structured data rather than managed documentation. When every obligation is traced to its source article, and your organizational profile determines which regulations apply, the Data Act stops being a new project and becomes new edges in an existing graph. Answer once. Assess everything. The Article 3 access-by-design obligation, the Article 13 unfair-terms blacklist, the Article 29 switching-charge prohibition: each maps to the products, contracts, and services you already described, and where it overlaps a GDPR obligation, the overlap is resolved once rather than implemented twice.

This is what a connected regulation model buys you. A posture you can defend in front of a regulator, a board, or a plaintiff, where the dashboard agrees with the underlying data because it is built from it, and where the next regulation is configuration, not a rebuild.

Your data governance program does not cover the EU Data Act because it was never built to. The fix is not a parallel program. It is a model where every regulation that touches your data is mapped to the same profile, with overlaps resolved and every obligation traced to source text.

Map your Data Act exposure alongside GDPR and 245+ regulations in one organizational profile at aegis-grc.com. Inside 60 minutes you'll see your exposure mapped to the obligations that actually apply to you. No call required.

FAQ

Is the EU Data Act a privacy regulation like the GDPR?

No. The Data Act (Regulation (EU) 2023/2854) covers both personal and non-personal data and governs data access, B2B data sharing, and switching between data processing services. Article 1 states it is without prejudice to data protection law and that, in the event of conflict, the GDPR prevails. It complements the GDPR's Article 15 and 20 rights rather than replacing them, so a GDPR-only program does not cover it.

Does the EU Data Act apply to my company if I don't make connected products?

Possibly. Chapter II applies to manufacturers of connected products and providers of related services, but Chapter IV's unfair-contract-terms rules (Article 13) apply to data-related contracts between enterprises generally, and Chapter VI's switching rules (Articles 23 to 30) apply to providers of data processing services. If you sell cloud services or sign B2B data-sharing contracts, you are likely in scope.

When does the EU Data Act take effect?

Under Article 50, the Regulation applies from 12 September 2025. The Article 3(1) access-by-design obligation applies to connected products placed on the market after 12 September 2026. The Article 29 prohibition on cloud switching charges takes effect 12 January 2027. Chapter IV reaches contracts concluded on or before 12 September 2025 from 12 September 2027 where they are indefinite or due to expire at least ten years from 11 January 2024.

What are the cloud-switching obligations under the EU Data Act?

Article 23 requires data processing service providers to remove obstacles to switching. Article 25 mandates a maximum 30-calendar-day transitional period after a notice period of no more than two months, plus a data-retrieval period of at least 30 days. Article 29 prohibits switching charges from 12 January 2027. Article 30 requires free open interfaces for portability and interoperability.