Data Act – interpretation questions and practical challenges

Data Act gives users control over the data generated by the use of network-connected products and related services. To lawfully secure the right to utilize non-personal data generated from these products and services for purposes such as product development or analytics, the data holder must establish an agreement.  

The requirement for an agreement on data use applies to data collected from 12 September 2025 onwards and applies equally to new and existing users. In addition to new customers, arrangements must also be made with existing customers to ensure the data holder's right to use data collected after the Act comes into force. Depending on the nature of the products and services and the details of their sale, delivery and use, a number of factors may pose challenges to reaching an agreement. 

The data holder has an obligation to identify the user (considering data protection requirements) to ensure that it has agreed with the correct user on the use of data generated by that specific user's device or service. Practical challenges may arise from the large volume of customers and how the data holder can ensure that a valid agreement has been concluded between the user and the data holder. In particular, connected products that do not include a user interface for identifying individual users, for example through a user profile, may pose practical challenges in terms of identifying the contractual partner. After the Data Act comes into force, information must also be maintained on which users have consented to the use of data concerning them for the data holder's own purposes. If the user has not given their consent in the agreement, the data holder may not use the data generated by that user's actions. All this places increased demands on the data holder's practices regarding the management of data masses. 

The Commission's expert working group has drawn up model contract terms to support the drafting of agreements with users. However, companies must adapt the contractual changes resulting from the Data Act to their own existing contractual structures and practices. The model contract terms cannot be recommended for use as-is. In practice, the terms and conditions for data use have been agreed upon through a variety of mechanisms. In some cases, a new data use agreement has been added to the product sales agreement package and signed separately with customers. In other cases, an existing service agreement has been modified to meet the requirements for data access and use, and the terms and conditions have been updated for all service users. Regardless of the solution model used, the data holder must always take concrete steps to ensure that users are familiar with and accept the terms and conditions relating to the data. 

The protection of trade secrets requires contractual safeguards, as the disclosure of data cannot, in principle, be refused solely on the grounds of trade secrecy. At the user's request, data from the connected device and related service, including any trade secrets it contains, must also be disclosed to a third party. This third party may also be a competitor of the data holder. In order for data to be protected as a trade secret, it must be identified in advance in a data access and use agreement and must meet the definition of a trade secret under the Trade Secrets Directive. One challenge may be to define raw and pre-processed data and metadata subject to the sharing obligation as trade secrets in accordance with the Trade Secrets Directive. On the other hand, it is open to interpretation which processing operations applied to raw data may constitute inferred or derived information that is no longer subject to the sharing obligation under the Data Act. These issues may give rise to disagreements between data holders and third parties.  

In practice, agreements between data holders and users concerning the use of and access to data should include specific terms and conditions aimed at protecting trade secrets. These concern the obligations of the user and third parties to implement technical and organisational measures to protect trade secrets. The above model contract terms provide a starting point for agreeing on these terms, but each data holder must assess and define the appropriate terms and protective measures according to their situation. Refusal to disclose data containing trade secrets requires that the data holder and the user (or the data holder and a third party) cannot agree on the content of the protective measures concerning trade secrets, or that the user or third party does not comply with the agreed protective measures. 

With regard to data processing services, challenges have arisen due to the ambiguity of the definition of data processing service, particularly in certain borderline cases and situations open to interpretation. A data processing service refers to a digital service provided to a customer that enables a shared set of configurable, scalable and flexible IT resources, which are available anywhere and can be used on demand, centralised, distributed or highly distributed IT resources that can be quickly deployed and decommissioned with minimal administrative effort or interaction with the service provider. For a service to be considered a data processing service in accordance with Data Act, it should comply with the definition in all respects.  

The last part of the definition is particularly open to interpretation, as it states that a data processing service must be able to be quickly deployed and decommissioned with minimal administrative effort or interaction with the service provider . Does this mean that the necessity of a service provider's implementation or modification project would automatically exclude the service from the scope of application? If such a measure is necessary on the part of the service provider in order to use the service, it cannot be said that 'it can be quickly enabled and disabled with minimal administrative effort or interaction with the service provider'. 

At the same time, however, the Act states that services whose main features are tailored to meet the specific needs of an individual customer are subject to only partial exemption from the obligations of the Act. This would seem to undermine the interpretation that the necessity of the implementation project would automatically exclude the service from the scope of the Act, since even minor customisation of the main features of the service does not mean that it is excluded. In any case, the preamble to the Act states that the Act is intended to apply to a wide range of data processing services, including not only the well-known IaaS, PaaS and SaaS delivery models, but also other types of service models. 

From the perspective of service providers, such ambiguity regarding the scope of application is highly problematic. If, in ambiguous situations, the requirements of the Data Act are implemented in full, this will inevitably cause administrative hassle (such as meeting contractual requirements) and often also require a significant amount of product development resources (meeting technical requirements). If it later turns out that the service was not within the scope of application, this effort and cost will have been wasted. If, as a result of the Act, mandatory contractual terms specified in the Data Act have been adopted which are considerably less favourable to the service provider, for example in terms of notice periods, returning to the old terms and conditions may be practically impossible or at least cause strong dissatisfaction among service users. 

A specific issue worth mentioning is the conflict between service termination and the revenue logic generally applicable to such services. The Data Act stipulates as a mandatory condition that services falling within its scope must be terminable by the customer with a maximum notice period of two months. This also applies to service agreements concluded before the Data Act came into force. If the company providing the service has calculated its future turnover and possibly its entire valuation on the basis of the continuous cash flow (Annual Recurring Revenue, ARR) generated by long-term contracts, the possibility of termination may cause significant difficulties, for example in obtaining additional financing. However, the negative effects of the termination option on the service provider are mitigated by the possibility of determining reasonable compensation for the premature termination of fixed-term contracts. However, the assessment of reasonable compensation remains a case-by-case matter, as there is no interpretative material available on this issue yet. 

Service providers are therefore in a difficult situation if the applicability is unclear: compliance with the Data Act is likely to lead to costs and possibly other problems, but non-compliance may mean that the company is knowingly breaking the law. One possible way to figure out a sensible way forward is to weigh up the pros and cons of different options and compare them with how likely it is that the Data Act applies. Both options should be weighed up against the characteristics of each service, current contract terms, customer base, potential reputational damage and subsequent effects. 

When processing data that is subject to the sharing obligation under the Data Act, data protection regulation must also be complied with when the data contains personal data. It is also possible that personal data and non-personal data in a data set are inextricably linked. The starting point of the Data Act is that, in the event of a conflict, the GDPR takes precedence. In order to comply with the obligations of both regulations, it is essential to identify the roles in which the company operates in relation to data in each case.  

In the Data Act, the data holder is the entity that has the right or obligation under the Data Act or other regulation to use or make available product or related service data. When processing personal data, the role of the controller is defined for individual processing operations according to which entity determines the purposes and means of processing the personal data. The data holder can be considered a concept similar to that of the controller in the GDPR. The preamble of the Data Act specifically states that processors of personal data should not be considered data holders.  

However, no clear parallels can be drawn between the roles of the Data Act and the GDPR, and the roles under the GDPR should always be assessed on a case-by-case basis. For example, ancillary services related to devices are often provided to other companies in the role of a data processor, even though the data is managed in the service provider's environments. However, according to the preamble of the Data Act, the service provider could not be the data holder for personal data processed on behalf of the controller. In this case, we may be in a situation where the Data Act would not apply to personal data, but access to the data would have to be provided based on the GDPR. However, it is possible that the service provider processes some of the personal data for its own purposes as a controller, or collects non-personal data, for example for product development purposes, in which case the service provider could be considered the data holder for such data. Furthermore, according to the Commission's FAQ document on the Data Act, a business user under the Data Act may be a controller with regard to personal data when the product/related service data contains personal data of natural persons, such as company’s employees’ personal data, but it could not be the data holder for the same data (unless the business user and the data holder agree separately on a joint controller arrangement). These different processing scenarios tend to create very complex situations in terms of the roles associated with the data. For successful determination of the roles, a company is required to carefully manage both its own and its customers' data and to understand the data structures of the organisation. 

There are still many uncertainties and unanswered questions surrounding the Data Act. Unfortunately, a certain degree of uncertainty regarding the correctness of interpretations and solutions will inevitably overshadow preparations for some time to come, until binding official guidelines on individual issues are issued. For the time being, each operator must strive to interpret and apply the Act to the best of their understanding. 

Our team of data economy  experts is ready to assist you with all your needs regarding the Data Act, including suitability assessments and contract drafting.  

This article is part of a series of articles focusing on the Data Act, which delves into individual issues  of the regulation from different perspectives and in as practical a manner as possible. Previous parts of the series: