From Policy to Practice: 7 Essentials for Effective Automotive Cybersecurity Governance

Let’s be upfront: the seven essentials are somewhat tricky. Organizations, development projects, structures, and processes are so multifaceted that no clipboard checklist can be pulled out in actual practice. Accordingly, the seven essentials we present here are not necessarily to be viewed sequentially. Rather, they are intended to provide well-founded insights based on real consulting practice from recent years.

1. Cybersecurity Policies: Only with Genuine Executive Commitment [RQ-05-01]

Let’s actually begin with the first requirement that ISO/SAE 21434:2021 establishes: A lean, company-wide known cybersecurity policy as a starting point. It contains the commitment to cyber risks in road vehicles. (Sounds trivial but is immensely important: recognizing that one’s own work does indeed carry cybersecurity-relevant risks.)

This involves clear objectives and linkage to corporate goals, combined with tangible commitment from executive management. Why? Without a binding policy supported by top management, projects lack orientation; measures become inconsistent, and gaps in approaches and associated documentation are inevitable.

Actually remarkable: ISO/SAE 21434 explicitly requires a management-authorized cybersecurity policy – including commitment from executive leadership to actively manage the risks. In practice, this means:

• Genuine signal from the top: Signature by CEO/CTO and internal publication (intranet, postings) ensure visibility and backing. (Increasingly important in today’s environment.) At the same time, management commitment should effectively contribute to providing resources.
• Integration: The policy should not exist in isolation, but rather reference follow-up components – e.g., applicable processes, responsibilities, and resource allocation. Simultaneously, a well-founded policy strengthens the integration between departmental objectives and the overall organization.
• Clear framework: It can also include statements on general risk treatment (e.g., cybersecurity strategy or vulnerability handling in the field, among others), so that projects have tangible guidelines.

2. Rules & Processes that Effectively Guide Daily Vehicle Security Operations – Including Supplier and Distributed Development Documents [RQ-05-02]

Nobody really wants to hear about new processes in the complex automotive environment. Except in rare cases when something actually works as intended. Then it’s: Good thing we have this process for that. Even in consideration of cybersecurity, they are therefore indispensable: Concrete, traceable processes (“What is done how and with what?”) that are integrated into existing company workflows.

This also includes clearly defined approaches for distributed development activities with suppliers and in the multi-layered development collaborations. Why? Uniform rules ensure consistency across all projects, reduce onboarding time and errors.

Furthermore, ISO/SAE 21434 requires organization-specific cybersecurity processes across the entire product lifecycle – from the concept phase to decommissioning – including proper methodologically-correct implementation of Threat Analysis & Risk Assessment (TARA), Incident Response, Monitoring, and vulnerability management. Important here: organization-specific. While ISO/SAE 21434 templates can be used here and there, tailoring and adaptation to actual internal workflows inevitably becomes necessary.

Without systematized implementation of the mentioned artifacts, each project improvises regarding cybersecurity and important requirements (e.g., also those for suppliers) remain unfulfilled. So what becomes important?

• Define process landscape: Build a hierarchy (guideline → process → method → tool) and connect to existing quality assurance and engineering processes (e.g., change, requirements, documentation, configuration management).
• Seriously involve suppliers in cybersecurity topics: For distributed development, align clear expectation documents (needs/expectations) and responsibilities (RACI matrix between OEM and supplier). Contract-relevant documents – such as the Cybersecurity Interface Agreement (CIA) according to ISO/SAE 21434 – establish who assumes which security activities, how results are shared, and how controlled tailoring/reuse takes place.
• Provide templates: Standardized templates and work aids used organization-wide and project-wide (e.g., for cybersecurity plans, assessments, and reports) can help obtain consistent work products both internally and with suppliers.

Especially considering that there are no one-size-fits-all solutions here (compare, for example, the structures of global OEMs with those of technology providers in the SME environment), it’s important to note: A sensible first step to integrate cybersecurity into defined processes is to systematize implicit knowledge and “lived working methods.” Only this way can consistent quality, efficient resource utilization, and scalability be achieved.

3. Often Underestimated: Clear Cybersecurity Roles, Responsibilities & Stakeholder Communication

A clearly defined role and responsibility model (e.g., Cybersecurity Manager, Project Cybersecurity Coordinator, PSIRT Lead) as well as planned information flow between all stakeholders is the foundation of successful vehicle security. Without clear accountabilities, tasks fall through the cracks; auditors typically recognize immediately when responsibilities are unclearly assigned and requirements are consequently not implemented. ISO/SAE 21434 therefore specifies assigning responsibilities and equipping them with authority. Especially the latter ultimately determines whether a paper tiger emerges in the company or whether measures can be taken (even against resistance). Best practices like RACI matrices ensure transparency in projects. So what needs to be done?

• Organizational chart & guidelines: Anchor roles and escalation paths in the organizational handbook. For example, it should be clearly described who functions as the Cybersecurity Owner at the department management level (often a senior manager with budget and directive authority). Pro tip: Also ensure that existing and new employees are truly aware of the existence of these materials.
• Stakeholder analysis: Identify all affected areas – R&D, development, procurement, quality, legal, Information Security/ISMS, after-sales, etc. – and create a communication plan. This defines how and when information flows between, for example, development teams, the central cybersecurity team, and the Product Security Incident Response Team (PSIRT) (among others).
• Needs-based training & awareness: No, sending the security colleagues to a training once is not what’s meant here. Rather, ensure that all responsible parties understand their role and have the necessary specific security competencies. Regular coordination meetings (such as a Cybersecurity Board or SteerCo) help to stay informed across departments.

In practice, misunderstandings repeatedly arise between roles at the organizational level (e.g., Head of Cybersecurity), where responsibility lies in establishing cybersecurity at the company level, and those in projects, where it’s about making a product more secure (e.g., Cybersecurity Engineer). At the same time, defined roles in a process must not be confused with job descriptions – another frequent starting point for ambiguities.

4. “Security? That colleague isn’t here right now.” Resource & Competence Management as an Ongoing Task

Yes, just ask us. We’ve experienced it for years and in nearly every organization: cybersecurity is pushed to the sidelines as a rather unpopular support function.

However, providing personnel, time, and tools as well as structured competence management are still necessary. This is actually often misunderstood: UN R155 and ISO/SAE 21434 require truly robust CSMS capabilities in practice – without skills and tools, cybersecurity remains theory. That’s no longer sufficient. Organizations, departments, and teams must have adequate resources (qualified employees, suitable tools, etc.) to fulfill their work in accordance with requirements and competently. No question: This is additional effort that must be managed. But there’s no other way. This includes:

Skill matrix & training plan: Define the required capabilities for each role. Create a qualification matrix and plan training (e.g., annual training goals per employee). This also includes awareness of new threats and technologies. This doesn’t have to become rocket science – not everyone needs to become an expert. There just needs to be clarity about the relevant aspects in each work area. Only this way can work capability be consistently ensured in this fast-paced domain.

Manage tool landscape: Create a complete directory of all relevant cybersecurity tools (for TARA, requirements management, V&V tests, SBOM/vulnerability management, etc.), including responsible parties and qualification status. It’s important to demonstrate that the use of these tools doesn’t negatively impact cybersecurity, for example through regular tool reviews or verification of tool results. A starting point for this can be synergy with Functional Safety, which also must evaluate and qualify software tools according to ISO 26262. Beyond this, it can be helpful to engage professional external assistance.

Plan capacities proactively: Cybersecurity activities should be documented in project plans with dedicated effort (buffer for TARA workshops, penetration tests, incident exercises, etc.). Conduct quarterly management reviews. Check metrics such as the number of completed work products, aligned requirements, tests performed (among others). (This review should take place both at the project/product development level and at the organizational level – with metrics such as training rate, number of discovered vulnerabilities, or audits conducted.)

5. Automotive Cybersecurity Remains a Matter of Culture and Information Exchange

You’ve surely also been to professional events on vehicle cybersecurity and spoken with other stakeholders there. How refreshing could the entire field of automotive cybersecurity be if people worked more with each other instead of against each other or not at all?

Measures for security culture (awareness campaigns, “speak-up” mentality, lessons learned) as well as regulated handling of confidential information must be standard today.

Corporate culture is part of ongoing organizational activities; without acceptance and mindset, even the best processes fail – that’s a fact.

Moreover, effective cybersecurity requires cross-functional information sharing – internally (between Security, IT, Safety, etc.) and especially in a meaningful way externally as well (with suppliers, service providers, but also industry bodies, etc.).

Not coincidentally, ISO/SAE 21434 explicitly requires fostering a strong cybersecurity culture. This includes:

Increase awareness: Launch security awareness campaigns (e.g., testing as an entry point into security topics, brown-bag sessions on security topics, visible Security Champions in development teams). Departments and teams must understand cybersecurity as a shared value – from development to management. Internal newsletters or lunch-and-learn formats can address current threats or incidents and thus continuously raise awareness. Important: Awareness is not “one and done” – A one-time campaign fades after a short time. The topic must be repeated regularly.

Lessons learned & “blameless” culture: Establish mechanisms to learn from incidents and near-misses (post-mortems, root-cause analyses) and share these insights while maintaining confidentiality. Employees should be able to escalate security problems without fear of blame.

Regulate sensitive information exchange: Establish binding processes for handling highly sensitive cybersecurity documents – such as penetration test results or vulnerability reports. Where possible, grant external auditors only on-site access (or via screen-sharing) instead of releasing documents. Additionally, define clear classification criteria and release processes for security-relevant information to maintain their confidentiality. In daily practice, actively selecting confidentiality levels (e.g., for emails or documents) directly promotes security awareness and establishes data protection and confidentiality as a matter of course. In practice, systems like Outlook or SharePoint can be configured so that employees are required to select a classification level for every external email or upload – a small step with major governance impact.

6. Automotive Cybersecurity Audit & Assessment Programs – Focus instead of Certificate Hunting

At the organizational level, regular CSMS audits should (or on the manufacturer side: must) take place (both internal and external), while at the project level, targeted assessments verify effectiveness in individual development projects. Why? The UN R155 Conformity Audit (for the Certificate of Compliance) examines the company’s entire Cybersecurity Management System – meaning the organizational processes and their implementation. ISO/SAE 21434 itself, however, is still not a certifiable standard, but rather a best-practice framework.

Priority therefore lies with the effectiveness of measures, not with displaying an ISO certificate. Accordingly, a systematized ISO/SAE 21434 gap analysis (if in doubt, also with external support) is the right approach, while pursuing certifications for specific use cases, categories, products, etc. is likely often putting the cart before the horse.

A structured audit program can help ensure that you’re not blindly producing documents “for the auditor,” but rather achieving genuine continuous improvement. How?

Establish audit lifecycle: Use ISO 19011 and ISO/PAS 5112 as guidelines to build an audit program. Plan annual internal CSMS audits (against your own processes or ISO/SAE 21434 criteria; or also considering ENX VCS) as well as an external audit by a Technical Service every three years (for UN R155 CoC). Each audit should go through the full cycle: Initiation → Preparation → Execution → Report → Closing meeting → Follow-up.

Set priorities: Design project-related cybersecurity assessments as a complement. These can be conducted before milestones (e.g., before SOP of a vehicle) to evaluate the implementation of cybersecurity in concrete products. This way you link the organizational audit with practical effectiveness verification.

Handling sensitive data: Train teams on how to handle audit requests. Auditors often want to see confidential details (e.g., regarding current vulnerabilities). This requires tact: Prepare an audit readiness plan that defines what evidence-based information is shown and how. Some companies, for example, don’t allow removal of documents, only on-site inspection – this should be documented in the audit plan.

Evaluation & tracking: Define uniform evaluation criteria for audit findings, e.g., for Conformity, Minor Non-Conformity, or Major Non-Conformity. This way audit results can be clearly classified. Each finding must be provided with corrective actions and tracked. Feed the insights back into the CSMS (continuous improvement loop) to eliminate deficiencies by the next audit.

Here too, responsibilities and contacts: Also regarding audits and assessments, and especially with regard to documents and elaborations to be presented, it must always be traceable who is responsible for what and how at which point, and what the associated communication and information channels look like.

Specify concrete audit scope: Which audit is it even about? UN R155, GB 44495, South Korean regulation, the (emerging) Indian regulation? Sure, there are large overlaps, but you need to address the specific priorities and separate requirements. You know your role in the supply chain and current or future target markets. Early determination of scope is often more advisable than retrofitting the CSMS later.

7. Supporting Processes, genuine continuous Improvement and Integration with QMS, Risk Management, Tool Management

Okay, all of the above is well and good – but how does this really work in practice? The load-bearing walls of governance are an effective Quality Management System (according to ISO 9001 / IATF 16949), established enterprise risk management (ISO 31000), and defined mechanisms for continuous improvement.

A fundamental tool management also belongs here (regulations for tool versioning, qualification, access rights, backups, etc.).

Without these supporting processes, cybersecurity measures ultimately often remain inefficient.

Many audit questions target exactly these fundamentals, e.g.,

• Does a configuration management exist?
• How is it ensured that changes are traceably documented?

When gaps emerge here, the entire cybersecurity governance becomes unstable. ISO/SAE 21434 expressly requires that cybersecurity be integrated into all relevant disciplines and processes – which is hardly possible without a mature QMS.

A very simple example: If the QMS lacks a defined process for reviewing and releasing new or modified processes (e.g., CSMS processes), it remains unclear who is even authorized to approve such adaptations. This leads to uncertainties in responsibility and evidence provision – and at the latest during an audit, to critical questions. A robust QMS creates clarity and accountability here.

Among other things, it is therefore necessary to consider:

• Provide QMS evidence: Ensure that core processes such as requirements and change management, documentation, and configuration management are functional and auditable. Cybersecurity should be seamlessly integrated into these workflows (e.g., Security as a mandatory part of the Change Control Board, security requirements as part of requirements management, etc.). An existing, certified QMS (ISO 9001/IATF 16949) is the foundation; cybersecurity must be anchored within it. Want a practical example? Retention requirements for cybersecurity-relevant data and documents (according to UN R155: 10 years after EOP) should be anchored in the QMS process for data storage.
• Risk management at organizational level: While the Threat-Analysis-and-Risk-Assessment methodology is certainly fun in the security field, be sure to supplement Enterprise Risk Management (according to ISO 31000) with (product/vehicle) cybersecurity aspects. This means cyber risks should be maintained in the enterprise risk register and regularly discussed before top management – analogous to financial or supply chain risks. This gives cybersecurity topics the necessary priority and ensures that risks are not only considered at the project level.
• Continuous improvement (CIP): Implement a formal continuous improvement process for cybersecurity. This includes management reviews of CSMS activities (e.g., semi-annual reporting of cybersecurity KPIs (Yes, exactly!) to executive management) and regular lessons learned workshops. Utilize audit and assessment results: Findings from audits should be converted into measures and their effectiveness should be checked after some time. This PDCA cycle (Plan-Do-Check-Act) keeps governance alive and evidence-based.
• Tool governance: Establish clear guidelines for the use of development and security tools. Which tool versions are approved? How is a new tool qualified or validated before being used for security tasks? How are tool configurations secured (backups) and access controlled? Clean tool governance (ideally part of the QMS) prevents faulty tools from leading to security vulnerabilities and signals to auditors orderly processes in digital tools. At the same time, this is a prime example of how CSMS and IT security should be interlocked: only coordinated development and IT tool landscapes create a consistently secure working environment.

From Skepticism to Strategy: Effective Automotive Cybersecurity Governance as a Driver for the Vehicle Industry

Let’s revisit the skepticism of many practitioners toward governance and cybersecurity policies mentioned at the beginning: Where does this reluctance come from? The answer is obvious: In quite a few companies, clearly defined responsibilities, truly consistent processes, and established control mechanisms are often missing, even independent of cybersecurity. So it’s no wonder that additional governance is initially viewed critically.

Truly effective governance, especially in the still young field of automotive cybersecurity, only emerges where responsibility, transparency, and demonstrable effectiveness merge together.

Companies that today systematically build and continuously develop commitment and implementation of their cybersecurity governance benefit in multiple ways: They not only reduce cyber risks, but may simultaneously catch up on creating missing fundamentals – such as clear responsibilities, consistent processes, and qualified tooling. Thus, cybersecurity becomes a building block for higher speed and increased efficiency (see also Cybersecurity as a lever for cost reduction).

At the same time, and there is consensus among experts on this, trust in cybersecurity will advance to become an integral component of business excellence in the future.

In this regard too, product and vehicle cybersecurity can learn from colleagues in information security, who already have many years of experience in this field – for better or worse.