供应商风险评估流程图（决策树）
供应商风险评估流程图：一棵由数据、访问权限、采购量、依赖度与认证等测试组成的决策树，用来确定风险等级与尽职调查的深度。
什么是供应商风险评估流程图（决策树）流程
多数第三方风险文档描述的是一个次序：申请、审查、合同、登记入册。这一份描述的是一次判断。下面这张图是一棵决策树，而不是一张跨职能流程图。它只回答一个问题——就我们对这家供应商所知道的情况而言，它属于哪一个风险等级、这会触发多深的尽职调查、以及谁有资格作出这个判断——而穿过它的每一条路径都终结于一个具名的结果，而不是绕回一条共同的顺利路径。
这个区分之所以重要，是因为这两类文档的失效方式不同。流程图失效，是在某次交接没有被写下来、于是这份文件落在了没有人手上的时候。决策树失效，是在那些测试没有被写下来的时候：同一家供应商被一位评估人定为高等级、被另一位定为低等级，于是登记册变成了一份关于谁做过这次评估的记录，而不是关于这家供应商到底是什么的记录。如果你们要的是端到端的流程——申请表、法务与财务审查、合同签署、银行信息验证以及合格供应商登记册——请改用供应商准入流程模板，它以泳道流程的形式覆盖同一片地界。供应商审批流程模板则覆盖与之相邻的那个问题：一家供应商被批准可以供应什么。
这棵树有九个决策，分布在四条按决策权划分的泳道上。安全与合规回答数据、访问权限、国别与文件方面的问题；采购与财务回答依赖度与采购量；第三方风险委员会把守最后一道关口，并负责关键供应商这个结果。它一共给出五个终点：凭一份简版问卷批准为低风险等级、在标准尽职调查包之后批准为中风险等级、在扩展审查与审计之后批准为高风险等级、带着一份商定的业务连续性与退出方案批准为关键供应商，或者拒绝。四个关键测试上都放了写明标准的注释，因为一棵没有写下阈值的决策树，只是一种带着箭头的看法。
本流程图涵盖的内容
本模板包含
- 四条按决策权划分的泳道——业务责任人、安全与合规、采购与财务、第三方风险委员会——横跨五个阶段：受理、数据与访问权限、采购量与依赖度、国别与文件，以及风险等级与结果。
- 开头的分叉在“是否处理个人数据或受监管数据？”：“是”通向“数据处理协议是否已被接受？”，其中“已拒绝”终止于“拒绝该供应商”；“否”通向“是否需要访问系统、场所或知识产权？”，它问的是即使没有数据流动，这家供应商是否仍然能触及你们的系统、场地或知识产权。
- 由采购与财务回答的低敞口分支：“是否为单一来源或难以替换？”把“是”送往业务连续性与退出方案以及关键供应商这个结果，而“否”通向“采购量是否超过重要性阈值？”，其中“超过阈值”会启动标准尽职调查包，“低于阈值”则只拿到简版供应商问卷。
- 由安全与合规回答的敏感分支：“是否属于高风险国别或行业？”把“高风险”导向“制裁名单或负面报道是否有命中？”——“有命中”即拒绝，“无异常”进入扩展审查——而“标准”则通向“认证是否有效？”，其中“已认证”下降到标准包，“没有”则升级为扩展审查与审计。
- 最后一道关口“扩展审查是否通过？”把“通过”送往带控制措施的高风险等级批准，把“未通过”送往同一个拒绝终点，好让扩展审查是一次真实的测试，而不是一道形式。
- 五个各不相同的终点——批准为低风险等级、批准为中风险等级、批准为高风险等级、批准为关键供应商、拒绝该供应商——外加放在数据、依赖度、采购量与认证这四个测试上的标准注释。
何时使用本模板
- 两个人把同一家供应商定成了不同等级，你们需要把这些测试写下来，而不是每次都拿来争。
- 你们要按敞口来设定尽职调查的深度，而不是给每一家供应商都发同一份四十页的问卷。
- 一份客户安全问卷，或者一次面向 ISO 27001 或 SOC 2 的就绪工作，问起你们如何对第三方分级、以及每个等级会触发什么。
- 你们需要商定决策权：哪些问题由安全回答、哪些由采购与财务回答，以及在哪里必须让风险委员会介入。
- 你们已经有一条供应商准入或审批流程，而里面那个风险分级步骤是一个孤零零、没有解释的方框。
运作方式
打开模板，并重命名按决策权划分的泳道
把业务责任人、安全与合规、采购与财务以及第三方风险委员会，换成你们组织里真正回答这些问题的角色。把泳道限定在拥有决策权的人身上，而不是把每一个部门都画进去，否则这棵树又会变回一张流程图。
把你们的重要性阈值写到节点上
用你们自己的货币定一个金额，与财务商定，并把它放进“采购量是否超过重要性阈值？”的注释里。把它用在承诺的年度采购量上，而不是第一笔订单上，并写明当一家现有供应商在期间中途越过这条线时会发生什么。
定义什么才算高风险国别或行业
指名你们使用的来源，而不是把它留给主观判断——腐败与制裁指数、你们自己的受限国别清单、处于特定监管之下的行业。对制裁名单与负面报道检查也做同样的事，指名要筛查哪些名单、由谁执行搜索。
写明你们接受哪些认证，以及它们的边界
列出可以让一家供应商走上“已认证”分支的文件：一份认证范围覆盖你们所采购服务的有效 ISO 27001 证书、一份新近的 SOC 2 Type II 报告、一项获得认可的行业认证。并且明确写出：过期的证书，或者认证范围指向另一个法律实体的证书，不算数。
补齐每个风险等级究竟要求什么
那四个批准终点，只有在它们背后的调查包真的存在时才有用。写下简版问卷问些什么、标准尽职调查包包含什么、扩展审查与审计在实际操作中意味着什么，以及对一家关键供应商而言，一份可接受的业务连续性与退出方案是什么样子。
设定重新评估的触发条件，然后送出去签署确认
给每个风险等级挂上一个复评间隔，并加上会把一家供应商重新拉过这棵树的事件触发条件：股权变更、一次数据泄露通报、一条新的数据流、采购量越过阈值。把这张图分享给安全、采购与财务，取得他们的批准，并对它做版本管理，好让图和成文的政策不会各自漂移。
常见问题
供应商风险评估和供应商准入流程有什么区别？
它们回答的是不同的问题。准入是一张流程图：它展示接下来会发生什么、由谁去做，从最初的申请，经过法务与财务审查、合同签署、银行信息验证，直到合格供应商登记册上的那条记录。供应商风险评估则是一棵决策树：它展示你们选择哪一个选项、以及谁有资格作出这个选择——它拿走关于一家供应商的事实，返回一个风险等级，外加这个等级所要求的尽职调查深度。在多数组织里，这次评估是准入流程里的一个节点。把它们分开记录，既能让准入图保持可读，又能迫使分级标准被真正写下来，而不是藏在一个写着“评估风险”的方框里。
供应商风险评估应该采用哪些标准？
六个测试能覆盖多数情形，也正是这棵树里的那六个：这家供应商是否处理个人数据或受监管数据、是否会获得对系统、场所或知识产权的访问权限、年度采购量相对于重要性阈值处在什么位置、它是不是单一来源或者难以替换、所在国别或行业是否带有更高风险，以及它是否持有有效且范围合适的认证。把清单保持得足够短，让一位评估人可以凭受理记录就回答完，并把每一条阈值写在它所属的问题旁边。只活在另一份政策文件里的标准，会被凭记忆近似套用——而两位评估人从同样的事实得出不同等级，正是这么来的。
我们应该设几个供应商风险等级？
三个等级加上一个单独的关键标识，对多数组织都适用，这也正是这里的结构：低、中、高，以及为那些你们没法轻易替换的供应商准备的“关键”。等级更多只会带来关于该放哪一档的争论，而不是更好的决定。“关键”值得与“高”分开，因为它由依赖度驱动、而不是由敞口驱动——一家数据很少、采购量很小、却没有合格替代方案的供应商，需要的是一份业务连续性与退出方案，而不是一份更长的安全问卷。等级应当驱动两件事：批准之前所要求的文件，以及此后这家供应商被重新评估的频率。
认证可以替代扩展尽职调查吗？
部分可以，而且只有在你们认真核查过的前提下。一份有效的 ISO 27001 证书或一份新近的 SOC 2 Type II 报告，是关于某个控制环境已被评估过的独立证据，而在这棵树里，“已认证”分支会把一家供应商从扩展审查下降到标准包。有三项检查决定它是否算数：认证范围声明必须覆盖你们实际采购的服务、认证机构必须获得认可、日期必须仍然有效。此外，一份 SOC 2 Type II 报告还带有一个审计窗口和一组例外事项，因此要读的是那些例外事项，而不是封面。在涉及个人数据的情况下，认证永远不能替代一份数据处理协议。
供应商风险评估的决定权应该归谁？
按问题拆分，而不是把整次评估交给某一个团队。安全与合规最适合回答数据、访问权限、国别与认证方面的问题，因为文件在他们手上。采购与财务回答采购量与可替换性。由此得出的等级应当是从这些答案算出来的结果，而不是一场谈判。把风险委员会留给真正需要行使裁量权的两处：在扩展审查之后接受一家高风险等级的供应商，以及签署那份让一家关键供应商变得可以接受的业务连续性方案。执行了这次审查的人，不应当同时是接受剩余风险的人。