接受与例外为什么必须成文
安全工作的现实是：总有一部分风险在当下无法消除，只能选择暂时接受；也总有一部分设备或系统偏离了基线而无法立刻整改。这些情况本身并不可怕，可怕的是它们停留在口头层面——没人知道存在、没人负责跟踪、也没人能说清为什么接受。文档化的作用是把模糊的「先这样吧」变成明确的记录：谁判断的、依据是什么、配套了哪些补偿措施、什么时候必须重新评估。这样风险接受就从被动的默许变成了主动的管理决策。
基本信息
| 风险接受要素 | 风险描述、影响、现有与补偿控制、残余风险、接受理由、接受人、有效期、复审条件 |
|---|---|
| 例外要素 | 偏离对象、偏离内容、偏离原因、补偿措施、责任人、有效期、关闭条件 |
| 审批权限 | 接受人须具备与该风险影响相称的决策权限，不能由执行人自行接受 |
| 有效期 | 必须设置期限或复审触发条件，禁止无限期 |
| 复审触发 | 厂商停止支持、设备改造、发生相关事件、监管要求变化 |
| 台账管理 | 统一台账、定期统计未关闭项与超期项 |
落地要点
- 统一台账：把风险接受与配置例外放在同一份台账中管理，避免散落在多份文件
- 写清理由：记录为什么选择接受而不是处置，包括成本、窗口与技术约束
- 配套补偿：每条接受项都要有补偿控制说明，否则等于无控制暴露
- 明确权限：由对生产后果负责的管理者签署，而不是由执行工程师代签
- 设置期限：给出失效日期或复审触发条件，到期自动重新评估
- 定期统计：按周期统计未关闭项与超期项，作为管理评审输入
- 关闭留痕：整改完成后记录关闭依据与验证结果
状态与后续动作
| 状态 | 含义 | 后续动作 |
|---|---|---|
| 待评估 | 已识别但未完成判断 | 补充影响与补偿分析，指定责任人 |
| 已接受 | 有权限者签署接受并设定期限 | 按期限跟踪，条件变化时重新评估 |
| 补偿中 | 正在实施补偿控制 | 验证补偿有效性后转入已接受 |
| 已整改 | 风险已消除或降低到基线要求 | 记录关闭依据与验证结果 |
| 已过期 | 超过有效期未复审 | 立即重新评估并上报，禁止默认延续 |
例外最怕的是「无界」：没有期限、没有复审条件、责任人也换了。有效的做法是给每条例外绑定一个明确的重新评估触发点，比如设备大修、厂商支持结束或年度评审，到期没有动作本身就是一个应被上报的问题。