Search every question across sub-FAQs

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.

No. 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 make readily available data accessible to a third party at the user's request under Article 5.

The dates differ. Chapter II and the request-based Articles 4 and 5 have applied since 12 September 2025. The Article 3(1) design obligation applies to connected products and related services placed on the Union market after 12 September 2026, so record the individual vehicle's placing-on-the-market date before treating direct access as a design requirement.

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 record 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.

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.

The Data Act defines non-personal data as data other than personal data. Classify by substance and context, not by the dataset label. A machine telemetry export, support log, vehicle dataset, or cloud export can contain non-personal fields alongside fields that identify or relate to a natural person. A field that appears anonymous in isolation can still be personal data when combined with other reasonably available information.

For connected products and related services, the Data Act access analysis should start with raw and pre-processed data that is readily available to the data holder, plus metadata needed to interpret and use it. Inferred or derived information, highly enriched outputs, protected content, and material outside the connected-product or related-service boundary should be marked separately instead of silently included.

No. The Data Act complements EU data-protection and privacy law and must not be interpreted to diminish personal-data rights. When a mixed dataset contains personal data, GDPR, the EU institutions data-protection regulation, and ePrivacy rules continue to control the personal-data processing layer.

The Data Act also does not create a new legal basis for collecting or generating personal data. If the user requesting data is not the data subject, personal data generated by a connected product or related service may be made available to the user or a third party only where a valid GDPR legal basis exists and any relevant special-category or ePrivacy conditions are satisfied.

The main roles are user, data holder, third party, and data recipient. A user owns a connected product, has a temporary contractual right to use it, or receives a related service. A data holder has the right or obligation under the Data Act, applicable Union law, or qualifying national legislation to use and make data available. A third party established in the Union can receive data at the user's request and may be a data recipient for business-to-business sharing rules.

Do not assign roles once for the whole company. The same organisation can be a user in one workflow, a data holder in another, and a data recipient in a supplier or aftermarket-service workflow. Role classification controls who can request data, who must make it available, who may use it, and who must preserve trade secrets or delete data when it is no longer needed.

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 without undue delay, in the same quality available to the holder, securely, free of charge, and in a comprehensive, structured, commonly used, machine-readable format. Access must be continuous and real-time only where relevant and technically feasible.

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, the data holder may disclose to the third party only where the GDPR and any relevant ePrivacy conditions are met. The third party may use received data only for the purposes and conditions agreed with the user. It must erase the data when no longer necessary for that purpose, unless the user agrees otherwise for non-personal data.

A data holder may use readily available non-personal data only on the basis of a contract with the user. The holder must not use those data to derive insights about the user's economic situation, assets, production methods, or product use 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.