EU Data Act Pre-Contractual Information FAQ

Before conclusion of a purchase, rent, or lease contract for a connected product, Article 3(2) requires the seller, rentor, or lessor to give the user clear and comprehensible information. The disclosure must cover the type, format, and estimated volume of product data the connected product can generate.

The same pre-contract notice should also tell the user whether the product can generate data continuously and in real time, whether data can be stored on the device or on a remote server, the intended retention duration where applicable, and how the user may access, retrieve, or, where relevant, erase the data.

For a related service, Article 3(3) requires the prospective provider to disclose both product data it expects to obtain and related service data that will be generated. The notice must explain the nature, estimated volume, and, for product data, collection frequency, plus access or retrieval arrangements and storage or retention arrangements.

A related service disclosure also has to say whether the prospective data holder expects to use readily available data itself, the purposes of that use, and whether one or more third parties may use the data for purposes agreed with the user.

The Article 3 notice should focus on product data and related service data, not a broad inventory of every file associated with the product. Commission guidance describes Chapter II as covering raw and pre-processed data that are readily available to the data holder, including relevant metadata, while inferred or derived data and protected content can fall outside that Chapter II access scope.

For a useful pre-contract notice, translate internal labels such as telemetry, diagnostics, sensor logs, or app events into the Data Act categories that matter to the user: product data, related service data, readily available data, relevant metadata, and material that is not being offered because it is derived, inferred, content, or otherwise outside the access duty.

Article 3(1) requires connected products and related services to be designed so product data and related service data are easily, securely, and freely accessible to the user in a structured, commonly used, machine-readable format, and directly accessible where relevant and technically feasible.

The pre-contract information should therefore say whether access is direct, indirect, or split by data type. Commission FAQ material explains direct access as user access without asking the data holder to act, while indirect access means the user has to ask the data holder, for example through a portal or approval process.

Yes for related services. Article 3(3) requires the related service provider to disclose the prospective data holder's identity, including its trading name and geographical address, plus means for quick and efficient communication. For a connected product without a related-service contract, Article 3(2) does not list the data holder's identity among the seller's mandatory disclosures, although the user still needs a workable access route.

Commission FAQ material warns that the manufacturer is not always the data holder. A related service provider or another entity may be the data holder if it controls access to readily available data, and users must be told who the data holder or data holders are before signing the relevant contracts.

For related services, Article 3(3) requires information on how the user can ask for data to be shared with a third party and, where applicable, how to end that sharing. It also requires disclosure of whether the prospective data holder intends to allow one or more third parties to use the data for purposes agreed with the user.

The notice should not overpromise third-party access. Commission guidance states that users can ask data holders to share data with a third party of their choice, but Digital Markets Act gatekeepers are excluded from the third-party role and the Data Act does not oblige a data holder to share with third parties based outside the EU.

The Data Act does not supersede the GDPR. Commission FAQ material states that the GDPR is fully applicable to personal data processing under the Data Act, and that GDPR rules prevail in a conflict. Article 3 disclosures can describe personal-data categories and access routes, but they do not create a new legal basis for collecting, generating, or disclosing personal data.

Where the user requesting data is not the data subject, personal data can be made available only if there is a valid GDPR legal basis. A practical notice should therefore separate personal and non-personal data where possible, explain when anonymised data may be provided, and avoid suggesting that Data Act access overrides privacy, confidentiality of communications, or data subject rights.

Article 3(3) requires the related-service notice to say whether a prospective data holder is the holder of trade secrets contained in accessible or generated data, and, if not, to identify the trade secret holder. The Data Act also allows safeguards for trade secrets and security, but those safeguards should be explained as limits on access or sharing, not as a blanket reason to avoid clear Article 3 disclosures.

A useful pre-contract package should identify trade secret-sensitive data categories at a high level, explain any agreed confidentiality measures, and avoid exposing the secret itself. If security requirements laid down in EU or national law could restrict access or sharing, the notice should point users to the practical consequence for the relevant data stream.

No. The Data Act pre-contract obligation is a user-facing information duty about generated data, access, retrieval, data holder identity, third-party sharing, and related limits. It is not a CE-style declaration of conformity or a standalone self-certification document under the Data Act.

A seller, lessor, rentor, or related service provider may choose a stable web page, product documentation, contract schedule, or another appropriate form for the Article 3 information, as long as the user receives clear and comprehensible information before the relevant contract is concluded.

Keep the version of the disclosure that the prospective user could see before contracting, together with its publication or deployment date, the product model or related-service version, market and language, sales or rental channel, and contract version. A later reviewer should be able to prove both what the notice said and when it appeared in the user journey.

Behind the notice, retain the data inventory and field-to-disclosure map supporting type, format, estimated volume, generation frequency, storage or retention, direct or indirect access, data holder identity, intended use, third-party sharing, trade-secret holder, contract duration and termination, complaint route, and Article 5 request process. Record assumptions where a volume, retention period, or planned use is not fixed.

The actor with the Article 3 duty should own delivery: the seller, rentor, or lessor for the connected-product disclosure and the related-service provider for the service-contract disclosure. Internally, assign one content owner who can stop release when the disclosure is missing and one technical owner who can confirm the data fields, access route, volume, frequency, storage, and retention statements.

Legal should map each statement to Article 3, privacy should keep GDPR transparency separate but consistent, the data holder or prospective data holder should approve intended-use and sharing language, and support should maintain the contact and complaint route. Where different companies fill these roles, the contract should assign who supplies updates and how quickly the sales channel must publish them.

Test the disclosure against the product and service rather than reviewing text alone. A usable file links every Article 3 statement to a data dictionary field, architecture or API record, retention configuration, contract clause, data-holder contact, intended-use approval, sharing flow, and complaint channel. A sample purchase, rental, lease, or service sign-up should confirm that the correct notice appears before the user commits.

Reassess after a new product model, firmware or app release, changed related service, new data field, changed format or access method, revised retention, new data holder, new intended use or recipient, contract change, or complaint-channel change. Preserve the old notice for earlier transactions and issue a new effective version instead of overwriting the evidence.