Why the Gap Matters More Than the Regulation Itself
UN R155 introduced a formal requirement for a Cybersecurity Management System (CSMS) in automotive development.
On paper, the regulation appears clear: manufacturers must demonstrate that cybersecurity risks are systematically identified, managed, and continuously monitored across the vehicle lifecycle.
In practice, however, a recurring gap emerges—not between the regulation and technology, but between what auditors expect to see and how engineering organizations actually operate under real delivery constraints.
This article examines that gap from a system and organizational perspective, focusing on why it persists and how it quietly undermines both compliance and security outcomes.
UN R155 represents a regulatory shift in how automotive cybersecurity is evaluated.
Rather than assessing security as a set of technical features or test results, the regulation treats cybersecurity as a management responsibility, requiring organizations to prove that risk handling is structured, repeatable, and resilient to change.
At the center of this requirement is CSMS.
Not as a security control or toolchain, but as a management framework that governs how cybersecurity decisions are made, recorded, reviewed, and improved over time. This distinction is subtle but critical, because many of the difficulties surrounding UN R155 originate from misunderstanding what CSMS is meant to demonstrate.
From a market perspective, this shift carries direct consequences.
Today, the European Union has made UN R155/156 compliance a formal part of EU type approval, with phased applicability that moved from new vehicle types to all new vehicles. As a result, CSMS is no longer an internal policy choice—it has become a prerequisite for accessing regulated markets.
What Auditors Expect from a CSMS
From an audit perspective, CSMS is evaluated primarily as a governance system. Auditors are not reviewing source code or cryptographic algorithms; instead, they look for evidence that cybersecurity is institutionalized across the organization.
Typical audit expectations include:
- Clear ownership and accountability
Defined responsibility for cybersecurity decision-making, escalation paths, and risk acceptance. - Lifecycle-wide risk management
Evidence that cybersecurity risks are identified early and revisited as systems, suppliers, and architectures evolve. - Traceability of decisions
Clear links between identified risks, mitigation strategies, and the rationale behind acceptance or rejection. - Consistency across vehicle programs
A CSMS that applies at the organizational level, rather than being recreated for each individual project.
In essence, auditors are evaluating whether cybersecurity behaves like a managed system, not an ad-hoc collection of activities.
What Engineering Teams Actually Do
Engineering organizations rarely resist CSMS intentionally. The gap usually emerges from how product development actually works.
Most teams operate in a project-centric model, optimized for delivering vehicles under fixed schedules and cost constraints. Cybersecurity tasks are distributed across architecture, software, IT, and supplier teams, often without a single operational owner responsible for maintaining cross-project coherence.
Security activities also tend to start late.
By the time cybersecurity reviews or assessments begin, key architectural decisions may already be locked, leaving limited room for structural change. Documentation, meanwhile, is frequently treated as a byproduct—assembled retrospectively to satisfy audit requests rather than generated naturally during development.
As a result, organizations may deliver technically robust products while still struggling to demonstrate CSMS integrity during audits.
Where the Gap Becomes Visible
The mismatch between audit expectations and engineering reality becomes most visible during formal assessments. Certain questions surface repeatedly:
- Who formally accepts cybersecurity risk, and at what organizational level?
- How are risks re-evaluated after architectural or supplier changes?
- How do project-level security decisions influence future vehicle programs?
- Where is the evidence of continuous improvement?
Engineering teams usually have practical answers to these questions.
What they often lack is structural alignment—a way to present those answers within a coherent, organization-wide CSMS narrative.
The issue is not absence of effort, but absence of a shared frame of reference.
Why the Gap Persists
Several structural factors make this gap difficult to close:
- CSMS is organizational, not technical
Engineering cultures excel at solving technical problems, not at modeling governance structures. - Audits reward clarity, not activity
What matters is not how much work was done, but how clearly decisions are justified and documented. - Cybersecurity maturity evolves unevenly
Advanced technical controls often coexist with immature process integration. - Delivery pressure reshapes priorities
Under schedule constraints, cybersecurity activities tend to become reactive and localized.
These conditions are not exceptional. They are common across complex automotive development environments.
Bridging the Gap Without Overengineering
Effective alignment does not require heavier processes or more documents. In practice, it often involves a small number of focused adjustments:
- Explicit decision points
Clearly defining where cybersecurity decisions are made and recorded. - Minimal, standardized CSMS artifacts
A limited set of outputs reused consistently across projects. - System-level ownership
Responsibility assigned above individual programs, but close to engineering reality. - Audit-aware workflows
Development processes that naturally generate evidence as part of normal work.
When CSMS supports engineering instead of constraining it, compliance and real security outcomes improve together.
Conclusion
UN R155 does not fail because its requirements are unrealistic.
It fails when organizations assume that strong technical security automatically satisfies regulatory expectations.
Auditors evaluate systems.
Engineering teams build products.
A CSMS succeeds only when it connects those two worlds—without forcing either to abandon how they actually work.