Most security operations centres were built to watch Windows endpoints, cloud logs and e-mail, and an analyst who sees an unusual Modbus write or a PLC switched into program mode often has no idea whether it is an attack, a maintenance task or a process upset. An OT security operations centre (OT SOC) closes that gap: it brings industrial network monitoring, engineering context and plant escalation paths into detection and response. This guide covers operating models (separate, converged and hybrid), the data sources that matter, triage with process context, OT use cases mapped to MITRE ATT&CK for ICS, playbooks agreed with operations, staffing and metrics. It is written for SOC managers, OT security leads and plant engineering managers. It builds on the general SOC Guide and does not repeat sensor deployment detail covered in the OT Network Security Monitoring Guide.
Key takeaways
- Safety and availability come first in every decision. NIST SP 800-82 Rev. 3 treats safety as an overarching priority; an OT SOC never takes a containment action on a control system without the asset owner's operations authority.
- Most OT attacks start in IT. CISA's Volt Typhoon advisory (AA24-038A) describes actors pre-positioning on IT networks to move laterally to OT, so the IT and OT views must be correlated in one place.
- Process context is the triage multiplier. An alert is only actionable when the analyst knows the asset's function, zone, criticality, maintenance window and normal communication pattern.
- Passive network monitoring is the primary data source. Many controllers log little or nothing, so traffic between OT assets and other systems, plus engineering workstation and remote access logs, carries the detection load.
- Converged SOCs need OT-literate people and joint playbooks, not only a new data feed. Measure the time it takes to reach an on-shift engineer as seriously as time to detect.
What makes an OT SOC different
| Dimension | Enterprise SOC | OT SOC |
|---|---|---|
| Primary concern | Confidentiality and integrity of data | Safety, availability and integrity of the physical process |
| Main telemetry | EDR, identity provider, cloud and e-mail logs | Passive traffic capture (industrial protocols), OT firewall and remote access logs, engineering workstation, historian and HMI host logs |
| Asset behaviour | Dynamic, frequently changing | Deterministic and repetitive, so baselines are strong and deviations meaningful |
| Response actions | Isolate host, disable account, block IP | Advise operations; isolation only with operations sign-off; fall back to manual operation as planned |
| Change windows | Weekly or continuous | Planned outages, sometimes once a year |
| Who decides | SOC manager, CISO | Plant or control room manager with safety responsibility, advised by the SOC |
| Typical adversary behaviour | Credential theft, ransomware, data theft | The same in IT, then remote services, program download, parameter changes and alarm suppression in OT |
NIST SP 800-82 Rev. 3 (Final, September 2023) describes graceful degradation from normal automated operation to emergency operation with more operator involvement and then to manual operation. The OT SOC's response options must fit inside that model. NIST published an initial public draft of SP 800-82 Rev. 4 in September 2026, with comments due 30 November 2026; check the final text before relying on new details.
Choosing an operating model
| Model | How it works | Best fit | Main risk |
|---|---|---|---|
| Separate OT SOC | Dedicated team and tooling for OT, often owned by engineering or operations | Large asset owners with many sites, strict regulatory separation, or safety-critical processes | Blind to the IT intrusion that precedes most OT attacks; duplicated cost |
| Converged SOC | One SOC monitors IT and OT; OT alerts flow into the same SIEM and case system | Organisations with a mature enterprise SOC and a manageable number of sites | Analysts lack OT context and treat OT alerts like IT alerts |
| Hybrid (hub and spoke) | Central SOC does tier 1 triage and IT correlation; an OT cell or site engineers handle OT tier 2 and response | Most mid to large industrial organisations | Hand-off delays if escalation paths are not rehearsed |
| Managed or co-managed | MSSP or OT monitoring provider supplies analysts and sometimes sensors | Smaller operators, water utilities, single-site manufacturers | Provider has no authority on site; contracts must define escalation and evidence handling |
Decision guidance: choose converged or hybrid when the main threat path is IT to OT, which the Volt Typhoon advisory shows is common. Choose a separate OT team only when regulation or safety demands it, and then still feed key OT events to the enterprise SOC for correlation. Small organisations get the best value from a managed provider plus a named on-call engineer per site. See the Co-Managed SOC and SOC-as-a-Service Guide.
Data sources and visibility
- Passive network monitoring: sensors on SPAN or TAP points at Purdue levels 1 to 3 decode protocols such as Modbus/TCP (port 502), EtherNet/IP (port 44818), S7comm (port 102) and DNP3 (port 20000) to see reads, writes, program downloads and mode changes. CISA's AA24-038A recommends collecting traffic between OT assets and other systems where OT logs are non-standard or unavailable.
- Boundary devices: IT/OT firewall, DMZ, jump host and remote access gateway logs. These show the IT-to-OT pivot and third-party sessions.
- Windows hosts in OT: engineering workstations, HMIs, historians and OT domain controllers. Collect Windows Security and Sysmon events as you would in IT, with care for host performance and vendor support terms.
- Controller and application events: PLC mode changes, project downloads, firmware changes, controller audit logs where available, and alarm and event journals from the control system.
- Asset inventory: the context layer. Every alert should be enriched with asset role, zone, criticality and owner. See the OT Asset Visibility Guide.
- Regulated monitoring: in the North American bulk power sector, NERC CIP-015-1 Internal Network Security Monitoring (approved by FERC on 26 June 2025) requires a documented process to collect network data feeds inside the Electronic Security Perimeter of high impact and medium impact (with External Routable Connectivity) BES Cyber Systems, detect anomalous activity, evaluate it, retain data relating to anomalies until evaluation is complete, and protect that data from unauthorised deletion or modification. Check the implementation plan for dates. See the NERC CIP Guide.
Triage with process context
The single biggest difference in an OT SOC is how an alert is judged. The same event, such as a write to a holding register, can be routine tuning, a contractor mistake or the start of an attack. Build these questions into the triage runbook and the alert enrichment:
- What does this asset do? Function, process unit, zone and conduit, safety relevance (is it a safety instrumented system or connected to one?).
- Is there an approved change? Check the permit-to-work, maintenance schedule or management-of-change ticket. Integrate the change calendar into the SIEM where possible.
- Who and what initiated it? Which engineering workstation, which user or vendor account, which remote session. Compare with the known list of engineering hosts allowed to talk to that controller.
- Is the process affected? Ask the control room: are values, alarms or operating modes abnormal? Historian trends often answer this faster than packet captures.
- Is there an IT precursor? Correlate with IT detections for the same identity or host in the past days: credential theft, new remote access, lateral movement.
| Priority | Example condition | Escalation |
|---|---|---|
| P1 | Unapproved program download, mode change or parameter write on a safety-relevant or high-criticality controller; signs of alarm suppression | Immediate phone call to control room and on-call engineer; incident declared |
| P2 | New remote access path into OT, IT-side compromise of an account with OT access, unknown host talking industrial protocols | OT analyst within 30 minutes; site engineer informed |
| P3 | Policy deviations: insecure protocol use, unapproved software on HMI, sensor gaps | Ticket to site owner; weekly review |
The response times above are examples; set your own with operations and record them in the playbooks.
OT detection use cases mapped to ATT&CK for ICS
| Use case | ATT&CK for ICS technique | Data source |
|---|---|---|
| Remote session into OT from an unusual source or outside an approved window | T0822 External Remote Services; T0886 Remote Services | Remote access gateway, jump host, OT firewall |
| IT credential used on OT assets, default vendor credentials | T0859 Valid Accounts | OT domain controller, HMI and EWS logon events |
| Scanning or enumeration of controllers | T0846 Remote System Discovery; T0888 Remote System Information Discovery | Passive network sensor |
| Project or logic download to a controller | T0843 Program Download | Protocol decoding, controller audit log |
| Controller switched to program or remote mode | T0858 Change Operating Mode | Protocol decoding, controller status polling |
| Unexpected write commands or setpoint changes | T1692.001 Unauthorized Message: Command Message; T0836 Modify Parameter | Protocol decoding with baseline of normal writers |
| Alarms disabled or suppressed | T0878 Alarm Suppression | Alarm management system, HMI logs |
| Device restarts or denial of service | T0816 Device Restart/Shutdown; T0814 Denial of Service | Network sensor, controller diagnostics |
| Log or artefact deletion on OT hosts | T0872 Indicator Removal on Host | Windows event forwarding, Sysmon |
The Volt Typhoon advisory also asks defenders to baseline normal ICS traffic and alert outside those norms, monitor for unauthorised controller change attempts, and check controller logic against a known-good baseline. On the IT side it lists ESENT event IDs 216, 325, 326 and 327 as signals of NTDS.dit extraction, which matters when the OT domain trusts or shares credentials with IT. For the history behind these techniques, see the ICS Malware History Guide and the FrostyGoop Modbus Malware Guide.
Where identity fits
Identity is the most common bridge from IT to OT. AA24-038A reports actors testing access to domain-joined OT assets with default vendor credentials, and in some cases reaching OT systems with credentials taken through NTDS.dit theft. An OT SOC should therefore watch:
- Shared and vendor accounts: logons by integrator and support accounts outside contracted windows, and any use of default credentials. See the OT Third-Party and Integrator Access Guide.
- Service accounts and machine identities: historian replication accounts, OPC client identities and backup agents that span IT and OT zones. New interactive use of such an account is a P2 signal.
- Remote access tokens and sessions: new MFA registrations or session tokens for OT remote access. See the OT and ICS Identity and Access Guide and the OT Remote Access Guide.
Playbooks, people and escalation
NIST SP 800-82 Rev. 3 recommends a cross-functional team that includes a control engineer, a control system operator and a network and system security expert, alongside IT staff and management, with the control system vendor or integrator consulted. Turn that into a staffed model:
- Roles: tier 1 analysts (IT and OT triage with runbooks), an OT analyst or OT cell (protocol and process knowledge), named site engineers on call, the control room as decision maker, and an incident commander who understands both worlds.
- Joint playbooks: for each P1 use case, write who calls whom, the decision points (observe, contain at the IT/OT boundary, isolate a zone, move to manual operation), and the evidence to preserve (packet captures, controller project files, EWS disk images). See the OT Incident Response Guide and the OT Ransomware Response Playbook.
- Containment ladder: start at the boundary (block the IT/OT conduit, disable remote access, suspend vendor accounts) before touching controllers. Any action inside a zone needs operations approval.
- Skills: cross-train IT analysts on industrial protocols and Purdue levels, and engineers on SOC tooling. See the GICSP Certification Guide.
How to implement: a phased rollout
- Agree the charter (month 1): scope, decision rights, and the rule that the SOC advises and operations decides inside OT zones. Sign it with plant leadership.
- Build the context layer (months 1 to 3): asset inventory with criticality, zone and owner; list of approved engineering hosts and vendor accounts; change calendar feed.
- Pilot one site (months 2 to 4): deploy passive sensors in listen-only mode at the IT/OT boundary and level 2 to 3, forward boundary and Windows OT host logs, and run detections in observe-only mode for at least one full operating cycle to learn normal behaviour.
- Tune and write playbooks (months 4 to 6): remove noise from known maintenance traffic, agree P1 to P3 definitions and run a tabletop with the control room.
- Go live and expand: enable alerting for P1 and P2 use cases, then add sites in waves. Roll back by returning a site to observe-only mode if alert volume overwhelms analysts; sensors are passive, so this does not affect the process.
- Exercise: run at least one joint IT/OT exercise per year that includes a move to manual operation and evidence collection.
Detection and measurement
| Metric | What it shows | Example target |
|---|---|---|
| Sites and critical zones with passive monitoring coverage | Visibility gaps | 100% of high-criticality zones |
| OT alerts enriched with asset role, zone and owner | Quality of context | Above 95% |
| Time from P1 alert to engineer or control room contact | Escalation path works | Within 15 minutes |
| Controller changes reconciled to an approved change | Change control and detection alignment | 100% within one working day |
| Remote OT sessions matched to an approved request | Third-party access discipline | 100% |
| Joint IT/OT exercises completed per year | Readiness | At least one per major site |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01, DE.CM-09, DE.AE-02, DE.AE-06, RS.MA-01 | Monitoring, analysis, sharing and coordinated response |
| NIST SP 800-53 Rev. 5 (with the SP 800-82 OT overlay) | SI-4 System Monitoring, AU-2 Event Logging, AU-6 Audit Record Review, IR-4 Incident Handling, IR-8 Incident Response Plan | Control baseline for the SOC function |
| NERC CIP | CIP-015-1 INSM; CIP-008 incident reporting and response | Regulatory monitoring and escalation for bulk electric systems |
| IEC 62443 | 62443-2-1 programme; 62443-3-3 system requirements for monitoring | Asset owner programme and system capabilities |
| MITRE ATT&CK for ICS | Techniques in the use case table | Detection coverage and gap analysis |
See the IEC 62443-2-1 Asset Owner Security Programme Guide.
Common failure patterns
- Treating OT alerts like IT alerts: analysts isolate an HMI or block a controller's traffic without asking the control room, creating the outage the attacker wanted.
- No IT correlation: a separate OT team sees the program download but not the week of credential theft that preceded it.
- Baselines learned during abnormal periods: sensors trained during a shutdown or commissioning flag everything once normal production resumes, and analysts start ignoring alerts.
- No change calendar: every maintenance write becomes an alert, and the true positive is lost in noise.
- Escalation that ends at a mailbox: P1 alerts sent to a shared inbox overnight with no on-call engineer.
- Shutting down on uncertainty: with no visibility into whether OT is affected, operators may have to stop production as a precaution.
Lessons from incidents
In the Colonial Pipeline ransomware attack in May 2021, attackers entered through a legacy VPN account without MFA and deployed ransomware on IT systems. NHI Mgmt Group's analysis notes that the pipeline shutdown came from Colonial's decision to contain the attack, not from attackers touching pipeline controls. That is the case for an OT SOC in one sentence: monitoring that can show whether OT is clean, and a joint IT/OT playbook, give leadership the evidence to decide how far containment needs to go. See the Volt Typhoon Threat Actor Profile for a pre-positioning campaign that targeted the IT-to-OT path.
Practitioner checklist
- Sign an OT SOC charter that states the SOC advises and operations decides inside OT zones.
- Choose an operating model (converged, hybrid, separate or managed) and document hand-offs.
- Build an asset inventory with role, zone, criticality and owner, and enrich every OT alert with it.
- Deploy passive monitoring at the IT/OT boundary and in high-criticality zones; collect boundary, remote access and OT Windows host logs.
- Feed the maintenance and change calendar into triage.
- Implement P1 use cases first: program download, mode change, unexpected writes, alarm suppression, new remote access.
- Correlate OT alerts with IT identity and endpoint detections for the same accounts and hosts.
- Write joint playbooks with a containment ladder and evidence list, and test them with the control room.
- Name an on-call engineer per site and measure time to reach them.
- Check sector rules such as NERC CIP-015-1 and map coverage to ATT&CK for ICS.
Standards and references
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- CISA: PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure (AA24-038A)
- NERC: CIP-015-1 Cyber Security, Internal Network Security Monitoring
- MITRE ATT&CK: ICS Matrix
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- CISA: Best Practices for Event Logging and Threat Detection
Related NHI Mgmt Group resources: SOC Guide · OT Network Security Monitoring Guide · OT Incident Response Guide · OT Security Guide · OT and ICS Identity and Access Guide