Who should own cybersecurity accountability in a manufacturing organisation when operational and IT risks overlap?

Cybersecurity accountability should be shared, but not vague. Manufacturing security works best when operational leaders, IT security, and business executives each own defined parts of the risk, with clear decision rights for identity, access, and incident response. If responsibility sits with only one function, gaps emerge at the boundaries where most plant attacks take advantage of confusion.

How cybersecurity ownership works when the plant and IT stack intersect

In a manufacturing organisation, cybersecurity accountability should follow the control point, not the org chart. Operational technology teams usually understand process safety, uptime, and equipment behaviour, while IT teams typically control enterprise identity, endpoints, logging, and network governance. The overlap is where failures appear: remote access, engineering workstations, vendor connectivity, segmented networks, and incident response coordination all require explicit ownership rather than informal collaboration. For a useful external baseline on cross-functional cyber governance, NIST Cybersecurity Framework 2.0 explains how organisations can organise risk ownership across functions without assuming a single team can carry the full burden; read the NIST Cybersecurity Framework 2.0 alongside your internal responsibility model.

The practical question is not whether IT or operations is “in charge” overall, but who has authority to approve access, accept residual risk, interrupt production, and escalate when controls fail. In practice, many manufacturers discover that their accountability model was never tested until a vendor session, production outage, or containment decision forced separate teams to act without a shared decision path.

Where shared responsibility becomes real in manufacturing security

Ownership becomes meaningful when it is attached to decisions that can be traced, measured, and escalated. Operational leaders should own the cyber risk introduced by plant availability, process interdependencies, and safety-adjacent control changes. IT security should own enterprise security standards, identity governance, monitoring, and incident handling across corporate systems and shared infrastructure. Business executives should own the residual risk decision when security work competes with production, cost, or schedule. That structure avoids the common failure mode where every team is consulted, but no one can say yes or no.

Accountability also needs to reflect the different pace of the two environments. IT can often change controls quickly; plant environments may require maintenance windows, vendor coordination, validation, and rollback planning. A good ownership model therefore separates execution from decision rights. For example, operations may own whether a line can be taken offline, while IT security owns whether the access path, logging, and authentication controls are acceptable. The distinction matters because “shared responsibility” without named authority usually turns into delay, duplicated work, or unsafe exceptions.

Control frameworks can help clarify those handoffs. If identity and access are part of the overlap, teams often map the decision chain to control families rather than to departments. Where cross-domain visibility is weak, organisations may use NIST SP 800-53 Rev 5 Security and Privacy Controls to separate access enforcement, logging, monitoring, and contingency expectations into assignable duties. The value is not the framework itself, but the discipline of forcing each risk owner to name the control they actually manage.

Operations owns plant availability, maintenance timing, and the cyber impact of process changes.
IT security owns authentication, logging, network controls, and corporate security standards.
Executive leadership owns residual risk acceptance when production priorities override remediation.

The model breaks down when the same committee is asked to “own everything” but no one is empowered to stop unsafe access, approve a compensating control, or force an incident decision.

When responsibility splits cleanly and when it does not

Tighter accountability often improves control clarity, but it also adds coordination overhead, so organisations have to balance decision speed against the need for explicit risk ownership. That tradeoff is most visible in hybrid environments, where engineering, maintenance, and security all touch the same asset or remote session. In those cases, consensus is not enough. Guidance differs across industries on the best operating model, but there is broad agreement that the owner of the business process should not be confused with the owner of the security control.

One common edge case is third-party support. A vendor may manage a controller, a historian, or a diagnostic tool, but that does not remove internal accountability for access approval, monitoring, or incident escalation. Another edge case is incident response during production. IT may lead containment, but operations must judge safety and continuity impacts, and leadership must decide whether to pause output. Those handoffs need to be documented before a crisis because the first incident is the worst time to discover that the organisation cannot decide who may disconnect which system.

Manufacturing organisations also underestimate how often cyber accountability becomes a business decision, not a technical one. If a control change would reduce exposure but requires downtime, the organisation needs a named owner for the acceptance of that delay. In that sense, shared accountability is strongest when each team owns a different question, and weakest when everybody owns the same answer.

Risk and Threat Considerations

The main risk in overlapping operational and IT environments is not simply weak security, but ambiguous authority at the boundary between uptime, safety, and access control. That ambiguity creates delays in containment, inconsistent approvals, and gaps in monitoring when a vendor path, remote access route, or plant workstation sits between teams.

Failure mechanism: An attacker or internal failure can exploit unclear ownership by using the least-governed access path, the slowest escalation route, or the control that no team believes it owns. In manufacturing, that often means remote support channels, shared admin credentials, or delayed containment decisions that let activity continue long enough to spread.

Impact: The result can be delayed incident response, loss of visibility across plant and enterprise systems, unapproved access persistence, production disruption, or a safety-adjacent operational decision being made too late to prevent damage.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RM — Risk Management Strategy	Covers assigning cyber risk ownership across business and operational functions.
	GV.OV — Oversight	Supports governance oversight when accountability is split across functions.
	PR.AA — Identity Management, Authentication, and Access Control	Applies where ownership overlaps around remote access, approvals, and privileged sessions.
Recommendation — Define explicit risk owners for plant, IT, and executive decisions at overlap points. Set oversight forums that can resolve accountability disputes and approve exceptions. Assign clear owners for authentication and access decisions across plant-connected systems.
CIS Controls v8	Control 6 — Access Control Management	Relevant to defining who approves and revokes access across operational and IT boundaries.
	Control 8 — Audit Log Management	Supports accountability by ensuring boundary actions are logged and reviewable.
	Control 17 — Incident Response Management	Applies because incident ownership must be defined across production and IT response paths.
Recommendation — Use access control ownership to separate approvers, enforcers, and reviewers. Retain and review logs for privileged and vendor activity across shared environments. Assign incident authority so containment decisions do not stall between teams.

Practitioner Guidance

What to prioritise: Define decision rights before defining reporting lines. The first test is simple: who can approve access, who can accept residual risk, who can stop a production-connected session, and who must be notified when those decisions are exercised?

What good looks like: Each high-risk overlap has one accountable owner, one backup approver, and one documented escalation path. If a control crosses plant and enterprise boundaries, the organisation should be able to name the person who owns the control outcome, not just the technology.

Common mistake: Treating “shared accountability” as a substitute for named ownership. That usually produces committee governance with no enforcement power, which is exactly where boundary failures survive.

Practitioner takeaway: In manufacturing, the right answer is not a single owner for all cyber risk, but a clear owner for every boundary decision where production, safety, and access control intersect.