Continuous Monitoring Isn't 24/7

When a buyer asks for a VSOC, they're usually picturing a 24/7 SOC with a "V" in front of it — analysts on rotation, real-time dashboards, automated containment. That's the IT security operations model, and it's what most of them have been pitched. It works for laptops. It doesn't work for vehicles, and the gap between what was bought and what's actually needed is where programs end up retrofitting data foundations they should have built first.

The core misconception is this: "continuous monitoring" doesn't mean 24/7, and trying to make it mean 24/7 produces a worse program at higher cost.

What "continuous monitoring" actually requires

The purpose of a VSOC should be based on an organization’s overall vehicle cybersecurity program and aimed at achieving a better operational awareness of the cybersecurity of vehicles in the field. The relevant regulations and standards — UN R155, ISO/SAE 21434, NIST SP 800-137 — require monitoring sufficient to support risk-based decisions. None of them prescribe 24/7 staffing. None of them prescribe real-time responses. "Continuous" means uninterrupted in coverage. It does not mean instantaneous in reaction. Those are different problems, and conflating them is how budgets get burned on the wrong thing first.

Three reasons the IT SOC model doesn't transfer

None of these is theoretical. Each one shows up the first time a real engagement starts producing real alerts.

You can't isolate the asset. The IT SOC's standard response is to contain the endpoint — kill the process, block the IP, take the laptop off the network. A vehicle at highway speed cannot be isolated without creating a safety incident. Heavy equipment mid-operation cannot be disabled remotely. There is no at-will containment capability for cyber-physical systems in motion, which means the entire "detect and respond in minutes" loop that anchors an IT SOC is structurally unavailable here.

Response timelines are months, not minutes. When a VSOC validates a real event, the resolution path runs through engineering — root-cause analysis, fix design, validation, then a hardware refresh or an OTA cycle. Three to six months is a normal resolution window. Twenty-four/seven monitoring of a system whose remediation cadence is measured in quarters is a budget mismatch. You're paying weekend overtime to escalate something that's going to sit in an engineering backlog until the next firmware drop.

The data isn't a security feed. Raw vehicle telemetry — CAN traffic, diagnostic logs, telematics — is operational data that happens to contain a small percentage of security-relevant signals. IT SOCs spent thirty years separating security logs from infrastructure noise. The product world hasn't done that work yet. In a typical engagement, roughly 95% of inbound data has to be filtered out before the remaining 5% is even legible as a security signal. A SIEM by itself gets you to maybe 60% of the picture; the rest takes engineering judgment, stakeholders from cloud and app security, and an understanding of the specific product's normal behavior.

What a VSOC actually is

A working VSOC is closer to vulnerability management than to traditional SOC operations. Timelines are set by when engineering can act on a finding, not by detection latency. Status is tracked over weeks and months. Most of the labor is validation: is this event a farmer modifying their own tractor for more horsepower, or is it a safety-related cybersecurity threat? That validation work is engineering work. It requires people who understand the product, not just people watching a screen.

The phrase we use internally: a VSOC is engineered, not deployed. You don't buy it and turn it on, though some vendors would have you believe otherwise. You build the data pipeline, the detection logic, the validation playbook, and the escalation path — each one custom to the product architecture and the TARA outputs it inherits. Without that engineering foundation, a SIEM with a logo on it produces noise, not insight.

What this means for buyers

The practical shape of a working VSOC for most OEMs and suppliers looks like this: business-hours monitoring with a defined escalation model, a small team of analysts who coordinate directly with hardware and software engineering, and a tuned alert pipeline that surfaces material risks instead of drowning the team in operational noise. Extended coverage exists for specific high-stakes use cases, but it isn't the default and shouldn't be priced as the default.

What value looks like in a working VSOC: detection logic you can trace to specific TARA threat scenarios on that product, an alert handoff into a structured PSIRT triage — not a generic SOC analyst queue — and a documented path from finding to engineering remediation that actually closes. If a vendor can't show all three, what you're being sold is noise dampening, not product security monitoring. 

Stop trying to run an IT SOC against a fleet

That isn't the work. The work is engineering operational awareness into a product whose remediation cadence and safety constraints look nothing like an enterprise network. Build that, and "continuous monitoring" stops being a 24/7 staffing problem and starts being what it was supposed to be — a governance function that catches what matters and routes it to people who can fix it.

‍