The EU Data Act is a fundamental reset of how companies design, deploy, and monetise connected products and digital services. While the GDPR focused on protecting personal data, the Data Act is about controlling access to all product and service data who can use it, how it can be shared, and under what terms. It turns what was once considered proprietary operational data into a regulated asset that users and their chosen third parties must be able to access directly.
This shift has profound implications. For manufacturers, it means that connected products from cars and medical devices to industrial equipment and household appliances must be designed so that users can retrieve raw product data in usable formats, often in real time. For service providers, it means that related apps and platforms will need to support seamless data portability and avoid lock-in. For cloud providers, the Act makes switching obligations legally binding: customers must be able to exit services predictably, at cost-only until 2027 and free of charge thereafter.
This article explains the scope of the Data Act, what data must be made available, how cloud switching works, and what it all means for both EU and US businesses. It concludes with a practical compliance roadmap tailored for product, legal, and engineering teams preparing for the September 2025 start date.
This article was written by Mourad Seghir ([email protected]) and Lorena Velo ([email protected]). Mourad & Lorena are consultants with RSM Netherlands Business Consulting, focusing on technology and business strategy.
Who is affected
At first glance, the Data Act may look like a routine extension of Europe’s regulatory playbook on data protection. But its focus is far broader than the GDPR’s emphasis on personal data privacy.
- Connected products: Physical items that obtain/generate data about their use or environment and can communicate it (wearables, vehicles, appliances, industrial equipment, smartphones). If these products are placed on the EU market, users obtain rights to the data they generate even when the product is used outside the EU.
- Related services: Digital services (other than mere connectivity or power) that are connected to the product that without them, they are unable to perform one or more functions, and that involve two-way data exchange (e.g., the app that controls the machine).
- Data processing services: IaaS, PaaS, and SaaS are subject to the switching and interoperability chapter, with IaaS bearing a “functional equivalence” duty on exit and PaaS/SaaS required to provide open interfaces, exportable formats, and compatibility with repository-listed standards.
What data must be made available?
The Act is focused on “readily available” product and related-service data that the data holder has or can obtain without disproportionate effort, together with the metadata necessary to interpret it. Think raw or pre-processed signals such as temperature, speed, battery level, status flags and timestamps, not your value-added analytics or inferences. The format must be comprehensive, structured, commonly used and machine-readable (examples include XML, JSON and CSV); quality must match what the holder uses internally; and timeliness is “without undue delay,” with real-time where relevant and technically feasible. Access should be easy and secure, with automation and self-service wherever possible. Where personal data is involved, GDPR rules apply in parallel: if a user’s request implicates personal data, the processing must have an appropriate GDPR basis. DPAs remain competent for personal-data questions.
Architecture matters. If your design prevents external storage or transmission of such data, it isn’t “readily available.” If at any point raw or pre-processed data are (or can be) stored or transmitted, even briefly, proportionate access paths should exist.
Topic | What you must do | Conditions & limits | Practical guidance |
User access to device data | Provide the user with the product/related-service data without undue delay in a structured, commonly used, machine-readable format, including the metadata needed to interpret it. | Delivery should be timely and, where relevant and technically feasible, real-time. You should ensure the path is easy and secure. | Decide per product whether access is direct (no data-holder involvement) or indirect (via the data holder) and document the choice. |
User-mandated transfer to a third party | On the user’s instruction, transmit the same data to a third party on fair, reasonable and non-discriminatory terms with appropriate security. | The mandatory transmission duty covers recipients established in the EU; sending to non-EU recipients is permitted but not legally required. | Keep recipient verification proportionate to the risk and avoid collecting more information than is necessary to execute the transfer securely. |
Gatekeeper limitation | Exclude DMA “gatekeepers” as recipients under the mandatory Article 4/5 channel. | The prohibition does not stop you from entering into voluntary, separate commercial arrangements outside the mandatory channel. | If a customer nominates a gatekeeper, offer an alternative route (e.g., export for onward use or a separate commercial agreement). |
Trade-secret protection (“handbrake”) | Protect trade secrets by applying confidentiality safeguards before refusing or restricting disclosure. | Refusal or suspension must be assessed case by case and justified by a high likelihood of serious economic damage despite safeguards. | Record the analysis, the safeguards you considered, the reason for refusal or restriction, and any notifications provided to the user. |
Legacy fleets and unidentified users | Continue using data from legacy products if, after reasonable efforts, the actual user cannot be identified. | Once the user becomes known (for example, after an access request), continued use should be placed on a contractual footing with that user. | Build a pragmatic process to identify users over time and trigger a contract update when identity is confirmed. |
Cloud switching and interoperability – ensuring no lock-in by design
- Switching has a predictable structure. The notice period starts when the customer tells the provider they want to switch and can be up to two months.
- The transition period then starts and is 30 calendar days by default, during which the provider cooperates to complete the switch; the customer may replace the 30 days with a longer period.
- Providers can extend up to seven months only if, within 14 days during the notice period, they can prove that 30 days would be technically unfeasible.
- After 12 January 2027, there are no switching or egress charges; until then, charges must be cost-only. The narrow exception is continuous, in-parallel multi-cloud use, where ongoing egress costs can still be billed.
Third-country government access
Article 32 addresses a narrow class of international data flows: it aims to prevent unlawful access to or transfer of EU-held non-personal data by non-EU public authorities. It does not regulate private B2B transfers across borders. Providers should verify lawfulness (for example, an MLAT), ensure proportionality and judicial review where applicable, and implement measures such as encryption, audits, adherence to security certification schemes, and updated corporate policies. National MLAT bodies or the Member State data coordinator can be consulted in difficult cases.
Obligations hinge on EU market presence, not company nationality. Place a connected product on the EU market or offer covered data-processing services used in the EU, and the Act applies. What everyone must do:
- Build user-access and share-on-request paths for in-scope device data; protect trade secrets and safety.
- Honour cloud switching: publish formats/interfaces, support notice and transition, and align fees with the statutory phase-out.
- Keep GDPR-first when personal data is involved.
US companies typically feel more friction for US-centric cloud stacks, the pinch points are Article 32 conflicts and exit economics key management, MLAT workflows, notifications, and the shift from egress-heavy pricing to cost-only now and zero charges by early 2027. For EU manufacturers with complex distribution chains, the work lies in user identification and access paths across owners, lessees, renters and second-hand markets, and in aligning sector-specific safety/type-approval regimes with Data Act duties.
Implementation guidance
Step | Objective | Action points | Key dates / notes |
1. Scope & roles map | Know where you’re in scope and who owns what | List all connected products, related services, and cloud used by EU customers. Mark roles per item (data holder, cloud provider, cloud customer). Capture resale/lease flows and define who the “user” is over time. | Effective from 12 Sep 2025. This anchors every downstream control and contract. |
2. Data catalogue (right level) | Separate sharable signals from value-add analytics | Inventory readily available raw/pre-processed signals + needed metadata; distinguish derived/inferred outputs. Map where data sits (edge vs backend) and whether it’s externally retrievable. | Mandatory device-data sharing targets data generated on/after 12 Sep 2025. Architecture drives “readily available.” |
3. Access model & formats | Decide how users actually get their data | Choose direct (no holder in the loop) or indirect access per product. Provide data without undue delay, in comprehensive, structured, commonly used, machine-readable formats, at the same quality you use internally; real-time where relevant/feasible. | Started 12 Sep 2025. Keep paths easy and secure; automate via APIs/portals where possible. |
4. Third-party transfer | Enable “send my data where I say” safely | Build an end-to-end flow to transmit the same data to a third party on FRAND terms. Verify recipients proportionately. Exclude DMA gatekeepers from the mandatory channel. | Legal duty to transmit covers EU-established recipients; non-EU recipients are optional (your choice). |
5. Trade-secret & safety handbrake | Protect IP/safety without over-blocking | Define refusal/suspension threshold (high likelihood of serious economic damage or safety risk). Apply safeguards first (NDAs, secure rooms/environments). Document decisions and user notices; train teams. | Use case-by-case, evidence-based. Prefer safeguards before refusal. |
6. Cloud switching mechanics | Make exit feasible in contracts and ops | Contract notice ≤ 2 months. Plan transition = 30 days by default (customer can set longer). Provider may extend up to 7 months only if 30 days is technically unfeasible and proof is given within 14 days during the notice period. Keep services running during transition. | Fees: cost-only now → zero from 12 Jan 2027 (narrow parallel-use egress exception). Dry-run a switch. |
7. Interoperability & assets | Avoid format lock-in and meet listed specs | Maintain inventory of exportable data, images/configs, and interfaces. Track the EU interoperability repository; start a 12-month internal timer for each listed standard/spec and plan upgrades. | Duties differ by layer: IaaS → functional equivalence; PaaS/SaaS → open interfaces + compatibility. |
8. Third-country request playbook (Art. 32) | Handle non-EU government orders lawfully | Verify: treaty/MLAT, specificity, proportionality, judicial review, EU interests. Implement encryption (customer-controlled keys where feasible), audits/certifications, and notification protocols. Identify national contact/data coordinator. | Art. 32 covers non-personal data and non-EU public-authority access only. Follow secrecy exceptions. |
9. GDPR lane-lines | Keep personal-data compliance clean | When personal data is involved, apply GDPR legal bases and data-subject rights; coordinate with DPAs. Limit what you share to what’s necessary to show compliance. | Data Act doesn’t create a new legal basis for PD processing—GDPR rules prevail. |
Forward thinking
Product and engineering teams should design compliance by setting clear data boundaries: share only raw or pre-processed data signals and relevant metadata but avoid disclosing proprietary inferences or machine learning outputs. In other words, think in terms of providing “sensor truth plus context” rather than value-added analytics.
For edge device architectures, if data is never stored or transmitted externally, sharing rules are not triggered; however, if external flows exist, proportionate access options such as dual data flows, secure buffers, and short retention periods should be built in. On cloud exit, providers must be prepared to support customer offboarding with notice periods of up to two months and a default transition period of 30 days, which can be extended at the customer’s request. Providers may only extend transitions up to seven months if they can demonstrate technical infeasibility, making it essential to begin mapping formats and automating export processes now. Finally, interoperability is a moving target: the EU will maintain a central repository of standards and specifications, and once a relevant standard is listed, organisations will have one year to ensure compatibility. Continuous monitoring and proactive alignment are therefore critical for ongoing compliance.
RSM is a thought leader in the field of Strategy and Digital Law consulting. We provide frequent insights through training and the sharing of thought leadership, based on our detailed knowledge of industry developments and practical applications gained from working with our customers. To discuss a secure AI roadmap tailored to your environment, please contact one of our consultants.