EU Data Act Vehicle Data Guidance FAQ

It is Commission guidance for automotive stakeholders applying Chapter II of the Data Act to vehicle data. The guidance focuses on connected vehicles, vehicle-related services, data within the scope of Chapter II, and the access rules for users and third parties chosen by users.

The guidance is not a new legal obligation and does not extend or modify the Data Act. It is also sector-specific: it concerns the automotive sector, including OEMs, suppliers, aftermarket service providers, and insurance providers, and should not be automatically applied to other industries or the public sector.

The guidance covers vehicles that qualify as connected products under the Data Act: vehicles that obtain, generate, or collect data about use or environment and can communicate product data electronically, by physical connection, or through on-device access.

A vehicle-related service must be a digital service connected with the vehicle in a way that affects the vehicle's operation or behavior. Examples in the guidance include remote vehicle-control services, some predictive maintenance services that exchange data with the vehicle and adapt functionality, cloud-based driver preference services, and dynamic route optimization shown through the vehicle interface.

The Data Act context is the starting point for this answer. For this guidance, vehicle data means product data generated by the use of a connected vehicle and vehicle-related service data. The in-scope set includes raw and pre-processed data, together with relevant metadata needed to interpret and use the data.

The guidance treats inferred or derived information as outside Chapter II. That boundary matters for repair, mobility, and insurance use cases because a measured value such as speed, location, odometer value, battery level, tire pressure, or fault information can be in scope, while a proprietary driver score, route prediction, risk assessment, or other new insight may be outside scope.

The Data Act context is the starting point for this answer. The user is the person or organisation that owns, rents, or leases the connected vehicle or receives a vehicle-related service. A data holder is the party that has the right or obligation to use and make available readily available product data or related service data. A third party is selected by the user to receive data from the data holder.

In practice, the request file should identify the vehicle or service, the user, the data holder, the requested third party, the requested data fields, the intended route for access, and whether personal data, trade secrets, safety, or cybersecurity issues affect the response.

Start with the vehicle-data field, not the market label. The Data Act can support access to readily available vehicle data for aftermarket uses, but the guidance also explains that the Data Act does not create access rights to vehicle functions or resources.

For independent repair shops and other independent service providers, the guidance is explicit that access quality should not be lower than the quality made available to the data holder, subsidiaries, authorised partners, dealers, or repairers. Access must also be easy, without undue barriers, costs, or procedural hurdles.

The Data Act context is the starting point for this answer. No, not in every situation. The guidance explains that direct access under Article 3 applies where relevant and technically feasible. If users cannot access data directly from the vehicle, the data holder must provide indirect access to readily available data under Article 4, and must make readily available data accessible to a third party at the user's request under Article 5.

The Data Act is technology-neutral about the access method. The guidance mentions remote backend solutions, onboard access, and data intermediation as possible routes, but the chosen method must still satisfy the Data Act conditions, including access to data of the same quality as available to the data holder.

Trade-secret and security concerns should be handled as specific safeguards, not as blanket refusals. The Data Act contains mechanisms for protecting trade secrets and allowing appropriate technical and organisational measures, while the vehicle guidance stresses that access still has to remain easy and non-discriminatory.

For vehicle data, the file should identify the protected interest, the precise data or interface affected, the measure applied, and what data remains available. Safety, cybersecurity, and trade-secret controls are most defensible when they are proportionate to a documented risk and do not turn an access right into a dead end.

The Data Act does not supersede the GDPR. Where vehicle data is personal data, GDPR rules apply to the processing, and the Commission FAQs state that GDPR rules on personal-data protection prevail in the event of conflict.

This means an access workflow can be within Chapter II of the Data Act and still need a GDPR basis, data-subject analysis, minimisation, security, and recipient controls. Location data, driver behavior, charging history, and vehicle-use patterns should be assessed carefully because they can often identify or relate to a person depending on context.

The vehicle guidance is limited to the Data Act. It does not interpret or displace sector-specific automotive rules, including the Type Approval Regulation, rules on on-board diagnostics information or vehicle emissions data, competition rules for motor vehicle repair and spare parts, or other sector guidance.

A practical vehicle-data review should therefore mark whether the request is a Data Act Chapter II access request, a sector-specific access request, a GDPR issue, or a combined case. That prevents a team from using Data Act language to narrow rights that already exist under another rule, or using another rule to ignore Data Act access duties.

The Data Act context is the starting point for this answer. Keep a vehicle-data access matrix that lists the data field, vehicle or service source, role map, raw or pre-processed classification, inferred or derived exclusion if relevant, personal-data status, access route, recipient, safeguards, source citation, decision, and delivery or refusal outcome.

For recurring aftermarket or mobility requests, also keep interface evidence: API specification, data dictionary, quality comparison, authentication model, recipient terms, support script, and logs showing what was delivered and when. The point is to make later complaints, partner disputes, or authority questions answerable without rebuilding the decision from memory.

Keep the source clause, Commission guidance reference, actor role, dataset, request trigger, and approving owner together so the decision can be checked later. A short record is enough if it points to the exact Data Act source and the specific vehicle-data field or workflow that was reviewed.

Also keep the cited external URL, decision date, reviewer, unresolved assumptions, and implementation artifact with the decision file. That makes the answer auditable without forcing teams to reconstruct the reasoning from email threads.

Assign one accountable owner who can actually change the affected process under the Data Act, such as legal, product, procurement, cloud, support, or security. That owner should be the person who can approve the interpretation, coordinate the fix, and confirm the workflow now matches the guidance.

Use consulted teams and evidence dependencies to support the owner, but keep them separate from the single accountable owner. That helps teams avoid stalled decisions and makes follow-up reviews easier when the vehicle-data workflow changes.