Guides

What is a SOC for OT? Security operations for industrial systems

Key takeaways

An OT SOC watches the networks and assets that control physical processes, not just office IT.
Monitoring is mostly passive (SPAN/TAP sensors) because active scanning can disrupt fragile control equipment.
Detection needs industrial protocol knowledge (Modbus, S7, DNP3, OPC UA) and a baseline of normal process behaviour.
Response decisions are shared with the control room — safety and uptime come first.
NIS2, IEC 62443 and NIST SP 800-82 all expect continuous monitoring and incident handling for critical OT.

Term

A SOC for OT

is a security operations center that continuously monitors operational technology (OT) — the systems that control physical processes — for cyber threats, and coordinates incident response together with plant operations.

What does a SOC for OT do?

A SOC for OT does the same four jobs as any security operations center — see, detect, respond and improve — but in an environment where the “endpoints” are programmable logic controllers (PLCs), remote terminal units (RTUs), human-machine interfaces (HMIs), engineering workstations and historians.

Visibility. Build and maintain an inventory of OT assets, their firmware and their communication relationships, largely from passive network traffic.
Detection. Spot behaviour that indicates an attack or a dangerous change: a new engineering connection to a PLC, an unexpected program download, a write to a safety-relevant parameter, or a known ICS malware pattern.
Response. Triage alerts with process context, escalate to the control room and coordinate containment that does not endanger safety or production.
Improvement. Feed lessons back into segmentation, remote-access rules, detection use cases and the asset owner’s risk register.

Which systems does an OT SOC monitor?

The scope is usually described with the Purdue model. An OT SOC concentrates on levels 1 to 3 and the industrial DMZ, where attacks on control systems become visible on the network.

Passive sensor (SPAN/TAP) — Purdue model with typical OT SOC monitoring points

Typical telemetry sources are:

Passive network sensors on SPAN ports or network TAPs between levels 1–2, 2–3 and at the industrial DMZ. They decode industrial protocols such as Modbus/TCP, S7comm, PROFINET, EtherNet/IP, DNP3, IEC 60870-5-104, IEC 61850 and OPC UA.
Logs from Windows-based OT hosts — HMIs, engineering workstations, historians and domain controllers in the OT domain.
Firewalls, data diodes and remote-access gateways that guard the conduits between zones (in IEC 62443 terms).
Change and maintenance information from operations, so that a planned PLC download is not mistaken for an attack.

How is an OT SOC different from an IT SOC?

The tooling looks similar — a SIEM, case management, threat intelligence — but the priorities are reversed. In IT, confidentiality usually comes first and an infected laptop is isolated within minutes. In OT, availability and safety come first, and isolating the wrong controller can stop a production line or create a hazardous situation.

IT SOC vs OT SOC at a glance
Aspect	IT SOC	OT SOC
Primary priority	Confidentiality and integrity of data	Safety, availability and integrity of the physical process
Main telemetry	EDR agents, identity and cloud logs	Passive network sensors, OT host logs, firewall and remote-access logs
Protocols	HTTP(S), DNS, SMB, Kerberos	Modbus, S7comm, PROFINET, DNP3, IEC 104, OPC UA
Containment	Automated isolation is common	Coordinated with the control room; automation is rare
Patching	Days to weeks	Months to years, often only during planned shutdowns
Key frameworks	MITRE ATT&CK Enterprise, NIST CSF	MITRE ATT&CK for ICS, IEC 62443, NIST SP 800-82

We cover these differences in depth in IT SOC vs OT SOC.

What does an OT SOC detect?

Good OT detection combines three approaches: asset and behaviour baselines (what normally talks to what, and how), threat-informed use cases mapped to MITRE ATT&CK for ICS, and known indicators from ICS-specific threat intelligence. Examples of high-value use cases:

T0843 Program Download to a PLC outside a maintenance window.
T0836 Modify Parameter on setpoints or alarm limits.
T0855 Unauthorized Command Message such as a stop command from an unexpected host.
T0886 Remote Services used by a third-party vendor account at an unusual time.
T0846 Remote System Discovery — network scanning inside the control network.

How does incident response work in OT?

Incident response in OT follows the same lifecycle as in IT — prepare, identify, contain, eradicate, recover, learn — but every step is agreed with the people who run the process. NIST’s DFIR framework for OT (NISTIR 8428) is a useful reference.

In practice this means: a named contact in the control room for every site, pre-agreed containment options per zone (for example, closing the remote-access conduit rather than isolating a controller), out-of-band communication, and verified backups of PLC logic and configurations.

Which SOC models exist for OT?

Researchers at SINTEF and NTNU distinguish five models: an integrated IT/OT SOC, a dedicated OT SOC, an in-house SOC, an outsourced (managed) SOC and a vendor-operated SOC run by the automation supplier. Many organisations combine them, for example an in-house IT SOC with a managed OT detection service. The right choice depends on the number of sites, available OT expertise and regulatory obligations.

Which regulations and standards require OT monitoring?

NIS2 (Directive (EU) 2022/2555) requires essential and important entities to take risk-management measures including incident handling, and to report significant incidents with an early warning within 24 hours. See NIS2 and OT monitoring.
IEC 62443-3-3 includes system requirements for audit logs and continuous monitoring (SR 6.1 and SR 6.2).
NIST SP 800-82 Rev. 3 recommends continuous monitoring and an OT-specific incident response capability.
National laws add detail: the Dutch Cyberbeveiligingswet and the German BSI Act (§31 BSIG, attack detection systems for operators of critical facilities).

How do you get started with a SOC for OT?

Agree on scope and ownership between IT security and operations — including who decides on containment.
Map the network to Purdue levels and IEC 62443 zones and conduits, and pick sensor locations.
Deploy passive monitoring at the most critical conduits first and build the asset inventory.
Define a first set of use cases (10–20) mapped to MITRE ATT&CK for ICS, with response playbooks per site.
Choose an operating model — in-house, managed or hybrid — and test it with a tabletop exercise that includes the control room.

Frequently asked questions

What does SOC for OT mean?

SOC for OT means a security operations center whose scope includes operational technology — the industrial control systems that run plants, utilities and infrastructure. It combines people, processes and tooling to detect, analyse and respond to cyber threats in those environments.

Can my existing IT SOC monitor OT?

Partly. An IT SOC can extend into OT when it receives OT-specific telemetry (from passive network sensors), understands industrial protocols and has agreed escalation paths with operations. Without those three, alerts from OT tend to be misunderstood or ignored.

Do I need agents on PLCs or HMIs to monitor OT?

Usually not. Most OT monitoring is passive network analysis via SPAN ports or network TAPs, supplemented with logs from Windows-based OT hosts, firewalls and remote-access gateways. Agents are only installed where the asset owner and vendor support them.

Is an OT SOC required by NIS2?

NIS2 does not prescribe a SOC by name, but it requires risk-management measures including incident handling (Article 21) and reporting significant incidents within 24 hours (early warning) and 72 hours (notification). For organisations with critical OT, meeting those obligations in practice requires continuous monitoring — which is what an OT SOC provides.

Sources

NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security — National Institute of Standards and Technology
MITRE ATT&CK for ICS matrix — MITRE
Directive (EU) 2022/2555 (NIS2) — EUR-Lex
ISA/IEC 62443 series of standards — International Society of Automation
NISTIR 8428: Digital Forensics and Incident Response (DFIR) Framework for OT — National Institute of Standards and Technology
A Comparative Study of SOC Models for Operational Technology — SINTEF / NTNU

IT SOC vs OT SOC: 10 differences that matter in industry

How a SOC for operational technology differs from an IT SOC in priorities, telemetry, protocols, response, skills and KPIs — with a side-by-side comparison table.

NIS2 and OT monitoring: what the directive means for your SOC

What NIS2 requires from operators of industrial and critical OT — risk-management measures, incident handling and 24h/72h reporting — and how an OT SOC helps you comply.