Most data governance programs were built around one regulation: GDPR. They classify personal data, manage consent, answer subject access requests and document processing. The EU Data Act, Regulation (EU) 2023/2854, asks a different question. It is less concerned with protecting data than with making it flow: from connected products to their users, from users to third parties they choose, from businesses to public bodies in emergencies, and from one cloud provider to another. For many organizations, that means governance has to answer questions it has never been asked, such as “what data does this product generate, in what format, and how fast can we hand it to a competitor if the customer asks?”
The Act has applied for most purposes since September 12, 2025. Two milestones make late 2026 a critical moment: the access-by-design obligation for connected products placed on the market from September 12, 2026, and the end of cloud switching charges on January 12, 2027. This playbook explains what the obligations mean for data governance and how to build the capabilities to meet them. It is a practical guide, not legal advice; confirm your specific position with counsel.
The Timeline That Matters in 2026–2027
Based on law firm analyses from McCann FitzGerald and Bird & Bird, the key dates are:
- September 12, 2025: general application, including user data access rights, data sharing obligations, B2B unfair terms rules for new contracts, and cloud switching rules.
- September 12, 2026: Article 3(1) access by design applies to connected products and related services placed on the market after this date.
- January 12, 2027: providers of data processing services may no longer charge for switching under Article 29. Until then, switching charges must be limited to costs actually incurred.
- September 12, 2027: unfair terms rules extend to certain older contracts, including those of indefinite duration or expiring at least ten years from January 11, 2024.
Alongside these dates sits the European Commission’s Digital Omnibus package, proposed in November 2025, which would amend the Data Act and fold in rules from the Data Governance Act and related instruments. As of a Greenberg Traurig analysis in July 2026, the Council’s compromise text was still under negotiation, and McCann FitzGerald reports that the Irish Council Presidency aims to reach agreement with the European Parliament by the end of 2026. Governance teams should plan against the law as it stands while tracking the amendments, which mostly adjust edges rather than remove core duties.
Why the Data Act Is a Data Governance Problem
Legal teams can interpret the Act, but they cannot comply with it alone. Almost every obligation depends on capabilities that sit with data and platform teams:
- Knowing what data exists. You cannot make product data available if you do not have an inventory of what each product and related service generates, where it is stored and what metadata explains it.
- Classifying data correctly. The Act covers raw and pre-processed data readily available to the data holder, but excludes derived or inferred data, and gives special treatment to trade secrets. Those distinctions must be recorded per data element.
- Delivering data in usable formats. Access must be easy, secure, free of charge to the user, and structured and machine-readable. That is an interface and data product problem.
- Controlling onward sharing. When users direct data to third parties, you need consent records, access controls, and contractual and technical protections for trade secrets.
- Supporting portability out of cloud services. For cloud providers and their customers, switching depends on documented data structures, export formats and tested procedures.
In other words, the Data Act rewards organizations with mature metadata, cataloging, classification and data product practices, and exposes those without them.
Access by Design: What Changed on September 12, 2026
Article 3(1) requires manufacturers of connected products and providers of related services to design them so that product data, related service data and the metadata needed to interpret it are, by default, easily, securely, free of charge, and in a comprehensive, structured, commonly used and machine-readable format, and where relevant and technically feasible directly accessible to the user. Matheson’s analysis highlights several points that matter for governance:
- The obligation is forward-looking, applying to products placed on the market after September 12, 2026, so product development and release processes must include a Data Act checkpoint.
- Direct access (through an interface the user controls) is distinguished from indirect access, where users request data from the data holder, for example via a portal under Article 4.
- The “where relevant and technically feasible” qualifier gives manufacturers some discretion, but the decision and its reasoning should be documented.
- Both personal and non-personal data are in scope, so Data Act and GDPR processes must work together.
- Sellers, renters and lessors must give users pre-contractual information about the data a product generates and how to access it.
Governance Capabilities Required
- A product data inventory for each connected product line: data points generated, frequency, storage location, retention, and whether the data is raw, pre-processed or derived.
- Metadata and documentation sufficient for a user or third party to interpret the data, including units, codes and timestamps.
- Classification flags for personal data, trade secrets and derived data at the data element level.
- Access channels designed and tested: device interfaces, APIs or portals, with authentication and rate limits.
- Design review records showing how access by design was assessed for each product and why direct access was or was not provided.
Data Sharing, Trade Secrets and Contract Governance
Beyond access by design, users can ask data holders to share data with third parties of their choosing. Data holders may protect trade secrets with confidentiality measures and, in limited cases, refuse disclosure. The Digital Omnibus would make refusal more workable: the Greenberg Traurig analysis notes that the Council text removes the “exceptional circumstances” qualifier, lowers the threshold from “highly likely” to “likely” serious economic damage, and adds a ground covering high risk of unlawful use by third-country entities in jurisdictions with weaker protection.
For governance teams, this means trade secret decisions need a repeatable process rather than ad hoc judgment:
- Identify trade-secret-sensitive data elements in advance, with documented reasoning, rather than deciding under time pressure when a request arrives.
- Define standard protective measures, such as confidentiality terms, technical access controls and aggregation, that can be applied before considering refusal.
- Record each request, decision, measure applied and notification sent, because refusals must be justified and can be challenged.
- Use the Commission’s non-binding Model Contractual Terms for data access and use as a baseline for third-party agreements, and review B2B contract templates against the unfair terms rules.
Cloud Switching: Preparing for Zero Switching Charges
The switching chapter (Articles 23–31) affects both cloud providers and every organization that buys cloud services. Maples Group’s overview summarizes the mechanics: customers can initiate switching with a maximum notice period of two months; the transition must generally complete within 30 calendar days; customers get at least 30 days afterward to retrieve data; contracts must exhaustively list exportable data and digital assets; and providers must maintain an online register of data structures, formats and interoperability specifications. If the 30-day transition is technically unfeasible, the provider must explain why within 14 working days and may propose up to seven months.
From January 12, 2027, switching charges are prohibited, though standard service fees and early termination penalties remain separate. The Omnibus would add transitional exemptions for certain contracts concluded on or before September 12, 2025, including heavily customized services and non-infrastructure services provided to SMEs and small mid-caps, according to the Greenberg Traurig analysis.
What Customers Should Do Now
- Inventory critical cloud services and map which data, configurations and digital assets you would need to port.
- Review contracts for the required switching terms, exportable data lists and retrieval periods; raise gaps at renewal.
- Prefer open formats and open table formats for analytical data, so portability does not depend on a proprietary export.
- Run a switching rehearsal for at least one non-critical workload to test export formats, timing and completeness.
- Use the end of switching charges as leverage in renewal negotiations and multicloud architecture decisions.
What Providers Should Do Now
If you provide SaaS or platform services to EU customers, governance must cover the register of data structures and formats, documented export procedures, functional equivalence for IaaS, and contract templates that include the mandatory terms. Treat exportability as a product feature with its own test suite.
The Data Act turns data governance from a defensive discipline into an operational one. If you cannot describe, classify and export your data on request, you are not just inefficient; from late 2026 you may be non-compliant.
A 120-Day Data Act Governance Playbook
Days 1–30: Scope and Inventory
- Determine whether you are a manufacturer, related service provider, data holder, data recipient, cloud provider, cloud customer, or several of these.
- List connected products and related services on the EU market, and those planned for launch.
- Inventory product and service data, using existing catalogs and engineering documentation, and identify owners.
Days 31–60: Classify and Decide
- Classify data elements as raw, pre-processed or derived; personal or non-personal; trade secret or not.
- Document access-by-design decisions for new products, including direct versus indirect access.
- Define the trade secret protection process and request-handling workflow with legal.
Days 61–90: Build Channels and Controls
- Implement or harden access channels such as APIs and portals, with documentation and metadata.
- Set up request logging, consent capture for third-party sharing, and audit trails.
- Update contract templates using the Commission’s model terms and standard clauses.
Days 91–120: Test and Operationalize
- Run end-to-end tests: a user access request, a third-party sharing request, and a cloud export.
- Assign ongoing ownership in the governance operating model, with metrics such as request turnaround time.
- Add Data Act checks to product release gates and cloud procurement processes, and set a cadence for tracking Omnibus changes and national enforcement rules.
Operating Model: Roles, Tooling and Metrics
A Data Act program fails quietly when it is run as a one-off legal project. Requests arrive through sales, support and partner channels; products change with every firmware release; contracts renew on rolling schedules. Sustained compliance needs a standing operating model with clear roles.
- Data Act owner: usually within the data governance office or privacy function, accountable for policy, tracking regulatory changes and reporting to leadership.
- Product data stewards: one per product line, accountable for the data inventory, metadata and classification staying current as products evolve.
- Request desk: a defined intake for user and third-party requests, shared with or modeled on the GDPR subject access process, with service-level targets and escalation to legal for trade secret questions.
- Platform and API owners: accountable for access channels, export formats, uptime and security.
- Procurement and vendor management: accountable for switching terms and exit plans in cloud contracts.
Tooling should reuse what you already have. A data catalog can hold the product data inventory and classifications if you extend its metadata model with Data Act attributes: data category (product, related service, derived), trade secret flag, access channel and legal basis. Lineage helps identify which datasets would be affected by a request, and policy engines can enforce sharing restrictions automatically. Ticketing or workflow tools can manage request intake and evidence. The goal is that a request, a design decision or a contract review leaves an auditable trail without manual spreadsheet work.
Finally, measure the program. Useful indicators include the share of in-scope products with a complete, current data inventory; median turnaround for access and sharing requests; the number of trade secret decisions with documented reasoning; the share of critical cloud contracts with compliant switching terms; and the date of the last successful switching rehearsal. These metrics give leadership a clear picture and give regulators evidence that obligations are handled systematically.
Worked Example: An Industrial Equipment Maker
Consider a manufacturer of connected compressors sold across the EU, with a cloud analytics service that predicts maintenance needs. A new model launches in November 2026, so access by design applies to it. The governance team inventories the sensor data the compressor generates, including pressure, temperature, runtime and fault codes, and the metadata needed to interpret them, such as units, sampling intervals and fault code tables. The predictive maintenance scores produced by the analytics service are classified as derived data, outside the core access obligation, while the raw sensor readings are in scope.
Engineering adds a local data export through the maintenance interface and an authenticated API for remote access, both producing documented, machine-readable files. Fault code tables are published as reference data with version history so third-party service companies can interpret them. The firmware’s control algorithms are flagged as trade secrets, and the team documents why exposing certain high-frequency signals could reveal them, along with the confidentiality measures it will apply before considering refusal. Sales updates pre-contractual information, and a request log tracks every access and third-party sharing request. Meanwhile, IT reviews its own cloud contracts ahead of January 2027 and schedules a switching rehearsal for its analytics platform.
Conclusion
The EU Data Act is often discussed as an IoT or cloud regulation, but its real demand is for governance maturity: inventories that reflect reality, classification at the data element level, documented decisions, usable interfaces and tested export paths. With access by design now in force and switching charges ending in January 2027, late 2026 is the time to move from legal analysis to operational capability. Organizations that build these foundations will not only comply; they will be better placed for data sharing, AI and multicloud strategies that depend on the same disciplines.
How Hanoi Technology Can Help
Hanoi Technology helps organizations turn EU Data Act obligations into working governance, from product data inventories and classification to access APIs, contract-ready documentation and cloud portability tests.
Further Reading
- Data Act Developments: 2026 and Beyond – McCann FitzGerald
- The Data Act Access by Design Requirement Comes into Force – Matheson
- EU Digital Omnibus Package Proposes Amendments to Data Act – Greenberg Traurig
- The EU Data Act’s Switching Framework: A Practical Overview – Maples Group
- The EU Data Act: Where Things Stand Now – Bird & Bird