Search every question across sub-FAQs

The Data Act context is the starting point for this answer. Where the user cannot directly access the data from the connected product or related service, the data holder must make readily available data and necessary metadata accessible to the user without undue delay, in the same quality available to the data holder, securely, free of charge, and in a comprehensive, structured, commonly used, machine-readable format. Where relevant and technically feasible, access should be continuous and real-time.

That duty covers both personal and non-personal data only when the personal-data layer is lawful. If GDPR conditions are not met for a personal-data field, the data holder should not treat that as a reason to suppress the non-personal fields that can lawfully be made available.

Yes, but the same boundaries apply. At the user's request, the data holder must make readily available data and relevant metadata available to a third party under the Data Act conditions. A gatekeeper under the Digital Markets Act is not an eligible third party for this user-requested Chapter II sharing route.

For personal data in a mixed dataset, the data holder may make the data available to the third party only where the GDPR and any relevant ePrivacy conditions are met. For non-personal data, the third party must use the data only for the purposes and conditions agreed with the user, and must erase it when it is no longer necessary for that purpose unless the user has agreed otherwise for non-personal data.

The Data Act context is the starting point for this answer. A data holder may use readily available non-personal data only on the basis of a contract with the user. The data holder must not use that data to derive insights about the user's economic situation, assets, production methods, or use of the product in a way that could undermine the user's commercial position.

Third parties that receive Data Act data at the user's request also face limits. They may not use the data to develop a competing connected product, make it available to a Digital Markets Act gatekeeper, or use non-personal product or related-service data to derive commercial insights about the data holder. These restrictions should be visible in contract terms and recipient controls, not buried in a generic data-sharing policy.

Trade secrets are not a blanket reason to deny a Data Act request. The data holder or trade-secret holder must identify protected data, including relevant metadata, and agree proportionate technical and organisational measures with the user or third party. Examples in the Data Act include contractual terms, confidentiality agreements, strict access protocols, technical standards, and codes of conduct.

Withholding, suspension, or refusal needs a written, substantiated basis. A refusal based on trade secrets is exceptional and must be assessed case by case. Security limits are also narrow: users and data holders may restrict or prohibit access, use, or further sharing where processing could undermine legally-laid-down security requirements of the connected product and cause serious adverse effects to health, safety, or security.

The Data Act context is the starting point for this answer. Chapter V is different from ordinary user and third-party access. Public sector bodies, the Commission, the European Central Bank, and Union bodies may request data from data holders on the basis of an exceptional need, but the request must be limited in time and scope and tied to statutory duties in the public interest.

For public emergencies, the Commission explainer states that the public body should request non-personal data and may request personal data only if non-personal data is insufficient; where possible, the data holder should anonymise it. For non-emergency exceptional need requests, the Data Act route is limited to non-personal data and requires the requesting body to show that it could not obtain the data by other means.

The Data Act also contains rules for data processing services and international governmental access to non-personal data held in the Union. Providers of data processing services must take adequate technical, organisational, and legal measures, including contracts, to prevent third-country governmental access or transfer of non-personal data where it would conflict with Union or Member State law.

This cloud rule should not be confused with connected-product user access. It is a separate control for providers of data processing services and is relevant when a cloud provider receives a third-country decision or request concerning non-personal data held in the EU.

Keep evidence that proves the classification and the outcome, not a generic compliance memo. The minimum useful record is a field-level data inventory, the Data Act role map, the requester and recipient identity checks, the GDPR basis or exclusion for any personal-data fields, and the final delivery or refusal file.

For each excluded or limited field, preserve the reason and source: outside product or related-service data, not readily available, inferred or derived, personal-data restriction, trade secret, security requirement, public-sector-request condition, cloud third-country access rule, or other Union or national law. The record should let a reviewer understand what was delivered, what was withheld, why, who approved it, and what was communicated.

For mixed datasets, the decision record should point to the exact Data Act article or recital, the Commission guidance used, the actor role, and the specific dataset or workflow reviewed. That makes it easier to explain why some fields were shared, some were excluded, and which law controlled each part of the decision.

Keep the cited source URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the page remains auditable and easy to update when the underlying Data Act process changes.

For mixed datasets, the Data Act workflow should name the legal, product, procurement, cloud, support, or security owner who can change the affected process. The owner should be the person who can approve the field-level classification, route any GDPR or trade-secret review, and close the request with a documented outcome.

For mixed datasets, use one accountable owner per action, then record consulted teams and evidence dependencies separately so the handoffs remain clear if the decision is reviewed later.

The Data Act context is the starting point for this answer. 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.

The Data Act context is the starting point for this answer. 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 Data Act context is the starting point for this answer. 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.

The Data Act context is the starting point for this answer. Article 3(1) says connected products and related services should 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.

The Data Act context is the starting point for this answer. Yes for related services, and in practice the identity question is central for connected products too because the user needs to know who controls access to readily available data. Article 3(3) requires the related service provider to disclose the prospective data holder's identity, such as trading name and geographical address, plus communication means for quick and efficient contact.

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.

The Data Act context is the starting point for this answer. 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.

For pre contractual information, the Data Act record should identify the source clause, Commission guidance, actor role, dataset, request or contract trigger, and the owner who approved the interpretation.

For pre contractual information, keep the cited external URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the answer remains auditable.

For pre contractual information, the Data Act workflow should name the legal, product, procurement, cloud, support, or security owner who can change the affected process.

For pre contractual information, use one accountable owner per action, then record consulted teams and evidence dependencies separately.