Most OT-to-SOC integration advice treats this as a data problem. Get the telemetry flowing, normalise it, enrich it, and the SOC can finally see the plant floor. Chinna Botla’s recent piece on integrating OT telemetry into enterprise SOCs is a clean version of that argument, and the direction is right.
Underneath, though, this is mostly a human problem, and telemetry is a technical answer to it. The order that works runs people, then process, then technology. Telemetry is the technology step. It usually comes first, because it’s the part the security team controls and the part suppliers sell, and it pays off once the people and the process are in place.
So telemetry in the SOC is the easy 80%. The 20% that decides the outcome lives in the two steps it skips. Who owns the assets, that’s the people. How a detection becomes a safe action, that’s the process. Miss those two steps and you’ve bought a clearer view of a problem you still can’t act on.
What the piece gets right
The practical advice is sound. Start with one high-value process area. Pick eight to ten critical data points rather than trying to instrument everything. Use protocol-aware collectors, keep the data flows tightly controlled, involve OT engineers early. That is roughly how you should start, and it matches how I began a global OT security programme across 40+ manufacturing sites. Narrow scope first, prove value, expand.
The strongest idea in the piece is correlation. A suspicious login on the business network, sitting next to unusual behaviour on a pump, tells you something neither signal reveals alone. That is real, and it is exactly the kind of context an enterprise SOC is built to spot.
So this isn’t a teardown. It’s the next layer.
Telemetry is a data problem. OT-to-SOC is an ownership problem.
Start with the people. Read the integration write-ups closely and notice the grammar. Telemetry is “brought into” the SOC. Analysts are “trained on what normal looks like.” Operations are “involved early.” The SOC is the subject of every sentence. OT is a feed, and a stakeholder to be onboarded.
In a real plant, the authority runs the other way.
The automation and process-control teams own the controller. They own the change window, the safety case, and the definition of normal. Normal is not something an analyst learns from a fortnight of baselining. It is something the engineer who commissioned the loop already knows, including the seasonal quirks and the one pump that always runs hot. Pull that into an alert-tuning exercise and you get a thin copy of what the asset owner already holds.
This matters because the asset owner is the decision maker. They own the operational consequences of any downtime, and security decisions about their assets should reflect that accountability. Routing OT telemetry to the SOC does not move that accountability. It gives the SOC a better view of assets it still cannot touch.
Process, not packets
One more limit, and Joe Weiss has been making it for years. The telemetry most platforms collect is network-observable. Asset discovery, flow metadata, remote sessions, configuration changes. All of it sits at Purdue Levels 2 and 3. None of it sees the process physics, the actual sensor values, the Level 0 and 1 reality where equipment damage and safety events happen. Network monitoring reduces the likelihood of compromise. It does little about the consequences of a sensor that drifts, a controller that fails, or an engineering error. That is Weiss’s distinction between the cyber and the engineering, and it holds. “Now you can see the plant floor” is true only for the part of the plant floor that speaks Ethernet.
Detection without response is a faster alarm
Here is the test the visibility framing skips. An OT alert fires. Then what?
In IT, the analyst has options. Isolate the host. Disable the account. Kill the process. In OT, those same actions can trip a line or create a safety event. The SOC analyst cannot, and must not, unilaterally act on the process network. Response has to route through operations and the automation team, the people who know whether isolating that one device drops a safety interlock.
Before our programme, we once detected malware on OT assets and knew almost nothing about them. The naming convention was English, so the infected devices were somewhere across our English-speaking sites. We spent weeks chasing contacts across countries and time zones to work out what the assets were, who owned them, and whether they were business-critical. After we built the asset inventory, with ownership and criticality mapped, the same class of incident took minutes. Not because the inventory stopped the malware. Because it connected detection to the people who could act.
That is the lesson most SOC-integration pitches miss. The value of telemetry in the SOC is not the alert. It is whether the alert reaches someone who can do something about it, safely and fast. If the integration delivers detection but no agreed response path into the automation team, you have built a quicker way to notice things you still cannot act on. That is one false positive away from being switched off, the morning it trips production for nothing.
You already run a connected response model
There is a shortcut most cyber teams walk past. The mill already has a connected response model. It is called safety.
Process-safety incident response is mature, drilled, and understood at mill level. Who gets alerted, who holds the authority to stop the line, how an event escalates, where command sits during a serious incident. All of that already exists, and people have practised it. You do not need to invent an OT-cyber response process from a blank page. You need to extend one that already works.
The shape stays the same. What changes is the content. A mechanical or process-safety event pulls operations and maintenance through a known sequence. A suspected compromise on a controller rides the same escalation spine, but the diagnostic actions are different and the people in the room are different. Automation engineers, OT security, often supplier support. Same process, different actions, different responders.
That is the connected response model worth building. Cyber response wired into the safety response the site already trusts, not a parallel runbook in the SOC that the plant has never drilled and will not follow at three in the morning.
What to do with this
The practical advice in the original piece still holds. Add one step in front of it.
When you pick that first high-value process area, the first artefact isn’t the data-flow diagram. It’s the agreement on who acts on what. Sit down with the automation team and co-produce two things before a single packet moves:
- A criticality model. Which assets matter, and why.
- A response playbook. Who does what when an alert fires, who can veto an action on safety grounds, and how it plugs into the mill’s existing safety incident process.
Then wire the telemetry to that. People first, then process, then technology. Do it in this order and the telemetry lands somewhere. Do it the other way round and you get a dashboard.
The integration that matters is between people
Getting OT telemetry into the SOC is worth doing, and Botla’s starting points are the right ones. But you can’t buy your way past the sequence. The people own the assets. The process turns a detection into a safe action. The telemetry only earns its keep once those two are in place. Lead with the technology and you get a faster alarm. The integration that matters was never between the OT network and the SIEM. It is between the security team and the people who own the consequences.
I advise manufacturing companies on security governance and risk management. If this resonates with challenges in your organisation, get in touch.