Your OT Expert Is Not an Escalation Process

Analyst Brief

Executive Summary

In many industrial organizations, the path from an OT alert to an operational decision runs through one individual. The SOC sees the alert, lacks the industrial context to interpret it and calls the OT expert, who then investigates, consults operations, runs the runbook and prepares the evidence. Each step is reasonable. Together they make one employee the connection between cybersecurity and operations.

The model persists because it produces results, and its weaknesses are procedural: few organizations have written criteria for when an operational anomaly becomes a cybersecurity investigation, and the authority to contain or isolate is often settled by habit.

It also has a ceiling. People who can do this work are scarce, senior security roles take months to fill and stress is now the leading reason security professionals leave. Guidance from NIST and CISA describes the alternative in practical terms: a cross-functional team, authority assigned ahead of time, written criteria and exercises that include the people who run the plant.

An operational technology (OT) alert reaches the security operations center (SOC) a little after 2 a.m. The analyst on shift can see the source, the account and the asset name. What she can't see is what that asset does, whether anyone is supposed to be working on it tonight, or what would stop if she isolated it.

So she does the sensible thing. She calls the person who knows.

Many industrial organizations have that person. Sometimes the title is OT security lead, sometimes controls engineer, and sometimes it's just the name everyone learned to ask for. Once the call connects, the job list is long: investigate the event, judge what it means for the process, talk to operations, interpret the runbook, coordinate the response, brief the compliance team and assemble the evidence afterward.

There's a name for this role, and it isn't flattering to the org chart. Human middleware is the person who manually carries context between two groups that don't share it, in this case the SOC and the plant. The first article in this series, OT Visibility Isn't OT Security Capability, ended by asking who investigates an OT alert at 2 a.m. If your honest answer was a single name, this article is about that name.

The SOC Is Right to Escalate OT Alerts

Escalating to an OT expert is the correct instinct, and the data explains why it happens so often. In the 2026 SANS SOC Survey, only 16% of SOCs fully support all of their organization's at-risk smart systems, the category that includes OT, industrial control systems (ICS) and internet of things devices.

Analysts trained on enterprise systems are being handed telemetry from environments that run on different rules. An action that is routine in IT, such as disabling an account or isolating a host, can interrupt a physical process. NIST's Guide to Operational Technology Security notes that OT often uses operating systems and applications that can seem unconventional to typical IT personnel. Nobody wants a guess at that hour.

Planning ahead doesn't close the gap by itself, either. In the SANS State of ICS/OT Security 2025 survey, only 57% of organizations that had an ICS/OT incident response plan said IT understands OT constraints.

The call itself is good practice. What deserves a second look is how much of the organization's OT response lives inside it.

Why a Working Escalation Path Hides a Structural Problem

The arrangement survives because it works. Alerts get resolved, auditors see a response, and nothing on the surface says anything is wrong.

Look underneath and the gaps are procedural. Dragos reported in May 2026 that 82% of the asset owners it observed lacked clear criteria for when an operational anomaly should trigger a cybersecurity investigation. Without written criteria, the trigger becomes a judgment call, and the judgment belongs to whoever picks up the phone.

Decision rights are just as informal. Writing for SANS in November 2025, Principal Instructor Dean Parsons argued that the biggest opportunities in ICS/OT security are "no longer just technical." Delays in incidents and exercises, he wrote, often come from uncertainty over who leads containment, who decides whether to keep operating through an attack while maintaining safety and who is allowed to isolate control systems.

In a lot of plants, all three answers are the same person, and none of them is written down.

The signs are easy to spot once you look for them. OT alerts get a phone call instead of a procedure. One name appears on every escalation, on shift or off. Runbooks exist, but only one person has ever executed them, and the context an investigation needs gets rebuilt from memory each time.

What Happens When Your OT Expert Is the Process

Depending on one person stops working as volume grows, and volume is growing. More sites send telemetry, more vendors connect remotely, and every new detection is another reason to make the call.

The supply of people who can take that call is thin. Only 9% of ICS/OT security professionals work on ICS/OT security full time, according to a 2025 SANS budget survey. Hiring a second one is slow: the 2026 SANS and GIAC Cybersecurity Workforce Research Report found that 55% of senior security hires take six months or longer to fill.

Then there's the load on the person. ISACA's State of Cybersecurity 2026 report found that 68% of cybersecurity professionals say their role is more stressful than it was five years ago, and that high work stress is now the leading reason people leave, cited by 52%. The busiest expert in the building is also the one a recruiter would most like to reach.

Documentation alone doesn't fix it. Mithryl Systems has seen organizations invest in a set of OT runbooks only to find the workload went up, because the operational knowledge needed to execute them still sat with one individual. A runbook only one person can run is still that person.

What Does a Repeatable OT Escalation Model Look Like?

A repeatable model moves what the expert knows into the organization, so the expert's judgment is saved for the hard cases. Authoritative guidance is fairly specific about the parts.

A team instead of a name. NIST SP 800-82 Rev. 3 says an OT cybersecurity team should include, at a minimum, a member of the IT staff, a control engineer, a control system operator, a network and system security expert, a member of management and a member of the physical security department. That is six roles.

Decision authority assigned before the incident. NIST's 2025 incident response guidance, SP 800-61 Rev. 3, lists among the things an incident response policy typically defines "which roles have the authority to confiscate, disconnect, or shut down technology assets." Colonial Pipeline shows what that looks like under pressure.

Whatever one thinks of the decision to halt the pipeline in May 2021, the person on shift had the authority to make it. CEO Joseph Blount told the House Committee on Homeland Security that the control center's operations supervisor issued the stop work order, and that all 5,500 miles of pipeline were confirmed shut down by 6:10 a.m., a little over an hour after an employee found the ransom note.

Written criteria and captured context. CISA's Cybersecurity Performance Goals 2.0, released in December 2025, call for "clear criteria and processes for adverse events." The companion step is recording operational context ahead of time: what each asset does, what a jump host can reach and when maintenance windows fall.

Practice with the right people in the room. The SANS State of ICS/OT Security 2025 survey found that fully prepared organizations were 66% more likely to include field technicians in preparedness exercises. Exercises are how knowledge leaves one head and becomes a team's.

What changes when escalation stops depending on one person

Question	Escalating to a person	Escalating to a process
When does an anomaly become a cyber investigation?	Judgment of whoever answers the phone	Written criteria
Who can isolate a control system?	Settled by habit	A named role with assigned authority
Where does operational context come from?	Rebuilt from memory during the event	Recorded ahead of time
Who can execute the runbook?	One individual	A team that has practiced it

Name the Person, Then Build Around Them

Try one exercise this week. Write down the name every OT escalation reaches. Under it, write who takes those calls when that person is on vacation, out sick or working for someone else.

If the second line is blank, the organization doesn't have an OT escalation process yet. It has a very good employee. That expertise is worth protecting, and the way to protect it is to stop spending it on questions a documented process could answer: whether a maintenance window was open, who owns the asset, who has the authority to act.

This is the gap Mithryl Systems OT MDR (managed detection and response) was built to fill. It works as an operating layer between the SOC you already have and your OT operations, bringing OT expert investigation, operational context and runbook execution to each event, so an escalation lands on a team and a workflow. Operations keeps decision authority throughout.

To see how that would work in your environment, schedule an executive briefing with Mithryl Systems. Your OT expert will probably thank you for it.

CyberFusion Center Perspective

The Question a CyberFusion Center Asks About Escalation

A traditional SOC measures escalation by whether the ticket was handed off. A CyberFusion Center asks what the handoff depended on. If the answer is one person's memory of which assets matter, who owns them and what tonight's maintenance schedule looks like, the organization has a single point of failure that no architecture diagram will show.

The fusion view treats that knowledge as something the operation should hold in common. Operational context, decision authority and escalation criteria are captured, kept current and shared across security, engineering and operations, so an investigation starts from what is already known. The expert remains essential. Their time moves to the questions only an expert can answer.

How Mithryl Systems Approaches It

Mithryl Systems OT Managed Detection & Response is designed as an operating layer between an organization's existing SOC and its OT operations. It extends the SOC with OT expert investigation, so an escalated OT event reaches analysts who can interpret it in operational terms.

The service works with the security tools and telemetry an organization already owns. Operational context is brought into the investigation from the start, and runbooks are executed as part of a repeatable workflow, which spreads the work that often falls to one in-house expert. Operations keeps authority over any action that could affect production or safety.

Frequently Asked Questions

Who should respond to OT security alerts, the IT SOC or the OT team?

Both should, with responsibilities agreed before an incident. The SOC is well placed to triage and investigate. Decisions that could affect a physical process need engineering and operations knowledge. NIST SP 800-82 Rev. 3 describes a minimum OT cybersecurity team of six roles drawn from IT, engineering, operations, security, management and physical security.

Can an IT SOC monitor OT environments?

An IT SOC can collect and watch OT telemetry, but full coverage is uncommon. The 2026 SANS SOC Survey found only 16% of SOCs fully support all of their organization's at-risk smart systems, which include OT and industrial control systems. The harder gap is context: knowing what an asset does and what a response would interrupt.

Why do OT alerts keep getting escalated to the same person?

The knowledge needed to interpret the alert usually sits with one individual: what the asset does, whether maintenance is underway and what a response would stop. Dragos reported in May 2026 that 82% of the asset owners it observed lacked clear criteria for when an operational anomaly should trigger a cybersecurity investigation.

Who decides whether to shut down or isolate a system during an OT cyber incident?

Whoever the organization named in advance. NIST SP 800-61 Rev. 3 lists the roles with authority to confiscate, disconnect or shut down technology assets among the things an incident response policy typically defines. When that is unsettled, SANS Principal Instructor Dean Parsons notes, incidents and exercises stall on exactly that question.

How do you reduce dependence on one OT security expert?

Move what that person knows into the organization. Record operational context before an incident, write down who has authority to act, set criteria for escalation and run exercises with engineers, operators and field technicians present. The expert's judgment is then reserved for the cases that need it.

Why is it so hard to hire OT security people?

The role calls for security skills and plant knowledge together, and few people have both. A 2025 SANS budget survey found only 9% of ICS/OT security professionals work on ICS/OT security full time. The 2026 SANS and GIAC workforce report found 55% of senior security hires take six months or longer to fill.

Related Reading

• Mithryl Systems OT Managed Detection & Response
• Mithryl Systems Launches Flagship OT Managed Detection & Response Service
• OT IR as Operational Discipline
• Who Owns OT Risk? What Red Team Tabletops Actually Find
• Mind The Gap: Who Owns What in OT Security?

From one expert to an operating model

What happens to your OT escalations when your expert is unavailable?

Walk through one of your own OT escalations with our team and see which steps a repeatable workflow could take off a single person.

• Explore OT MDR
• Schedule an executive briefing