TL;DR
The EU Data Act becomes an enforceable law on September 12, 2025. It requires sharing of data from all connected products or services. It applies to any US business that has data in its possession from connected products or services that is above a certain size threshold. Most US companies are not at all prepared for this. And many to whom it applies likely haven’t even heard of it. This article is designed to let you know the basics in time to get ready.
Introduction
The EU Data Act is a law that is almost entirely without precedent in the developed world. Whereas most of the laws related to data access—such as the CFAA, DMCA, and copyright laws—impose certain restrictions and penalties associated with accessing and using data where the data holder does not want you to access the data, the EU Data Act mandates data access for third parties that want access to data. It’s democratization of data in a way that we have never seen before.
On September 12th, 2025, the EU’s Data Act goes into effect. While the Regulation has been compared to the GDPR, its spirit is quite different: it seeks to make sure everyone has access to data to feed it into analytics or artificial-intelligence pipelines. Most SaaS vendors have never before faced a legal obligation to open an API or data feed to third parties.
Fines match the GDPR scale—up to four percent of worldwide turnover—yet many firms are still in the dark about what they must do during the final weeks before go-live. This guide sets out, in plain language, a step-by-step approach to compliance that emphasizes practicality over theory and opportunity over fear. Most importantly, this should be on your radar now, because we’re nearly two months away from mandatory data requests, and most American companies are not ready.
Why This Regulation Matters
The EU Data Act applies across all sectors, from industrial-Internet-of-things vendors that sell smart machinery to pure software companies whose “connected product” is nothing more than a smartphone app. It is also territorial. A United States company with no European office still falls in scope if even just one EU-based customer uses its service from within the European Economic Area. And it is forward-looking. The Regulation states that all data generated after September 12th must be made available on request, while older “legacy” data may remain outside scope. Regulators view these obligations as a catalyst for European digital competitiveness. For vendors, however, the Regulation is an operational and contractual challenge: it touches engineering road maps, commercial pricing, customer-success workflows, incident-response playbooks and even marketing messaging. The Regulation’s potential upside is often overlooked. Firms that comply early can advertise “Data Act-ready” status as a competitive differentiator.
Timeline and Key Milestones
The Data Act went into law last January, but it only becomes enforceable on September 12th, 2025—a twenty-month grace period designed to give companies time to redesign products and contracts. Some obligations, such as the “access-by-design” requirement in Article 3, apply to new products placed on the market after September 12th, 2026, but most day-to-day sharing duties begin on the drop-dead data this September. Member States are still writing national guidance, yet the European Commission’s own FAQs make it clear that a pan-EU approach will prevail, meaning firms cannot avoid the Regulation by routing traffic through a particular Member State.
Who Must Comply and Who Is Exempt
The Regulation contains important size-based carve-outs. Micro-enterprises (fewer than ten employees and no more than two million euro in annual turnover) and small enterprises (fewer than fifty employees and no more than ten million euro in annual turnover) are exempt from the heavy-duty obligations in Chapters II and III, provided they are not linked to, or subcontracted by, a larger group. A medium-sized enterprise (50-249 employees and ≤ €50 m turnover/≤ €43 m balance-sheet) is subject to some of the requirements immediately but not all. Because venture-funded SaaS start-ups often grow rapidly, they should treat the exemption as a deferral, not a permanent safe harbor. Even where an exemption exists, smaller vendors still benefit from the rights that the Regulation grants: they can request data from larger incumbents, invoke protections against unfair contractual clauses, and avail themselves of public-sector data in emergency scenarios.
Rights and Obligations in Plain English
At the core of the Regulation are two intertwined rights: first, a user of a connected product or related service may demand a copy of the product data and related service data that they generate; second, the user may instruct the data holder to send the same data directly to a third-party service provider of the user’s choosing. The data must be provided “without undue delay” in a commonly used, machine-readable format. Data holders can charge only their direct costs plus a reasonable margin not exceeding twenty percent. Requests from public bodies during a declared emergency must be honored immediately and without charge. The Regulation also imposes design obligations: newly marketed products must, from 2026 onward, enable direct user access, sometimes referred to as “APIs out of the box.”
What the heck is a Connected Product or Related Service?
“‘Connected product’ means an item that obtains, generates or collects data concerning its use or environment and is able to communicate product data via an electronic communications service, physical connection or on-device access, and whose primary function is not the storing, processing or transmission of data on behalf of any party other than the user.”
Think of a “connected device” under the Data Act as any physical IoT gadget that creates its own data and can pass that data on–unless it’s basically a server or content player. If your hardware meets those three tests, you’re in scope for the Regulation’s data-access and sharing regime.
Outside the IoT universe, the only data the Act truly “regulates” are (i) whatever a cloud customer stores, for the purpose of switching; and (ii) whatever a public authority demands in a duly justified exceptional-need request. All other enterprise data—web-scraped, CRM, analytic models—stays outside the Act’s mandatory-sharing net.
Understanding Product Data and Related Service Data
Product data means raw information that a connected device or software service as a direct result of user interaction: Examples include sensor streams, event logs, user-entered records and so on. Related service data is contextual information without which the raw data would be meaningless—field names, time-stamps, measurement units, conversion tables. Many SaaS databases store product and related service data side by side, which complicates compliance because certain fields might embed trade secrets. In practice, firms will need to identify the lowest granularity at which they can separate user-generated content from proprietary insight. Where commingling is unavoidable, the Regulation allows redaction or aggregation, but only if the user can still achieve the legitimate purpose that motivated the request.
Preparing Your Data Inventory
Compliance starts with visibility. Assemble a multidisciplinary team—legal, data engineering, product, customer success—and map every table, blob store and log bucket that may contain in-scope data. For each dataset, record the following: schema owner, retention policy, presence of personal data, embedded trade secrets, expected volume, and current method of extraction. A spreadsheet works for the first pass, but a data catalog tool is superior because it integrates with governance workflows. Remember that the inventory itself may contain personal data, so secure it accordingly. Once the inventory is complete, classify each dataset: eligible for disclosure as is; eligible subject to redaction; or exempt because it is pure trade secret or falls outside the Regulation. Classification drives all downstream work, from API design to contract drafting.
Creating an Access Channel
Although the Regulation does not mandate a particular protocol, an authenticated API is the obvious solution for most enterprises. Where volumes are huge—think industrial machinery emitting gigabytes per hour—consider an event bus or managed object storage with pre-signed URLs. Use OAuth 2.1 for authentication. Avoid long-lived access tokens; rotate them via refresh tokens or mutual TLS certificates. Implement granular scopes—two times the ninety-fifth-percentile of normal traffic is a commonly defensible ceiling. Record all calls in an immutable log that captures requester identity, dataset name, record count, payload hash and purpose statement. Store these logs for five years, or ten years if any downstream AI system qualifies as high-risk under the EU AI Act.
Protecting Trade Secrets and Personal Data
The Regulation insists on fair access, but it also recognizes intellectual-property and privacy constraints. If a dataset contains trade-secret-protected model coefficients, you may remove or aggregate them, provided the user still receives data that supports the documented purpose. If the dataset contains personal data, you must ensure a lawful basis under the GDPR—most often “legitimate interest” or “contractual necessity.” Where neither basis suffices, you must pseudonymize or anonymize before disclosure. Users who intend to process personal data beyond the original purpose may themselves become controllers under the GDPR, triggering their own compliance duties. Include flow-down clauses in your contracts to bind third-party recipients to equivalent GDPR standards.
Drafting a Data-Sharing Agreement
Because the Commission plans to publish model clauses but has not yet done so, vendors should craft their own interim template. A robust agreement contains: a clear definition of the data, including schema references; permitted purposes; security obligations mapped to ISO 27001, SOC 2 or similar frameworks; incident-notification timelines; confidentiality undertakings; prohibitions on onward sale or re-identification; intellectual-property license scope; termination triggers; dispute-resolution forum; and liability caps. Article 33 requires FRAND terms, so differential pricing or bespoke indemnities must rest on objective criteria. If you offer tiered service levels, document the cost basis for each tier; regulators and customers alike may request evidence.
Calculating Reasonable Compensation
Direct costs usually fall into three buckets. First, labor: engineer hours to set up access, monitor usage and handle support tickets. Second, infrastructure: incremental cloud-egress charges, storage replication, and compute cycles for data transformation. Third, overhead allocations: security tooling, logging, audit reviews. Compute the first two buckets at actual rates; add a line item equal to up to twenty percent of the sum as your reasonable margin. Publish the formula in your commercial policy or attach it as an appendix to the Data-Sharing Agreement. Transparency deters accusations of discriminatory charging and reduces negotiation friction.
Integrating Compliance into Daily Operations
Compliance is not a one-off technical feature; it is an ongoing operational discipline. Embed a “Data Act triage queue” into your ticketing system so every access request is tagged, prioritized and routed to the correct owner. Automate alerts when a request lies unanswered for more than seven days. Hold quarterly reviews where legal and engineering jointly examine the disclosure logs and adjust rate-limits or fee models. Include Data Act readiness in your vendor-security questionnaires so that third-party libraries and subcontractors do not become blind spots. Finally, align your incident-response plan: if a data breach involves information disclosed under the Data Act, you may have overlapping notification deadlines under both the Data Act and the GDPR.
Relationship to Web-Scraping Disputes
Before the Data Act, many users resorted to web-scraping to obtain data that was commercially or operationally valuable. Platforms responded with cease-and-desist letters citing the Computer Fraud and Abuse Act, state computer-access statutes, copyright laws, or trespass-to-chattels. The Data Act changes the calculus. A business user who has a legal right to an API feed can argue that scraping restrictions are unreasonable, possibly anti-competitive. Likewise, regulators investigating a platform for refusal to deal will examine whether the platform honored Data Act requests. Vendors should therefore harmonize their anti-scraping policies with their Data Act processes, ensuring that a request denied under one framework is not simultaneously mandated under another.
A Short Illustrative Scenario
Imagine a Berlin-based logistics company that uses an American route-optimization SaaS tool. The tool logs every route, driver, time-stamp and fuel metric. The logistics company wants to feed that data into its in-house carbon-emissions dashboard, which is built by a third-party software consultancy. On 15 September 2025 the logistics company emails the SaaS vendor, citing the Data Act and requesting an automated nightly feed delivered directly into the consultancy’s cloud account. Under the Regulation, the SaaS vendor must first confirm the consultancy’s designation in writing, then provide the data without undue delay. The vendor may charge only the cost of preparing and hosting the feed plus up to twenty percent margin. It may not insist that the logistics company upgrade to a higher subscription tier or sign a multi-year exclusivity clause. The vendor can redact proprietary optimization parameters so long as the raw routing data remains useful for emissions calculations. If the vendor refuses, the logistics company can lodge a complaint with its national data-protection authority and potentially seek an injunction for unfair contract terms.
Risks of Non-Compliance
Financial penalties headline the risk register, but the practical dangers are broader. Contract disputes may trigger injunctions that freeze product launches. Reputational damage can deter enterprise procurement teams already anxious about supply-chain stability. Private plaintiffs can weave Data Act violations into broader antitrust or unfair-competition claims, especially if they suspect a dominant platform of favoring its own analytics offering. Finally, the inevitable post-implementation guidance from EU regulators will be more lenient toward firms that show good-faith efforts than toward laggards.
Opportunities Hidden in Compliance
Compliance work can yield strategic benefits. First, exposing a well-documented API creates upsell opportunities: premium throughput, historical back-fills, enriched analytics layers and bespoke service-level agreements. Second, the firm’s own engineers gain a cleaner, better-documented data architecture, reducing technical debt. Third, participation in a fair data ecosystem may unlock consortium deals—joint research, cross-licensing or co-marketing—that were legally impossible when data was siloed. Many cloud providers already advertise “Data Act support” toolkits, and early adopters enjoy media visibility that pure marketing dollars could never buy.
Conclusion and Call to Action
The EU Data Act rewrites the rules of industrial and operational data across the continent. For SaaS and API providers, the next few months are a decisive window. By mapping your datasets, building secure access channels, drafting FRAND-compliant contracts and integrating Data Act workflows into daily operations, you will not only avoid penalties but also win customer trust and perhaps open new revenue streams. If you would like personalized assistance—including a tailored Data-Sharing Agreement and a readiness workshop—please feel free to get in touch. The sooner you act, the more likely you are to turn regulatory obligation into strategic advantage.