Search every question across sub-FAQs

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.

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

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

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

For indirect access under Article 4 and third-party sharing under Article 5, the Data Act requires readily available data to be made available without undue delay, in the same quality available to the data holder, easily, securely, free of charge to the user, in a comprehensive, structured, commonly used and machine-readable format, and where relevant and technically feasible continuously and in real time.

The vehicle-data guidance makes that practical for the automotive sector: access methods can vary, including remote backend access, onboard access, or data intermediation, but the chosen method must not give users or independent service providers lower-quality data than the data holder, subsidiaries, authorised partners, dealers, or authorised repairers receive in comparable circumstances.

A trade-secret label is not enough by itself to block access. The Data Act requires trade secrets to be preserved through proportionate technical and organisational measures, such as confidentiality agreements, strict access protocols, technical standards, model contractual terms, or codes of conduct. Withholding or suspension is possible where measures are not agreed or implemented, and refusal is reserved for exceptional case-by-case situations where serious economic damage is highly likely despite safeguards.

Safety and security are also limited grounds. Article 4 allows users and data holders to restrict or prohibit access or further sharing only where processing could undermine legally laid down security requirements of the connected product and result in a serious adverse effect on health, safety, or security. Decisions to refuse, withhold, or suspend should be reasoned, written, notified to the competent authority where required, and open to challenge through competent authorities, dispute settlement, or courts.

The Data Act context is the starting point for this answer. Article 6 limits third-party use to the purposes and conditions agreed with the user, subject to data-protection law where personal data is involved. That means the request should state the service purpose: diagnosis, repair estimate, maintenance alert, fleet optimization, insurance product, charging support, leasing service, or another specific use.

The third party may not use the data for prohibited purposes such as developing a competing connected product, making the data available to a Digital Markets Act gatekeeper, using the data for profiling unless necessary to provide the requested service, undermining security, disregarding agreed trade-secret measures, or passing the data onward except on the permitted contractual basis.

The GDPR boundary is central. Article 1(5) says the Data Act is without prejudice to EU and national personal-data law, and the Commission FAQ states that GDPR rules prevail in a conflict. The Data Act can complement GDPR access and portability rights, but it is not a free-standing legal basis for giving personal data to a user who is not the data subject or to a third party.

In vehicle contexts, personal data can appear in location data, driving behaviour, user accounts, in-vehicle preferences, and multi-user or rental situations. If the user is not the data subject, the data holder must assess a valid GDPR legal basis, relevant special-category conditions where applicable, and ePrivacy limits where relevant, or provide anonymised data where that is the compliant route.

The Data Act context is the starting point for this answer. A useful request record should be concrete enough for a later complaint, dispute, authority question, or contract review. It should show who the user is, who the third party is, who the data holder is, which vehicle or related service is involved, which data fields and metadata were requested, which fields were delivered or excluded, and why.

For high-volume repair, fleet, insurance, and mobility workflows, maintain an access matrix rather than deciding from scratch each time. The matrix should identify common use cases, standard data categories, GDPR status, trade-secret or security safeguards, access route, expected latency, compensation position for B2B recipients where relevant, refusal or escalation triggers, and evidence owner.

For aftermarket repair and mobility services, the Data Act record should keep the cited Article 4, 5, 6, or 7 basis, the Commission vehicle-data guidance reference, the actor role, the data categories affected, the request or contract trigger, and the approver who signed off on the interpretation.

Keep the external source URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the answer stays auditable when the same repair or mobility case returns later.

For aftermarket repair and mobility services, the Data Act workflow should name a single accountable owner for each operational change, such as legal, product, procurement, cloud, support, or security.

That owner should coordinate the affected workflow and decision record, while consulting other teams as needed and keeping evidence dependencies separate so implementation can be updated without reopening the whole legal analysis.

For aftermarket repair and mobility services under the Data Act, the most useful evidence is the material that lets a later reviewer reconstruct the decision without guessing. That usually means the source article or guidance cited, the data inventory or request log, the contract clause or access rule, the security or trade-secret control used, and the approval record.

If the workflow changes, the evidence should show what changed and when. That makes it easier to compare a repair request, fleet request, or mobility-service request across versions instead of re-litigating the same scope question from scratch.

For aftermarket repair and mobility services, the Data Act answer should be reviewed whenever the product architecture, service model, dataset, customer role, or contract terms change in a way that could change who controls the data or how it is shared.

It should also be revisited when Commission guidance, the vehicle-data implementation approach, or the security and privacy setup changes, because those are the points most likely to affect repair, fleet, insurance, or mobility workflows.

Under the Data Act, functional equivalence means re-establishing a minimum level of functionality after a customer switches to a new data processing service of the same service type. The comparison is based on the customer's exportable data and digital assets, and it looks at whether the destination service delivers a materially comparable outcome for the same input and for shared contractual features.

That is narrower than identical performance, identical configuration, or a full replica of the old environment. Teams should frame functional equivalence as a switching outcome to facilitate, not as a warranty that every workload, integration, latency profile, or provider-specific feature will carry across unchanged.

The Data Act context is the starting point for this answer. The functional-equivalence obligation in Article 30(1) is aimed at providers of data processing services limited to infrastructural elements such as servers, networks, and virtual resources. In practical cloud terms, the Commission FAQ describes this as applying to source providers of Infrastructure as a Service.

PaaS and SaaS providers are still covered by Chapter VI when their services meet the Data Act definition of data processing services, but their Article 30 duties are different. They must make open interfaces available, support data portability and interoperability, and comply with applicable interoperability specifications or standards when those references are published as required by the Data Act.

For an in-scope IaaS switch, the customer should be supported toward using a destination service of the same service type with materially comparable outcomes for shared features. The Data Act does not say the source provider must make the destination service identical, rebuild the workload for the customer, or control the destination provider's environment.

A useful switching plan therefore states the target outcome in operational terms: which workloads, configurations, data categories, access rights, security settings, machine images, containers, or other digital assets will be exported or documented; which destination features are shared; and which differences remain outside the source provider's control.

The Data Act context is the starting point for this answer. For IaaS functional equivalence, the source provider must take reasonable measures within its power. Article 30 describes the facilitation package as capabilities, adequate information, documentation, technical support, and, where appropriate, necessary tools.

The provider's switching contract and public information should also tell customers how switching and porting work, which methods and formats are available, what restrictions or technical limitations are known, and where to find the provider's register of data structures, formats, standards, and open interoperability specifications for exportable data.