vendor-due-diligence

⚠️ 实验性 — 此技能仅用于教育和信息参考，不构成法律建议。用户需对使用承担全部责任。采取任何行动前，请咨询合格的法律专业人士。

供应商尽职调查技能

概述

用于评估 IT 服务提供商、技术供应商和第三方合作伙伴的生产就绪框架。提供三阶段评估（初步筛选、详细评估、最终评估）、涵盖 6 个维度并针对关键服务加权的多因素风险评分、适用于 8 个框架的法规合规检查清单、供应商比较矩阵，以及包含预警指标的持续监控。专为评估技术供应商的采购团队、法律顾问、IT 安全人员和合规专员设计。

目录

• 工具
• 参考指南
• 工作流
• 故障排除
• 成功标准
• 范围与限制
• 反模式
• 工具参考

首先明确事项

对供应商评分前，请确认以下信息。如果有任何一项未知或含糊不清，请提问，不要自行假设：

• 服务是否属于关键/重要服务 — --critical 标志会将安全和合规的权重提高到 2 倍，这可能改变综合得分以及批准/拒绝建议
• 适用的法规框架 — GDPR、DORA、NIS2、SOX、PCI DSS、ISO 27001/SOC 2、HIPAA、FedRAMP — 用于确定要运行哪些合规检查清单
• 问卷答复 + 独立证据 — 这决定 6 个维度的得分；仅有自我报告的数据会抬高得分，因此请确认是否有 SOC 2 / 渗透测试 / 财务证据作为佐证

停止规则：只询问最能影响输出的 2–3 项。如果用户说“直接起草”，则继续，并在评估开头列出你的假设。

工具

1. 供应商风险评分器（scripts/vendor_risk_scorer.py）

根据问卷答复，对供应商的 6 个风险维度进行评分。计算加权综合得分，并对关键服务应用 2 倍乘数。生成风险热力图和总体建议。

# Score a vendor from questionnaire responses
python scripts/vendor_risk_scorer.py vendor_responses.json

# JSON output for dashboards
python scripts/vendor_risk_scorer.py vendor_responses.json --json

# Flag as critical service (2x weight on security + compliance)
python scripts/vendor_risk_scorer.py vendor_responses.json --critical

2. 供应商比较（scripts/vendor_comparison.py）

接收多个供应商风险评估 JSON，并生成并排比较矩阵。按综合得分对供应商排名，并给出首选供应商建议及理由。

# Compare two vendors
python scripts/vendor_comparison.py vendor_a.json vendor_b.json

# Compare multiple vendors with JSON output
python scripts/vendor_comparison.py vendor_a.json vendor_b.json vendor_c.json --json

# Compare with critical service weighting
python scripts/vendor_comparison.py vendor_a.json vendor_b.json --critical

参考指南

参考资料	用途
references/risk_assessment_framework.md	6 维评分系统、加权方法、综合得分解读
references/regulatory_checklists.md	GDPR、DORA、NIS2、SOX、PCI DSS、ISO 27001/SOC 2、HIPAA、FedRAMP 的预设合规检查清单
references/monitoring_framework.md	季度审查、预警指标、KPI 指标、风险缓解策略、入驻检查清单

工作流

工作流 1：三阶段供应商评估

阶段 1：初步筛选（第 1—5 天）

1. 收集供应商基本信息（公司概况、财务状况、认证）
2. 使用初步数据运行 vendor_risk_scorer.py，进行初步风险分类
3. 查看 regulatory_checklists.md 中适用的监管框架
4. 决策关卡：进入详细评估或提前拒绝

阶段 2：详细评估（第 5—15 天）

1. 发放全面的供应商问卷，涵盖全部 6 个风险维度
2. 使用完整的问卷答复运行 vendor_risk_scorer.py
3. 执行所有适用框架的监管合规检查清单
4. 索取支持性文档（SOC 2 报告、渗透测试结果、财务资料）
5. 开展推荐人核查和公开记录检索

阶段 3：最终评估（第 15—20 天）

1. 如果评估多个供应商，则运行 vendor_comparison.py
2. 汇总供应商风险报告，列出各维度的细分情况
3. 根据 risk_assessment_framework.md 记录差距和所需的缓解措施
4. 提出建议（批准／有条件批准／拒绝）
5. 如果获批，则根据 monitoring_framework.md 生成入驻检查清单

工作流 2：供应商竞争性遴选

1. 明确要求——记录必备和可选标准，并将其映射到风险维度
2. 筛选候选者——对所有候选者进行初步评分；淘汰任何风险等级为严重的候选者
3. 深入评估入围者——对排名前 2-3 位的供应商进行完整的 6 维度评估
4. 比较——对入围者的评估结果运行 vendor_comparison.py
5. 谈判——在合同谈判中利用风险发现作为筹码（与 tech-contract-negotiation 技能集成）
6. 选择并办理入驻——批准首选供应商；根据 monitoring_framework.md 设置监控

工作流 3：持续供应商监控

1. 季度审查——使用更新后的数据重新评估供应商；与基准进行比较
2. 事件触发审查——在发生并购、安全漏洞、监管变化或领导层变动时重新评估
3. 年度重新评估——使用更新后的问卷，重新进行完整的 6 维度评估
4. 早期预警响应——监控 monitoring_framework.md 中的指标；按照既定路径升级处理
5. 退出规划——如果风险超过阈值，则启用退出条款和双源策略

故障排除

问题	原因	解决方案
所有维度的评分均为 1（低风险）	供应商在问卷中自我报告时过于乐观	与 SOC 2 报告、渗透测试结果和财务申报资料交叉核对；根据证据调整评分
综合评分未反映已知的安全问题	对于关键服务，安全维度的权重不足	使用 --critical 标志重新运行，以便对安全和合规维度应用 2 倍乘数
比较矩阵显示所有供应商评分相同	评分输入过于相似或粗略	索取更细致的数据；使用风险框架中的 5 级评分标准进行区分
监管检查清单似乎不适用于所在行业	仅预置了 8 个框架	通过添加行业特定要求作为额外条目来自定义检查清单
供应商拒绝填写问卷	供应商认为评估过于繁琐	仅分享与其服务范围相关的维度；可接受 SOC 2／ISO 27001 报告作为部分替代材料
风险评分在两个季度之间发生显著变化	发生了重大事件（安全漏洞、并购、领导层变动）	这是预期行为；记录触发事件，并遵循事件触发审查流程

成功标准

• 评估完整性：100% 的供应商评估均覆盖全部 6 个风险维度，并为评分提供证据支持
• 时间安排遵守情况：90% 的评估在 20 个工作日内完成三阶段评估
• 风险预测准确性：被标记为高风险／严重风险的供应商，在 12 个月内发生事件的概率是低风险供应商的 3 倍
• 法规覆盖率：95% 的评估均完成所有适用的法规检查清单，且没有遗漏任何框架
• 比较一致性：由不同评估人员重新评分时，供应商比较排名保持稳定（评估者间信度 > 85%）
• 监控合规性：100% 的季度审查均按计划完成，并记录审查结果
• 早期预警检测：80% 以上的供应商事件发生前，监控中至少已标记一项早期预警指标

范围与限制

此技能涵盖：

• 涵盖 6 个维度（财务、运营、合规、安全、声誉、战略）的多因素风险评分，并按关键服务调整权重
• GDPR、DORA、NIS2、SOX、PCI DSS、ISO 27001/SOC 2、HIPAA 和 FedRAMP 的法规合规检查清单
• 并列比较供应商，提供综合排名和维度级别分析
• 持续监控框架，包括季度审查、早期预警指标和升级路径
• 按风险等级制定风险缓解策略和入驻检查清单

此技能不涵盖：

• 实时供应商监控仪表板、自动化数据馈送，或与 GRC 平台集成（所有输入均通过 JSON 文件提供）
• 供应商财务审计、法务会计或详细的财务报表分析（请使用 finance/financial-analyst 技能）
• 实体安全评估、现场设施审计或硬件供应链验证
• 供应商合同的法律审查或条款谈判（请使用 legal/tech-contract-negotiation 技能）
• 超出风险评估范围的供应商关系管理、绩效优化或战略合作伙伴关系拓展

反模式

反模式	失败原因	更好的做法
仅依赖供应商自我评估问卷	供应商可能少报风险；缺乏独立核验	将问卷回答与 SOC 2/ISO 27001 报告、渗透测试结果和公开记录交叉核验
不考虑服务类型，对所有维度采用相同权重	薪资服务供应商与营销工具的风险状况不同	对关键服务使用 --critical 标志；根据服务分类调整维度权重
只做一次尽职调查，此后再不复查	并购、数据泄露、市场变化等因素会导致供应商风险随时间变化	按监控框架实施季度监控和年度重新评估
不考虑缓解措施，仅因单个高风险维度就拒绝供应商	可能因此淘汰存在可弥补缺口的优质供应商	使用差距分析的严重性分类；对于重大问题，要求在最终决策前提交整改计划
独家采购时跳过比较矩阵	错失将供应商与市场标准进行基准比较的机会	参照行业基准或以往的供应商评估进行比较，以建立风险基线

工具参考

scripts/vendor_risk_scorer.py

对供应商的 6 个风险维度进行评分，并生成总体建议。

usage: vendor_risk_scorer.py [-h] [--json] [--critical]
                              input_file

positional arguments:
  input_file            Path to JSON file with vendor questionnaire responses

options:
  -h, --help            Show help message and exit
  --json                Output results as JSON
  --critical            Apply 2x weight to security and compliance
                        dimensions (for critical/essential services)

**输出：**6 个维度的风险评分（各为 1-5）、加权综合评分、风险等级分类（低／中等／高／严重）、总体建议（批准／附条件批准／拒绝）、维度级别的发现，以及差距分析。

scripts/vendor_comparison.py

并排比较多家供应商，并推荐首选供应商。

usage: vendor_comparison.py [-h] [--json] [--critical]
                             input_files [input_files ...]

positional arguments:
  input_files           Paths to vendor assessment JSON files (minimum 2)

options:
  -h, --help            Show help message and exit
  --json                Output results as JSON
  --critical            Apply 2x weight to security and compliance
                        dimensions (for critical/essential services)

输出： 并排比较矩阵、综合评分排名、各维度的优势与劣势分析、附理由的首选供应商推荐，以及风险差异重点。