Data Act: Pre-contractual information obligations

What is the purpose of the new information obligations?

The Data Act is intended to make access to and use of data fairer. Its central provisions have largely applied directly since 12 September 2025. For companies, this is therefore no longer a future issue, but a concrete implementation task.

Behind this lies a simple problem that is highly relevant for many business models: users who buy, rent or lease a connected product, or use a related digital service, often do not know exactly which data are generated, where they are stored, who can access them and how they may later be used or shared.

The Data Act aims to reduce this information asymmetry. Users are to be informed before concluding a contract about the data-related consequences of their decision. This is therefore not only about rights that may become relevant at some point after purchase or during use. Transparency must already exist at the moment when someone decides for or against a product, a service or a provider.

For companies, this means that data-related information no longer belongs only in technical documentation, privacy notices or internal product documents. It must be prepared in such a way that it is clear, understandable and practically usable before the contract is concluded.

Who is affected by the pre-contractual information obligations?

The obligations primarily affect companies that offer connected products, related services or data processing services. Depending on the specific constellation, different actors may be subject to the obligations.

For connected products, the relevant actors may include in particular:

• sellers,
• rental providers,
• lessors.

For related services, the relevant addressee is the provider of the respective service. This refers to digital services that are functionally connected to a connected product and without which certain product functions would often not be usable, or would only be usable to a limited extent.

For data processing services, transparency obligations primarily affect providers of such services. This concerns, in particular, information on switching providers, switching procedures, potential costs and certain framework conditions of data processing.

One point is important in practice: the Data Act is not only relevant for classic consumer products. B2B constellations, industrial products, platforms, cloud-based services and complex technical ecosystems may also be affected. The decisive question is whether data are generated, used or made accessible in connection with a connected product, a related service or a data processing service.

The relevant factor is not solely where a provider is established. What may matter instead is whether there is a relevant connection to the EU market, in particular through users or data recipients in the Union.

Which information must be provided for connected products?

For connected products, the Data Act requires information to be provided before contract conclusion that gives users a realistic picture of the data generated. It is not sufficient to state in general terms that “data are processed”. The information must make clear which categories of data are concerned and how they are handled.

At the same time, one point is important: information under the Data Act does not replace privacy notices under the GDPR. Where personal data are involved, both regulatory frameworks must be considered together.

Typically, the information should cover:

• Type of data: What data can the product generate?

• Format of the data: In what form are the data available?

• Scope or volume: What approximate data volumes are to be expected?

• Mode of generation: Are data generated continuously, event-based or in real time?

• Storage location: Are data stored locally on the device or remotely?

• Retention period: How long are the data stored?

• Access, retrieval and erasure: Through which technical means can users access, retrieve or delete the data?

• Terms of use and quality of service: Under which conditions is data access practically available?

Examples of relevant data categories may include usage data, status and operating data, diagnostic and error data, configuration data, performance and telemetry data, or location and environmental data.

The challenge lies in choosing the right level of detail. A list of individual technical raw data points may be too difficult for many users to understand. A very broad statement such as “usage data and device data”, by contrast, may not be meaningful enough. A medium level of granularity is usually sensible: specific enough to make data flows understandable, but not so technical that the information loses its practical value.

Which additional information must be provided for related services?

For related services, the information obligations go beyond the product perspective alone. This is because not only product data are generated in this context, but often also data generated by the use of the service itself.

Before concluding a contract, users must in particular be able to understand:

• which product data the service collects,

• to what extent and how frequently these data are collected,

• which related service data are additionally generated,

• how these data can be accessed,

• whether and for which purposes the prospective data holder intends to use the data itself,

• whether data are shared with third parties,

• how sharing with third parties can be requested or terminated,

• who the prospective data holder is,

• through which means of communication quick contact is possible,

• whether the data may contain trade secrets,

• which contract term and termination arrangements apply,

• which complaint mechanisms are available.

This shifts the focus: the question is not only which data are technically generated. It is also about the role that service providers and prospective data holders have in relation to these data and which options users will have later.

This transparency is particularly important in digital ecosystems. A connected product may generate relatively manageable data when viewed on its own. In combination with an app, cloud service, analytics function, remote maintenance or platform integration, however, the resulting data flow can become significantly more complex.

What applies to data processing services and provider switching?

In addition to connected products and related services, the Data Act also contains transparency obligations in the area of data processing services. Here, the focus is primarily on switching providers. The aim is to reduce lock-in effects and enable users to realistically assess how burdensome a later switch would be.

Relevant information may in particular concern:

• switching procedures,

• switching methods,

• switching and export formats,

• online registers with exportable data,

• interoperability standards,

• costs associated with switching or early termination,

• potential obstacles to switching,

• the jurisdiction to which the deployed ICT infrastructure is subject,

• safeguards against international access to data,

• specific aspects of trial versions or individually developed services.

In practice, this information is not only legally relevant. It may also influence purchasing decisions. Anyone selecting a cloud, platform or data processing service will want to know whether a later switch is realistically possible, which data can be exported and whether additional costs or technical hurdles may arise.

Providers should therefore not treat this information as a formal side note. It belongs in an information architecture that is easy to find, easy to understand and closely linked to the sales process.

How must the information be provided?

The Data Act does not prescribe a rigid standard format. What matters is that the information is provided in good time, clearly and comprehensibly. “In good time” means before the contract is concluded. Users should therefore not receive the information only once the contract has already been concluded or the product is already being used.

Possible implementation formats include, for example:

• an information sheet or data sheet,

• a product-specific website,

• a contractual annex,

• a notice within the offer process,

• a search function based on product number or model,

• a multi-layered information architecture.

For companies with a small number of standardised products, a well-structured data sheet may be sufficient. For large product portfolios, a search solution may be appropriate, enabling users to find the relevant information via product name, article number, identification number or model designation.

For customised B2B products, a contract-related solution may be appropriate, for example through offer documents, project-specific annexes or product-related contractual documents. However, the key point remains the same: the information must be available before the contract is concluded and must not disappear into documents that are difficult to find.

Why is a multi-layered approach often particularly useful?

A practical implementation problem lies in combining two objectives: the information must be complete enough to meet the legal requirements. At the same time, it must be understandable enough for users to actually grasp it.

A multi-layered approach can resolve this tension. Instead of bundling all information into a single overloaded document, the information is structured in meaningful layers.

One possible model:

1. Short introductory layer

An easy-to-understand summary explains which data are generally generated and why this information matters.

2. Product- or service-specific detailed information

Tables or structured sections show data categories, examples, storage locations, retention periods, access options and generation frequencies.

3. Technical deep dive

For expert users, supplementary technical information, data formats, interfaces or registers can be provided.

4. Contract-related linking

Offers, ordering processes and contractual documents clearly refer to the relevant information and ensure that it is accessible before contract conclusion.

Such a layered approach has several advantages: it is user-friendly, scalable and easier to adapt to different target groups. Companies can use it to address both consumers and professional B2B customers without overwhelming one group or providing too little detail to the other.

Which mistakes should companies avoid?

At first glance, the new information obligations may look like a documentation issue. In reality, however, they affect product management, sales, legal, IT, data protection, compliance and customer communication at the same time. This is precisely why typical mistakes arise in practice.

Companies should avoid in particular:

• information that is too general: Terms such as “device data” or “usage data” are of limited help if it is not clear what they specifically mean.

• raw information that is too technical: Internal database fields, sensor names or event codes are not understandable for most users.

• lack of product specificity: General framework information may be helpful, but it does not replace allocation to the specific product or service.

• late provision: Information that only becomes accessible after contract conclusion or after activation of the service does not fulfil the purpose of advance transparency.

• hidden references: Information must be easy to find. A hard-to-find link buried deep in general terms and conditions is risky.

• lack of coordination with sales: If offer documents, product pages and contractual documents do not match, inconsistencies arise.

• static documents without a maintenance process: Product data, functions, storage locations and services can change. The information architecture therefore needs clear responsibilities and update processes.

The right balance between legal protection and practical comprehensibility is particularly important. Information that appears formally complete but is in practice barely readable misses the purpose of the regulation.

What legal risks may arise if implementation is insufficient?

Incorrect or missing information can trigger various legal risks. The main issues are regulatory, unfair competition and civil-law consequences.

From a regulatory perspective, distinctions must be made: the Data Act provides that infringements must be subject to effective, proportionate and dissuasive penalties. However, not every information obligation is structured in the same way under the German implementation system. For certain obligations in the area of data processing services, in particular in connection with Art. 26 Data Act, the adopted version of the German implementing act expressly provides for administrative offences subject to fines. By contrast, with regard to the information obligations under Art. 3(2) and (3) Data Act, companies should not too hastily assume that there is an express fine provision. Irrespective of this, regulatory complaints, unfair competition risks and civil-law consequences remain relevant.

Unfair competition risks may also arise. If material information is withheld, this may become relevant in a competitive context. Information that must be provided under EU law may be material for commercial decisions.

The issue is not resolved from a civil-law perspective either. A contract generally remains valid even if information obligations are breached. Nevertheless, insufficient or incorrect mandatory information can have consequences, for example in connection with pre-contractual liability or the question of whether certain statements may be understood as an agreed quality or characteristic. If the product or service later deviates from the information communicated in advance, this may become legally relevant.

In short: the information obligations are not merely “compliance text”. They can shape expectations, influence contractual content and trigger later disputes.

How should companies proceed now?

Companies should follow a structured implementation process. The first step is not to write a new text, but to take stock: Which products, services and data processing offerings fall within the scope? Which data are generated? Who within the company has this information? And where is it currently documented?

A practical roadmap may look as follows:

1. Check the scope of application

Which connected products, related services or data processing services are affected?

2. Create a data map

Which categories of data are generated, in which format, at which frequency and in which storage location?

3. Clarify responsibilities

Legal, product, IT, sales, data protection and compliance should work together.

4. Select an information model

Depending on the business model, a data sheet, website, search solution, contractual annex or layered approach may be appropriate.

5. Review the contract conclusion process

The information must be available at the right point in the purchase, rental, leasing or offer process.

6. Test comprehensibility

The information should not only be technically and legally correct, but also readable for the relevant target group.

7. Establish a maintenance process

Changes to product functions, data flows or storage locations must be reflected promptly in the information.

Companies that establish a clean structure early on not only reduce legal risks. They also build trust. Transparent data communication can be a competitive advantage in the market — especially where customers need to assess sensitive, complex or business-critical data ecosystems.

Conclusion: What is the key takeaway now?

The Data Act makes pre-contractual data transparency a central component of sales and contract design. The main challenge lies in explaining complex technical data flows in such a way that users can make an informed decision before concluding the contract.

The key takeaway is this: there is no single correct standard for all companies. What matters is a solution that is available before contract conclusion, sufficiently specific, easy to find and understandable. In many cases, a multi-layered approach will be the most convincing option — with a short introductory layer, product-specific details and a technical deep dive.

Companies should therefore not treat the new information obligations as a downstream legal document. A joint implementation process involving legal, product, IT and sales is advisable. Those who now create clear data structures, responsibilities and information channels will not only be better positioned legally, but will also communicate more transparently with customers and business partners.