Your high-level overview of EU Data Act compliance and regulatory requirements
Essential obligations for data holders and connected product manufacturers
| Requirement | Required Response | Negotiable Aspects | Examples & Implementation Guidance |
|---|---|---|---|
|
Pre-Contract Information Requirements Article 3(2), (3) |
Before sale/lease/rental contract conclusion, provide clear information about: 1) data types, formats, and volumes, 2) real-time capability, 3) storage location and duration, 4) access methods/conditions |
|
Example 1: Before contract signing for industrial equipment, we must provide comprehensive documentation detailing sensor data types, volumes, and access methods.
Example 2: Prior to cloud service contract, we must explain what data will be generated, stored, and how the customer can access it.
Implementation: Create standardized data sheets for each product/service. Include data dictionaries and sample datasets. Proactively provide updates when data capabilities change. Consider implementing automated data cataloging systems.
|
|
Access to Generated Data Article 4(1) |
Must provide user access to their Product Data free of charge, easily, securely, in a comprehensive, structured, commonly used, and machine-readable format and where relevant, directly and in real-time |
|
Example 1: Consumer using our MRI scanner must be able to access operational Product Data in standard format.
Example 2: Factory owner using our production equipment must be able to access Product Data.
Implementation: Set up secure API or customer portal with robust authentication. Ensure metadata is included to make data interpretable. Where technically feasible, provide real-time access. Implement proper error handling and rate limiting for APIs.
|
|
Data Sharing with Third Parties Article 5(1) |
Must allow User to share their data with third parties of their choice, providing data in same quality available to Data Holder, free of charge to user |
|
Example 1: Manufacturing customer wants to share equipment data with third-party Data Recipient for predictive maintenance.
Example 2: Energy company wants to share our grid equipment data with analytics firm for optimization.
Implementation: Create secure third-party sharing mechanism with OAuth 2.0 or similar authentication. Document API comprehensively for third parties. Cannot refuse sharing if third party provides adequate confidentiality guarantees, unless data would be used to develop a competing product. Implement audit logging for all data sharing activities.
|
|
Trade Secret Protection Article 4(6,7), 5(9,10) |
Must protect Trade Secret when sharing data, agreeing on necessary technical/organizational measures with user/third party before disclosure |
|
Example 1: Our industrial equipment contains algorithmic Trade Secret visible in operational data outputs.
Example 2: Our financial software contains proprietary risk models visible in data outputs.
Implementation: Systematically identify all trade secrets in data flows using classification tools. Document necessary protective measures including encryption, access controls, and NDAs. Can refuse access in exceptional cases where disclosure would cause severe economic harm despite protections, with proper notification to competent authority. Maintain trade secret register and protection evidence.
|
|
Unfair Contract Terms Article 13 |
Contractual terms concerning data access and use, liability, and remedies for breach or termination of data-related obligations that are unilaterally imposed by one enterprise on another enterprise are not binding if the terms are 'unfair'.
Fairness Assessment A. General Unfairness Test A contractual term is unfair if it has been unilaterally imposed and its nature grossly deviates from good commercial practice in data access and use, or is contrary to good faith and fair dealing. B. Terms Always Considered Unfair (Article 13(4)) 1. Terms that exclude or limit liability for intentional acts or gross negligence 2. Terms that exclude remedies for non-performance or breach 3. Terms giving exclusive interpretive rights to the imposing party C. Terms Presumed Unfair (Article 13(5)) 1. Inappropriately limiting remedies or extending liability 2. Allowing access to other party's data detrimentally 3. Preventing other party from using their own data 4. Preventing reasonable contract termination 5. Preventing data copy access post-termination 6. Enabling unreasonably short notice termination 7. Allowing substantial price changes without cause |
|
Example 1: Terms that exclude liability for intentional acts or gross negligence are always unfair and unenforceable.
Example 2: Terms that prevent a customer from accessing data they generated during contract term are presumed unfair.
Implementation: Conduct comprehensive contract review using unfairness checklist. Document genuine negotiation of all potentially limiting terms. Avoid unilateral imposition - burden of proof lies with term supplier. Consider implementing contract fairness assessment tools and regular legal reviews. Train contract teams on unfairness indicators.
|
|
Cloud Service Switching Articles 23, 25 |
Must facilitate Switching to another provider or back to on-premises infrastructure within 30-day transition period (after notice period not exceeding two months), maintain service continuity, and eliminate barriers |
|
Example 1: Customer wants to migrate from our cloud storage to competitor's platform with full data integrity.
Example 2: Financial institution wants to migrate from our platform to on-premises solution.
Implementation: Document comprehensive offboarding processes with clear timelines. Provide data in industry-standard formats (JSON, XML, CSV). Maintain functional equivalence for IaaS services. May charge reduced switching fees until January 12, 2027, after which switching fees are prohibited (Article 29). Implement automated export tools and validation procedures. Provide migration testing environments.
|
|
Public Authority Data Requests Articles 14, 15, 17 |
Must provide data to public authorities, Commission, ECB or Union bodies in cases of exceptional need (Public Emergency or specific public interest tasks)
Exceptional Need Criteria (Article 15) 1. Public Emergency Response: Data necessary to respond to public emergency when requestor cannot obtain data through alternative means timely and effectively 2. Specific Public Interest Tasks (non-personal data only): Public body acting under legal authority for tasks explicitly provided by law, having exhausted all other means including market purchases SME Protection: Microenterprises and small enterprises exempt from public interest tasks (scenario 2), but must comply with emergency requests |
|
Example 1: Health authority requests device data during pandemic emergency with demonstrated exceptional need.
Example 2: Statistical office requests anonymized data for official statistics, having demonstrated they exhausted market options.
Implementation: Establish verification protocols for authority requests with documented procedures. Verify legitimacy of emergency claims and exceptional need evidence. Document all data transfers to authorities with audit trails. For non-emergency requests, verify they've exhausted alternative sources. Implement secure data transfer mechanisms. For disputed requests, engage competent authority review process. Maintain emergency response procedures for rapid compliance.
|
|
Interoperability Requirements Article 33 |
Data space participants must meet essential requirements for Interoperability, including comprehensive data description, structure documentation, and technical access means |
|
Example 1: Our manufacturing platform must provide comprehensive API documentation for interoperability with industry data spaces.
Example 2: Our energy monitoring system must support standard protocols for data exchange.
Implementation: Document data structures using standard schemas (JSON Schema, OpenAPI). Support established interoperability standards (REST APIs, GraphQL). Provide comprehensive metadata for data interpretation including units, accuracy, and context. Enable automated data access where feasible. Implement semantic interoperability using standard ontologies. Participate in relevant data space initiatives.
|
|
International Data Access Protection Article 32 |
Must take reasonable technical, organizational and legal measures to prevent international government access to non-personal data that would contradict EU/Member State law |
|
Example 1: Cloud service storing EU customer data must implement protection against unauthorized foreign government access requests.
Example 2: Connected product data transmitted internationally must be protected against unlawful government interception.
Implementation: Implement end-to-end encryption and robust access controls. Document all international data flows with risk assessments. Establish protocols for responding to foreign government demands including legal challenge procedures. Notify customers when legally permitted about government requests. Consider data localization strategies. Implement data sovereignty controls and monitoring systems. Train staff on international data protection requirements.
|
Official definitions of key terms and concepts from the regulation
| Term | Definition Source | Definition |
|---|---|---|
| Data | Article 2(1) | Any digital representation of acts, facts or information and any compilation of such acts, facts or information, including in the form of sound, visual or audio-visual recording |
| Personal Data | Article 4(1) GDPR | Any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person |
| Connected Product | Article 2(5) | An item that obtains, generates or collects data concerning its use or environment and that 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 |
| Related Service | Article 2(6) | A digital service, other than an electronic communications service, including software, which is connected with the product at the time of the purchase, rent or lease in such a way that its absence would prevent the connected product from performing one or more of its functions, or which is subsequently connected to the product by the manufacturer or a third party to add to, update or adapt the functions of the connected product |
| User | Article 2(12) | A natural or legal person that owns a connected product or to whom temporary rights to use that connected product have been contractually transferred, or that receives related services |
| Data Holder | Article 2(13) | A natural or legal person that has the right or obligation, in accordance with this Regulation, applicable Union law or national legislation adopted in accordance with Union law, to use and make available data, including, where contractually agreed, product data or related service data which it has retrieved or generated during the provision of a related service |
| Data Recipient | Article 2(14) | A natural or legal person, acting for purposes which are related to that person's trade, business, craft or profession, other than the user of a connected product or related service, to whom the data holder makes data available, including a third party following a request by the user to the data holder or in accordance with a legal obligation under Union law or national legislation adopted in accordance with Union law |
| Product Data | Article 2(15) | Data generated by the use of a connected product that the manufacturer designed to be retrievable, via an electronic communications service, physical connection or on-device access, by a user, data holder or a third party, including, where relevant, the manufacturer |
| Related Service Data | Article 2(16) | Data representing the digitisation of user actions or of events related to the connected product, recorded intentionally by the user or generated as a by-product of the user's action during the provision of a related service by the provider |
| Readily Available Data | Article 2(17) | Product data and related service data that a data holder lawfully obtains or can lawfully obtain from the connected product or related service, without disproportionate effort going beyond a simple operation |
| Trade Secret | Article 2(18) with reference to Article 2(1) of Directive (EU) 2016/943 (Note: In Germany, transposed via GeschGehG § 2(1)) | Information which meets all of the following requirements:
a) it is secret in the sense that it is not, as a body or in the precise configuration and assembly of its components, generally known among or readily accessible to persons within the circles that normally deal with the kind of information in question; b) it has commercial value because it is secret; c) it has been subject to reasonable steps under the circumstances, by the person lawfully in control of the information, to keep it secret |
| Trade Secret Holder | Article 2(19) with reference to Article 2(2) of Directive (EU) 2016/943 (GeschGehG § 2(2)) | Any natural or legal person lawfully controlling a trade secret |
| Consumer | Article 2(23) | Any natural person who is acting for purposes which are outside that person's trade, business, craft or profession |
| Enterprise | Article 2(24) | A natural or legal person that, in relation to contracts and practices covered by this Regulation, is acting for purposes which are related to that person's trade, business, craft or profession |
| Small Enterprise | Article 2(25) with reference to Article 2(2) of the Annex to Recommendation 2003/361/EC | An enterprise which employs fewer than 50 persons and whose annual turnover and/or annual balance sheet total does not exceed EUR 10 million |
| Microenterprise | Article 2(26) with reference to Article 2(3) of the Annex to Recommendation 2003/361/EC | An enterprise which employs fewer than 10 persons and whose annual turnover and/or annual balance sheet total does not exceed EUR 2 million |
| Public Sector Body | Article 2(28) | National, regional or local authorities of the Member States and bodies governed by public law of the Member States, or associations formed by one or more such authorities or one or more such bodies |
| Public Emergency | Article 2(29) | An exceptional situation, limited in time, such as a public health emergency, an emergency resulting from natural disasters, a human-induced major disaster, including a major cybersecurity incident, negatively affecting the population of the Union or the whole or part of a Member State, with a risk of serious and lasting repercussions for living conditions or economic stability, financial stability, or the substantial and immediate degradation of economic assets in the Union or the relevant Member State and which is determined or officially declared in accordance with the relevant procedures under Union or national law |
| Union Bodies | Article 2(27) | The Union bodies, offices and agencies set up by or pursuant to acts adopted on the basis of the Treaty on European Union, the TFEU or the Treaty establishing the European Atomic Energy Community |
| Customer | Article 2(30) | A natural or legal person that has entered into a contractual relationship with a provider of data processing services with the objective of using one or more data processing services |
| Virtual Assistants | Article 2(31) | Software that can process demands, tasks or questions including those based on audio, written input, gestures or motions, and that, based on those demands, tasks or questions, provides access to other services or controls the functions of connected products |
| Digital Assets | Article 2(32) | Elements in digital form, including applications, for which the customer has the right of use, independently from the contractual relationship with the data processing service it intends to switch from |
| On-premises ICT Infrastructure | Article 2(33) | ICT infrastructure and computing resources owned, rented or leased by the customer, located in the data centre of the customer itself and operated by the customer or by a third-party |
| Switching | Article 2(34) | The process involving a source provider of data processing services, a customer of a data processing service and, where relevant, a destination provider of data processing services, whereby the customer of a data processing service changes from using one data processing service to using another data processing service of the same service type, or other service, offered by a different provider of data processing services, or to an on-premises ICT infrastructure, including through extracting, transforming and uploading the data |
| Data Egress Charges | Article 2(35) | Data transfer fees charged to customers for extracting their data through the network from the ICT infrastructure of a provider of data processing services to the system of a different provider or to on-premises ICT infrastructure |
| Switching Charges | Article 2(36) | Charges, other than standard service fees or early termination penalties, imposed by a provider of data processing services on a customer for the actions mandated by this Regulation for switching to the system of a different provider or to on-premises ICT infrastructure, including data egress charges |
| Functional Equivalence | Article 2(37) | Re-establishing on the basis of the customer's exportable data and digital assets, a minimum level of functionality in the environment of a new data processing service of the same service type after the switching process, where the destination data processing service delivers a materially comparable outcome in response to the same input for shared features supplied to the customer under the contract |
| Exportable Data | Article 2(38) | For the purpose of Articles 23 to 31 and Article 35, the input and output data, including metadata, directly or indirectly generated, or cogenerated, by the customer's use of the data processing service, excluding any assets or data protected by intellectual property rights, or constituting a trade secret, of providers of data processing services or third parties |
| Smart Contract | Article 2(39) | A computer program used for the automated execution of an agreement or part thereof, using a sequence of electronic data records and ensuring their integrity and the accuracy of their chronological ordering |
| Interoperability | Article 2(40) | The ability of two or more data spaces or communication networks, systems, connected products, applications, data processing services or components to exchange and use data in order to perform their functions |
| Open Interoperability Specification | Article 2(41) | A technical specification in the field of information and communication technologies which is performance oriented towards achieving interoperability between data processing services |
| Common Specifications | Article 2(42) | A document, other than a standard, containing technical solutions providing a means to comply with certain requirements and obligations established under this Regulation |
| Harmonised Standard | Article 2(43) with reference to Article 2, point (1)(c) of Regulation (EU) No 1025/2012 | A European standard adopted on the basis of a request made by the Commission for the application of Union harmonisation legislation |
| Metadata | Article 2(2) | A structured description of the contents or the use of data facilitating the discovery or use of that data |
| Non-personal Data | Article 2(4) | Data other than personal data |
| Processing | Article 2(7) | Any operation or set of operations which is performed on data or on sets of data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination, or other means of making them available, alignment or combination, restriction, erasure or destruction |
| Data Processing Service | Article 2(8) | A digital service that is provided to a customer and that enables ubiquitous and on-demand network access to a shared pool of configurable, scalable and elastic computing resources of a centralised, distributed or highly distributed nature that can be rapidly provisioned and released with minimal management effort or service provider interaction |
| Same Service Type | Article 2(9) | A set of data processing services that share the same primary objective, data processing service model and main functionalities |
| Data Intermediation Service | Article 2(10) | Data intermediation service as defined in Article 2, point (11), of Regulation (EU) 2022/868 |
| Data Subject | Article 2(11) | Data subject as referred to in Article 4, point (1), of Regulation (EU) 2016/679 |
| Making Available on the Market | Article 2(21) | Any supply of a connected product for distribution, consumption or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge |
| Placing on the Market | Article 2(22) | The first making available of a connected product on the Union market |
| Profiling | Article 2(20) | Profiling as defined in Article 4, point (4), of Regulation (EU) 2016/679 |
Scenarios where Data Act obligations may not apply or are limited
| Exemption Scenario | Legal Basis | Application Conditions | Examples & Implementation Guidance |
|---|---|---|---|
| Micro and Small Enterprise Exemption | Article 7(1) | Applies to microenterprises/small enterprises that manufacture or design connected products or provide related services, unless they are partner/linked enterprises with non-exempt companies or are subcontractors for larger companies |
Example 1: Startup with 30 employees making smart devices is exempt from obligation to design for data access.
Example 2: Small software company with 40 employees providing industrial monitoring services is exempt.
Implementation: Verify company size (under 50 employees and annual turnover/balance sheet ≤€10M). Check for parent company relationships that might disqualify exemption. Document size status at time of product development. Exemption does not apply if working as subcontractor for larger company.
|
| Temporary Medium Enterprise Exemption | Article 7(1) | Applies to medium enterprises (under Art. 2 of Annex to Recommendation 2003/361/EC) for one year from classification as medium enterprise, and for connected products for one year after being placed on market |
Example: Company recently growing to 100 employees has one-year transition period before compliance required.
Implementation: Document growth transition dates. Track market introduction dates for products. Does not apply if company has partner/linked enterprises that aren't small or micro enterprises.
|
| Legacy Product Exemption | Article 50 | Design obligation in Article 3(1) only applies to connected products placed on market after September 12, 2026 |
Example 1: Smart factory equipment sold in 2025 isn't subject to design obligation for easy data access.
Example 2: Medical devices marketed before September 2026 aren't covered by design requirements.
Implementation: Document market release dates for all products. Maintain records of design specifications for pre-/post-compliance versions. Consider voluntary compliance for product lines spanning the cutoff date.
|
| Legacy Contract Exemption | Article 50 | Unfair contract terms provisions in Chapter IV apply to contracts concluded after September 12, 2025, and to earlier contracts only from September 12, 2027 (if indefinite or lasting until at least January 11, 2034) |
Example 1: Cloud service contract from 2024 isn't subject to unfair contract terms restrictions until 2027.
Example 2: Data licensing agreement from 2023 with 5-year term isn't covered by unfair terms provisions at all.
Implementation: Catalog existing contracts with dates and durations. Plan compliance transition for indefinite and long-term contracts. Consider early alignment for customer goodwill.
|
| Custom Cloud Service Exemption | Article 31(1) | Cloud services where most core features are tailored to specific customer needs or all components developed for single customer (and thus are not offered commercially at scale) are exempt from:
- Functional Equivalence Obligation (Article 23 lit. d) - Gradual Withdrawal of Switching Charges (Article 29) - Technical Facilitation for IaaS Providers (Article 30(1)) - Standards Compatibility Requirement (Article 30(3)) |
Example 1: Custom-built cloud environment for specific government agency doesn't require full functional equivalence.
Example 2: Bespoke data processing service developed for single customer doesn't require functional equivalence.
Implementation: Document customization specifics that qualify for exemption. Maintain evidence the service isn't offered at commercial scale. Disclose exemption clearly to customers before contracting.
|
| Test/Evaluation Service Exemption | Article 31(2) | Cloud services provided for limited time for testing/evaluation purposes, not as full versions, are exempt from switching obligations |
Example 1: 30-day free trial cloud environment is exempt from switching requirements.
Example 2: Beta test version of data processing service doesn't require full switching capabilities.
Implementation: Clearly mark test/evaluation services. Document limited nature and duration. Disclose exemption status to customers upfront.
|
| Trade Secret Exception | Article 4(6-8), 5(9-11) | May refuse/suspend data sharing if user/third party doesn't agree to necessary measures to protect trade secrets, or in exceptional cases where severe economic harm would result despite protections
(Note: Invoking the 'trade secret exemption' requires notification of the data holder to the competent authority) |
Example 1: Industrial process algorithms in manufacturing equipment data can be protected with appropriate trade secret measures.
Example 2: Can refuse access to proprietary financial models in data if disclosure would cause severe economic harm despite protections.
Implementation: Identify and document all trade secrets. Implement technical and contractual protections. For refusals, provide written justification to requestor and notify competent authority. Severe economic harm exception requires objective evidence and should be used only in exceptional cases.
|
| Security-Critical Data Exception | Article 4(2) | May contractually restrict data access if it would impact security requirements and lead to serious adverse effects on health or safety |
Example 1: Vehicle security systems data can be restricted if sharing would create security vulnerabilities.
Example 2: Medical device security parameters can be restricted if access would compromise safety.
Implementation: Document security-critical systems with clear justification. Implement alternative access to non-security-critical data. Notify relevant authority of any access refusals. Must notify competent authority when invoking this exception.
|
| Content and IP Exclusion | Recitals 15-16 | Data related to recording, transmitting, displaying content (especially IP-protected content) is excluded from scope |
Example 1: Media content displayed on smart TVs isn't subject to access requirements.
Example 2: E-books accessed through connected e-reader aren't covered by data access provisions.
Implementation: Clearly separate content data from operational/usage data. Document IP protections that apply. Provide access to non-excluded data categories.
|
| Gatekeeper Platform Exclusion | Article 5(3) | Companies designated as gatekeepers under Digital Markets Act (Regulation (EU) 2022/1925) cannot request or receive data as third parties |
Example 1: Major tech platform designated as gatekeeper cannot request data access as third party.
Example 2: User cannot be incentivized to share data with gatekeeper platform.
Implementation: Track official gatekeeper designations. Implement controls to prevent data sharing with designated gatekeepers. Document any gatekeeper relationship verification procedures.
|
Authority powers, investigation procedures, and penalty frameworks
| Enforcement Element | Legal Basis | Key Requirements | Examples & Implementation Guidance |
|---|---|---|---|
| Competent Authorities | Article 37 | Member States must designate one or more competent authorities responsible for application and enforcement of the regulation. If multiple authorities, a Data Coordinator must be designated. |
Implementation: Identify the relevant national authorities for each EU country where you operate. Document their contact information and specific competencies. Create internal escalation procedures that align with each authority's requirements.
|
| Investigation Powers | Article 37(5) | Competent authorities can request information, conduct investigations, and access relevant documentation. They can take action based on complaints or on their own initiative. |
Example: German authority might request documentation of your data sharing mechanisms following customer complaint.
Implementation: Prepare compliance documentation packages that can be quickly assembled in response to authority inquiries. Maintain detailed records of all data sharing activities.
|
| Financial Penalties | Article 40 | Member States determine sanctions that must be "effective, proportionate and dissuasive." Financial penalties can include fines and potentially periodic penalty payments. |
Example: French authority could impose substantial fines for systematically refusing data access requests without legitimate basis.
Implementation: Monitor sanction regimes in all operating jurisdictions. Consider potential financial exposure in compliance risk assessments. Some violations involving personal data could trigger GDPR-level fines.
|
| Corrective Actions | Article 37(5)(d) | Authorities can order cessation of infringements and impose corrective measures to bring operations into compliance. |
Example: Italian authority might order immediate implementation of data access mechanisms.
Implementation: Develop rapid response plans for implementing required changes. Build flexible systems that can be quickly modified to address compliance gaps.
|
| Cross-Border Cooperation | Article 37(15-16) | Authorities must cooperate across borders to handle multi-jurisdictional issues. Data coordinators facilitate this cooperation. |
Example: For cloud services across multiple EU countries, authorities coordinate enforcement actions.
Implementation: For pan-European operations, prepare for coordinated authority actions. Document which national entities of your organization are responsible for which data.
|
| Individual Complaints | Article 38 | Natural and legal persons have the right to lodge complaints with competent authorities when they believe their rights have been violated. |
Example: Manufacturing customer complains about refusal to share equipment data with third-party service provider.
Implementation: Establish clear response procedures for customer complaints. Document justification for all data access decisions. Consider internal appeal processes before authority involvement.
|
| Judicial Remedies | Article 39 | Anyone affected has the right to effective judicial remedy against decisions of competent authorities or when authorities fail to act on complaints. |
Example: Customer challenges authority decision regarding trade secret exemption claim.
Implementation: Understand court procedures in each jurisdiction. Prepare for potential litigation by maintaining comprehensive compliance documentation.
|
| Representative Requirements | Article 37(11-13) | Non-EU entities providing connected products or services in the EU must designate an EU representative. |
Example: US manufacturer of connected industrial equipment must designate EU representative for Data Act compliance matters.
Implementation: Formally designate and document EU representatives. Ensure representatives have necessary information and authority to respond to competent authorities.
|
Mechanisms for resolving conflicts and disagreements under the Data Act
| Dispute Type | Resolution Mechanism | Process Requirements | Examples & Implementation Guidance |
|---|---|---|---|
| Data Access Disputes Article 10 |
Certified Dispute Resolution Bodies | Specialized bodies certified by Member States to resolve disputes about data access, conditions or compensation. Shall decide within 90 days. |
Example 1: Manufacturing company disputes fair compensation for providing specialized data to competitor.
Implementation: Identify certified bodies in relevant jurisdictions before disputes arise. Develop standard position papers for common dispute types. Decisions are binding only if parties agree in advance.
|
| Trade Secret Disputes Article 4(9), 5(12) |
Competent Authority Review | When data holder refuses access based on trade secret concerns, user/third party can file complaint with competent authority for urgent review. |
Example 1: Chemical process data withheld due to claimed trade secret status.
Implementation: Document trade secret identification and protection measures. Prepare detailed justifications for any refusal based on trade secrets. Develop expedited response process for authority inquiries. Must notify authority when refusing data access based on trade secrets.
|
| Contract Term Fairness Article 13 |
Court Proceedings | Courts determine whether unilaterally imposed contractual terms are unfair and therefore non-binding. |
Example 1: Cloud provider's terms limiting data portability challenged as unfair.
Implementation: Review all contracts for potentially unfair terms. Document negotiation process for key terms to demonstrate they weren't unilaterally imposed. Maintain evidence of industry standard practices to demonstrate terms aren't deviating from good commercial practice.
|
| Cloud Switching Disputes Articles 23-30 |
Technical Expert Resolution | Technical disagreements about switching feasibility may require expert assessment regarding technical feasibility, transition periods, and reasonable charges. |
Example 1: Dispute over technical feasibility of 30-day migration timeline.
Implementation: Document technical constraints with objective evidence. Prepare alternative solutions that demonstrate good faith. Maintain detailed records of all switching support offered. May need to justify extended transition periods with technical documentation.
|
| Compensation Disputes Article 9 |
Competent Authority Review | Disagreements about appropriate compensation for data provision can be reviewed by competent authorities. |
Example: Small enterprise challenges excessive compensation demanded by Data Holder.
Implementation: Document cost basis for all compensation requested. For data provided to small enterprises and microenterprises, ensure charges don't exceed costs. Maintain transparent pricing structures that demonstrate non-discrimination.
|
| Public Authority Data Requests Article 18(5) |
Competent Authority Review | When either a public authority challenges a data holder's refusal to provide requested data, or a data holder challenges the legitimacy of a data request, and the matter cannot be resolved through request modification, the dispute must be referred to the competent authority in the Member State where the data holder is established for resolution. |
Example: Cloud provider challenges purported emergency need for customer data.
Implementation: Verify legitimacy of all public authority requests. Document assessment of claimed exceptional need. Establish clear processes for handling cross-border authority requests.
|
| Multi-Jurisdictional Disputes Article 39 |
Judicial Proceedings | Complex disputes involving parties in multiple jurisdictions may require court resolution. |
Example: Connected Product vehicle manufacturer in Germany disputes with service provider in France and customer in Italy.
Implementation: Consider jurisdiction clauses in contracts. Document which national law applies to different aspects of service. Prepare for potentially complex legal proceedings.
|
| Informal Resolution | Direct Negotiation | Before formal mechanisms, parties can negotiate directly to resolve disputes. |
Example: Manufacturing company and third-party service provider negotiate acceptable terms for Related Service Data access.
Implementation: Create escalation procedures that encourage negotiated solutions. Document all negotiation attempts before invoking formal mechanisms. Consider establishing standardized mediation procedures.
|
How the Data Act relates to GDPR, DMA, and other EU regulations
| Regulation | Relationship with Data Act | Key Considerations | Examples & Implementation Guidance |
|---|---|---|---|
| GDPR (2016/679) Article 1(5) |
Complementary but subordinate | Data Act supplements but doesn't override GDPR. Any processing of personal data must comply with GDPR, including having a valid legal basis. |
Example: Vehicle telematics data containing driver behavior requires GDPR compliance alongside Data Act obligations.
Implementation: Map personal data flows within connected products. Ensure data access mechanisms include appropriate GDPR safeguards. Design data sharing with privacy by design principles. Personal data can only be shared if GDPR requirements are met.
|
| Digital Markets Act (2022/1925) Article 5(3) |
Restriction | Companies designated as "gatekeepers" under DMA cannot request or receive data under the Data Act's third-party data sharing provisions. |
Example: Major technology platform designated as gatekeeper cannot receive industrial equipment data as third party.
Implementation: Track official gatekeeper designations. Implement verification measures before sharing data with potential gatekeepers. Document procedures to prevent data flows to designated gatekeepers.
|
| ePrivacy Directive (2002/58/EC) Note: Transposed in Germany under UWG and TDDDG Article 1(5), Recital 36 |
Complementary prerequisite | Access to data stored on end devices requires consent per ePrivacy rules, unless necessary for explicitly requested service. |
Example: Connected home device requires proper consent before sharing usage data.
Implementation: Ensure connected products obtain and document required consent. Design connected products with privacy-friendly defaults. Consider implementing consent management systems that work across product ecosystems.
|
| Free Flow of Non-Personal Data Regulation (2018/1807) Article 1(7) |
Complementary | Data Act builds on and enhances data portability aspects introduced in this regulation, particularly for cloud services. |
Example: Cloud switching provisions extend beyond self-regulatory codes promoted in 2018 regulation.
Implementation: Update cloud exit strategies to align with enhanced requirements. Document how your solutions go beyond the self-regulatory framework. Ensure proper data portability for both personal and non-personal data.
|
| Data Governance Act (2022/868) Recital 70 |
Complementary, but separate scope | DGA focuses on data intermediaries and data altruism; Data Act establishes who can access and use data in specific contexts. |
Example: Data sharing through certified data intermediary must comply with both regulations.
Implementation: When using data intermediaries, ensure they meet DGA requirements. Align data sharing frameworks to work with certified intermediaries. Consider how data spaces developed under DGA connect with your data sharing mechanisms.
|
| Sector-Specific Regulations Article 44 |
Priority for Specifics | Sector-specific regulations (e.g., automotive, medical, energy) may impose additional or more specific requirements that take precedence. |
Example: Medical device data sharing must comply with both Data Act and medical device regulations.
Implementation: Create compliance matrices showing intersection of horizontal (Data Act) and vertical (sector-specific) requirements. Document where sector rules prevail. Design compliance frameworks that address the most restrictive applicable requirements.
|
| Trade Secrets Directive (2016/943) Article 4(6-8), 5(9-11), Recital 31 |
Balance | Data Act balances data access rights with protection of trade secrets, allowing refusal under specific conditions. |
Example: Manufacturing process data containing proprietary algorithms must be protected while providing necessary operational data.
Implementation: Document trade secret identification procedures. Implement technical measures to protect confidential aspects while sharing required data. Maintain records of third-party confidentiality agreements.
|