Security should own risk identification, operational context, and prioritisation, while operations should own feasibility, scheduling, and execution. The two teams need a common approval path with clear decision criteria, because vulnerability management in OT fails when either side can veto changes without a documented alternative.
How Security and Operations Should Split OT Remediation Ownership
The cleanest model is shared accountability with separated decision rights. Security should identify risk, explain exposure in operational terms, and rank what matters most; operations should decide what can safely change, when it can change, and how to execute it without destabilising the environment. In OT, remediation works when both functions treat the workflow as a controlled change process rather than a purely technical ticket.
That split matters because OT remediation often sits between safety, uptime, and cyber risk. A control room, a maintenance window, or a safety interlock can make a theoretically urgent fix impossible in practice. Good ownership therefore starts with a common vocabulary for severity, asset criticality, and acceptable delay, so that security does not overstate urgency and operations does not normalise indefinite deferral.
Where teams need a practical reference point, the remediation process should sit inside a broader OT operating model such as the OT Security Guide and the OT Security Maturity Model, because both frame remediation as part of segmentation, asset context, and repeatable governance rather than ad hoc fire drills.
What Each Team Owns in the Remediation Workflow
Security owns the risk signal. That means identifying exposed assets, interpreting exploitability, understanding business impact, and deciding which findings deserve immediate attention versus scheduled remediation. Operations owns feasibility. That includes whether the fix can be applied without breaking a process, whether a workaround is safer than an immediate patch, and what sequence minimises production disruption.
The joint decision point is prioritisation. Security should bring the evidence, but operations should be able to challenge assumptions about maintenance windows, dependency chains, and rollback risk. A remediation decision is strongest when the team can answer three questions together: what is the risk, what is the operational cost, and what is the safest path to reduce both.
That division works best when the teams also recognise the local context of OT assets, which is often captured well in the OT and ICS Identity and Access Guide and the Top 10 OT Security Risks, because remediation frequently depends on shared accounts, remote access paths, flat networks, or default credentials that change the remediation order.
How to Make the Approval Path Work Without Creating Stalemates
The approval path should be explicit, time-bound, and documented. Security should not be able to force a change that operations cannot safely perform, and operations should not be able to decline remediation without naming the compensating control or the date of the next review. The objective is not consensus for its own sake, but a decision record that shows why a risk was accepted, deferred, mitigated, or remediated.
Good practice is to predefine escalation thresholds. For example, a high-confidence exposure on a critical OT system should trigger a rapid review, while lower-confidence or lower-impact issues can follow the regular maintenance cycle. If the fix requires downtime, the approval path should also capture whether a safer interim mitigation exists, such as segmentation, access restriction, increased monitoring, or a scoped isolation measure.
That is why the remediation workflow should be linked to OT incident readiness and recovery planning, not treated as a standalone patch queue. The OT Incident Response Guide is useful here because it reinforces the same safety-first decision logic that remediation needs when changes may affect process availability.
Risk and Threat Considerations
OT remediation breaks down when either team can block progress without a documented alternative. The result is either uncontrolled change, where fixes happen informally and unsafely, or unmanaged exposure, where known vulnerabilities remain open indefinitely. Both conditions create attacker advantage and operational fragility, especially where exposed remote access, legacy assets, or shared credentials widen the blast radius.
Failure mechanism: Security can over-prioritise from a cyber perspective while operations can under-prioritise from a production perspective, and without a shared approval path the organisation ends up with vetoes instead of decisions. That gap allows vulnerabilities to persist, exceptions to multiply, and compensating controls to become permanent by accident.
Impact: The practical consequence is prolonged exposure on critical systems, delayed containment when a flaw is active, and higher chance of unsafe remediation later under pressure. In OT, the cost is not only security risk, but also process interruption, safety exposure, and loss of confidence in the remediation programme.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | OT remediation is vulnerability management under operational constraints. |
| Recommendation — Prioritise and track OT vulnerabilities with an exception path for unsafe or delayed changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | OT remediation often depends on controlled access paths and approval rights. |
| GV.RM-01 — Risk Management Strategy | Shared remediation ownership requires explicit risk acceptance and prioritisation criteria. | |
| Recommendation — Limit who can approve, change, and execute OT remediation actions. Define how cyber and operational risk are weighed for OT remediation decisions. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | OT remediation is a controlled change process that needs approval and rollback discipline. |
| RA-5 — Vulnerability Monitoring and Scanning | Security must identify and prioritise OT vulnerabilities before operations schedules fixes. | |
| IR-4 — Incident Handling | OT remediation and containment decisions must align with operational response and recovery. | |
| Recommendation — Require formal change approval and documented impact analysis for OT remediation. Continuously assess OT assets for vulnerabilities and feed results into remediation planning. Coordinate containment and recovery decisions with OT stakeholders during remediation. | ||
Practitioner Guidance
What to verify: Every remediation request should state the affected asset, the operational dependency, the preferred fix, the acceptable window, and the fallback if the fix cannot be applied. If any of those fields are missing, the request is not ready for approval.
Decision rule: If the issue can affect a critical production system, prioritise a joint review that weighs exploitability against downtime and safety impact; if it cannot, route it through the normal maintenance queue with a documented target date. The point is to make delay intentional, not accidental.
What good looks like: Security and operations use the same severity language, the same escalation path, and the same record of why a change was approved, deferred, or mitigated. When that is working, remediation no longer depends on individual relationships or informal escalation.
Practitioner takeaway: OT remediation is strongest when security judges risk and operations judges changeability, but neither side gets to stop the process without proposing a defensible alternative.
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI remediation in cloud environments?
- Who should own remediation when exposed OT systems sit at the intersection of security, IT, and plant operations?
- Who should own automated remediation decisions when MDR and internal security teams share responsibility?
- How should security teams govern non-human identities at scale?