Why Most IT/OT Security Policies Fail
I've reviewed dozens of security policies that claim to cover both IT and OT. Most of them are IT policies with a paragraph about PLCs bolted on at the end. That doesn't work.
IT and OT have fundamentally different failure modes. When an IT system goes down, people can't access their email. When an OT system goes down, a furnace overheats or a water treatment plant stops dosing chlorine. You can't treat these the same way and expect good outcomes.
The Real Difference Between IT and OT Security
IT security people think in terms of confidentiality first. Protect the data, encrypt everything, patch every Tuesday. OT security people think in terms of availability and safety first. That HMI needs to respond in under 200ms or an operator can't shut down a process in time.
These aren't just philosophical differences. They show up in practical ways. An IT team might push a firewall rule change at 2 AM on a Saturday. An OT team needs a maintenance window scheduled weeks in advance, with rollback procedures tested on a staging environment that mirrors the production line.
The tension between these two worlds is where most policy failures happen. You write a policy that says "all systems must be patched within 30 days" and the OT team ignores it because their SCADA server runs Windows Server 2012 and the vendor won't certify any patches.
What Actually Belongs in a Cross-Domain Policy
Risk Assessment That Accounts for Physical Consequences
Your risk assessment needs to go beyond "what data could be exposed." You need to ask: if an attacker pivots from the corporate network into the process control network, what can they physically do?
At one manufacturing site I worked with, the IT risk assessment rated a particular network segment as low-risk because it only contained "monitoring data." That monitoring data included real-time pressure readings from a chemical reactor. An attacker who could manipulate those readings could trick an operator into making a dangerous adjustment. Context matters.
Access Control, But Realistic Access Control
Multi-factor authentication and least-privilege access are table stakes. But in OT environments, you have to deal with shared operator accounts on HMIs, vendor remote access for maintenance, and 15-year-old devices that authenticate with a four-digit PIN.
The policy needs to acknowledge these realities instead of pretending they don't exist. For shared accounts, log which badge was tapped at the workstation. For vendor access, use a gateway like Trout Access Gate that provides session-level visibility and recording, so you know exactly what a third-party technician did during their maintenance window. For legacy devices, segment them aggressively and monitor the traffic.
Network Segmentation That Goes Beyond a Firewall Rule
Drawing a line between IT and OT on a network diagram is step one. It's not enough. You need segmentation within the OT network itself, separating safety systems from process control from historians from engineering workstations.
The Purdue Model gives you a starting framework, but most real environments don't map cleanly to it. You'll have devices that need to talk across levels, data that needs to flow up to business intelligence systems, and remote access requirements that punch holes in your neat architecture. Your policy needs to define how those exceptions are handled, documented, and reviewed.
Incident Response Across Both Worlds
Here's where things get interesting. Your IT incident response playbook probably says "isolate the affected system immediately." Try isolating a DCS controller that's managing a live batch process and see what happens.
OT incident response needs a different decision tree. Can we isolate this system without causing a safety event? Can we fail over to manual control? Who has the authority to make that call at 3 AM?
Write these scenarios out. Run tabletop exercises with both IT and OT staff in the room. The first time your SOC analyst and your process engineer try to coordinate during an incident should not be during an actual incident.
Getting IT and OT Teams to Actually Agree
The biggest obstacle isn't technical. It's organizational. IT reports to the CIO. OT reports to the VP of Operations or the plant manager. They have different budgets, different priorities, and often different reporting structures all the way up to the C-suite.
A policy that IT writes and hands to OT will be ignored. A policy that OT writes will miss half the cybersecurity basics. You need both teams drafting it together, with someone senior enough to break ties when they disagree.
One approach that works: start with the compliance requirements you both have to meet, and build outward from there. NIST 800-171, CMMC, NIS2, whatever applies to your organization. These give you a shared baseline that neither team can argue with.
Compliance as a Starting Point, Not the Goal
NIST 800-171 and CMMC
If you're in the defense supply chain, CMMC compliance forces you to implement controls across any system that touches CUI. In many manufacturing environments, that includes OT systems on the shop floor. Your policy needs to define exactly where CUI boundaries are and how OT systems inside those boundaries get the same controls as IT systems, or get isolated from CUI entirely.
NIS2
For EU operators of essential services, NIS2 requires risk management measures and incident reporting with tight timelines. If your OT environment is in scope, your incident response procedures need to account for the 24-hour early warning requirement. That means your OT team needs a clear path to notify the right people fast, even if the incident is contained to the plant floor.
Make the Policy a Living Document
Write the policy. Then put a review date on it. Quarterly is good for the first year while you're finding gaps. After that, every six months.
Every time you have an incident, a near-miss, or a major change to your network architecture, revisit the relevant sections. The policy should reflect how your environment actually works today, not how it worked when someone wrote the first draft.
The single best thing you can do right now: get your IT security lead and your OT/plant engineering lead in a room together, hand them both a copy of your current security policy, and ask them each to highlight the parts that don't apply to their environment. Whatever they both highlight is where you start rewriting.
