Incident response for OT/ICS isn’t just IT incident response with different labels slapped on. It’s a different world entirely—different rules, different risks, and consequences that go far beyond data loss. In IT, a misstep during containment might cost you a few hours of uptime. In OT, it can mean a pressure relief valve failing to open, a centrifuge spinning out of control, or a desalination plant going dark during a 45°C summer in Dubai. I was in the NOC of a major UAE utility during a tabletop drill when a responder rebooted what they thought was an old server. It turned out to be tied directly to pump sequencing logic. The simulation ended immediately. No breach occurred, but the damage was psychological: you do not treat OT like IT.
Most organizations across the Gulf Cooperation Council—especially in energy, water, and transport—have incident response plans. But when I look under the hood, the pattern is almost always the same: a repurposed corporate IT IR playbook with “OT” typed into a few sections. That’s not a plan. It’s a liability waiting to happen. You can’t isolate an ICS network segment the way you’d quarantine a malware-infected workstation. You can't take down a system for forensic imaging when it’s keeping a gas compressor running. And you can’t rely on EDR agents or log forwarding when half your devices are running proprietary firmware from the 1990s. What works in a DIFC bank’s data center will fail catastrophically in an Abu Dhabi oilfield SCADA environment.
OT Incident Response Isn't Slower IT—It's a Different Beast
Let’s cut through the noise: OT environments are not networks. They’re industrial processes with networked components. The top priority isn’t data confidentiality—it’s safety, availability, and integrity of physical operations. When a gas compression station in Saudi Arabia loses telemetry, the danger isn’t missing logs. It’s pressure building up in a pipeline with no way to vent. When a rail signaling system in Dubai freezes, the risk isn’t downtime—it’s a potential collision.
Just last quarter, a UAE water authority I was advising had a ransomware variant reach their OT perimeter. The IT SOC reacted quickly—initiated full network segmentation. Good call, in theory. But the segmentation severed the historian server’s connection to the PLCs. Operators lost real-time visibility. They couldn’t see tank levels. Had to switch to manual monitoring. Missed a failing pump by over an hour. The breach was contained, but the operational fallout was severe. My takeaway: blindly applying IT-style isolation in OT is dangerous without process-aware rules.
OT devices don’t play by IT rules. Many run on Windows XP or VxWorks. Some can’t handle even basic packet inspection. Firewalls that perform deep packet inspection can introduce latency that breaks time-sensitive protocols like Modbus or DNP3. I once saw a security team deploy a new IDS in a power plant in Abu Dhabi. Within hours, breaker synchronization started failing. The culprit? The IDS was buffering packets for analysis. Milliseconds mattered. The system wasn’t compromised—the security tool itself became the threat.
“One IR Plan Fits All” Is a Dangerous Lie
Most GCC enterprises operate under a flawed assumption: that a single incident response plan can cover both IT and OT. This usually stems from compliance—NESA, for example, requires IR plans—but the execution is often generic, copy-pasted, and disconnected from reality. I reviewed one such plan for a gas processing facility in Dubai. It listed standard containment steps: disable user accounts, block IPs, reimage endpoints. All textbook. Then I asked how they’d respond to a rogue command sent to a PLC. The answer? “Same as any endpoint—segment and rebuild.” No one had considered the PLC couldn’t be rebuilt without halting production for 72 hours and flying in vendor engineers.
That’s not incident response. That’s improvisation. And in OT, improvisation can be deadly.
I challenged a vendor on this exact issue last month. They were pitching an XDR platform that “automatically responds to threats across IT and OT.” Their demo showed a single playbook triggering containment across domains. I asked: “What happens when your playbook disables a network segment that includes emergency shutdown systems?” Silence. My point: most vendors selling unified IR don’t actually understand OT constraints. They market convergence as a feature, but in critical infrastructure, convergence without context is a flaw, not a benefit.
The real answer isn’t a single plan—it’s orchestrated coordination between separate, specialized playbooks. The IT IR team handles phishing, malware, and credential theft. The OT IR team handles protocol anomalies, rogue commands, and device tampering. They share intelligence, but act independently. I worked with a Saudi petrochemical plant that implemented this model. They have a joint war room, but separate runbooks. When a suspicious Modbus write command was detected, the OT team isolated the affected segment using programmable network switches that preserved heartbeat signals—avoiding process disruption. The IT team traced the source to a compromised engineering workstation. Both teams reported to a unified CIRT, but operated under different rules. That’s how it should work.
What Actually Works: A Practical Framework for GCC OT IR
So what does effective incident response for OT/ICS look like in the Gulf? It starts with separation of concerns, not convergence. You need OT-specific detection, OT-specific response playbooks, and OT-aware personnel. You can’t train an IT SOC analyst to interpret IEC 61850 traffic in a week. It takes months of immersion.
During my first tabletop exercise with a GCC government utility, the CISO expected a unified SOC dashboard. Instead, I showed two parallel tracks: one for IT, one for OT. They were skeptical. But when we simulated a ransomware attack jumping from corporate email to an engineering VLAN, they saw the value. The IT team contained the initial infection. The OT team monitored for abnormal HMI polling patterns. We caught a lateral move—a script trying to query PLC firmware versions—before any commands were issued. That detection only worked because we had OT-specific analytics tuned to protocol behavior, not just network logs.
Here’s what you need to build:
- OT Asset Inventory with Context: Go beyond IP and MAC addresses. Document device role (e.g., “Level 3 Historian”), criticality, vendor, firmware, physical location, and process dependency. Without this, impact assessment is guesswork.
- Protocol-Aware Monitoring: Use tools that understand Modbus function codes, S7Comm packet structures, or DNP3 timestamps. A spike in “Write Single Register” commands isn’t just noise—it could be preparation for sabotage.
- Process-Safe Containment: Avoid cutting network access. Instead, use rate limiting, protocol whitelisting, or air-gapped backup HMIs. A Dubai metro operator I worked with uses “shadow HMIs”—read-only replicas that stay online during incidents to maintain situational awareness.
- Vendor Coordination Plan: Many OT devices need OEM support for forensics or firmware updates. If your IR plan lacks contact info, SLAs, and secure data-sharing procedures for Siemens, ABB, or Rockwell, it’s incomplete.
How Attackers Exploit OT Response Gaps
Let’s talk about real threats. I won’t name APT groups unless I can tie them to actual TTPs in the GCC. But I will say this: we’ve seen reconnaissance campaigns in UAE energy firms that map OT network topology using legitimate engineering protocols. These aren’t brute-force scans. They’re low-and-slow queries that mimic normal HMI behavior. They fly under the radar because IT-focused SIEMs don’t know what “normal” looks like in OT.
One such campaign, observed in two separate Abu Dhabi facilities last year, used legitimate credentials from a third-party contractor to access the OT network. The attacker didn’t deploy ransomware. Didn’t exfiltrate data. Spent weeks learning the system—polling PLCs, reading register values, identifying safety interlocks. Classic pre-attack reconnaissance. When the CISO asked if it counted as an incident, I said yes. Any unauthorized access to OT systems is an incident—even if no damage is done. Because the next phase could be disabling emergency shutdowns during a maintenance window.
Another common gap: lack of forensic readiness. OT devices rarely log in SIEM-friendly formats. Many don’t support Syslog. Some store logs locally with no remote access. When an incident hits, you can’t just “pull logs” like from a Windows server. You need pre-incident setups: packet capture on mirrored ports, write-once storage for historian data, and procedures for imaging SD cards from RTUs without disrupting operations.
I’ve seen responders try to use standard memory dump tools on an ICS server running a real-time OS. It crashed the system. That’s not just a setback—it’s a safety event. OT forensics require specialized tools and training. If your team hasn’t practiced collecting evidence from a Siemens S7-1500 PLC, don’t wait for a real incident to figure it out.
What GCC Leaders Need to Do Now
You’re not going to fix this in a quarter. But you can start today.
First, declare OT IR a separate domain. Assign a dedicated OT security lead—not a dual-hatted IT admin. This person needs engineering awareness, not just cybersecurity training. If they don’t understand what a PID controller does, they can’t protect it.
Second, run IR drills that reflect real OT constraints. No “assume we can take everything offline.” Simulate scenarios like: “A PLC is sending abnormal commands, but the process can’t stop for 48 hours.” How do you respond? One UAE power plant I advised runs quarterly drills where the OT team must contain a simulated attack without interrupting turbine synchronization. That’s the kind of realism that builds real readiness.
Third, integrate OT IR into NESA and NCA ECC compliance efforts. NESA’s ICS Cybersecurity Framework requires incident response, but many organizations treat it as a checkbox. Don’t. Use compliance as a forcing function to build actual capability. Map each NESA control to a specific IR procedure. For example, NESA Control 14.1 (incident detection) should tie directly to your Modbus anomaly detection rules.
Fourth, build relationships with OEMs before an incident. I can’t stress this enough. When a PLC is compromised, you’ll need Siemens or Honeywell to help. But they won’t move fast unless you have a contract, a secure data pipeline, and a joint response agreement in place. I’ve seen cases where forensic analysis took three weeks because legal teams were still negotiating data sharing. In that time, the attacker could have returned.
Finally, stop buying tools that promise “IT/OT convergence” without proof. Ask vendors: “Show me how your containment action preserves process continuity in a live desalination plant.” If they can’t demonstrate it with a use case from the Gulf region, walk away.
What If You’re Already Breached?
Is your OT network actually secure? A lot of UAE enterprises think they are—until they find a rogue HMI server in an unsecured cabinet. Or until an external pen test reveals that the “air-gapped” network shares a VLAN with guest Wi-Fi.
Last year, during a VAPT engagement at a major Dubai industrial zone, we discovered that a maintenance laptop used for PLC programming had been infected with info-stealer malware. The laptop was only connected to OT networks during maintenance windows—but during those windows, it transferred thousands of register values, including safety setpoints. The malware wasn’t designed to disrupt—it was designed to enable future attacks. The organization didn’t even know the laptop was part of the OT environment. It was managed by facilities, not IT.
That’s the reality: OT attack surfaces are often invisible to central security teams. If you haven’t mapped every engineering workstation, every USB port, every third-party connection, you’re not ready.
Start with visibility. Then build specialized response. Then test relentlessly.
Final Thoughts
Most OT incident response in the GCC is theater. It looks good on paper for audits, but it wouldn’t survive contact with a real attacker. You can’t protect industrial systems with IT playbooks, IT tools, or IT assumptions. The stakes are too high. When I stand in a control room and see a spinning turbine on the screen, I don’t think about data breaches. I think about what happens if that turbine fails. That’s the mindset you need. Not compliance. Not convenience. Safety first, availability second, everything else after. Build your IR around that.
