风险接受决策流程图
风险接受决策流程图：是否已评估应对方案、剩余风险是否在风险偏好范围内、谁有权签字，以及这项接受何时失效。
什么是风险接受决策流程
接受是那种既不需要预算、也不需要项目、更不需要谁去做任何事的风险应对方式——正因如此，它也是各家组织最容易在不知不觉中落入的一种。一条风险躺在台账里，控制措施始终没有获得经费，两轮评审之后，这个条目就被描述成“已接受”，尽管没有人做过任何决定，也没有任何人的名字写在上面。把接受画成一棵决策树，正是把“有人选择去承担的风险”与“所有人都不再看的风险”区分开来的办法。
本页是一棵决策树，而不是一张流程图。它只回答一个问题——这项剩余风险是否应当被接受，以及谁有权接受它——办法是按顺序走完各道检验，最终抵达五个具名结果中的一个，而不是把所有分支重新收拢到一条顺利路径上。它并不描述围绕在外面的那个循环。识别、评分、控制措施有效性以及复评闭环属于风险评估流程图，那是一张说明“接下来发生什么、由谁来做”的跨职能流程图。程序层面的文件用那一张；本图用于其中那个需要在两个选项之间做出判断、并且需要有人签字的时刻。
左侧四条泳道命名的是谁来回答每个问题，而不是谁来干活：风险责任人、风险管理负责人、法务与合规，以及接受风险的审批方。这棵树有两处刻意不留余地。违反法定、监管或合同义务的风险根本不会走到审批方那里，因为不合规不是组织可以自行接受的，它直接出口到整改。而超出偏好的剩余风险不能被永久接受：它需要一项补偿性控制和一个失效日期，并作为由风险委员会批准的限时例外来承担，而不是一签了之。审核员要找的正是这两条分支。
本流程图涵盖的内容
本模板包含
- 四条决策权泳道——风险责任人、风险管理负责人、法务与合规、接受风险的审批方——铺在五个阶段上：提案、应对检验、适用性检验、附加条件，以及审批与记录。
- 在接受被摆上台面之前的两道关口：“是否已评估应对方案？”把没有依据的提案退回“补做应对方案分析”，而“应对是否可行且合乎比例？”在“是”这一侧直接出口到“采取应对而非接受”。
- 法务与合规泳道中的“是否违反法定或合同义务？”，其“是”分支通向“拒绝接受并整改”——这是全图唯一一种从不送交审批方的风险敞口。
- “剩余风险是否在风险偏好范围内？”分为“范围内”与“超出”。范围内继续走向附加条件与权限的检验；超出则进入“是否已有补偿性控制？”，要么彻底拒绝接受，要么经由“确认控制措施并设定失效日期”构建一个限时例外。
- 签字权由等级决定，而不是由谁有空决定：“剩余风险处于哪一等级？”把“低／中”送往“该经理是否拥有授权权限？”，把“高／严重”送往“风险委员会是否接受该剩余风险？”，因此“在经理层级接受”与“在高管层级接受”是两个各自独立的终点。
- “接受是否设定期限与复评日期？”带一条“否”分支，在任何人签字之前先设定失效日期；全图共有五个终止点：采取应对而非接受、拒绝接受并整改、在经理层级接受、在高管层级接受，以及临时接受至失效日期。
何时使用本模板
- 你们正在编写风险政策中关于接受或例外的条款，需要把各道检验写下来，而不是用散文描述。
- 你们的风险台账里有一些标着“已接受”的条目，既没有签字人，也没有附加条件和失效日期，你们需要让接受成为一个动作，而不是一种默认状态。
- 你们正在确定风险接受的授权分级，希望在下一次为“谁来签字”争论之前，把每一个等级都绑定到一个具名层级。
- 审核员或认证机构问起某项剩余风险是谁接受的、依据是什么——例如 ISO/IEC 27001 就要求风险责任人批准应对计划并接受剩余的信息安全风险。
- 某个团队申请一项安全或政策例外，你们需要一套可重复的检验，带附加条件和失效日期，而不是一次次逐案谈判。
运作方式
把泳道改成你们的决策权
把风险责任人、风险管理负责人、法务与合规以及接受风险的审批方，换成你们真正拥有的角色。让风险责任人与风险管理负责人保持分开：一个承担后果，另一个负责方法，而后者不应当是签字的那个人。如果你们的高管团队和风险委员会是同一个会议，就把它们合并成一个审批方，而不是画一次从不发生的交接。
把你们的偏好阈值写到偏好检验上
“剩余风险是否在风险偏好范围内？”是全图的枢纽，所以要把风险政策里的阈值写在它旁边——评分区间，或者用平实的话写明组织在金额、停机时间、伤害或声誉上愿意与不愿意承担什么。只活在政策文件里的偏好，只能凭记忆去估摸，而这正是同一种风险敞口在一个人的桌上算“范围内”、在另一个人的桌上算“超出”的原因。
把等级映射到具名的接受权限
把“低／中”和“高／严重”换成你们自己的评分区间，并写明每一级由谁签字。有两条规则能让这条分支保持诚实：当一项接受正是给某人自己的项目放行时，此人不得为自己承担的事项签字；以及经理那一支要显式检查授权权限，而不是假定资历自带权限。任何超出该经理权限上限的都走向委员会——“该经理是否拥有授权权限？”存在的意义正在于此。
定义什么才算补偿性控制
在超出偏好的那条分支上，补偿性控制是横在例外与拒绝之间的唯一一样东西，所以要把检验写清楚。它必须是已经在运行的，而不是计划中的；必须有证据，而不是口头声称；而且必须减少的正是这项风险敞口，而不是它旁边的另一项。监控只有在有人被要求对它报出的情况采取行动时才算数。
为接受期限设上限，并写明到期后会怎样
给期限设一个上限，而不是交给提案人自行决定——常见做法是不长于下一次既定评审，对高等级风险则更短——并加上事件触发条件，例如一起事件、一次系统变更、一份新合同，或者控制措施本身发生变化。写明到期后接受即告失效，风险重新进入本树，因为一项默默续期的接受，不过是一项贴了日期的无限期接受。
把决定记入台账，并只保留一个当前版本
这棵树的产出是一条记录：谁接受、在哪一等级、依据哪一项授权权限，附加条件与补偿性控制，失效日期与复评日期，以及那份论证“接受而非应对”的应对方案比较。把画好的图与风险、法务以及签字的人一起走一遍，改成他们实际在做的样子，然后发布那一版，并保留此前的各版，好让日后打开它的人知道自己读的是哪一版。
常见问题
什么是风险接受？
风险接受，是在知情的前提下选择保留一项剩余风险，而不是降低、转移或规避它。ISO 31000 把“经知情决定而保留风险”列在应对方案之中，而要抓住的正是“知情决定”这个词：接受一项风险与忽视一项风险的区别，在于有一位具名的、有权承担它的人，有一份关于决定当时已知情况的记录，以及附加在这项接受上的条件。当应对方案已被测算成本并被判定与风险敞口不成比例时，接受是正当的。而当没有人给控制措施拨款时，接受就不是正当的——这也正是本图前两道决策要在考虑接受之前先检验应对方案分析的原因。
谁应当有权接受一项风险？
对后果负责的那个人，且层级要与风险等级相匹配。多数组织把这写进一份授权表：低和中等级由直线经理或部门经理签，高和严重等级由高管责任人或风险委员会签。有两项保障比“线画在哪里”更重要。本图显式检查授权权限——“该经理是否拥有授权权限？”——而不是假定资历自带权限；任何超出上限的都升级处理，而不是在本地签掉。另外，接受风险的审批方不应当是这项接受对其有利的那个人：如果这项接受正是给某人的项目或预算放行，那么这个决定应当上移一级。
可以接受一项违反法律、法规或合同的风险吗？
不可以。组织无法决定自己不合规，因此对法定、监管或合同义务的已知违反要走整改而不是接受，而在本图中，那条分支根本到不了审批方，它出口到“拒绝接受并整改”。可以正当地设定时限的，是整改期间的过渡性风险敞口：一份有责任人和日期的计划，向需要知情的人做的上报，以及在适用之处就披露或申报义务征询的法律意见。把它记成一项已接受的风险，才是审核员和监管方反应很差的那个版本，因为它记录下来的是一个“决定承担一项违规”的决定。
风险接受应当设失效日期吗？
应当。一项接受，是对某一天的风险敞口、控制措施和应对成本所做的判断——而这三样都会漂移。给每一项接受设定期限和复评日期，把上限写进政策而不是交给提案人，并让等级越高、期限越短。明确写出到期后会发生什么：接受失效，风险回到这棵决策树重新取得一个答案，而不是点点头就续下去。在日期之外再加上事件触发条件——一起事件、一次系统或供应商变更、一份新合同，或者补偿性控制被更改或撤除——因为它们比日历更早告诉你们，这个判断已经过时了。
这与风险评估流程图有什么区别？
它们回答的是不同的问题。风险评估流程图是一张跨职能流程图：它展示接下来发生什么、由谁来做，从识别到评分、控制措施有效性、应对，一直到复评周期。本页则是这个流程内部某一个时刻的决策树——在那一刻，应对已经被测算过成本，有人必须在应对与接受之间做出选择。这里没有要交接的任务，只有需要凭证据回答的检验，而且它止于五个各不相同的结果，而不是一份结案记录。如果你们要写的是程序文件，就用风险评估流程模板。如果你们要了结的是“谁可以接受什么、在什么条件下、到什么时候为止”，就用本页这一张。