Who should own ISO 27001 in organizations with both IT and OT teams?

ISO 27001 should be owned at the enterprise risk and governance level, not by a single technical team. In organizations with both IT and OT, the usual pattern is:

• A single business owner for the ISMS (often CISO, CIO, or central Risk/Compliance) accountable for the management system, scope, risk methodology, and interfaces to regulators and auditors.
• IT leadership responsible for implementing and operating controls on corporate IT and cloud systems.
• OT leadership (often an OT/plant digital lead or engineering leader) responsible for implementing and operating controls on plant-floor and industrial control systems.

This separation recognizes that ISO 27001 is a management system standard, not a pure technology standard. The accountable owner must be able to balance risk, cost, and operational impact across both IT and OT, and must sit high enough to resolve conflicts between them.

Practical ownership model in IT/OT environments

In regulated, brownfield manufacturing environments, a workable pattern is:

• ISMS Owner (Accountable): CISO, CIO, or VP Risk/Compliance.
  • Owns the ISO 27001 scope, policy framework, risk assessment methodology, statement of applicability, internal audit program, and management review.
  • Ensures interfaces with quality systems, safety processes, and change control are defined and followed.
• IT Owner (Responsible for IT scope): Head of IT / Infrastructure / Enterprise Applications.
  • Implements and maintains controls for enterprise networks, servers, workstations, business apps, identity and access management, and cloud services in scope.
  • Coordinates with OT on shared infrastructure (e.g., identity, backup, logging, DMZs).
• OT Owner (Responsible for OT scope): OT leader / Automation engineering lead / Plant digitalization lead.
  • Implements and maintains controls on ICS/SCADA, DCS, PLCs, historians, MES, and plant networks, with explicit alignment to safety, quality, and validation constraints.
  • Ensures changes respect process safety, qualification, validation, and downtime limits.
• Supporting functions: Quality, EHS, Legal, HR, and Procurement.
  • Contribute to risk assessment, supplier requirements, training, incident response, and alignment with existing QMS and safety processes.

Formally, this is usually documented via a RACI that shows who is accountable for the ISMS overall, and who is responsible for each control area across IT and OT.

Why not let OT or IT “own” ISO 27001 alone?

Assigning ISO 27001 ownership solely to IT or OT usually fails for at least one of these reasons:

• Scope gaps: An IT-only owner may under-scope OT networks, vendor remote access, or plant data flows. An OT-only owner may under-scope corporate identity, remote workstations, or cloud services that touch OT data.
• Conflicting priorities: OT optimizes for uptime and safety; IT often optimizes for standardization and strong technical controls. Neither side alone can reliably balance the tradeoffs at the IT/OT boundary.
• Regulated change control: Many OT changes require engineering review, validation, or requalification. An IT-only owner may push control changes that are not feasible within existing change-control workflows or shutdown windows.
• Supplier and lifecycle realities: OT systems have long lifecycles and limited patchability. An OT-only view may under-leverage corporate capabilities (e.g., central logging, vulnerability management), while an IT-only view may set expectations that current OT assets cannot safely meet.

A central risk or security function is usually better positioned to arbitrate these tradeoffs and decide where risk is accepted, mitigated, or transferred.

Key design points for shared ownership

Regardless of where the ISMS owner sits, you will need to make the following explicit:

• Scope definition: Exactly which plants, networks, systems, and data are in the ISO 27001 scope, including shared IT/OT components (e.g., plant domain controllers, DMZ firewalls, data diodes, VPNs, cloud historians).
• Interfaces with other management systems: How ISO 27001 interacts with the QMS, safety management, validation/qualification, and change-control processes. In many regulated plants, ISO 27001 controls cannot override quality or safety requirements.
• Control ownership by domain: For each relevant Annex A control, who is responsible for implementation on IT systems, on OT systems, and for shared infrastructure.
• Change and downtime constraints: How OT downtime windows, turnaround schedules, and qualification testing are considered when planning security controls like patching, segmentation, or MFA rollouts.
• Incident response integration: How cyber incidents in OT are triaged, escalated, and resolved, including coordination with safety, operations, and quality incident processes.

Brownfield and long-lifecycle considerations

In brownfield plants with legacy MES, SCADA, and control systems, full “replacement” of existing practices with ISO 27001-style controls is rarely realistic. The ISMS owner should focus on:

• Mapping, not replacing, controls: Identify where existing QMS, safety, and engineering controls already meet or partially meet ISO 27001 requirements, and document equivalence instead of forcing new parallel processes.
• Risk-based prioritization: Concentrate on high-risk interfaces (e.g., remote access into OT, cross-plant connectivity, vendor support routes) rather than trying to standardize every legacy asset at once.
• Change-control alignment: Ensure that any new security controls go through established change-control, validation, and qualification gates for regulated equipment.

This is another reason why ownership at the enterprise risk/security level is important: they can negotiate realistic timelines and risk acceptances that respect operational and regulatory constraints.

How to decide in your organization

When you formalize ISO 27001 ownership:

1. Place accountability with the function that already owns enterprise risk or information security policy (commonly CISO/CIO or central risk/compliance), not within a single plant or a single IT/OT team.
2. Form an ISMS steering group with IT, OT, Quality, and operations leadership to agree on scope, priorities, and risk criteria.
3. Document a RACI that clearly distinguishes ISMS-level accountability from domain-level responsibility for control implementation in IT and OT.
4. Align with existing management systems (QMS, safety, validation) to avoid duplicate processes and to ensure security changes do not disrupt qualified and validated operations.

The result is a single accountable ISO 27001 owner, with shared responsibility across IT and OT that reflects how your plants actually run.