The vehicle SOC (VSOC) and UN R155 post-approval monitoring

Approval is not the finish line

The most common misreading of UN R155 is that the certificate ends the work. It does not. UN R155 requires the Cyber Security Management System to detect and respond to attacks and to monitor cybersecurity across the post-production phase — the years a vehicle spends in the field after it leaves the line. A CSMS that is strong through development and silent afterwards does not meet the regulation, and the assessor will look for the monitoring capability specifically.

This is a structural feature of the regulation, not an optional extra. UN R155 grants a Certificate of Compliance for the CSMS valid three years, plus per-vehicle-type approval. That three-year validity only makes sense against a management system that keeps operating. A vehicle type approved today faces threats that did not exist at approval; the CSMS is the mechanism by which the manufacturer keeps up with them.

What "monitoring" actually means

Monitoring under UN R155 is not a single tool. It is a capability that spans three sources of signal, and the practical vehicle for it is a VSOC — a vehicle security operations centre.

The first source is the fleet itself: telematics and vehicle telemetry that reveal anomalies in how vehicles behave and communicate. The second is the backend — the servers, APIs and update infrastructure that sit behind the fleet and are themselves a threat surface, as UN R155 Annex 5 makes explicit under its back-end and communication-channel categories. The third is the outside world: newly disclosed vulnerabilities in components, libraries and protocols that a vehicle already in the field may inherit.

A VSOC's job is to bring these together, triage what matters, and turn signal into decision. That last step is the one assessors care about most. Alerts that go nowhere are not evidence of monitoring; a documented path from detection to vulnerability assessment to treatment is.

Why a VSOC is not just an IT SOC

Teams that already run an enterprise security operations centre sometimes assume it covers the vehicle obligation. It does not, and the differences are worth setting out plainly.

Dimension	IT SOC	VSOC
Primary telemetry	Enterprise IT logs, endpoints, network	Vehicle and telematics telemetry, backend, in-vehicle networks
Assets protected	Corporate systems and data	The fleet, the backend, and vehicle safety-relevant functions
Threat model	IT intrusion, data loss	In-vehicle network attacks, OTA abuse, backend compromise reaching the vehicle
Output	Incident response, containment	Feeds vulnerability management and software-update / RxSWIN decisions
Regulatory driver	General security policy	UN R155 post-production monitoring

The core difference is what the two functions watch and what their output triggers. An IT SOC contains an intrusion; a VSOC's finding may end in a software update pushed to the fleet and a corresponding change to the type's software identifier. How that update is delivered safely is a separate discipline, and the in-vehicle attacks a VSOC must recognise are covered in building an automotive VSOC.

The loop the regulation expects

Post-production monitoring is best understood as a loop rather than a list of tools.

Signals arrive from the fleet, the backend and external vulnerability sources. The VSOC triages them and runs a vulnerability assessment on anything credible. Where treatment is needed, the decision flows into vulnerability management, which may result in a software update. If that update changes the regulation-relevant software of a type, the RxSWIN — the Regulation X Software Identification Number that identifies a type's relevant software — changes and is reflected against the type approval. The outcome is recorded, and the record becomes evidence for the next assessment.

Every stage of that loop produces records, and the records are the point. UN R155 is assessed on evidence that a process ran, not on a description of a process that could run. A monitoring capability that cannot produce triage records, vulnerability assessments and the link into update decisions is not assessable, however sophisticated its tooling. This is the same evidence discipline that governs the initial assessment, set out in what evidence the assessor actually opens.

Where suppliers sit

The fleet a VSOC watches is built from components a manufacturer did not write. A newly disclosed vulnerability in a Tier-2 library is the manufacturer's problem the moment it ships in a vehicle, even though the OEM did not author the code. Post-production monitoring therefore depends on the same supplier relationships that the development-phase CSMS relies on: the ability to reach into the supply chain, understand what is in the software, and get a fix. ISO/SAE 21434, the cybersecurity engineering standard UN R155 leans on, frames these relationships through cybersecurity interface agreements. Monitoring without a supply-chain path to remediation detects problems it cannot fix.

The AutoSifu view

Post-production monitoring is where a CSMS proves it is a living management system rather than a document produced for one audit. AutoSifu works with CIRT as one route — compliance, solutioning and CoC/VTA support with the approval body in the room — so the VSOC is built to feed the vulnerability-management and RxSWIN decisions the assessor will later check. The certificate lasts three years; the monitoring has to earn it every day in between.