Search every question across sub-FAQs

For connected products and related services, 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 beyond a simple operation. The Commission FAQ explains that Chapter II covers data generated or collected after the Data Act began to apply on 12 September 2025.

Product data is generated by the use of a connected product and designed to be retrievable from that product. Related service data represents user actions or events related to the connected product during the provision of a related service. The Commission explains the practical scope as raw and pre-processed data generated from use of a connected product or related service, where that data is readily available to the data holder.

Relevant metadata is part of the access duty. Article 3 requires product data and related-service data to include the metadata necessary to interpret and use them. Article 4 uses the same standard where the user cannot directly access the data and the data holder must make readily available data accessible.

In practice, an export that contains values but omits basic context can fail the point of the access right. The metadata set should let the user or an authorized third party understand what each field is, when and how it was generated, how units and identifiers work, and what quality or access limitations apply.

The Data Act does not name one universal file type for every connected product or related service. Instead, it requires access in a comprehensive, structured, commonly used and machine-readable format. Where relevant and technically feasible, Article 3 also expects direct access by default, and Article 4 expects continuous and real-time access where relevant and technically feasible.

A practical export catalogue should therefore state the actual delivery method and format for each dataset: API, bulk file, real-time stream, device interface, or another technical route. The format should be understandable outside the vendor's internal systems and should include the metadata needed to interpret and use the data.

Before a connected-product purchase, rent, or lease contract is concluded, the seller, renter, or lessor must give the user clear and comprehensible information about the type, format, and estimated volume of product data the product can generate, whether it can generate data continuously and in real time, where it can store data, retention information, and how the user can access, retrieve, or erase data.

Before a related service contract is concluded, the provider must disclose the nature, estimated volume, and collection frequency of product data it expects to obtain, the nature and estimated volume of related service data to be generated, access and retrieval arrangements, storage and retention arrangements, whether readily available data will be used by the prospective data holder, and how the user can request sharing with a third party.

For cloud and other data processing services, exportable data is a defined term used for switching obligations. It covers input and output data, including metadata, directly or indirectly generated or co-generated by the customer's use of the data processing service. It excludes assets or data generated by the provider or a third party that are protected by intellectual property rights or constitute the provider's or third party's trade secrets.

The customer-facing question is not only whether data can be downloaded. The provider must remove obstacles that inhibit customers from porting exportable data and digital assets to another provider of the same service type or to on-premises ICT infrastructure.

A provider of data processing services must give customers information on available switching and porting procedures, including available methods and formats, and known restrictions or technical limitations. The provider must also refer customers to an up-to-date online register with details of data structures, data formats, relevant standards, and open interoperability specifications in which the exportable data is available.

Where switching is between services of the same service type and no relevant common specifications or harmonised interoperability standards have been published in the central Union standards repository, the provider must, at the customer's request, export all exportable data in a structured, commonly used and machine-readable format.

For connected products and related services, the ordinary access scope does not include inferred or derived information that results from additional investments into assigning values or insights, particularly through proprietary complex algorithms, unless the user and data holder agree otherwise. The Commission gives examples such as highly enriched data and content being outside the Chapter II scope.

For cloud switching, exportable data excludes provider or third-party assets or data protected by intellectual property rights or constituting trade secrets. Providers are also not required to develop new technologies or services, disclose protected digital assets, or compromise customer or provider security and service integrity.

The Data Act preserves trade secrets, but it does not allow a broad confidentiality label to erase the access right. For user access and third-party sharing, the data holder or trade secret holder must identify protected data, including in the relevant metadata, and agree proportionate technical and organisational measures to preserve confidentiality.

Withholding, suspending, or refusing access on trade-secret grounds is limited and must be substantiated. Security restrictions for connected products require a risk that security requirements laid down by Union or national law would be undermined with serious adverse effects on health, safety, or security of natural persons.

A useful exportability register should make the Data Act answer reproducible. For each connected product, related service, or cloud service, record the data category, role, user or customer route, format, metadata, access method, retention or retrieval constraint, exclusion reason, safeguard, and owner.

The register should be specific enough to support pre-contract disclosures, user requests, third-party sharing requests, cloud switching requests, and complaints. It should also show whether the same dataset is governed by connected-product access rules, cloud switching rules, or both.

For exportable data and metadata, 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 exportable data and metadata, keep the cited external URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the answer remains auditable.

For exportable data and metadata, the Data Act workflow should name the legal, product, procurement, cloud, support, or security owner who can change the affected process.

For exportable data and metadata, use one accountable owner per action, then record consulted teams and evidence dependencies separately.

For exportable data and metadata, the Data Act evidence should be concrete enough for a later reviewer to reconstruct why the team classified the product, service, request, or contract in scope.

For exportable data and metadata, useful evidence includes source URLs, data inventories, contract clauses, request logs, technical controls, customer notices, and approval records.

Usually, the route is user-driven. Article 5 requires the data holder, on request by a user or by a party acting on behalf of a user, to make readily available product data and related service data available to a third party. In vehicle workflows, that third party may be an independent repair shop, fleet service provider, insurer, leasing provider, mobility platform, or other service provider chosen by the user.

The third party does not get a general entitlement to all vehicle systems or functions. The request must be anchored to a user, a connected product or related service, and data that the data holder lawfully obtains or can lawfully obtain without disproportionate effort going beyond a simple operation. A Digital Markets Act gatekeeper cannot use this mandatory Article 5 route.

The Commission's 2025 vehicle-data communication is non-binding guidance for automotive stakeholders. It does not alter the Data Act, replace the Court of Justice's authority to interpret EU law, or displace sector-specific rules such as vehicle type-approval and competition rules, GDPR, or other applicable legislation.

The Commission's vehicle-data guidance treats raw and pre-processed vehicle data as the core Chapter II access category. Examples include wheel speed, tyre pressure, brake pressure, yaw rate, oxygen sensor readings, CAN bus messages, component status, vehicle speed, acceleration, GNSS-based location, odometer value, battery level, fault codes, malfunction indicators, brake-pad wear, and time or distance to next service when those data are not predictions outside the guidance boundary.

That makes the Data Act highly relevant for diagnostic, maintenance, fleet-management, charging, routing, leasing, insurance, and mobility workflows. But it does not turn every analytics output into shareable vehicle data: inferred or derived information created through additional investment, such as driving scores, risk assessments, object classification, trajectory predictions, or certain optimal-route outputs, can fall outside the mandatory access scope.

Not usually. The Commission's vehicle-data guidance says traditional aftermarket services such as auxiliary consulting, analytics, financial services, and regular repair and maintenance are generally not vehicle-related services where they do not affect vehicle operation and do not transmit data or commands to the vehicle. Manual brake replacement or oil changes, for example, are not treated as related services just because they concern a connected vehicle.

The distinction matters because a provider of a vehicle-related service can itself become a data holder for data generated during that service. A digital repair, predictive maintenance, remote control, charging, cloud preference, or route optimization service may be different if it involves bidirectional data exchange and adds to, adapts, or affects vehicle functionality.