How to Build an OT SOC from Scratch: Operating Model, Tools, and Staffing

An OT Security Operations Center is not an IT SOC with industrial protocols added to the log ingestion pipeline. The threat models are different, the data sources are different, the alert logic is different, and the response procedures are categorically different because a response action that is routine in IT, isolating a host, restarting a service, rolling back a configuration, can shut down a production line or trigger a safety event in an OT environment.

Despite this, the majority of organizations that have invested in SOC capability for their OT environments have tried to extend their existing IT SOC. The result is typically an OT detection capability that generates either massive false positive rates (because IT alert logic is applied to OT traffic patterns that look anomalous by IT standards) or very low detection rates (because the OT environment is connected to the SIEM but the analysts have no context for interpreting what they see).

According to the SANS 2023 ICS/OT Cybersecurity Survey, fewer than 30% of OT environments have continuous monitoring in place. Building monitoring and response capability that actually works in an industrial environment requires purpose-built design, not extension of IT security infrastructure. This guide covers the operating model, technology stack, and staffing approach for organizations building OT SOC capability from the ground up.

 

What an OT SOC Is and How It Differs from an IT SOC

An OT SOC is a monitoring, detection, and response function specifically designed for industrial control system environments. Its primary purpose is detecting anomalous behavior in OT networks, correlating alerts with process context, and coordinating response actions that protect operational continuity and process safety.

 

Dimension	IT SOC	OT SOC
Primary asset type	Servers, workstations, cloud infrastructure, endpoints	PLCs, DCS controllers, HMIs, historians, SCADA servers
Traffic sources	Endpoint agents, firewall logs, DNS, authentication logs	Passive industrial network captures, process historian data, OT-specific protocols
Alert logic	Behavioral baselines for IT systems, threat intelligence feeds, IOC matching	Process deviation baselines, industrial protocol anomalies, unauthorized programming events
Response constraints	Isolate hosts, revoke credentials, patch systems, restart services	Every response action must be evaluated for operational and safety consequence before execution
Required expertise	Cybersecurity analyst with IT infrastructure knowledge	OT engineer with cybersecurity knowledge, or cybersecurity analyst paired with OT domain expert
False positive risk	Manageable with tuning	High if IT alert logic is applied to OT traffic without process context
Regulatory context	PCI DSS, SOC 2, HIPAA, general data protection	NERC CIP, TSA Pipeline Directives, IEC 62443, process safety regulations

 

OT SOC Operating Models

Model 1 — Standalone OT SOC

A dedicated OT SOC operates independently of the IT SOC, with its own analyst team, technology platform, and escalation procedures. This model provides the deepest OT-specific expertise and the cleanest operational separation, but it requires a significant investment in specialized staffing and technology. It is appropriate for large industrial operators with complex, high-consequence OT environments across multiple sites: major refineries, utilities, and critical infrastructure operators with dedicated OT security teams.

Model 2 — Integrated IT/OT SOC with Dedicated OT Tier

The integrated model brings OT monitoring into the existing IT SOC platform, typically a SIEM, but with a dedicated OT analyst tier that handles all OT-specific alert triage and response coordination. OT alerts are processed by analysts with OT expertise before any response action is considered. This model is more resource-efficient than a standalone OT SOC and is appropriate for mid-size industrial operators who have mature IT SOC capability and can allocate dedicated OT expertise within it.

Model 3 — Co-Managed OT SOC with Managed Service Provider

The co-managed model uses a managed OT security service provider to supply the monitoring platform, 24/7 analyst coverage, and threat intelligence, while the internal team manages the OT-specific response coordination with operations. This is the most common model for industrial operators without existing OT security teams, as it provides immediate capability without the multi-year timeline required to build internal OT expertise. The co-managed model requires a clear escalation protocol between the managed service provider and the internal operations team.

 

Core Functions of an OT SOC

Continuous OT Network Monitoring

The foundation of OT SOC capability is passive monitoring of industrial network traffic. OT-specific monitoring platforms, deployed on network taps or SPAN ports at key network segments, capture and analyze traffic without interacting with live control devices. They build behavioral baselines for normal process communications and flag deviations: new devices appearing on the network, unusual protocol commands, engineering software connections outside of maintenance windows, or traffic crossing zone boundaries through unexpected pathways. Network segmentation design directly affects what the monitoring platform can see and how meaningful its alerts are.

Alert Triage with OT Process Context

Raw alerts from an OT monitoring platform require interpretation by someone who understands both the cybersecurity implication and the process context. An alert that a PLC's programming port received a connection at 2 AM means something very different if the facility has a night shift doing scheduled maintenance versus if the facility is unmanned at night. Alert triage in an OT SOC requires analysts to apply process context before escalating, which means OT knowledge is built into the triage workflow, not added as an afterthought.

Incident Detection and Escalation

The OT SOC detects incidents and escalates them through a defined procedure that differs fundamentally from IT incident response. An OT incident that potentially affects a running process must be escalated to operations leadership before any containment action is taken. The decision to isolate a device, change a network configuration, or modify access controls in a live OT environment belongs to operations, not to the security team. OT incident response planning defines this decision authority explicitly so that it is clear under pressure.

Vulnerability Tracking and Reporting

The OT SOC maintains a live view of the vulnerability posture of monitored assets, tracking newly disclosed advisories, updating the asset inventory as new devices appear, and reporting remediation status against the vulnerability management program. This continuous visibility allows the SOC to adjust monitoring rules when new CVEs are disclosed for assets in the monitored environment.

 

Technology Stack for an OT SOC

Building an OT SOC requires a technology layer specifically designed for industrial environments:

• Passive OT monitoring platform: purpose-built for industrial protocols (Modbus, DNP3, EtherNet/IP, PROFIBUS, IEC 61850); examples include Dragos Platform, Claroty, and Nozomi Networks

• SIEM integration: OT alerts, enriched with asset and process context, forwarded to the organization's SIEM for correlation with IT security events

• OT asset inventory system: continuously updated from passive discovery, serving as the source of truth for alert context

• Threat intelligence feed: OT-specific intelligence including CISA ICS-CERT advisories, sector-specific threat reporting, and vendor security bulletins

• IR playbook library: OT-specific response procedures for each alert category, reviewed with operations and process safety before an incident occurs

 

Staffing an OT SOC

Staffing an OT SOC is the hardest part of building one. The combination of cybersecurity analytical skills and OT engineering knowledge required is rare in the market. Organizations typically address this through one of three approaches:

1. Hire OT engineers and train them in cybersecurity: works well because process knowledge is the harder competency to develop from scratch; cybersecurity skills can be overlaid through formal training

2. Hire cybersecurity analysts and embed them with OT engineers: paired model where security analysts handle tool operation and threat intelligence while OT engineers provide process context for alert interpretation

3. Co-managed model: managed service provider supplies 24/7 analyst coverage and tool expertise; internal OT engineers handle operations-facing response coordination

 

Integrating the OT SOC with the IT SOC

OT and IT SOC functions need a defined integration point for incidents that cross the IT/OT boundary. Zero Trust architecture at the IT/OT boundary helps by creating a controlled, logged crossing point. When an incident in the IT environment suggests potential OT impact, the OT SOC should be notified immediately. When an OT alert suggests that an attacker may have entered through the IT network, IT SOC capability is needed to investigate the IT-side entry point. Defining the handoff protocol, communication channel, and shared incident management system before an incident occurs is what makes joint IT/OT response function under pressure.

 

Frequently Asked Questions

How many analysts does an OT SOC require?

Minimum viable OT SOC staffing for a single-site continuous operation is typically two to three dedicated OT-knowledgeable analysts for 24/7 coverage across three shifts. Multi-site organizations need proportionally more coverage. The co-managed model with a managed service provider reduces the internal headcount requirement significantly, as the provider supplies 24/7 monitoring coverage while internal staff handle OT-specific response coordination during business hours.

 

Do we need a separate SIEM for OT or can we use our existing one?

Most organizations use their existing SIEM platform with an OT-specific data connector to ingest alerts from the passive OT monitoring platform. The SIEM then correlates OT alerts with IT security events. The important requirement is that OT alert context, specifically process area, asset type, and operational status, is included in the SIEM record so that analysts can interpret alerts correctly. A separate SIEM is appropriate when the IT SOC team should not have visibility into OT network traffic for operational security or data classification reasons.

 

What is the first thing to set up when building an OT SOC?

The first capability to establish is passive network monitoring and asset inventory, because every other SOC function depends on knowing what is on the network and what normal behavior looks like. Before alert rules, playbooks, or staffing decisions can be finalized, the monitoring platform needs to run for at least two to four weeks to establish baselines for normal process communications. This baseline is what separates a meaningful alert from a false positive. The OT risk assessment that should precede SOC buildout will define the architecture of the monitoring deployment.

 

How long does it take to stand up a functioning OT SOC?

A minimum viable OT SOC with passive monitoring, an asset inventory, basic alert triage capability, and a co-managed service model can be operational in three to six months. A fully staffed, internally operated OT SOC with mature playbooks and IT/OT integration is a 12 to 24 month build for most organizations. The co-managed model provides immediate monitoring coverage while internal capability is developed over time.

 

Ready to strengthen your OT security posture? We help industrial operators build practical OT security programs that work within real operational constraints. Book a free consultation to discuss your environment. Book Your Free Consultation at aristacyber.io