Who should be accountable for cybersecurity when safety-critical systems are being modernized across multiple teams?

Accountability should sit with the teams that certify, operate, and secure the connected system together, not with one function alone. Safety, operations, and cybersecurity all need defined ownership because modern control environments blur traditional boundaries. When responsibilities are split, critical issues such as insider monitoring, certification, and intrusion detection can fall between the gaps.

Who should own accountability when modernization spans safety, operations, and security?

Accountability should sit at the system level, not inside one silo. When teams modernize safety-critical environments together, the accountable owners are the people who can certify the change, operate the live service, and secure the connected components end to end. That means shared responsibility with clear decision rights, not shared confusion.

In practice, this is a governance problem as much as a technical one. If modernization changes interfaces, trust boundaries, monitoring paths, or fail-safe behavior, then the accountable group must be able to answer for the full control chain, including the handoffs between engineering, operations, safety, and cybersecurity.

Why siloed ownership breaks down in modern control environments

Modern safety-critical systems rarely stay inside one team’s boundary. A change to a controller, a telemetry path, a remote maintenance channel, or a cloud-connected service can alter both operational safety and cyber exposure at the same time. If ownership is split too thinly, each team may assume another function will catch the problem.

That is where gaps form around certification evidence, monitoring coverage, and intrusion detection. A safety team may validate functional behavior, operations may keep the plant running, and security may watch for compromise, but none of them can be accountable if they cannot see the full dependency chain or own the final risk decision.

This is why modernization programs need one accountable integration owner for the connected system, even when multiple teams execute the work. The owner does not do everything; the owner makes sure nothing is left unowned.

How accountability should be structured across teams

The most defensible model is a named accountable lead with explicit responsibility across the full change lifecycle, supported by specialists for safety, operations, and cybersecurity. The accountable lead should own the final sign-off criteria, the escalation path, and the decision to accept residual risk when a modernization step crosses team boundaries.

Specialists then retain authority over their own domain outcomes. Safety validates hazard impact, operations validates service continuity, and cybersecurity validates integrity, access, logging, and detection. The point is not to merge those functions into one team, but to force the program to reconcile them before go-live.

Where connected systems are involved, accountability should also include evidence quality. If the team cannot show who approved the change, who tested the failure modes, who verified monitoring, and who owns response if something degrades after deployment, then accountability exists only on paper.

Risk and Threat Considerations

Modernization projects increase exposure when responsibilities are fragmented across teams with different success criteria. The dangerous pattern is not just missed communication, but a control gap where everyone thinks another group owns the risk, so abnormal behavior, weak segmentation, or incomplete logging goes unchallenged.

Failure mechanism: Handoffs across safety, operations, and cybersecurity create blind spots in certification, monitoring, and response, especially when a change affects remote access, trusted integrations, or connected control paths.

Impact: A compromised or misconfigured modernization path can create unsafe operating conditions, delay detection of malicious activity, or leave the organization unable to prove who approved, tested, and monitored the change.

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 NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.OV-01 — Oversight of Governance, Risk, and Compliance	Modernization across teams needs clear oversight and accountable decision rights.
	GV.RR-01 — Roles, Responsibilities, and Authorities	The question is fundamentally about who is accountable across safety, operations, and security.
Recommendation — Assign one accountable owner for cross-team modernization oversight and sign-off. Define roles and authorities for safety, operations, and cybersecurity before deployment.
NIST SP 800-53 Rev 5	PM-1 — Information Security Program Plan	Cross-team modernization needs an authoritative program structure and ownership model.
Recommendation — Document program accountability for integrated safety and cybersecurity changes.
ISO/IEC 27001:2022	A.5.2 — Information security roles and responsibilities	Accountability across multiple teams depends on explicit role ownership.
	A.5.24 — Information security incident management planning and preparation	Joint ownership must include who responds if modernization introduces compromise or failure.
Recommendation — Assign and record security responsibilities for each team involved in modernization. Define response ownership and escalation paths before connecting modernized systems.

Practitioner Guidance

What to verify: Confirm that every modernization initiative has one named accountable owner for the connected system, plus explicit owners for safety approval, operational readiness, and security assurance. If any one of those roles is missing, the project is not ready for final authorization.

Decision rule: If a change crosses a boundary between control engineering, operations, and cyber defense, require a joint sign-off package that includes certification evidence, rollback criteria, and monitoring ownership before deployment. If that package does not exist, treat the change as incomplete, not merely pending documentation.

Practitioner takeaway: In safety-critical modernization, accountability should follow the system outcome, not the org chart. The safest model is one accountable owner for the integrated change, with named domain owners who can be held to their part of the control chain.