Search every question across sub-FAQs

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.

Product data are data generated by the use of a connected product that the manufacturer designed to be retrievable by a user, data holder, or third party, including the manufacturer. They concern the product's performance, use, or environment. Classify the field from the product's design and generation source, regardless of whether the business labels it telemetry, diagnostics, or customer data.

Examples can include sensor measurements, hardware status, malfunction data, position, acceleration, speed, temperature, pressure, pH value, liquid level, flow rate, or similar data generated from the product's use or environment. Purely descriptive material that accompanies a product, such as a manual or packaging text, is not product data simply because it is about the product.

Related-service data represent user action, inaction, or events related to the connected product during provision of a related service. A related service is a digital service, other than an electronic communications service, connected with the product at sale, rent, or lease so that the product could not perform one or more functions without it, or later connected by the manufacturer or a third party to add, update, or adapt functions. It is not every service sold near the product.

A fridge app that regulates temperature or a machine service that changes operating parameters can generate related service data. Auxiliary consulting, analytics, financial services, regular repair, maintenance, power supply, or connectivity supply are not treated as related services merely because they concern the same product.

Yes. Chapter II covers raw and pre-processed data when they are product data or related-service data and are readily available to a data holder. Raw data are source or primary data points generated automatically without further processing. Pre-processed data can include records made understandable and usable before further analysis, such as a sensor signal converted into a physical quantity.

Pre-processing does not require the data holder to make substantial new investments in cleaning or transforming data for a requester. The boundary is between making raw data usable and creating enriched outputs or insights from additional investment.

The Data Act treats relevant metadata as part of what makes product data and related service data usable. The metadata must be necessary to interpret and use the data, such as basic context, timestamp, or conditions under which the data was collected or generated.

Metadata should not become a catch-all for every internal note, model feature, support annotation, or analytics output. Include it when it is needed to understand and use the raw or pre-processed data being made available.

Information inferred or derived from product data or related service data is generally outside Chapter II when it results from additional investment into assigning values or insights, especially through proprietary, complex algorithms. The Data Act draws this line to preserve incentives to build analytics, transformations, and autonomous decision processes.

Examples of out-of-scope material can include highly enriched data, proprietary sensor-fusion outputs, predictive insights, and textual, audio, or audiovisual content often protected by intellectual property rights. Privacy-preserving processes such as anonymisation, pseudonymisation, or encryption should not by themselves be treated as enough to exclude otherwise in-scope data.

Readily available data means 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. The test includes stored, retrievable, or externally transmitted data available by design; it does not cover every signal a redesigned device could theoretically generate.

If data cannot be directly accessed by the user, the data holder must make readily available data and the necessary metadata accessible without undue delay, in the same quality as is available to the data holder, easily, securely, free of charge, and in a comprehensive, structured, commonly used, machine-readable format. Where relevant and technically feasible, this can include continuous and real-time access.

Use a field-level inventory rather than broad buckets. A smart-home thermostat may generate product data such as temperature readings and device status; a control app may generate related-service data when it records user settings or sends commands that affect product behaviour; a vendor's proprietary comfort score or predictive energy model may be inferred or derived information if it results from additional analytics investment.

For vehicles, industrial machines, health devices, home equipment, agricultural machinery, or similar connected products, the same structure applies: identify the connected product, identify any related service that affects product functions, list raw and pre-processed fields, add necessary metadata, then separate enriched insights, content, trade-secret handling, personal-data handling, and unavailable data.