How should OT security responsibilities be distributed between IT and operations?

OT security works only as a joint responsibility between IT and operations. In regulated, brownfield environments, neither group can safely own it alone. The right model is a shared, explicitly documented split of responsibilities, with clear escalation paths and change control.

Core principle: joint accountability, clear ownership

Both IT and operations are accountable for OT security outcomes, but they own different layers:

• IT typically leads on enterprise security capabilities (networking, identity, monitoring, incident response tooling).
• Operations typically leads on process safety, availability, and equipment behavior (what can be changed, when, and how).

Trying to centralize everything in IT usually breaks on process and availability constraints. Pushing everything to operations usually breaks on security depth, tooling, and regulatory expectations for cyber controls.

Typical IT-owned responsibilities

The exact split varies by site and vendor stack, but in most industrial environments IT should own:

• Network and perimeter security
  • Design and maintenance of firewalls, VLANs, DMZs, and remote access solutions that segment OT from corporate IT.
  • Standard configurations for VPNs, jump hosts, and secure vendor access, in coordination with operations schedules.
• Core identity and access management
  • Corporate directory services (e.g., AD) and single sign-on where feasible.
  • Policies for authentication, password complexity, MFA, and account lifecycle for users who access OT systems.
• Enterprise security monitoring
  • Security information and event management (SIEM) platforms, log aggregation, and correlation rules.
  • Threat intelligence and detection engineering, including use cases that include OT events where supported.
• Baseline security services (where technically and operationally feasible)
  • Endpoint protection on engineering workstations, HMIs, and OT servers that can support it and have been tested.
  • Central patch infrastructure for systems under IT change control, with operations governing timing.
• Incident response leadership for cyber aspects
  • Coordinating triage, forensics, and external notifications for cyber incidents.
  • Driving standard incident playbooks that include OT-specific steps agreed with operations.

All of this must respect plant constraints. Many OT assets cannot be scanned, patched, or instrumented like office IT due to vendor qualification limits, obsolete OS versions, and validation burdens. IT should own the tooling and methods, but must implement them only where operations accepts the impact and risk tradeoffs.

Typical operations-owned responsibilities

Operations (often with engineering and maintenance) must own any security decision that can affect plant safety, product quality, or availability. Typical responsibilities include:

• Asset inventory and criticality ranking
  • Maintaining the authoritative list of OT assets (PLCs, DCS, HMIs, sensors, drives, historian servers, OT applications).
  • Classifying assets by safety, regulatory, and production criticality to drive risk-based security controls.
• Process constraints for security changes
  • Defining what downtime windows exist and what kinds of intervention (scans, patches, firmware updates) are acceptable for each asset class.
  • Approving or rejecting changes based on impact to process safety, product quality, and validated state.
• Configuration control for OT systems
  • Managing PLC, DCS, HMI, MES, and SCADA configuration changes under documented change control.
  • Reviewing and approving any security hardening, patching, or vendor updates that alter control logic or validated parameters.
• Physical and local access control
  • Controlling who can physically access panels, cabinets, OT server rooms, and shop-floor engineering workstations.
  • Managing day-to-day enforcement of badge, key, and escort policies on the floor.
• First-level response in the plant
  • Recognizing and reporting abnormal behavior in equipment and systems that might be security-related.
  • Executing plant-side steps during incidents (e.g., isolating a cell, switching to manual mode) consistent with safety and quality procedures.

Operations must ensure that any mandated cyber controls (for example from a corporate policy or external standard) are checked against process, safety, and regulatory needs before implementation.

Responsibilities that should be explicitly shared

Some areas are inherently cross-functional and cannot be safely assigned to just one group. These should be handled via joint governance and documented RACI:

• OT security architecture and zoning
  • Designing network zones and conduits for OT in line with frameworks such as IEC 62443.
  • Agreeing which traffic is allowed between OT and enterprise networks, and which technologies are approved for bridging.
• Vendor and system lifecycle decisions
  • Choosing OT security products (e.g., industrial firewalls, OT monitoring) and integrating them with existing MES/SCADA/QMS stacks.
  • Planning migrations or replacements for obsolete systems where security risk is no longer tolerable, including validation and downtime planning.
• Risk assessments and controls selection
  • Performing OT-specific threat and risk assessments jointly, with IT providing cyber risk expertise and operations providing process and safety context.
  • Agreeing risk acceptance criteria and compensating controls when direct fixes are not feasible on legacy equipment.
• Policy and standard development
  • Writing OT security standards that are technically enforceable and operationally realistic.
  • Ensuring that corporate security policies explicitly account for regulated manufacturing, validation, and long asset lifecycles.
• Incident response playbooks
  • Defining procedures that combine IT tasks (containment, forensics) with plant tasks (safe shutdown, line clearance, batch segregation, documentation).
  • Rehearsing joint exercises and updating playbooks based on lessons learned.

Working in brownfield, regulated environments

Most plants already run a mix of legacy and modern systems. Full replacement of OT platforms purely for security reasons rarely succeeds because of:

• Qualification and validation burden for control systems, MES, and related infrastructure.
• Downtime risk and limited outage windows for critical assets.
• Integration complexity with existing ERP, QMS, PLM, and historian systems.
• Long equipment lifecycles where OEM support is limited or conditional.

IT and operations therefore need a shared strategy that emphasizes:

• Compensating controls (network segmentation, jump hosts, controlled media handling) when direct patching is not possible.
• Documented risk acceptance where legacy constraints prevent meeting corporate standards fully.
• Incremental, risk-based hardening aligned to planned outages and validation cycles.

Practical way to formalize the split

A workable structure in many organizations is:

1. Define joint OT security governance
   • Create an OT security steering group with IT security, operations, engineering, and quality representation.
   • Give it authority to set standards, approve exceptions, and prioritize remediation work.
2. Establish a written RACI
   • List key activities such as asset inventory, patching, firewall rule changes, new vendor connectivity, and incident response.
   • Assign who is Responsible, Accountable, Consulted, and Informed for each, at site and corporate levels.
3. Integrate with existing change control
   • Ensure all OT security changes pass through established engineering and quality change processes.
   • Include impact assessments for safety, quality, validation status, and uptime, not just security.
4. Align on minimum baselines
   • Define a baseline set of OT controls (e.g., segmentation, backups, access control, logging) that every site must meet, with room for local adaptation.
   • Explicitly document where legacy or vendor constraints require deviations.
5. Test and iterate
   • Run tabletop exercises and small pilots to validate that responsibility splits work in practice.
   • Adjust the RACI and procedures based on actual incidents, near misses, and audit findings.

Key tradeoffs to acknowledge

When distributing OT security responsibilities, it helps to make tradeoffs explicit:

• Security vs. availability: aggressive scanning, patching, or endpoint controls may reduce cyber risk but increase unplanned downtime risk on sensitive OT assets.
• Standardization vs. local realities: uniform corporate policies simplify governance but may be impossible on older equipment without major retrofits.
• Speed vs. assurance: fast rollout of new tools can conflict with qualification, validation, and operator training requirements.

Documenting who owns which decision in each of these tradeoffs, and under what conditions, is more important than achieving a theoretically perfect split.