治理要解决什么
OT 安全治理解决的是「谁决策、谁执行、谁监督」。工控环境横跨生产、设备、信息化与安全多个部门，如果只由信息部门单方推动，在需要停机或改动控制逻辑时很容易被现场搁置。合理结构包含决策层（安全委员会或分管领导）、管理层（OT 安全负责人与制度维护）、执行层（控制工程师、网络运维、厂商与承包商）与监督层（审计、检查与考核），并明确各方在风险接受、变更审批与应急处置上的权限。
层级与职责
| 决策层 | 审定安全目标与资源投入，批准残余风险接受 |
|---|---|
| 管理层 | 制定制度与流程，组织风险评估与整改跟踪 |
| 执行层 | 落实技术措施，执行变更、巡检与备份 |
| 监督层 | 检查合规性、审计记录并推动整改闭环 |
| 外部方 | 厂商、集成商与承包商按合同要求作业并接受监督 |
| 跨部门机制 | 生产、设备、信息与安全共同参与的例会与联合审批 |
关键事项的职责划分
| 事项 | 主责 | 配合 | 审批 |
|---|---|---|---|
| 风险评估 | OT 安全负责人 | 控制与生产部门 | 分管领导 |
| 策略变更 | 网络与安全运维 | 控制工程师 | OT 安全负责人 |
| 程序下装 | 控制工程师 | 仪表与电气专业 | 生产调度 |
| 远程接入申请 | 申请人所在部门 | OT 安全负责人 | 生产与安全双方 |
| 事件处置 | 控制工程师先恢复生产 | 安全团队同步取证 | 应急指挥组 |
最小可行结构
- 明确一名 OT 安全负责人，同时对生产与技术两条线负责
- 建立跨部门例会，审议变更申请与风险处置进展
- 把安全要求写进操作规程与作业票，让执行层在日常流程中执行
- 把安全检查纳入既有考核，而不是单独立项造成两套流程
- 记录每次风险接受的决策人与时间，便于事后追溯
治理不必从庞大组织开始：在中小规模工厂里，最实用的做法是把 OT 安全要求挂到既有的设备管理与变更管理制度上，而不是另建一套并行流程。两套流程并行时，执行层一定会选择成本更低的那一套。
最危险的治理状态是安全部门有要求但没有否决权，生产部门有否决权却不承担安全责任。此时安全措施会在每次冲突中被推迟，直到发生事故才回头补做，而代价由整个组织承担。