风险评估流程图
风险评估流程图：界定范围与标准、识别风险、为可能性与影响评分、判断控制措施有效性、四种应对方案，以及复评循环。
运作方式
把泳道改成你们自己的治理结构
把流程责任人、风险责任人、风险管理负责人、领域专家和风险委员会，换成你们实际拥有的角色。在规模较小的组织里，风险管理负责人和委员会本来就是同一个会议，把它们合并比留下一条一年只开一次会的泳道更诚实。让风险责任人与风险管理负责人保持区分：一个承担风险，另一个负责跑流程。
把你们的量表与风险偏好写到标准那一步上
填入你们真正在用的可能性与影响定义，包括每一级在金额、时间或伤害上意味着什么，并写明超过之后风险必须被应对而不能被接受的那条阈值。活在另一份政策文件里的标准只能凭记忆去估摸——而这正是两位评估人从同样的事实得出不同分数的机制。
确定识别方法以及谁必须到场
决定风险是怎么被浮现出来的——研讨会、访谈、检查表、事件与审核历史——以及谁必须在场。由一个人在办公桌前完成的识别，会漏掉只有真正干这份活的人才看得见的风险，而事后再仔细的评分，也弥补不了一条根本没人写下来的风险。
先为固有风险评分，再给控制措施计分
像图里那样，把固有分数和剩余分数保持为两个独立的步骤。只评剩余状态会掩盖你们的安全余量有多少压在某一项控制措施上，而一旦那项控制发生变化，台账立刻就没用了。把控制措施的设计有效性和运行有效性分开评：设计再好却没人执行的控制，一文不值。
写明接受一项风险所需的审批层级
接受是一种正当的应对，也是被滥用得最多的一种，因为它同时也是“没有人采取行动”时会发生的事。写下每个评分区间由谁可以接受一项风险，并要求这项接受被记在一个具体的名字上。正是这一条规则，能防止台账里堆满被默认接受的风险。
设定复评触发条件，并让这张图保持版本化
按评分区间选定复评节奏，再加上事件触发条件——一起事件、一次供应商变更、一套新系统、一项审核发现。把复评日期记在台账条目上，而不是记在某个人的日历里。把流程图本身置于版本控制之下并留存其批准记录，这样评估人和评审人才是从同一套商定方法出发。
常见问题
风险评估流程包含哪些步骤？
确立范围与标准，识别风险，把每一条描述成原因、事件与后果，分析可能性与影响，对照你们的风险偏好评价剩余状态，选择一种应对，然后设定责任人与复评日期。ISO 31000 把中间三步合称为风险评估——识别、分析、评价——应对随后进行。正是这个顺序让结果变得可比：标准先于评分，描述先于分析，评价先于任何人开始提出控制措施。
固有风险和剩余风险有什么区别？
固有风险是把现有控制措施计分之前的风险敞口；剩余风险是计分之后剩下的部分。两个都评分，才能让控制措施变得可见——一条固有分数高而剩余分数低的风险，是被某样东西按住的，而如果那样东西是由一个人执行的一道手工检查，你们会想知道。只记录剩余分数的台账看上去让人安心，却没法告诉你们哪些控制措施是承重的。
风险应对的四个选项是什么？
降低（增加或强化控制措施）、转移（保险、合同条款、外包）、规避（停止或改变该项活动），以及接受（在知情的前提下承担这项风险）。接受是一个真实的选项，而且需要一位批准人：接受一项风险与忽视一项风险的区别，在于有一位具名的、有权承担它的人，以及一条“他确实这样做了”的记录。转移是最常被高估的选项——保险转移的是财务后果，很少能转移运营或声誉上的后果。
风险评估应该多久复评一次？
按分数决定节奏，再加上事件触发条件。对分数较低的风险，一年一次是常见的基准；对接近偏好阈值的风险，则是每季度甚至更频繁。触发条件比日历更重要：一家新供应商、一次系统变更、一起事件、一项法规变化或一条审核发现，都应当把受影响的条目提前拉出来。只按计划复评的台账，只在写下它的那一天是准确的，接下来的一整年都在悄悄漂移。