2. 第三方风险图谱与业务影响分析

第三方风险治理的第一步不是“管”，而是“看清”。如果组织连自己依赖了哪些第三方、这些第三方以什么方式接入业务、一旦失效会波及哪些环节都说不清，后续的准入评估、合同约束和监控都无从落地。本章聚焦于构建第三方风险图谱，并在此基础上完成业务影响分析，把“依赖关系”转化为可判断、可排序的风险结论。

一、第三方类型的识别与分层

第三方并非同质群体，不同类型的主体，其风险传导路径和治理手段差异很大。实践中通常将其划分为四类：

• 供应商：提供软硬件产品、云资源、网络设备等，风险集中在产品漏洞、供应链投毒、停服与断供。
• 服务商：提供SaaS、支付、短信、身份认证、CDN等持续服务，风险集中在服务可用性、数据托管与接口安全。
• 外包商：承接开发、运维、客服、数据处理等业务，风险集中在人员权限、数据外带与交付质量。
• 开源组件：以代码库、依赖包形式嵌入自有系统，风险集中在许可证合规、已知漏洞与维护中断。

识别时不能只看合同台账，还要结合采购记录、财务付款流水、系统集成清单和代码依赖清单交叉比对。很多“影子第三方”正是通过部门自行采购或开发人员直接引入依赖而进入组织的。

二、四类流：把依赖关系画出来

风险图谱的核心是“流”。仅列出第三方名单价值有限，真正能支撑分析的是数据流、资金流、系统流与依赖关系四条线索。数据流回答“哪些数据流向哪里、是否跨境、是否含个人信息”；资金流回答“谁向谁付款、金额与账期如何、是否存在集中依赖”；系统流回答“通过什么接口、协议、网络路径接入”；依赖关系则回答“谁依赖谁、是否存在单点”。

绘制时建议以业务系统为中心节点，向外连接第三方，再标注流的类型与方向。下面这张图给出一个典型电商业务的第三方风险图谱示例，其中数据流、系统流与依赖关系被同时呈现，便于识别集中风险点。

图中可以看到，云服务商同时承载数据流与系统流，属于高集中度依赖；支付服务商只有一条资金流通道，缺少冗余；外包团队通过依赖关系获得生产权限，是典型的人为风险入口。这些结论无法仅凭第三方名单得出，必须依赖图谱中的连接关系。

三、业务影响分析：从依赖到后果

有了图谱，下一步是评估“如果这个第三方失效，业务会怎样”。业务影响分析（BIA）需要回答三个维度：业务中断、数据泄露与合规传导。

业务中断关注可用性。评估时要区分“可容忍中断时长”和“实际恢复能力”。例如支付服务商中断，若业务可容忍时长为0，而服务商承诺的RTO为2小时，则缺口为2小时，必须通过备用通道或降级方案弥补。评估指标建议使用RTO（恢复时间目标）、RPO（恢复点目标）和MTTR（平均修复时间），并与第三方SLA逐项比对。

数据泄露关注机密性与完整性。要沿数据流追踪：哪些数据被共享、是否包含个人信息或商业秘密、传输与存储是否加密、第三方是否再委托下游。一个常见误区是只评估直接第三方，忽略“第四方”——第三方的分包商。数据一旦流出，追责与止损难度都会显著上升。

合规传导关注监管责任。即使违规行为由第三方实施，责任往往仍由组织承担。例如个人信息被外包商泄露，组织作为个人信息处理者仍需承担合规责任。因此需要梳理每个第三方涉及的法规义务，如数据出境、等级保护、行业监管要求，并确认合同中的安全条款、审计权与违约赔偿是否覆盖这些义务。

四、风险排序与处置优先级

影响分析的结果应落到一张可排序的风险清单上。建议用“可能性×影响”的二维矩阵，但影响维度要拆细，避免笼统打分。下面给出一个可直接使用的评估表结构示例，字段可根据组织实际调整。

排序之后，处置动作要与等级匹配。极高风险对象应优先纳入持续监控与合同强化；中低风险对象可采用周期性复核。需要强调的是，风险图谱不是一次性文档，当业务系统变更、第三方更换分包商或引入新依赖时，图谱必须同步更新，否则分析结论会迅速失真。

完成本章的图谱与影响分析后，组织就具备了“看清依赖、判断后果、排出优先级”的能力，这为后续的准入评估、合同安全条款设计和持续监控提供了直接输入。