An IT-OT SOC is a security operations function that correlates enterprise IT and operational technology events across both environments. It helps analysts spot attacks that move from corporate systems into industrial control assets or use identity, remote access, or shared services as a bridge. Teams should integrate logs, align response playbooks, and preserve safety priorities.
What an IT-OT SOC actually does
An IT-OT SOC is not just a traditional SOC with some plant logs added. Its job is to correlate enterprise telemetry, remote access activity, and industrial signals so analysts can see when a routine IT compromise becomes an operational event. The core value is context: IT alerts, OT alarms, asset state, and process impact are interpreted together rather than in isolation.
That operating model matters because the same event can mean very different things in each environment. A login anomaly in IT may be a phishing issue, while the same account in OT may be the first sign that an attacker is moving toward engineering workstations, historians, controllers, or remote maintenance paths. For background on OT-specific monitoring and segmentation concepts, see the OT Security Guide.
Most mature IT-OT SOCs also define which signals are safety-relevant, which are purely informational, and which require immediate escalation. That distinction prevents analysts from treating industrial noise like ordinary endpoint telemetry. It also reduces the common failure mode where teams either overreact to routine control traffic or underreact to signs of cross-domain movement.
How analysts connect the IT and OT sides
The practical work begins with ingestion and normalization. IT logs from identity, endpoint, network, email, cloud, and remote access systems are joined with OT sources such as historians, engineering workstation logs, jump host records, firewall events, and asset visibility feeds. The goal is to reconstruct a path, not just close individual alerts.
Correlation rules usually focus on bridges between environments, because that is where risk concentrates. Examples include privileged remote access into OT, unusual use of shared service accounts, remote vendor sessions, abnormal protocol activity, and changes to engineering software or controller-adjacent systems. A good reference point for OT architectures, segmentation, and defensive boundaries is NIST SP 800-82 Rev 3.
Because the environments differ operationally, playbooks also differ. IT containment may mean isolating a host or disabling an account. OT containment may require checking process stability, confirming safe fallback states, and coordinating with operations before making any disruptive change. The best teams predefine those decision rights so analysts are not improvising during an incident.
Why IT-OT SOC work is different from ordinary SOC operations
IT-OT SOC work is shaped by availability and safety constraints. In IT, the priority is often rapid containment. In OT, the priority is often controlled containment that avoids creating a process upset, loss of view, or unsafe shutdown. That means the SOC must understand not only malicious activity, but also the operational consequences of its own response actions.
It also changes how alerts are judged. Some evidence of compromise is obvious in IT, but in OT the same compromise may be hidden behind older protocols, shared hosts, scheduled maintenance, or vendor workflows. That is why the SOC needs asset context, engineering input, and a clear map of which systems are monitored by the business side versus the control side. For incident coordination and recovery choices in industrial environments, the OT Incident Response Guide is a useful companion.
Well-run IT-OT SOCs also treat identity and remote access as first-class control points. Many real cross-domain incidents begin with stolen credentials, overbroad remote access, or an exposed third-party pathway rather than with malware alone. That means the SOC is not only hunting malware, but also watching the access paths that let an attacker reach operational assets in the first place. For a live example of credential-driven access into business systems that can matter to industrial environments, see the Schneider Electric Jira breach 2024.
Risk and Threat Considerations
IT-OT SOCs exist because attackers often use enterprise trust paths to reach operational systems. The risk is not limited to data theft. A foothold in IT can become a staging point for credential abuse, remote access misuse, lateral movement, and interference with industrial operations if the SOC does not connect the dots quickly.
Failure mechanism: Separate monitoring teams miss the relationship between IT compromise and OT exposure, so the attacker keeps using legitimate access, shared services, or maintenance workflows to move deeper before anyone sees the full path.
Impact: Detection is slower, containment is more disruptive, and the incident can progress from a business-system compromise to operational downtime, degraded visibility, or unsafe control conditions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | IT-OT SOCs depend on cross-environment log correlation and alert analysis. |
| IA-5 — Authenticator Management | SOCs must watch credential use because remote access and shared accounts often bridge IT and OT. | |
| IR-4 — Incident Handling | IT-OT SOCs need coordinated containment and recovery decisions across enterprise and industrial environments. | |
| Recommendation — Centralize review of IT and OT audit records to identify cross-domain attack paths early. Control credential lifecycle for access paths that reach operational systems. Build incident handling procedures that coordinate IT response with OT safety constraints. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | IT-OT SOCs rely on monitoring network activity across enterprise and industrial segments. |
| CIS-17 — Incident Response Management | The SOC role includes coordinated industrial incident response and recovery decision-making. | |
| Recommendation — Monitor network activity across IT and OT segments for abnormal bridging behavior. Maintain incident response playbooks that account for operational safety and recovery. | ||
| NIST CSF 2.0 | DE.CM-01 — The network is monitored to detect potential cybersecurity events | An IT-OT SOC is fundamentally a cross-domain monitoring function. |
| RS.CO-03 — Information is shared consistent with response plans | IT-OT SOCs must coordinate response with operations and safety teams. | |
| RC.RP-01 — Recovery plan is executed during or after an incident | Industrial incidents require planned recovery to restore services safely. | |
| Recommendation — Monitor IT and OT networks together so cross-domain events are detected as one incident. Share incident information according to response plans that include OT stakeholders. Execute recovery plans that restore OT services without creating unsafe process changes. | ||
Practitioner Guidance
What to prioritise: Correlate remote access, identity, and engineering-workstation activity before you invest in highly granular process analytics. In most cross-domain incidents, the bridge matters more than the payload.
What to verify: Confirm that the SOC can see both the access trail and the operational consequence. If analysts can identify a login but cannot tell whether it touched a historian, jump host, or controller-adjacent system, the operating model is incomplete.
Decision rule: If an alert could affect a live process, escalate it with operations involvement before forcing containment, and use the least disruptive control that still preserves evidence and safety.
Practitioner takeaway: An effective IT-OT SOC is built around correlation and decision rights, not volume of alerts; the goal is to recognise cross-domain attack paths early enough to contain them without creating a worse operational problem.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities for SOC 2 compliance?
- How should security teams reduce OT remote access risk without blocking maintenance work?
- Who should own vendor and contract changes during SOC 2 work?
- How do SOC teams know whether automation is reducing risk or just hiding work?