选择正确的第三方风险管理框架

梅丽莎：接下来做个简单介绍。我是梅丽莎，担任客户经理一职。今天我们有几位特别嘉宾，其中包括几位老朋友。合规专家托马斯·汉弗莱再次莅临现场。欢迎回来，托马斯。托马斯：很高兴再次参与。 梅丽莎：还有我们的产品营销经理马特·德尔曼。马特，你好。马特：你好，梅丽莎。梅丽莎：马特将在最后环节分享如何利用Meteor平台优化现有项目，并探索更多可能性。关于会议安排：本次网络研讨会全程录制，结束后您将收到录播文件。 各位当前处于静音状态，请通过问答框提交会议期间的问题。我们将在会议中或结束后逐一解答。现在请托马斯接过话筒，他将探讨选择合适第三方风险管理框架的关键考量因素。托马斯，请开始您的分享。

托马斯：非常感谢，梅丽莎。各位女士先生们，早上好、下午好、晚上好。欢迎参加本次网络研讨会。呃，初次见面的朋友，我是汤姆·汉弗莱，现任Prevalent公司内容经理。我的主要职责是在平台内构建评估体系与框架。在审计领域，我已拥有近十五年的从业经验。 我的专业背景涵盖多国标准审计，尤其在ISO领域，服务对象遍及英国、新加坡及全球多家机构。今天我们将探讨各类第三方风险管理框架、信息安全与网络安全框架，并学习如何通过科学评估做出明智决策——这既是第三方风险管理（TPM）项目的重要环节，也是更广泛TPM实践的基石。 正如女士所言，我们始终预留问答环节。您可在必要工具内找到问答框，请随时上传问题，我们将在末尾集中解答。那么，让我们直接开始。首先从议程角度分解：我们将首先将审视若干广泛应用的网络安全框架，随后深入剖析这些框架及TPOM领域其他通用框架的优势与局限。重点探讨如何最大化利用这些框架的积极特质，从而优化第三方协作模式， 以及需要重点关注和询问的关键控制领域。

托马斯：我们将审视行业层面的常见框架，探讨如何运用内部风险画像与风险评估方法，并分析这些方法如何影响决策过程——特别是如何选择适合本组织的框架，最后通过具体步骤将实践与组织目标相融合，确保在恰当的时机运用正确的框架。——即如何选择适合我们的框架。最后我们将梳理若干步骤，确保实践与组织目标保持一致，重点在于理解并适时选用正确的框架来管理各类第三方。关于关键网络安全框架，显然信息网络安全领域的标准框架形态各异、复杂程度不一。 屏幕上列出的某些名称，相信多数人都非常熟悉。例如ISO 27001、NIST CSF（网络安全框架）等，堪称行业通用的顶级标准。它们通常适用于任何行业和领域的各类组织机构。 特别是ISO 27001这类标准，至今仍是信息安全管理领域应用最广泛的框架之一。尤其值得关注的是，许多机构正将27001的控制措施应用于推动第三方风险及第三方风险管理。此外，针对特定行业的框架也在持续增多。 屏幕上列举了若干案例：美国医疗领域的HIPAA标准，为管理PHI（公共健康信息）或EPI（电子健康记录）的机构制定了安全与隐私规范。 在安全与隐私领域更广为人知的当属纽约州金融服务局（NYDFS）的23500框架，该框架适用于纽约州内运营的金融机构，我们稍后将深入探讨其在当前纽约金融生态中的应用。 除上述广泛适用的框架（如ISO标准、NIST标准，以及美国NIST SIG的27、8、53等规范）外，

托马斯：我们当然发现，总会存在一些针对特定主题的框架，它们高度契合特定技术或特定应用场景。ISO 42001就是这样一个例子——这是国际电工委员会为管理人工智能系统制定的标准。该标准涵盖人工智能系统的设计、开发与应用，通常为定义和实施控制措施提供指导与要求，这些措施适用于特定技术系统，某些情况下也适用于特定行业。 此外，我们也不应忽视日益增多的基于法规的要求。无论是英国P或凭证等领域制定的框架——用于处理外包安排及更广泛的供应链管理；还是针对在英国及更广泛欧盟地区运营的金融机构所实施的NIS-2框架——该框架为欧盟组织制定了更全面的网络安全实践标准与预期要求，其核心内容与前述框架并无本质差异。 针对英国境内及更广泛区域的金融机构，欧盟的NIS-2框架则为欧盟组织制定了更全面的网络安全实践与预期标准——其要求与其他框架并无本质差异。各类框架层出不穷，其规模与复杂度各异，既有要求更为严苛的规范，也有覆盖范围更广的标准。 而围绕ISO、NIST框架（诸如SIGs、CIS等您可能熟悉的术语或缩写）的规范，在端到端网络安全治理、风险管控及合规性控制方面覆盖范围更为广泛。 面对如此众多的框架，初次接触者难免感到困惑——究竟该选择哪种安全框架？与第三方合作时该采用何种框架？如何评估第三方及更广泛的供应链？这些问题确实令人头疼。 下面我们快速浏览三个框架示例，稍后将深入探讨它们的结构划分及具体应用场景。

托马斯：首先，正如我所说，全球最广泛使用的框架之一仍是ISO 27001框架，用于定义、实施和管理信息安全管理体系。它与其他ISO标准并无太大差异。 这些标准从治理角度提供了清晰的指导框架：明确领导层职责，通过结构化风险管理框架识别并管控风险，进而扩展为企业可选用的控制措施体系以协助风险管理。 正如我所说，这是国际公认的标准。它真正适用于不同类型、规模和复杂程度的企业——无论是美国的软件公司、日本的广告代理商，还是英国的制造工厂。众多组织都将27000系列作为公认的最佳实践，用于实现良好的安全与安全管理。 当然，从早期版本到2022年最新版本，该标准始终对第三方管理、供应商管理及供应链管控设定了明确要求。当我们探讨合同管理时，需考虑如何识别直接供应商的管控措施，并通过监控、绩效评估及审计能力进行管理。可以说这是覆盖面极广且被广泛采用的框架。需要特别强调的是，该标准具备可认证性。 市面上存在许多非认证标准框架，虽无法认证但仍作为公认最佳实践被广泛采用。ISO 27001正是可通过独立审计及验证程序实现认证的标准范例。 近期更值得关注的是NIST CSF（美国国家标准与技术研究院网络安全框架）。该框架第二版于今年年初发布——我记得是2024年1月底或2月初。其与ISO的相似之处在于，都是深度网络安全框架，提供结构化的控制识别基准，并将其划分为五大核心功能领域。

托马斯：治理，即管控，这是新版中新增的领域，涵盖基于识别、保护、检测、响应和恢复的控制措施。 这五大核心功能又细分为治理层面的组织性控制与技术性控制。涵盖从人员管理、物理安防到逻辑/物理访问控制、业务连续性恢复、事件响应等全方位内容。与ISO 2701控制框架类似，治理层面的重点在于第三方管理、第三方风险认知及风险管控。 这种宽泛的框架设计使其能广泛适用于各类技术环境，这一点同样值得强调。当ISO和NCSF等框架发布时，其吸引力所在——同时也可能引发某些潜在问题——在于其采用的通用语言：许多控制措施的细节设计旨在满足不同组织的适用需求。 再以制造企业、软件开发商和广告公司为例，它们处理网络安全风险及第三方合作的方式截然不同，对风险的认知也各异。这些框架赋予了企业根据自身业务场景灵活适配的能力。最后以SOC 2为例， 该广泛采用的框架通过五大关键控制组评估组织能力——屏幕底部的五项控制涵盖：信息安全防护、保障数据与系统的机密性、完整性及可用性，同时包含隐私保护要素。 该框架能详细评估组织的整体运营与系统能力及其有效性。不过ISO与SOC 2之间存在些许差异：两者均提供认证级别，且都可由审计公司进行独立评估。

托马斯：不过在SOC 2认证中，机构在确定控制组范围时拥有很大自主权——即他们希望纳入认证评估的控制组数量。因此我们发现，有些公司仅关注特定产品、服务或组织能力范畴的安全防护，采取严格的隔离策略；而另一些机构则会全面评估全部五大关键控制组。 当然，这导致了对组织采用最佳实践程度的理解深度存在差异。但这再次印证了一个现象：无论是ISO、NIST CSF还是SOC 2，三者在控制措施类型上高度相似——无论是访问控制、人员安全培训、数据安全与完整性，还是业务连续性等领域。 因此尽管现有众多框架中仅有三种，但得知这些框架在最佳实践、要求及控制要求方面存在诸多共通点，或许也能带来某种安心感。 接下来深入探讨，让我们审视这些框架（特别是我们刚讨论的COMPOSE框架）的优势与局限性，尤其在企业选择合适第三方框架的决策过程中。 那么在选择标准或框架时，我们可能在哪些环节遇到阻碍？显然存在诸多潜在陷阱可能引发担忧。 我们已提及标准数量庞大的问题——无论是行业规范、特定领域主题还是通用标准。当然，每套评估框架对控制措施的识别方式及实施方法都有各自的解读。在风险评估的捕捉方式上，不同框架确实存在细微差异。

托马斯：以ISO为例，2701标准对如何识别、管理、应对信息安全风险有着非常清晰的结构化方法，并拥有自己的风险框架体系，如ISO 31000。而NIST则有其专属框架——NIST风险管理框架（RMF），甚至针对特定领域也设有专项框架，比如NIST人工智能风险管理框架或ISO 4201标准。这些框架这些框架在细节上存在微妙差异，若需选择框架并将其与现有风险管理方法对接，这些差异就值得重点考量。 当然，术语差异始终是需要重点关注的潜在问题，尤其当不同组织对特定主题的称谓存在微妙差异时，术语的细微调整可能引发"这究竟意味着什么？"或"可能暗示什么？"的困惑。 当然，如果我们过于急躁，在未充分尽职调查且未真正理解框架目标的情况下贸然选定，可能会导致某些领域出现认知偏差。 比如NIST 853这类框架，因其深度和复杂性而广受推崇。对比2701标准仅涵盖93-95项安全控制措施，853标准却包含900多项控制措施，由此可见853这类标准能达到的深度。 但这可能导致两个问题：企业内部人员对此框架不熟悉，而当企业向供应商提出基于这些框架的关键问题时，外部合作方同样会感到陌生。 若选择深度评估路径，问题数量可能从20-30个激增至200-300个。这种信息过载反而可能导致无法精准捕捉企业真正需要的控制要求深度。

托马斯：因此，关键在于理解这些框架的核心诉求及其具体要求，同时学会如何根据自身需求进行定制——尤其在与第三方合作时，要明确关注重点。当然，这种定制可能导致覆盖不足，某些亟待探索的关键风险领域反而被忽略。 但或许由于领域陌生、问卷或评估内容过于复杂，供应商可能产生误解。那么在评估框架能否满足需求时，我们该提出哪些关键问题？ 我认为首要问题是：该框架能否覆盖所有层级的评估？如今多数组织显然拥有多层次的第三方合作方——既有规模庞大的全球性企业，也有美国俗称的"夫妻店"式小微企业，甚至仅有五名员工采用居家办公模式的超小型机构，其运营模式与大型数据中心供应商截然不同。 因此我们需要确保现有框架能根据不同层级，以及我们对各第三方供应商的分类评估结果进行定制化评估。该框架是否具备这样的能力：对于一级或关键供应商，我们可能需要提供完整的端到端要求； 同时，无论是单项评估还是多框架并行，能否根据供应商层级动态调整问题数量与复杂度？ 当然，该框架能否适应可扩展的第三方风险管理（TPRM）？毕竟TPRM并非一次性任务，而是需定期审查的流程——某些情况下每周审查，至少每月一次，当然也包括年度审查。

托马斯：当然，这意味着随着时间推移，当我们审视业务运营中新兴技术的发展时，可能需要扩展这些框架的覆盖范围，并调整合作的第三方类型。特别是当涉及到基于业务发展方向的新要求、新法规时。那么随之而来的问题是：现有框架是否足够前瞻？ 它是否具备应对新兴趋势、威胁及新技术的能力？评估体系能否适应这些变化？还是需要拓展其他领域？例如当我们涉足人工智能、量子计算或其他运营技术时，若现有框架无法满足需求，我们还能寻求哪些解决方案？ 现有框架能否覆盖这些领域？还是需要扩展调整以适应新趋势、新威胁及其他风险领域？我们还需考虑哪些因素才能明智地选择最优框架或标准来评估第三方？让我们退一步审视当前TPRM的典型驱动因素。 当然，监管机构和立法无疑是重要因素，我们看到越来越多的行业将此列为优先事项。我之前提到英国的P（金融业），无论是美国、加拿大、英国还是欧洲，金融领域就是一个典型例子——对组织如何应对、管理供应商、供应链及外包实践的期望正持续提高。 无论是向监管机构提交的报告类型，还是客户群体日益精明且警惕更广泛供应链中潜在威胁与风险的趋势——过去两三年来，勒索软件事件及其他影响小型或大型供应链的攻击事件数量激增，便是明证。

托马斯：但我们的客户乃至整个行业都更加关注我们如何应对——当我们向第三方提供可能包含敏感信息或敏感数据的系统时，我们采取了哪些措施？ 当然，新出现的威胁和漏洞始终是关注焦点。回顾过去两三年中较为突出的安全事件，正是这些威胁促使行业机构和监管部门提出：我们需要更多证据，不仅要加强第三方管理，更要提升整个供应链的可追溯性。 例如当存在单点故障或可能扰乱整个供应链的重大风险时，企业如何应对？无论是从业务连续性还是灾难恢复角度，相关知识都至关重要。虽然现有框架体系相当广泛，但当企业内部采用特定评估框架的标准、知识和技能体系时，这显然会影响我们的决策倾向，同时也能更轻松地判断哪种框架最适合我们。显然，若组织已获得ISO2701认证，已采用SOC2标准，或已通过NIST 853框架推动自身网络安全最佳实践—— 当然，若企业内部已具备相关知识、技能和理解，能够灵活运用这些标准，明确所需关键控制措施，并将这些要求传递给第三方或围绕这些标准向第三方提出问题，无疑会使工作变得更轻松。 尤其在构建第三方风险框架和管理方法时，这能作为起点，同时也能审视更广泛的第三方生态。正如我们提到的，第三方类型多种多样。

托马斯：嗯，你们可能有咨询顾问，我们可能有呼叫中心，可能有系统开发人员或软硬件开发人员，也可能有零部件制造商。通常我们会发现企业会引入多种类型的第三方服务商。当然这有助于我们确定需要评估的深度和复杂程度。 我们是否需要重点关注在系统与软件开发、运营技术方面实力雄厚的框架？特别是当涉及大量制造企业及其能力时。 因此，思考产品与服务供应链结构，确实有助于厘清评估类型，并明确这些第三方评估对业务的关键性——尤其当我们看到更广泛的第三方生态系统也在持续扩张时。 以纽约州金融服务局（NYDFS）为例：若我们在金融领域拓展业务，进驻纽约州市场，或开始使用当地供应商，那么NYDFS的监管要求就成为我们必须重点关注的对象，同时需明确对第三方实施何种控制措施及控制评估。 接下来我们探讨适用于行业及更广泛风险场景的通用框架。我特别想强调的是，如何将监管或行业特定要求与现有框架结合使用——这些框架可能需要扩展以适应新规。我之前提到的NYDFS框架已运行多年，该机构会定期更新框架（与其他评估机构类似），但其核心关注点始终围绕着： 该框架已运行多年，纽约金融服务局会定期更新，其更新模式与其他评估机构并无太大差异。但核心仍聚焦于保护客户数据和信息技术系统的网络安全要求。其中许多控制措施与国际标准化组织（ISO）和美国国家标准与技术研究院（NIST）的标准具有高度相似性。

托马斯：因此，当前聚焦于安全政策、数据安全管理、信息隐私保护以及访问控制——包括逻辑访问授权与身份验证等领域。尽管这些措施针对纽约地区金融机构的特定应用场景，但在信息安全与网络安全层面，它们与现有最佳实践框架仍存在诸多共通之处。 显然，行业框架（特别是法规立法）与ISO27001、NIST CSF或853等标准的关键区别在于：违反或未能完全实施框架（或其部分内容）将面临处罚与罚款。过去三四年间，纽约金融服务部及纽约州银行监管局已多次实施此类处罚。 因此，机构在首次采用某项法规时需格外关注：尤其当涉及第三方合作时，必须了解对方如何运用该法规——例如在事件响应能力、风险报告机制等第三方风险管控方面，其尽职调查是否充分到位。 纽约金融服务局对此有明确规定，强调必须识别第三方服务提供商的风险并进行评估，同时要求其满足最低安全标准。这与ISO、NIST、C、SIG等众多标准的理念相通。因此企业需思考：我们是否根据合作第三方类型评估了风险？ 我们需要考虑哪些最低要求？特别是涉及第三方合同协议时，同时确定最佳评估框架以证明符合监管和行业合规要求。

托马斯：因此我们还需重点关注的领域是——尤其当我们看到无论是行业主导还是监管机构对信息安全、网络安全及供应链管理的要求与指南显著增加时——这些要求特别强调了控制措施，但它们与我们现有工作存在高度关联性。本页便给出了一个实例。 加拿大OSI监管机构（其职能与纽约金融服务局NYDFS高度相似）专注于加拿大金融服务及金融行业监管。2023年，该机构制定了聚焦技术与网络风险管理的B13指南。我们列举了若干要求示例：企业需建立技术资产管理标准与流程，并维持当前有效的全面资产管理体系或技术资产全生命周期清单。这表明完善的资产管理计划、资产管理系统及资产清单至关重要。 显然，当企业被要求遵循行业规范、监管要求或信息网络安全立法实践时——无论是采用ISO、NIST CSF、SOC 2、SIG等框架—— 这些框架均涵盖相同的核心要求：企业必须建立涵盖硬件、软件、数据资产及其他信息资产的完整清单，并在资产全生命周期内实施监控——从资产入库到最终处置。 因此，如果我们已建立如ISO 270101等成熟框架，并据此向供应商提出相关问题——是否因即将生效的B13新指南或法规而需废弃现有框架？答案其实是否定的。

托马斯：因为我们知道，B13所询问的许多控制措施与270001等标准之间已存在密切关联，通过标准映射也能体现这种关联性。 如果能将B13要求的控制措施映射到我们的ISO 27001框架或CSS框架中，就能向客户及其他关键利益相关方证明：我们仍在满足要求，仍在向供应商提出相同的管理要求——本案例中涉及资产管理、资产清点及管理等环节。 当然，某些情况下所需控制措施会高度契合特定指南、法规或行业标准。以OSI为例，其B10指南聚焦第三方风险管理，要求企业必须在签订合同前及合作期间持续评估集中风险。 我们已提及，无论是ISO、NIST还是全球各类标准制定机构，都对供应链管理、供应链风险管理及第三方风险管理提出明确要求。这些标准均要求企业建立识别机制，针对第三方可能引发的风险制定管控政策以有效规避风险。 但这些规范并未具体到要求企业将集中度风险列为关键评估对象。例如ISO 27000或CSF框架，这正是现有风险管理框架或供应商评估体系可能覆盖不足的领域。 同样，纽约金融服务局（NYDFS）的管控措施也针对企业报告网络安全事件的方式作出具体要求，这与GDPR在数据隐私泄露时要求企业向隐私监管机构报告的规定颇为相似。

托马斯：在NIDFS框架内，我们还看到更广泛的控制组示例，它们要求特定类型的身份验证。其中专门有一节涉及多重身份验证。回顾ISO和NIST等标准，其中大量控制措施都涉及事件响应与事件响应管理，这些措施同样触及用户身份验证问题——无论是内部用户、承包商还是网络及信息系统的外部用户。不过这些标准这些规范未必会具体要求必须采用多因素认证，更多是回归ISO标准所强调的"需实施认证及适当认证技术"这一更广泛原则。因此当我们基于清晰的框架评估第三方时，如何采纳并实施这些行业监管或立法要求的独特控制措施？ 某些情况下，可能需要增加额外问题以确保100%覆盖。若我们已要求第三方说明其网络安全事件处理、应急响应及业务连续性措施，还可通过备注、文档上传等途径深入挖掘 例如如何向纽约州金融服务局局长等监管机构上报事件；或在管理第三方风险时，是否针对单一供应商等集中风险制定应对方案。在构建全新框架前，我们可采用多种方法。 当然，在某些特殊情况下，我们可能需要补充问题以确保覆盖全面。但显然，具备评估差距并整合这些标准的能力至关重要，这能使工作变得轻松许多。

托马斯：我们经常发现，许多企业起初采用单一框架（如ISO、NIST或SIG），随后为确保全面覆盖特定法规或利益相关方提出的关键要求，会不断添加映射方案。 因此在审查多个框架时，我们必须重点关注它们如何应对我们已识别的重要风险领域和关键漏洞，尤其要关注显著扩展、变更或新出现的威胁。 我们提到的新兴技术领域——人工智能已发展多年，如今正进入关键阶段：越来越多的企业开始要求第三方说明其人工智能技术使用情况，无论是开源平台还是产品服务中自主研发的人工智能能力。 因此，我们必须重新审视现有标准框架，思考其对当前业务的影响：我们是否已建立能涵盖新兴技术能力的框架？是否已纳入相关考量？正如我们从法律监管角度所强调的，企业管理第三方供应商及供应链能力的监管力度正日益加强。 通过风险评估和第三方画像实施的监管至关重要，我们必须切实掌握：如何管理第三方供应商？如何对其进行画像与识别？OCB10或PSS221等法规要求的最低标准是什么？这些因素又如何影响我们当前使用的框架？

托马斯：嗯，显然通过合同和协议可以识别关键控制措施。要求建立一套标准控制措施固然重要——比如即时管理、业务连续性与恢复报告、访问控制等——但更需关注的是：当涉及组织层面至关重要的风险与漏洞时，我们如何针对这些领域提出问题？ 我们如何审查这些控制点？如何监控它们？当第三方完成评估后，若这些关键控制点被判定为风险，我们又如何管理整改流程？当然，法律法规还要求持续审查——无论是现场还是虚拟审计——必须证明第三方管理计划的有效性并能提供实证。 综上所述，我们已探讨了各类框架体系——既有受法规驱动的，也有行业主导的。显然，我们需要不断追问：评估的预期目标是什么？框架体系应具备哪些特性？是否具备可扩展性？能否适应新兴威胁与技术？ 它能否在关键控制领域满足我们的需求？其深度与复杂性是否契合第三方特性？如何将这些要素整合到更广泛的第三方风险管理计划及全生命周期中？当我们基于行业认知及其他关键标准，确定最适合企业需求的框架后—— 在审视完整流程时，存在若干关键问题可用于强化并借鉴关键控制领域。思考评估识别环节时需注意：这显然是个循环往复的过程——我们始终在向一级、二级及三级供应商发送的评估中追问：这些标准是否始终契合实际需求？ 我们提出的问题是否准确？

托马斯：我们是否根据第三方机构的业务范围覆盖了正确领域？这必然涉及我们如何对第三方机构进行分类分级的问题。因此关键在于明确我们拥有何种类型的第三方机构，以及它们对业务的重要性程度。 他们是否为独家供应商？是否提供关键或敏感组件/服务？我们能否根据这些情境调整评估标准？评估的质量取决于分类与分层的精准度。显然响应管理至关重要——在确定采用何种框架（或融合多框架的最佳实践）后， 我们如何与第三方合作？若能建立清晰的框架体系、明确评估方法及频率，便能更有效地向第三方传达要求，确保其全程深度参与。 当然，在确定框架后，我们希望进入识别关键控制措施的阶段：是否存在强制性控制要求？例如对加密类型是否有最低预期标准？ 他们如何与供应商或第四方、第五方建立合同协议？显然，一旦我们确定了框架，明确了关键控制领域或强制性控制措施，当风险出现时，在风险管理层面上，当风险因框架实施而反馈时，就能使TPM流程的这一部分变得更容易，明确优先处理事项。 最后在报告能力方面，若我们对所有第三方采用统一框架——尽管框架规模可能因对象差异而不同，但核心框架保持一致。

托马斯：在向整个业务部门乃至高层管理层汇报备份工作时，能够展示并解释对特定框架或标准的合规程度，无疑会使工作更轻松——尤其当我们开始基于第三方风险类型进行趋势分析时。那么这些标准、法规和指南对供应链中的第三方究竟有何要求？ 众所周知，每项标准、法规和指南在条款架构上都有其独特诉求。但聚焦第三方管理时，我们发现诸多共通点——不仅体现在ISO、NIST、SIG等国际标准中，甚至在多项立法中亦然。例如金融领域广泛采用的OVI和P标准。 医疗行业同样如此——当涉及要求第三方提供更广泛供应链信息时，各方对企业识别和掌握供应商身份的期望值很高。这既包括供应链采购流程的初始阶段，也涵盖识别供应链风险并建立风险管控流程。因此，正式的供应链风险管理方法、合同条款及协议条件在所有框架中都极为常见。 这些框架普遍关注第三方合同或供应链合同的识别机制，以及合同中纳入的管控措施。即便在控制层级上，我们也发现诸多共性特征。 例如应对突发事件或业务连续性事件的控制措施，正是我们在各类框架中普遍观察到的最低控制标准。供应商管理与监控机制同样反复出现——尤其在当前正在制定的监管框架中更是如此。

托马斯：嗯，无论是针对审计和审计能力的具体要求——无论是现场还是远程审计——还是供应商与贵方之间、贵方第三方与他们的第三方、贵方第四方与更广泛供应链之间其他形式的绩效监控与报告机制。 因此存在诸多共通点——当涉及多少框架能涵盖并要求供应链风险管理及良好实践时。这些可用于我们第三方风险管理（TP RM）的成功标准与最佳实践，能推动更广泛的第三方项目，尤其在框架应用方面。但显然需从企业内部建立清晰的指导委员会或工作组开始。 众所周知，第三方风险管理中，组织内部参与人员越多，获得的支持就越广泛，在处理供应商、应对流程及第三方风险管理计划中产生的风险时，成功标准也就越高。 显然，对于小型企业而言，这可能由同一组人员负责；而在大型组织中，则需考虑不同业务部门负责人——这些人员可能需要与第三方进行互动。

托马斯：无论是采购与收购环节，还是运营环节，乃至IT部门及其他业务板块——凡涉及第三方互动的领域，显然都需要在TPM项目运行框架内明确需求范围。在早期阶段完成这项工作，将极大助力后续框架的构建。当我们厘清运行机制、确定运行频率以及关键绩效指标（KPI）和关键信息指标（KIS）的设定。我们需要明确向第三方交付该框架时的成功标准，同时通过风险反馈机制——特别是长期趋势分析——观察关键风险量是否下降。趋势分析，通过KPI、KIS及其他绩效指标观察关键风险量是否下降。显然，作为TPRM计划的组成部分，制定更广泛的政策与风险管理方案来规范第三方合作，是至关重要的第一步。这需要指导委员会、工作委员会及董事会成员共同确立正式方法论， 业务培训与内部宣传同样重要。在确立框架并向各组织推送后，需确保向风险接收方及相关人员进行充分培训，使其了解风险要求。 他们需要采取哪些行动？管理机制如何运作？是否会使用特定平台或工具来记录风险行动与风险任务？ 当然，由于这是循环式方法，涉及持续改进计划，我们如何优化现有工作？尤其要着眼于框架扩展方向——选择何种框架类型，以及如何调整框架以适应新兴技术带来的风险与威胁。现在请马特继续。马特：谢谢托马斯。

马特：那总是，呃，总是好的，如果你能停止分享的话。谢谢。 我们将详细探讨Muterek第三方风险管理方案如何助力您的第三方风险管控。首先需要理解的是，传统第三方风险管理（TPRM）大多依赖电子表格。我们发现约50%的企业仍在使用电子表格进行第三方风险审计与控制，包括风险评估、框架合规性等环节。 仅有约三分之一的供应商得到主动管理，且覆盖整个供应商生态。最终导致的结果是：仅29%的企业能追踪整个第三方供应商生命周期中的风险——从入驻签约到离职终止。这实为隐患，因为若缺乏贯穿供应商风险生命周期的可视性，您将面临——我能在一句话里重复多少次"风险"呢？——遗漏关键环节的风险。 遗憾的是，我们最终发现第三方风险管理计划的目标在于：获取团队所需数据以做出更优风险决策、提升效率并打破部门壁垒。第三方风险需通过企业内部多个利益相关方协同管理——可能涉及采购部门、信息安全团队或财务部门。 真正的第三方风险管理解决方案，应致力于打破这些壁垒，助力TPRM项目持续进化与扩展。我们通过Mutate第三方风险平台实现这一目标，采用贯穿供应商全生命周期的描述性方法：从自动化、智能化的供应商筛选与评估开始，优化RFX流程，提供供应商风险评估。 有人提到其他框架涉及运营、财务等维度——这些框架多以评估为导向，未必具备法律约束力，但我们支持多种评估体系。

马特：据最新统计，我们的平台目前拥有750种不同类型的问卷模板。通过持续监测数据输入平台，我们提供持续验证功能，帮助您完成各类任务——例如通过分析关键绩效指标（KPI）和关键信息指标（KIS）来评估供应商效能。若您终止与供应商的合同，我们还负责管理离职和终止流程。这些正是Meteorch第三方风险管理所涵盖的风险领域。我们划分为六大主要类别： 网络安全领域涵盖暗网监控、基础设施滥用监测、漏洞与配置错误排查；ESG领域涉及健康安全、现代奴役问题——英国、欧盟及加拿大均有相关法规约束现代奴役与强迫劳动，我们已将相关数据纳入平台；此外还包括业务运营风险、声誉风险、财务风险及合规风险。 我们的运作模式融合了人员、数据与平台三大要素。我们提供第三方风险管理托管服务，旗下风险运营中心（ROC）拥有全球顶尖团队——成员均为认证第三方风险管理专家。他们将全面接管您的第三方风险管理项目日常事务，包括开展风险评估、追踪未完成评估的供应商。 我们将提供评估、整改、管理全流程服务，实现完全外包。同时拥有约50万份实时更新的供应商档案，支持跨领域第三方风险情报的即时调用。我们的平台能将所有工作集中管理，实现全企业范围的访问。这只是行业领先企业风险管理平台的组成部分之一。 您知道，该平台涵盖ESG管理、业务连续性规划、网络安全政策管理、道德举报热线及合规培训，真正实现了GRC（治理、风险与合规）及企业风险管理的全套解决方案。我在此诚邀所有客户参加达拉斯互动大会——这场重要的客户盛会。

马特：嗯，这个活动将在四月于奥斯汀盖洛德酒店举行，它确实能提供大量学习和培训GRC的机会，还能促成许多非常有价值的深度交流。这就是我的部分内容。现在进入提问环节，梅丽莎将负责筛选问题。

梅丽莎：明白了，谢谢。马特，嗯，就像你说的，在问答环节提个问题吧。我这就启动最后一次投票。我很好奇，你们是想优化现有交易对手风险管理流程，还是建立全新流程？或许你们还在用电子表格？嗯，是时候摆脱它了。 2025年新年伊始，正是焕新之际。或许你们正考虑搭建平台。我们后续会跟进，请如实作答。几分钟后我们还有几个问题。托马斯，是否有哪个问题更让你印象深刻？需要的话我可以逐一朗读。

托马斯：他被静音了。你也静音了。哦，抱歉。我没说我还没取消静音。好的。嗯，是的，我们来看看。 那么，嗯，重点关注网络安全框架，但同时也涉及财务健康、运营韧性、合同、SLA、合规性。这还应纳入TPRM的审查和监控范围。哪些框架能涵盖所有领域？是的，这是个有趣的ACU问题，因为我们发现虽然今天聚焦网络安全，但TPR项目还有许多其他重要领域。 目前尚未出现真正覆盖所有领域的通用框架。不过已有部分框架尝试拓宽视野，不仅涵盖信息安全与网络安全，还纳入合规、隐私保护等领域，甚至延伸至传统治理、风险与合规（GRC）能力体系，同时兼顾韧性建设。 SIG就是典范——其框架虽包含网络安全与信息安全模块，但设有专门章节聚焦整个供应链。法律合规部分涵盖欺诈防范、反贿赂等领域，甚至涉及人工智能等新兴议题。因此确实存在少数力求全面覆盖的框架体系。 值得注意的是，尽管我们在此讨论了ISO 27K和NIST CSF等具体框架，但我们发现部分企业正开发扩展型框架，力求涵盖更多元化组件——这种趋势正呈现显著增长态势。 目前已有若干案例，SIG框架堪称典范——或许是我能举出的最佳范例，其兼具广泛适用性与强大执行力。第二个问题涉及组织内部采用特定安全标准时，如何应对合同方采用其他标准的情况。这正是我们反复遇到的情况。SOC就是典型案例——许多组织向供应商提出SIG等特定框架要求，最终却收到SOC报告，常伴随"这够格吗"的质疑。最佳应对方式是通过数据与标准映射：我们越能量化SOC与SIG核心框架或ISO标准的契合度，就越能快速填补差距。 若存在显著差距——比如SOC未能完全覆盖我们基于SIG核心框架提出的要求——我们就能明确差异点，向供应商提出需要补充说明的主题领域。 不过这种情况确实很常见——供应商提供的各类文档和框架，往往与贵方组织正在实施的框架存在不完全匹配的情况。

梅丽莎：太好了。谢谢你，托马斯。嗯，也感谢你们今天提供的所有见解，托马斯和马特。呃，感谢各位的提问。讨论非常精彩，现在正好到整点时间。相信我会收到部分朋友的邮件，或许在我们未来的网络研讨会上再见。今天就到这里。 祝大家剩余的白天和夜晚都愉快，我们很快再见。保重。托马斯：谢谢。马特：感谢各位。谢谢。