In Part 2 of our FAQ on Access to Vehicle Data and Data Governance, we address the establishment of a comprehensive Data Governance Management System. This includes its organizational structure, processes, controls, and assigned responsibilities. We also examine the implications of potential infringements, strategies for enforcing rights, and methods for defending against claims.
If you have not yet read Part 1 of the FAQ, you can find it here.
6. How can OEMs and other "data holders" develop and implement a data governance system that effectively addresses the topics outlined in Part 1 of the FAQ? What does such a governance framework entail, and what are its key elements and responsibilities?
Given the wide range of requirements, spanning from technical access obligations to data protection and competition law, it is crucial for OEMs and other data holders in the automotive industry to develop a comprehensive data governance system. Such a framework integrates these requirements into the organization and its operations, ensuring consistent and auditable implementation. The key building blocks and responsibilities include:
- Clearly defined responsibilities and interdisciplinary teams: Data governance begins with an organizational framework. Companies should establish a cross-functional structure encompassing Legal/Compliance, IT/Security, Engineering/Development, and After-Sales. In practice, a Data Governance Board is often an effective mechanism for setting standards and coordinating decisions. Roles should be clearly defined, such as appointing a Data Protection Officer for GDPR compliance or an “RMI/Data Access” owner for Regulation (EU) 2018/858 and the Data Act. Interlinking is essential to ensure that new tools and processes (e.g., software) are simultaneously secure, accessible, and GDPR-compliant. Management sponsorship and adequate resources to support security and privacy by design are fundamental to achieving these goals.
- Data inventory and classification: The foundation lies in creating a comprehensive data inventory, identifying which in-vehicle data are generated, where they are located (vehicle, backend, or cloud), and how they should be classified (e.g., personal data, safety-critical, trade secrets, or RMI-relevant). Classification enables the application of specific rules to each category (e.g., ensuring RMI data on the portal remains up to date or tagging personal data for filtering purposes). These rules should be documented clearly within a governance policy. Appointing data stewards for each domain can facilitate data maintenance and ensure data quality, ensuring that the information provided is accurate and complete
- Processes for External Data Access: Companies must implement standardized processes to efficiently manage claims.
- RMI process: 24/7 access to the portal, streamlined registration/authorization processes (e.g., SERMI), and support. In light of the CJEU's 2023 case-law, unnecessary obstacles (e.g., mandatory online unlock procedures) must be eliminated; modifications to gateways should be legally/technically reviewed before rollout to ensure relevant third-party tools continue to have access.
- EDR / public-authority process: Clear process for requests from public authorities (responsibilities, making available/interpretation), and where appropriate an on-call / incident response setup for serious accidents. Requests from vehicle holders for EDR data, or from service providers seeking information, should also be covered with defined points of contact.
- Data Act and GDPR requests: Ideally an integrated self-service portal/app (e.g., “Download data” under Articles 15/20 GDPR; “Share data” under the Data Act). Behind this: workflows for authorisation checks, (partly) automated data delivery, deadline management (GDPR as a rule: one month; Data Act: “without undue delay”), and review steps to protect third parties and trade secrets.
- Competition-law / antitrust cases: Process for legal assessment of access requests without a clear sector-specific provision (e.g., “essential facility”). Involve antitrust expertise; where appropriate define a clear policy for voluntary, fair data sharing / API offerings to reduce disputes.
- Technical infrastructure (“data platform”): Governance needs a robust technical basis (e.g., a central backend platform / extended vehicle server) with managed access rights. Elements can include:
- API management: Secure APIs and a gateway for authentication/authorisation (e.g., user tokens, consents, roles).
- Logging and monitoring: Logging of all data retrieval (who/when/what) for compliance evidence and user transparency; monitoring to detect misuse and errors.
- Security and data protection mechanisms: Anonymisation/pseudonymisation where possible; encapsulated read-only access for third parties; “access by design” in the architecture (what may be shared externally, and how it is protected).
- Policies and training: Clear policies (e.g., requests from public authorities, repairer access, data protection principles) and regular updates are necessary. Training for Engineering/Development (privacy/security by design), Customer Support (handling requests) and Legal (technical understanding) creates consistency. A data-aware culture helps to use in-vehicle data responsibly while remaining within the rules.
- Continuous monitoring and adaptation: Data governance is ongoing. OEMs should establish legal/regulatory monitoring (new judgments, application of the Data Act, national rules) and include technological developments (e.g., new sensor data). Regular audits verify whether processes work and whether access is in fact made available in a non-discriminatory manner and with sufficient quality. The system should also be able to respond to new standards/initiatives (e.g., mobility data spaces).
In short, an effective data governance system connects people, processes and technology. It reduces legal and reputational risks, creates trust among customers/partners and enables scalable data-driven services without infringing access and data protection obligations.
Conclusion: Through the interplay of organisational measures, technical solutions and forward-looking compliance, companies can implement the multitude of requirements in a practical way. A well-designed Data Governance Management System manages risks and opens opportunities by supporting a responsible and at the same time innovative approach to in-vehicle data.
7. Are there standards or best practices for establishing such a governance system that should be known and, where appropriate, considered?
Yes. Even though there is no single standard explicitly named “Automotive Data Governance Standard”, there is a clearly recognisable set of international standards, regulatory-shaped frameworks and industry-driven models that in practice form a benchmark for establishing a data governance system – also in the automotive industry. In practice, such a system therefore does not follow only one requirement, but a combination of multiple complementary standards and best practices.
At the overarching governance level, ISO/IEC 38505 (Governance of Data) is particularly relevant. This standard embeds data governance as a leadership and steering task at management level and defines core principles on responsibilities, control, compliance and data value. It effectively provides the organisational framework in which data governance is understood not merely as an IT topic, but as part of corporate governance.
From a technical and security perspective, data governance in the automotive context is difficult to imagine without ISO/IEC 27001 and ISO/IEC 27002. These information security management standards provide the structural basis for access controls, logging, risk management, third-party management and security by design i.e., precisely those elements that are decisive for controlled access to in-vehicle and backend data. In addition, ISO/IEC 27701 as a privacy extension plays a central role, because it provides governance structures specifically for personal data and thereby systematises processes around GDPR data subject rights, role models (controller/processor) and data protection impact assessments. In the automotive industry, standards building on this, such as TISAX, further specify corresponding mechanisms for certain industry use cases.
A frequently underestimated but very important building block particularly for regulatory data access obligations (e.g., RMI, diagnostic or telemetry data) is data quality. Here, ISO 8000 and ISO/IEC 25012 provide recognised models for data quality characteristics such as accuracy, completeness, consistency and traceability. They are relevant because regulatory “access to data” also means in practice that data must be usable, interpretable and technically processable.
Automotive-specific security and vehicle-related frameworks also come into play. Particularly central is ISO/SAE 21434 (Road Vehicles – Cybersecurity Engineering). This standard shapes how data access in the vehicle is technically secured, how risks from external access are assessed, and how security measures can be aligned with access requirements. Closely linked to this are the UNECE Regulations No. 155 (Cybersecurity Management System) and No. 156 (Software Update Management System), which are effectively binding via type-approval. They require documented management systems, role-based access concepts, auditability and end-to-end evidence core elements of a functioning data governance system in the vehicle context.
Quality management standards also indirectly influence data governance. IATF 16949, a central quality standard, addresses process stability, traceability, documentation requirements and supplier management. These aspects are decisive when data from control units, sensors or supplier systems must be integrated into an overarching governance model.
In the context of new European data access regimes particularly the Data Act models from the data-space and interoperability world are also gaining importance. These include architectures and governance concepts from International Data Spaces (IDS) as well as initiatives such as GAIA-X, which provide trust-based data sharing models, standardised usage conditions and technical access controls for federated data ecosystems. In addition, industry-driven best practices, for example from COVESA or the Auto-ISAC environment, serve as reference points for secure data architectures and governance patterns.
Specifically for the access to vehicle data in the vehicle environment, ADAXO ("Automotive Data Access – Extended and Open") has been developed specifically by the German Association of the Automotive Industry (VDA) as a framework to enable secure and fair access to vehicle data along the entire value chain – from data generation in the car to further processing for data-based services. In practice, ADAXO serves as a technical framework that defines how data is collected, transmitted, and shared via a standardized interface (typically via the so-called Extended Vehicle Model). With the Data Act and other regulatory developments, ADAXO is gaining additional practical significance because it is an existing model that fits into EU strategies.
In practice, this landscape creates a multi-layered “Automotive Data Governance Framework”: at the top strategic governance principles (ISO/IEC 38505), underneath information security and privacy management (ISO/IEC 27001/27701), supported by data quality standards (ISO 8000/ISO/IEC 25012), embedded in vehicle-specific cybersecurity and update requirements (ISO/SAE 21434, UNECE R155/R156), and complemented by automotive quality management (IATF 16949) and data-space models (IDS/GAIA-X). This combination forms a best-practice benchmark for how OEMs and service providers can integrate data access, security, compliance and technical implementation into a consistent governance system.
8. What are the legal consequences of an infringement?
A. Infringement of RMI / access to repair and maintenance information requirements (Regulation (EU) 2018/858 – “Type-Approval”)
In practice, disputes often arise between OEMs and service providers around additional conditions for RMI data access (mandatory registration, online obligations, proprietary dongles/subscriptions) that make the l access practically more difficult.
On the one hand, infringements in this area are relevant for type-approval compliance; in parallel, civil-law and antitrust claims may arise if independent operators are disadvantaged.
- Typical claimants: independent repairers, parts distributors, tool manufacturers, roadside assistance providers, testing organisations
- Subject matter of claims: access to RMI / OBD / diagnostic data streams within the legally prescribed scope
- Enforcement: via type-approval authorities / market surveillance authorities (market surveillance procedures / orders to take corrective measures up to restrictions on type-approval / making available on the market), national sanctions, and in addition civil-law claims for injunctive relief / performance (often combined with antitrust law) and harmonised administrative fines by the European Commission (in some cases in the multi-thousand range per non-compliant vehicle/system).
B. Infringement of EDR data (event data recorder) technical obligations and access
In practice, EDR infringements are primarily a type-approval and market surveillance issue: if data fields/integrity/read-out capability do not comply with the requirements, or if read-out capability within the permitted framework is not ensured, corrective measures by market surveillance authorities may follow. Data protection arguments do not “cure” technical infringements but can become additionally relevant if EDR data become (directly or indirectly) personal data.
- Typical claimants: type-approval authorities and market surveillance authorities; indirectly experts/accident assessors; in individual cases possibly also service providers (e.g., manufacturers of corresponding tools)
- Subject matter of claims: compliant EDR implementation (specified data fields, integrity/protection against manipulation, capability to be read out via OBD/DLC or alternatively at the module) and making available technical information on how to read out/interpret
- Enforcement: inspections and orders to take corrective measures by authorities (correction; possibly restriction of making available on the market/type-approval consequences), national sanctions and possibly EU-level administrative fines within the system framework (depending on the constellation); where personal data are involved, additional GDPR risks; civil-law and antitrust claims by third parties seeking information
C. Antitrust and competition law (Articles 101/102 TFEU; in Germany: GWB) – data access as an abuse/FRAND issue
Antitrust law becomes practically “sharp” when an OEM controls data access as a bottleneck and hinders competitors/independent operators through conditions, discrimination or tying. The risk increases because, in addition to cessation, significant administrative fines and follow-on damages claims may arise. Whether and to what extent such claims apply alongside other sector-specific claims must be assessed case by case.
- Typical claimants: competitors/independent operators (repairer chains, tool providers, telematics/service providers), associations, competition authorities (European Commission, Bundeskartellamt)
- Subject matter of claims: cessation/injunction against abusive foreclosure (e.g., refusal of essential data, discriminatory conditions, unfair prices, tying) and, where applicable, damages
- Enforcement: authority proceedings with corrective measures and administrative fines (European Commission up to 10% of group turnover), private injunctive and damages actions (procedurally facilitated, including access to evidence); often in parallel with RMI disputes
D. Data Act (Regulation (EU) 2023/2854) – penalties, complaints, judicial redress
If user rights (access/sharing) are not implemented “without undue delay” and in a practical manner, or if third parties (data recipients) are in fact not connected despite the user’s authorisation, national sanctions and corrective measures may follow. Where personal data are concerned, GDPR enforcement is an additional pressure factor. In addition, corresponding access claims may be enforceable under civil law by claimants. Blanket refusals invoking “cybersecurity” or “trade secrets” are sustainable only where narrowly and documented with specific reasons.
- Typical claimants: users (vehicle holders/lessees/fleet operators), designated third parties (e.g., repairer, insurer, telematics service) via the user; in special cases public sector bodies in situations of “exceptional need”; in supervisory measures competent authorities
- Subject matter of claims: access to data generated by use and the possibility to share with third parties; FRAND-oriented terms/fees vis-à-vis third parties (not vis-à-vis users); traceable application of safeguards (trade secrets/security)
- Enforcement: complaints to nationally competent authorities and judicial redress; national administrative fines/corrective measures under implementation; where personal data are involved, additional supervision/orders/administrative fines under the GDPR may apply
E. GDPR data access (Article 15 GDPR et seq.) – data subject rights and supervisory measures
In practice, the GDPR is the largest administrative-fine and reputational risk once telemetry, location and driving behaviour data are personal data (or easily linkable). Supervisory authorities expect timely, traceable processes. Total refusals are rarely sustainable. Defence typically succeeds through precise delineation, protection of third parties, and redaction/segmentation rather than “no” as the default response.
- Typical claimants: data subjects (drivers, vehicle holders, possibly co-users/passengers, employees in fleet contexts), data protection supervisory authorities
- Subject matter of claims: right of access/copy (Article 15), right to data portability (Article 20), and where applicable deletion/restriction (Articles 17/18) each relating to personal in-vehicle data
- Enforcement: complaint and supervisory orders (disclosure, process adjustment, erasure) and judicial redress; administrative fines up to EUR 20 million or 4% of worldwide annual turnover (depending on infringement category)
F. Road Traffic Act (StVG) (Germany; exemplary: Section 63a StVG) – disclosure claims in automated driving
In the StVG context, the main risk is less the classic “administrative fine” and more evidentiary and liability constellations: if relevant event/driving-mode data are not properly stored, erased, or made available in a dispute, procedural disadvantages (spoliation/adverse inference/secondary burden of pleading) and escalation of liability disputes may result. In parallel, the GDPR may apply where data are personal data and disclosure processes are not cleanly role based.
- Typical claimants: parties involved in accidents/injured parties, insurers (depending on legal basis), public authorities in investigative/administrative contexts; indirectly courts via procedural requirements
- Subject matter of claims: event and driving-mode data for automated driving functions (storage, access in dispute/event scenarios, consistent deletion periods); traceability for clarification of responsibility
- Enforcement: civil procedure via disclosure/injunction/damages constellations (depending on basis) and procedural consequences for missing data; in parallel data protection supervision/GDPR risks in case of unlawful processing/disclosure
8. What should OEMs and other data holders have “readily available” in order to defend themselves?
The strategy for defending against data access claims always depends heavily on the legal basis and the subject matter of the claim.
Article 61 of Regulation (EU) 2018/858 (RMI data) is, for example, not an optional service obligation but part of the type-approval compliance regime. In many cases, the defence therefore will not be based primarily on “no claim exists”. Otherwise, such a strategy can quickly turn into market surveillance procedures, communications with the type-approval authority, or allegations of systemic non-compliance. The strategic objective in such cases is therefore almost always: to control, narrow and structure claims not to block them across the board.
Experience shows that data access demands in this area tend to initially go beyond Article 61 (e.g., requests for access to proprietary development data, access to backend cloud systems, source code/algorithms, comfort, infotainment and usage data). This is where the greatest room for manoeuvre lies. Other levels within the limits of current case-law include cybersecurity. If data access endangers vehicle safety, enables unauthorised access to control units, or compromises over-the-air systems, the manufacturer may and must be able to restrict access. Similar considerations apply for data protection.
This strategy may look different for other legal bases and subject matters (including data access under the Data Act), because the supervisory risk profile can differ.
Irrespective of that, certain mechanisms have proven effective and significantly simplify fact finding and defense in dispute scenarios. These include:
- Playbook per legal basis (RMI/2018-858, Data Act, GDPR, antitrust) including standard responses, deadlines, escalation.
- Evidence of non-discriminatory practice (price lists, SLAs, technical equivalence, audit logs).
- Security justification file (specific threat models instead of blanket assertions; technical overviews for substantiation approaches).
- Trade secret governance (marking in metadata, trade secret register, catalogue of technical and organisational measures (TOMs)).
- Litigation readiness: documentation of why which data were made available / redacted / refused (crucial for authorities and courts).
