合规播客网：2020 年第三方风险管理研究

梅丽莎：大家好，欢迎各位参加。很高兴看到大家陆续加入本周三的会议。请稍等片刻调整状态、连接设备，如果需要的话也请先喝杯咖啡提神。与此同时，我将启动首次投票。 稍后你们屏幕上就会弹出投票窗口。我想了解大家参与本次网络研讨会的动机：是因为刚启动第三方风险管理项目？还是现有的Prevalent客户？或许只是在做项目调研？请如实回答。 或许您正不知所措？我不确定。那么让我们开始吧。先做个自我介绍：我是梅丽莎，负责业务拓展工作。今天我们邀请到嘉宾埃里克·布朗，他是Cytokinetics公司的首席信息安全官。欢迎埃里克。

埃里克：大家好。

梅丽莎：接下来请出场的是普瑞文特公司的首席营销官迈克·亚菲。你好，迈克。

迈克：你好。

梅丽莎：最后但同样重要的是，我们有斯科特·朗，我们自己的产品营销副总裁。你好，斯科特。

斯科特：嘿，梅丽莎。

梅丽莎：今天埃里克和迈克将深入探讨如何将TPRM转化为商业对话的关键步骤。今天的内容基本上就是迈克和埃里克之间的对话。那么，先说些会议安排事项。 本次网络研讨会正在录制，稍后您将收到录播视频及配套幻灯片。目前所有参与者均处于静音状态，若有疑问请随时在问答框中提出。不必拘谨，欢迎畅所欲言。那么，现在就请埃里克和迈克开始分享。两位请开始吧。

迈克：说得对。埃里克，感谢你今天加入我们。特别感谢你，毕竟你没能参加RSA大会——我们之前聊过这个背景。梅丽莎，谢谢你。请切换到第一张幻灯片。还有几件事要说：各位，对于没参加RSA大会的人，我想我们都去过那里。 这周不用和三万人挤在一起，感觉挺好的。所以现场比较安静。其次，我得为此道歉。嗯，我的长相确实没法改变，但这次的休闲风格——妻子刚生了孩子，我知道你们在想"他这把年纪还当爸爸"。 确实如此。不过目前我只能做到这样。所以，我正在努力。今天你们戴着帽子，氛围更随意些。但这绝对会是场超有趣的对话。听着，我真的很兴奋。埃里克一直是我们非常好的朋友，他经验极其丰富。 我觉得，当你把他的IT和网络安全经验、他的技术背景结合起来看，这真是绝佳的组合——既是深谙技术精髓的专家，又能深入一线实战，同时因其职位身份，深谙如何向高管层汇报工作，如何将技术概念转化为董事会能理解的语言。 就我们当前目标而言，要让首席信息安全官或董事会层级接受业务方案、支持扩展或推动TPRM计划专业化都极具挑战。埃里克本人或许不会这么说——他为人谦逊——但他确实是这方面的专家，职业生涯中已多次成功推进此类工作。 能请他抽出时间指导我们并帮助各位理解，实属幸运。再次提醒，若各位在聊天区有任何疑问，请随时提出。我们会尽量结合上下文解答，若无法即时回应则留待最后处理。埃里克，您想先谈谈什么吗？梅丽莎，请切换到下一张幻灯片。

埃里克：不，我非常感谢你的引荐。我期待深入探讨。

迈克：好，我们开始吧。 所以，看，第一个问题主要是为了让大家统一认识：你们是怎么做到的？在组织里实现上下统一的协调其实并不容易。我总爱问：你们属于什么类型的机构？想听答案吗？其实又不想听答案对吧？所以，呃，你们是如何达成共识的？你们会把自己归类为哪种类型的组织呢？

埃里克：好的。那我先从组织架构部分说起，用几种方式来解释。我所在的是广义上的制药行业，对吧？有些人会把它归类到医疗健康领域。不过它其实是不同的商业模式。制药业的生死存亡取决于知识产权。所以这点很重要——要了解客户，了解受众群体。 Cytokinetics规模较小，员工约500人，加上承包商、顾问、服务商等用户群体约千余人，并非大型机构。在我接任首席信息安全官之初，我们始终强调的核心理念是：将网络安全计划定位为超越技术范畴的整体战略。 当然会涉及技术环节与技术手段，但这本质上是更广泛的企业风险管理策略的一部分——其终极目标是保障组织内部所有成员及关键利益相关方（无论内部外部）的幸福与安全。因此首要任务就是开启这场关于...的讨论。

迈克：那具体是什么样子？比如说，如果组织里从来没有过这种东西，而你正试图让大家——你知道的——把所有东西都塞进小盒子里，或者堆在角落里，那该怎么办？

埃里克：对吧？

迈克：所以，那个高阶骗局到底是什么？你该从何开始？该怎么开始？该从谁开始？

埃里克：是啊。近年来有些事情确实变得容易些了，因为太多事件都成了头条新闻，对吧？无论是SolarWinds事件，还是本地大学或医疗机构遭入侵，或是勒索软件攻击，又或是人们看到Target、Visa、CASA这类公司中招。欧洲大型零售商的门店也曾因收银系统遭黑客攻击而停业数日。 所以说，所谓"晚间新闻"确实让这类讨论变得更容易了。于是我们看到更多董事会成员开始发问——尤其当他们身兼数职时——质问我们如何保障资产安全？新闻快讯和资讯推送铺天盖地，整个社会对网络安全的认知已今非昔比。十到十五年前，网络安全还只是个基础问题：我们是否配备了最新最强的防火墙？ 所以

迈克：有些的有些的

埃里克：技术问题在于，A等于B，它本该是这样运作的——执行这个操作，然后...埃里克：所以我们关注的另一部分，不是技术问题，而是法律部门在组织内部的定位。 没人会把法律职能视为合同管理体系的一部分。埃里克：但人们认为网络安全是防火墙、访问权限和身份认证等功能的体现。这些都很重要，对吧？它们和合同管理体系一样关键。但我们需要帮助人们理解，法律部门的存在是为了协助企业处理合同层面的风险管理。 网络安全部门则负责处理网络技术层面的安全风险管理。当然，技术手段不可或缺，但关键在于帮助人们建立这种类比认知。同时我们通过夯实基础工作赢得信任——在技术、流程和管控措施上做到位，让内外审计方都认可"这艘船很稳"。这使得讨论能从技术术语转向更贴近业务的语言。

迈克：那么如果必须排序的话，你打算从谁开始着手让大家接受这个方案？法律部门排第一，这其实是个问题而非陈述——但你认为最需要重点合作的三个部门是哪些？需要重点帮助他们理解背后的原因。

埃里克：是的。在我们特定的架构中，最初至关重要的三个职能部门——或者说少数几个关键职能组织——是质量合规部，但法律部尤为突出。话虽如此，我们还另行开展了与高层领导团队的协作工作，即向组织中的副总裁及以上级别管理层展示：这些顾问和承包商构成了我们组织的核心能力支柱。 他们构成了我们组织能力的重要支柱，对吧？他们支撑着自动化系统、数据处理以及日常运营。如果我们无法识别这个庞大群体中的风险点，就极易陷入瘫痪、遭受损害、面临声誉危机——诸如此类的连锁负面效应，都将成为我们必须应对和克服的挑战。所以，

迈克：你必须在那个语境下解释吗？因为你之前说过，对吧？那是PII（个人身份信息），对吧？所以你是否需要帮助他们理解，这才是组织最迫切或首要的关切？你就像在说，我们甚至不知道有多少人——我不是说你做了或没做，但...

埃里克：嗯，

迈克：能够访问个人身份信息（PII），或知晓这些信息流向何处、由谁访问，以及访问者如何使用这些信息。

埃里克：没错。所以，个人身份信息对我们显然很重要。我的意思是，欧洲的《通用数据保护条例》、加州的隐私法规，这些都很有道理。

埃里克：嗯，知识产权才是更重要的事。所以当我们开始看到新闻里那些组织机构消失时——

迈克：对了，我指的是IP。刚才那句是我的大脑自动翻译，先道个歉，其实我说的是IP，只是字母组合一样。所以，抱歉啦。

埃里克：不，别担心。嗯，是的。所以，所以帮助他们理解这可能是什么样子？这可能表现为数据泄露到组织外部，落入不该接触的人手中。这可能表现为——比如我们的关键意见领袖或其他医疗专业人士可能不愿与我们合作，因为他们不信任我们。 我们无法保障数据安全，甚至不清楚具体发生了什么。所以那些我常提到的负面影响，其实很少涉及"有人黑了服务器"这类具体事件——通常用商业术语来说，就是指我们必须应对的下游负面效应，以及我们正努力抵御的风暴。这通常才是核心关注点。

迈克：在安全营销领域，这种做法是否足够危险？我从事这行二十多年了，主要有两种策略：一是赋能型策略——强调更优、更快、更强或更安全；二是恐惧、不确定性与怀疑（FUD）策略。 你觉得哪种有效？是混合策略吗？但具体要向利益相关者传递什么信息？如果要区分高管团队和法务部门——或许本质相同——但具体该如何展开论述？

埃里克：是的，这是个好问题，我认为两者兼而有之。我的意思是，在网络空间中，现实情况更多是——我未必会直接说FUD（恐惧、不确定性与怀疑），但我理解这种心态，我会将其归入风险规避与成本控制的范畴。显然，恐惧、不确定性和怀疑是驱动该领域行为的核心动因。埃里克：不过总体而言，若我们能有效管理风险、降低不必要成本负担，这固然很好。但团队内部还秉持着原则性立场：在确保运营顺畅的前提下，始终将风险最小化作为核心目标。只要能以极低甚至零摩擦的方式实现，就是理想状态。 这样做能赋能团队成员——我们通过技术手段最小化或缓解风险。关键在于如何让访问更便捷且更安全：多因素认证该如何配置？单点登录该如何设计？既要提供广泛便捷的应用访问，又要加强后台控制力度。 这既涉及赋能环节，最终更要建立组织内部的信任基础——让人们主动质疑"我们是否做对了？"，而非将网络安全项目强加于人，用"你做错了，我来指正"的姿态介入。 现在业务伙伴主动找我们商讨：如何将网络安全纳入决策考量？在供应商多选方案中如何运用网络安全作为决策依据？而不是将其视为又一项必须完成的勾选式任务，拖慢整个流程。

迈克：是啊，这看起来很棒，对吧？我的意思是，如果你能达到评估他们控制措施的阶段，这就会成为一个差异化因素，对吧？一个超级积极的差异化因素，因为你会觉得他们确实做到了，这意味着你在这方面已经走得很远了。 还有个后续问题——观众席确实有人提问。关于风险接受度的问题：当资源不足时，你总无法填补所有漏洞。我的意思是，你是否该向高管团队坦言：我们必须承认这存在潜在威胁，但风险概率仅4%或1%，我们仍会采取行动？ 如何让高管团队以书面形式确认：我们愿意接受X或Y风险？

埃里克：是的。所以，我认为这个问题提得很好。面对这类问题，我的开场白总是：除非你拥有数学意义上的无限预算，否则必须设定优先级。埃里克：这本质上取决于资金池的大小，对吧？因此无论如何你都需要取舍。如果仅基于风险进行投资，理论上你甚至能超越任何公司的营收规模——因为风险不可能归零，而营收终究有限。 因此从本质上讲，鉴于信息的重要性，我们始终处于优先级排序的实践中。我们通常将风险进行分类——出于某些显而易见的原因，我不会深入细节，但希望能让大家有所了解，希望这对大家有价值。

迈克：嗯。嗯。完美。

埃里克：我们通常从几个不同维度对风险进行分类。 我们处理的数据敏感度如何？公司内部采用从公开信息到需知信息的分级体系。特定平台系统供应商等要素的业务关键性如何？此外，我们运用Prevail作为TPRM解决方案的组成部分，围绕SIG轻型系统（此处仅举例说明）进行分类，并制定了正式的标准操作规程（SOP）该SOP经过质量体系认证，其中包含风险决策矩阵。该矩阵通过数据分类与风险程度的真值表，确定风险接受的具体层级。例如，若涉及托管公共互联网系统的平台，其数据本就属于公开信息，按定义应对外公开。 若该平台存在风险，可能由我的网络分析师签字确认：对于公开系统而言属于低风险。 我们的真值表根据数据敏感度和风险等级明确了审批权限，审批层级从网络分析师逐级上报，直至由我与该领域职能主管共同决策。这是经正式审批、培训和传达的标准操作流程。 这就是我们如何将风险接受标准嵌入流程，让所有人都能看到。未来是否可能出现例外情况引发投诉？是的，或许会有。

迈克：总会有例外情况，对吧？这很有趣。总会有异常处理，对吧？你知道的，你永远不可能——如果你试图构建一个包罗万象的系统，那你还没到那里就会失败，对吧？80/20法则，各位。 嗯，这回答了我们其中一个问题。另一个问题是：有人问到一个基础问题——如何让高管团队重视并投入时间进行网络安全教育？我对此持相当强硬的立场。第一，这是CISO的职责所在，对吧？ 其次，我怀疑你未必能让高管团队真正重视网络安全。这可能关乎组织基因——有些机构天生就漠不关心，安于现状。埃里克，如果你觉得我偏离主题尽管直说，但我确实不认为所有组织对网络安全的重视程度都相同。

埃里克：嗯，我觉得这话表面上确实有道理。不过听着，我认识不少高管，他们对公司日常运营的多数环节根本不关心。 不过话说回来，我目前还不清楚你的受众群体。我不确定多数高管是否真的关心网络安全项目——他们真正关注的是员工能否正常工作，能否安心入睡而不必担心某些公司（比如几年前某家耗资逾十亿美元应对勒索攻击的MC集团）遭遇的灾难。那些高管事前毫不在意，事后才惊慌失措。所以有时会演变成危机，有时则不会。 别推销没人想要的产品。对吧？处理那些没人想要的事务本就是安全团队的职责。他们不需要幕后操作，但要谈论他们真正关心的问题：员工能否正常工作？风险管理到位吗？是否存在需要警惕的盲区？ 其余事务，就交给幕后的魔法师们处理吧。

迈克：嗯，还有还有，你看，我一直强调的两件事——第一，是保险，是保险。

埃里克：嗯。

迈克：对。你的人生需要多少保险？我这么比喻可能不太贴切——对某些人来说确实如此——但关键在于你有风险承受能力，而我买了人寿保险，对吧？随着情况变化，你可以增加或减少保额。 投入安全保障越多，心理可能越踏实，但开销也随之增加。这确实是成本中心，但必须从风险角度考量——若家中遭遇洪水，或万一有人无法工作，你是否有保障？安全技术正为此提供支持。 埃里克，我还想说，我们观察到一个普遍现象——无论在哪个公司都如此：一旦发生安全事故，所有人会立刻对安全问题产生宗教般的虔诚，预算也会立刻到位。这确实无可奈何，但有时组织就是需要这样的警醒。

埃里克：我还要补充最后一点。没错。我的意思是危机危机，就是别让危机白白浪费，对吧？正如有人曾经说过——

迈克：对吧？就是那个，我超爱那首。

埃里克：嗯，我想补充一点，我也能想象这样一个世界：有许多以设计汽车为生的人坚信，每个人都应该阅读随车附带的说明书——而实际上我们谁都不读，因为我们只想跳进车里，按下按钮，直奔目的地，然后下车。 我们根本不想读那本说明书。所以有时，对吧，我们或许渴望说服他人认同自己工作的价值与必要性，但这终究是件难推销的产品。不如专注于成果本身，以及为组织管控风险——抱歉。

迈克：那是梅丽莎，我们看第二张幻灯片。呃，但这点至关重要，埃里克。关键在于——你能深入探讨吗？重点在于结果对吧？这才是核心所在。 你看，这直接跳到了故事的结局对吧？我们面临一个商业决策：是否愿意实施？我的意思是，当我们进入下一个关于商业案例的讨论时，这个商业案例本质上就是组织可能面临的负面结果。 我知道我们讨论的是FUD与赋能的对比，但迈克： 嗯——迈克：你需要深入探讨的是：当安全团队向你提交商业案例时，你关注哪些要素？哪些因素能真正推动你做出积极决策？反之，若案例阐述不清，你又会基于什么理由将其否决？

埃里克：是的，这是个好问题。所以，嗯，当我们开始构建框架时——我用TPRM作为简称——但当时我们试图厘清第三方乃至某些情况下第四方的风险所在，其实并未采用标准商业案例模式。对吧。 因为我们不追求投资回报率（ROI），风险规避本身就是一种回报，对吧？本质上是成本规避或风险缓释。不过为了阐明方案——即明确投资额度、预期价值、执行方式，以及之前提到的"专业化"实施路径——

埃里克：对吧？要让大家行动起来，这可不是又一项只有少数人在幕后把玩的技术。我们的目标在于：通过寻找供应商来识别风险所在，这样各部门和业务同事就能围绕这些风险进行管理，或通过额外流程和控制措施来降低风险。 再次强调，董事会成员若能深入了解该领域，并主动询问"你们在网络安全项目中做了哪些工作？"，将极大推动工作进展。

埃里克：每当我们谈及TPRM时，他们都会说：“哦，太棒了，请详细说说。”对吧？ 因为他们吃过亏。呃，埃里克：所以当外部审计机构如安永问起"你们的网络安全计划和TPRM如何"时，这其实是件容易说明的事——我们无需做太多准备，因为在某种程度上这是市场波动中经营成本的一部分。所以我们这样阐述：这是我们计划投入的领域"——"这就是原因，"——""这是预期收益，"——""未来发展路径如下：我们不会首日就解决所有问题，而是循序渐进，随着时间推移逐步完善，但会为这个演进过程设定严格标准。当团队成员提出建议时，"——" "嘿，我想做这个或那个。"最终我们仍需面对预算问题。但我的评估标准与对高管的要求一致：这如何为组织管控风险？我们计划如何运用它？ 我们对当前起点和未来发展方向的愿景是什么？然后我们会逐步解决这个问题。但这绝不是因为某人结束了销售电话，就盲目签约下一个必备工具，声称没有这三四个工具就无法支持细胞动力学。这种讨论毫无意义。

迈克：没错。关键在于必须明确目标导向。你当前处于A点，我们需要抵达B点。那么B点是什么样子的？最终状态该如何呈现？对吧？我们该如何倒推规划？我一直强调，像你这样的首席信息安全官在采购时，必须确保整体效益最大化。 有时变革是渐进的，但这已是极限，对吧？推动组织转型时，不可能一夜之间从60分跃升到92分。或许从60分提升到62分，但真正的路径是通过这个方案先达到75分，再逐步推进。 但这终究是种策略，是种过程。必须指出，如今充斥着太多兜售灵丹妙药的骗子——他们承诺过多，兑现不足。而安全领域的大多数措施，需要时间才能见效。它们不会立竿见影，不会两周见效，事情从来不是这样运作的。

埃里克：嗯。绝对。绝对。

迈克：那么，在所有商业案例中，你能告诉我你见过最棒的一个吗？梅丽莎，也请切换到下一张幻灯片。

埃里克：这个……是从提交给我的商业案例中得出的。

迈克：是的。

埃里克：明白了。

迈克：为什么？

埃里克：嗯，这是个好问题。让我想想，找个合适的解释来说明。 所以，我希望大家能告诉我他们的起点、对项目走向的预判以及推进思路。这并非因为我认为他们无所不知、能预知未来，而是他们确实动过脑筋——用脑子好好琢磨过，说出"项目现状是这样，我打算这样推进"。

埃里克：所以，呃，作为我们EDR解决方案的一部分，最近我们新增了某种恶意代码分析功能，对吧？这样就能具体分析恶意素材的实例了。埃里克：这个方案设计得相当周全，对吧？这里是成本明细，还有几个可选方案。 我们可以这样做，也可以那样做。如果捆绑这个方案，还能获得额外功能——虽然不确定是否实用，但价格就是这样。我认为组织内部这个团队现在就能用上，未来可能扩展。这是我们的使用规划，也是我们对明年发展前景的预期。 好的，这些说明足够清晰了吧？这并非重大投资，金额也未达五位数级别。嗯...这表明有人已全面考量过问题维度。

迈克：正想说这思路很周全。就像你刚才阐述的那样，简直考虑得无微不至。先说明需求依据，再列出适用人群，接着阐述核心价值，接着展示未来扩展空间和长期效益，最后明确成本及实施理由。一气呵成。

埃里克：这个方案对我来说很有效，它最终成为我未来几年规划中的重要部分。所以没问题，我们有人负责监督并保持其完善状态。可以就此推进了。

迈克：就是说，你心里有个路线图，显然我觉得每个人都有。我们在市场营销领域就有一个，对吧？这就是我们正在做的事。但这个路线图有多灵活？比如你是否愿意——你知道的，我总觉得首席信息安全官们要同时处理二十个想做的项目，却只能执行其中一个，对吧？而且问题甚至不在于资金，对吧？ 关键在于能否有效调配资源来管理这些工具和技术，从而实现价值。如果没人能操作这些工具，也无法从中获取价值，那你不可能引进十项技术。

迈克：那么，你们如何确定优先处理哪些事项？团队又是如何向你汇报优先级的？首先，如果出现突发状况，你们会如何调整优先级排序？

埃里克：嗯，这是个合理的问题。那么，我给你两个答案——一个是自上而下的咨询式答案，另一个是自下而上的运营实用性答案。

迈克：对对

埃里克：嗯，通常来说，我会列一份清单——抱歉用了这些流行术语，但这些定义对我确实有实际意义。我会列出目标清单，这些目标都带有方向性陈述：增加、减少、最大化、最小化。我列出的目标既与组织目标保持一致，也是我将付诸行动的。然后我制定若干策略来支持这些具体目标。 这些行动方案最终会落实为具体措施，而路线图则是一系列实现战略目标的具体目标和战术。这就是我写在纸上的内容——假设在理想状态下，一切不变，这就是计划。但计划终究是计划。现实中，万物时刻都在变化，对吧？这正是你问题的核心所在。 对我而言，构建能力本身意义不大——抱歉说句可能显得愚蠢的话——真正关键的是运维能力。我见过太多组织启动大量项目、部署诸多技术，结果第二年就彻底停摆。

迈克：同感。就像他们总在强调安全性，对吧？他们总说：“哦，看这个。哦，看那个。哦，看那边。说真的，简直难以置信。”

埃里克：所以，既没有第二年的规划，也没有可持续性规划，埃里克：更缺乏对实际运营层面的务实考量。因此，当我们接近要部署所谓路线图上的某个概念性项目时，或者当我评估某人的提案时——他们会说"我们知道有路线图，但考虑做这个相邻的边缘项目"。 那么，这是否可持续？至少它是否与我们的目标和战略不冲突？是否支持现有工作？或许存在些许偏差？这没关系。 能否在第二或第三年推进？这里的推进不仅指资金保障，更需明确：是否有内部团队成员负责执行？是否有服务供应商承担实施？这些都无妨。关键在于整体业务是否协调一致？若该项目像TPR那样公开透明，我们的合作伙伴是否也愿意在这些条件下运作？

迈克：这观点实在太棒了，对吧？老实说我之前根本没往这方面想——比如把这种模式扩展到合作伙伴、顾问团队以及所有相关人员身上。你愿意这么做吗？他们怎么看待这件事？能否和他们顺利推进？毕竟如果难度太大，那就不该或不能这么做。

埃里克：然后它就会死掉。你第一年做的所有事，不就是白白浪费钱吗？

迈克：是啊。组织惯性实在太大了。所以呢，你看这张幻灯片里你提了好几次预算，我接着问个后续问题——我们先处理这个，然后有人现场提问了关于KPI和KIS的问题，但...

迈克：我的意思是预算就是预算，你可能多拿5%，也可能少拿10%，就是这样。迈克：那你如何为一个你认为至关重要却未获资助的项目争取资金？我的意思是，这里存在权衡取舍——软件成本是X，人力成本是Y，运营支出、资本支出，然后你根据优先级、对你或合作伙伴的影响以及风险降低程度来决策。迈克：嗯，迈克：但你知道，总会有其他你想做或认为关键的事项。这种情况该如何处理？

埃里克：是的。所以部分决策权在我这个层级，对吧？取决于我们正在做什么以及需要多大的调整幅度。 如果这是预算外需求，比如一年内突然出现，那我得权衡内部资源如何调配——要么直接管理层拍板，要么就得向财务部门或更高层管理团队提出申请，说明需要更多资源，并暗示需要其他部门做出让步，同时阐明理由。 通常来说，我更倾向于自主掌控本部门资源，而非逐级申请。但你也知道，有时不得不主动争取，这也是我的职责所在。

埃里克：嗯，正如我之前所说，对吧？既然预算在数学上并非无限，就必须设定优先级。因此，我们提出TPRM（或有人称之为VRM）的部分依据，就是明确说明我们将如何优先推进这项工作。我们将聚焦关键系统、敏感数据和新供应商，对吧？ 这样至少能向利益相关方证明，我们并非试图包揽所有事务。随着时间推移，共识将逐步形成。人们会逐渐适应，组织内部自然会涌现支持者——我认为这种转变将通过多种途径实现，从而推动项目进展。而我们采取的策略确实成效显著。 所以——是的，我随时都愿意接受这样的胜利，但其中确实有些运气成分。有个姊妹机构在推进相关工作时拖拖拉拉，因为他们视其为强制性任务。结果他们最终选定的供应商在为期约一年的执行过程中表现不佳。

埃里克：后来他们回过头来，根据我们和那家供应商的合作情况，他们说：“啊，明白了。 现在我们会更配合了。"对吧？这是我的说法，不是他们的原话。但基本就是这个意思。现在他们成了优秀的合作伙伴，会说："不不不，这对我们是增值服务，因为它提供了上次合作时我们不具备的可视性。我们曾忍受过糟糕的合作关系。所以，我们随时都愿意接受这种合作。"

迈克：你知道吗，这很有趣。我也听过很多类似的说法，而且我不得不痛苦地学到这些教训。但对我来说，关键在于向团队明确传达你的行动计划，对吧？这样他们就不会措手不及。要帮助他们理解优先级、预算安排、执行方案，让所有人达成共识并支持决策，然后说： "看，这就是我们要做的七件事。"结果总有人找你——可能是董事会成员、高管团队，或是某个销售人员——他们总说发现了新奇玩意儿，就问："为什么我们不能做这个？"你只能说：我们已经达成共识了这七件事

迈克：作为一个组织，对吧？这就是我们的策略。我很乐意调整，但这七件事中我们能停止做哪几项？或者说我们应该停止做哪几项，才能加入第八项？毕竟我们已经达成共识了，对吧？埃里克，对我来说，正是这种超高效的沟通让它迈克：取得了成功。

埃里克：是的，我同意。

迈克：嗯，我们来聊聊关键绩效指标（KPI）和简明原则（KISS）。观众席上有人提了相关问题。我的意思是，雪莉，在从零开始制定供应商风险管理计划时，组织应该关注哪些关键绩效指标？雪莉，我们在这方面做了不少工作。我会安排会后把相关材料发给你，但很想听听埃里克的看法。

埃里克：是的。所以，我肯定会……呃，抱歉让大家失望了。 我绝对不会谈论其他组织"应该"怎么做，但很乐意向您介绍我们重点关注的几个关键指标，希望它们能有所启发。我们持续更新所有完成TPR流程组织的风险指标数据，同时借助Bitsite进行外部信用评分评估。 这些数据我们持续追踪。坦白说，这些指标对高管层的吸引力有限——只要我们处于右上角绿色区域（优于同行水平），这已是他们关注的核心要点。而我更注重分享的是：风险类型分布及职能负责人对风险的接受程度。 这正是我们高管文化——或者说CC套件文化——的核心理念：坚信职能部门负责人需对本部门风险负责。因此让副总裁、高级副总裁、执行副总裁能清晰知晓：组织中哪些领导者承担了哪些风险？这些风险是否合理？ 这些正是他们需要掌握的核心信息。本质上是风险接受度指标——我们与供应商开展了多少工作来规避潜在风险？当供应商提出"我们不做这个"时，我们会基于合作经验反驳"你们确实应该考虑实施"。 这些才是风险组合和风险评分中更具意义的指标——它们更广泛地反映了TPRM项目的成效。当然我们也追踪其他数据。比如有人想知道评估耗时多久，尽管通常耗时主要来自第三方，但我们也有相关记录。 据我所知，本机构内部无人真正关注这些细节。大家更希望了解本部门的风险目录概况。

迈克：嗯。我之前和一位CEO共事过，他总爱说一句话——这确实是句金玉良言：关键不在于数据好坏，而在于你能否向高管团队展示数据。比如你可以说：我们完成了百万次评估。

埃里克：好的

迈克：没错，你希望他们都被上百万次评估数据震撼到，于是你问"你们到底做了多少次？"答案可能是"一千万次"对吧？所以啊，没有上下文或基准参考，这些数字对很多人来说毫无意义，全是些流行术语。尤其在你们项目里——我同意你对Bitsite的看法，看看它做的不过是外骨骼扫描而已。我认为它对Delta测试有价值——前提是配置正确且后续有变动。但你知道，它就是这样。嗯，帕特提问：具体测量哪些与TPRM相关的指标？能否列出三四个？梅丽莎请切换到下一张幻灯片。

埃里克：是啊，这确实主要围绕风险清单展开。我之所以有点含糊其辞，是因为……

迈克：不不不，别担心。所以，我们不是在问什么独家秘诀。所以，

埃里克：嗯。嗯。嗯。埃里克：呃，我会尽力让它有意义。所以，一般业务流程是这样的：有人提出需求，某个部门发现想用的新工具或供应商。很好。 我们会启动流程。我们会进行内部需求分析和基准调研，以明确该合作伙伴的具体应用场景。这份调研问卷（约12道题）由内部业务同事填写，随后我们会向供应商发送标准的SIG轻量版问卷，获取包含36道题（具体数量可能略有浮动）的反馈，并据此完成需求分析。 此时多数业务伙伴最关心的核心问题是：何时能让这些人员上岗？因为今日签约并上岗对运营至关重要。虽然网络安全并非同步步骤，但我们不会直接批准或拒绝交易，而是采取咨询模式。 他们仍想确认：当我们指出风险（我指的是需向总监或副总裁汇报的关键风险）后，能否顺利通过障碍？你们是否愿意承担这些风险？我认为风险不小，但缺乏业务背景判断——能否及时找到替代方案？ 所以，让我们深入探讨。根据我的经验，此时高管会开始思考：我们推进得太急了。我得和团队商议是否该重新评估。对了，顺便说回指标问题——我手头其他项目进展如何？ 因此在引入供应商时，我们会进行组织分类。这样我就能随时向任何职能副总裁、高级副总裁或执行副总裁汇报："支持临床运营的供应商池如下，其风险评分如下。"然后围绕这些数据展开讨论。

埃里克： 我们是否认为某些领域存在过度脆弱性？他们无法从其他数据中获取具体数字，但可追踪的指标是供应商在组织层面的整体风险评级。这样我才能与职能主管沟通，让他们判断是否需要调整措施——而非依赖基准指标、KPI、KIS或KAS这类数据来证明网络安全计划的合理性。

迈克：说得对。嗯，梅丽莎·斯科特，我们大概还会有五到七分钟，最后留些提问时间。所以埃里克，再问几个问题我们就收尾吧。顺便说一句，这次讨论太棒了。 嗯，说说你们如何评估解决方案供应商？就是整体评估时，比如在TPRM（供应商风险管理）方面——哪些做得不错，哪些需要改进。我特别想了解你们如何引入合作伙伴（虽然大家都用这个词），无论你们怎么称呼这些合作方，对你们来说最重要的考量是什么？

埃里克：嗯，所以我会跳过很多商业层面的内容——毕竟合作方通常不是初创企业，因为我们没有那种在初创领域常见的风险承受能力。假设我们合作的对象确实是可持续经营的企业，盈利稳定，且运营时间超过短暂的热潮期，那么现在我们可以深入探讨其他有意义的事项了。 对我而言，尤其在TPR领域，最关键的是：这个产品够不够好用？对吧？我完全可以把糟糕的解决方案塞给内部团队，然后说"大家得慢慢适应"，对吧？即便产品本身很复杂，但它带来的独特价值确实非常突出。 思科当年靠Catalyst OS系统撑下来就是这么回事，iOS界面糟糕透顶，但网络工程师只能忍着继续干活。 但像TPRM这类需要向业务同事发放问卷或向供应商推送的工具，其核心价值在于能否获得有效反馈。如果操作不够直观便捷，系统很快就会被弃用。所以我们必须兼顾易用性——既要提升参与度，也要确保合规性。 那个...是否有特定供应商采取过加速推广的措施？毕竟我们都是独一无二的存在，但许多问题设计确实...嗯，可能不符合我的提问习惯，或者与软件工程师的构建方式存在差异——但这些都不重要，对吧？毕竟9美元在星巴克只能买杯咖啡。

埃里克：所以这只是个人观点。那么，是否有能让我们快速启动的措施，既能推动项目进展，又无需对所有环节进行逆向工程？具体到这个案例， 我们考察过的一个方向是：是否存在可补充的服务？比如将TPR项目部分环节外包给Prevalent这类供应商代为执行，从而追踪单一供应商。那么现有数据目录是否存在？是否存在外包机会？我们能否付费让第三方介入以提升可扩展性？这些都是可选方案。但最初最具意义的方案之一，正是这种简化思路。

迈克：而且我们确实收到很多问题，所以我想补充下你的观点，不过让我先说明下情况。我觉得我们该暂停一下，让斯科特先讲几分钟。想提问的可以输入问题，不过我们这里已经收到五个问题了。所以先这样处理，之后我们可以留下来回答问题。 埃里克，最后一点——你提到启动这类项目要遵循"爬行-行走-奔跑"原则，我知道这是老生常谈。我理解这个道理，但我们见过太多案例，实施过数百个项目。那些人总说"我有500家供应商"，却从最基础的可执行环节开始构建项目。 各位，这关乎肌肉记忆。特别是供应商风险管理项目，既非易事也非直观可得。就像雪花补偿机制，对吧？人人都觉得自己与众不同，但事实未必如此。

迈克：对吧？我觉得还是那个80/20法则。90%甚至85%的事情都已经有了现成的解决方案。你只需在实践中摸索那15%的未知领域，而且要在安全的环境里操作。埃里克，如果你觉得我说得一派胡言，尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管尽管

埃里克：不。所以，我基本同意。我想稍微展开说说爬行、行走、奔跑这个比喻。我希望我们的流程从爬行阶段开始并快速推进。我希望我们的控制措施从爬行阶段开始。但我不需要软件从爬行阶段开始。

埃里克：对吧？所以不同方面在成熟度的不同阶段启动。 我们最终可能调整某些环节——随着新发现不断涌现。但大多数组织（抱歉，我指的是在获取技术或流程控制平台时）往往忽略：虽然细胞动力学公司有区别于其他药企的独特之处，制药行业也有区别于零售、制造、批发等领域的特质，但这些都只是更广泛平台的边缘部分。 因此我们可能进行调整，但绝不会在技术应用的前五天就着手变革。通常要经过一两年实践后才会发现：哦，原来这里存在值得优化的空间。目前我们正在推进部分优化工作。

埃里克：在隐私问题引发轩然大波的当下，我们会进行边缘调整，声称需要围绕此事提出更多问题——毕竟我们可能选择进入特定市场。但这只是微调。我们并非从第一天就开始这么做，而是在运营两年后才启动调整。你无法衡量自己不具备的东西，你根本无从知晓。犯错是正常的。 听着，我们深耕这个领域已久。我敢说自己犯过所有可能的错误。那么，梅丽莎，接下来该由你提问还是转给斯科特？我本该清楚，却偏偏记不清了。

梅丽莎：接下来我们把话筒交给斯科特。来看看——哇，问题可真不少。开始吧。嗯，斯科特，现在全靠你了。

斯科特：太棒了。谢谢，梅丽莎。嗯，请继续切换到下一屏。就是我们刚才听到的——虽然倒也不算太远，但回到上一屏吧。斯科特：是的，今天和埃里克的对话中，我们主要听到的是关于在整个生命周期中，如何基于事实做出关于第三方的一致性决策。这正是我从今天许多讨论中领悟到的核心。那么，您在做出这些优质决策时会采用哪些标准？或是依赖何种数据类型？——基于事实的数据来决策，贯穿整个生命周期。这正是我从今日讨论中提炼的核心要义。请问你们依据哪些标准来做出这些优质决策？又运用何种数据？这些是否符合众多客户对第三方风险管理项目最迫切的需求？ 为他们提供助力决策的数据，帮助提升团队效率，打破团队、部门及工具间的隔阂，从而优化决策过程。第三，使项目具备随第三方供应商风险评估需求变化而持续进化扩展的能力。这三点正是客户普遍期望获得的核心价值。请切换下一张幻灯片。 梅丽莎，请再演示一次。就是这样。我们的方法论在于协助您在第三方风险管理全生命周期每个阶段实现这三项目标。我们不仅关注供应商尽职调查与入驻流程，更着眼于风险的分析与管控。 而是要对每个可能出现问题的阶段进行风险分析与整改。这始于供应商的筛选与选择——通过自动化与智能技术，在评估潜在新供应商时做出基于风险的决策，同时判断其是否符合业务需求或目标。 其次，在接纳与入职环节，为供应商风险档案、接纳流程、合同签订及入职工作流提供统一数据源，将第三方关系管理这一基础理念延伸至企业内部所有相关方——不仅是安全部门，还包括采购、风险管理、法务、合规等职能部门。 第三，当选定符合风险特征与业务需求的供应商，完成初步签约与入职后，如何快速掌握该供应商对企业环境的风险态势？这不仅涉及初步风险分级，更需据此制定持续评估策略。 我们通过数据驱动的洞察来计算固有风险评分。在完成分层、建模和分类阶段后，我们将协助您自动化开展尽职调查和持续评估流程，覆盖第三方供应商在安全、信息、网络、数据隐私、合规等多重风险领域——包括安全与非安全相关的ESG、财务、腐败等各类风险。最终我们将这些洞察整合到单一可信数据源中，形成统一风险档案，助力您做出明智决策：通过单一风险登记册，您可据此制定决策。反腐败、ESG、财务等非安全领域。我们将所有洞察整合至统一数据源的单一档案中，助您精准决策：通过风险登记册明确整改方向——哪些风险低于阈值可暂缓处理，哪些需与供应商强化协作。这便引出了生命周期中的监控与验证阶段。 我们观察到许多企业分别使用网络安全工具、财务工具、商业新闻/运营更新工具、ESG工具及声誉管理工具——这些工具虽能提供优质洞察，却极少实现数据协同。 我们专精于整合现有解决方案或提供自主平台，将各类风险输入数据汇聚至统一系统，使企业各环节人员能根据自身核心风险需求，按需获取定制化数据视图。 说到关键风险，我们提到过KPI和KIS——我们还能从平台导入的合同中提取KPI和KRI数据，并在整个合同周期内协助您明确责任归属与衡量标准。提及合同周期，正如尼尔·索达卡所言，每段关系终有终结之时，"分手总是艰难"。

迈克：我正要说呢，好的，我知道这个。是的。

斯科特：不过，如果你们逐步结束与该供应商的合作关系，我们会提供一份安全离职检查清单，确保你们完成线下事项、收取最终款项，并妥善终止访问权限。 归根结底，屏幕底部的三项要点正是我们协助您实现的目标：通过统一数据源和流程加速简化入职流程；优化风险评估流程；完善全生命周期覆盖并弥补安全漏洞；最终实现跨生命周期的团队协同。梅丽莎，请切换下一张幻灯片。 我们通过专业团队的综合能力实现这一目标：代您完成入职、评估、整改及管理等繁重工作，整合前述所有数据源至平台，通过自动化工作流、报告与分析功能，助您有效管控第三方资产。梅丽莎，请切换下一页。我们应对多种风险类型。 我在此列出了六个大类，涵盖我们平台通过问卷调查或持续监控所覆盖的领域。但关键在于，这些信息被整合为单一的运营风险概况，助您做出优质的基于风险的决策。梅丽莎，请切换到下一张幻灯片。这是最后一张。 再次强调，我们最终的目标是赋予您智慧，使组织在管理第三方风险时更具前瞻性。通过整合团队、系统与流程，并提供规范性指导，帮助您在供应商关系全生命周期中有效管控风险。以上便是我们的核心价值主张。

梅丽莎：麦克，把提纲再递给你。呃，埃里克，提问时间。

梅丽莎：嗯，好的，我这就启动第二轮投票。很快就好。你们屏幕上可能显示我这边没启动成功，真是太棒了。等我两秒钟，可能得先结束第一轮投票。今天系统特别不听话。 总之，我想问问各位：未来几个月内，你们是否计划扩充或建立TPRM项目？请如实回答，我们后续会跟进。你们会收到我的电话或邮件通知。所以请务必回答。 但我想真心了解各位的计划，若不确定也请如实告知。不过眼下我们确实积压了不少问题。埃里克，若您方便的话，能否先解答其中几个？我知道问题堆积如山，而我们只剩五分钟左右时间，您是否愿意挑选一两个最突出的问题来回答？

埃里克：是的，我会逐一回应所有问题。其实让斯科特先做推介挺好的，这样我能有时间思考问题。首先感谢大家的赞誉。我会先回答凯伦的问题，然后按顺序处理。凯伦，就我们而言，无论Prevalent如何表述，我们确实将Bitsite与Prevalent进行了集成。 Bitsite提供外部技术信用评分视角，但我们也利用Prevalent内部的VRM功能获取外部组织的商业视角。不过Bitsite确实能与之对接——您可在Prevalent仪表盘中直接查看Bitsite评分，具体集成细节可由他们向您说明。 关于更换第三方风险管理工具的问题，我个人没有相关经验。但若监管机构或检查机构提出要求，我可分享常规处理思路。 我的基本思路是：第三方风险管理的核心并非工具本身，而是由政策、流程、程序和控制措施构成的体系。工具只是对这些体系的辅助。因此我们应聚焦于标准操作规程（SOP）和控制措施，并以符合业务需求的方式实现自动化。关键在于明确风险处理流程、风险审批权限以及风险承担主体。 风险承担权限归属。若任何审计机构过分关注具体工具集，我通常会将讨论重点转向这些核心环节。关于风险登记册的问题——我们多次强调过，我们的方法是聚焦于第三方监控与管理。 并非管理服务本身，也非管理工具集。因此我们关注第三方主体。若遇到单一供应商在组织内提供两种服务的情况，从风险管理角度应如何考量？ 通常而言，若供应商内部存在数据敏感度差异——例如部分部门管理低敏感度数据，另部分管理高敏感度数据——我们会将其整体归入高敏感度级别。具体操作是：将其纳入最高敏感度的系统运行规范，归入最高级别的数据分类体系，并以供应商为单位进行管理，而非按部门划分。 关于风险登记册，我们确有标准操作规程（SOP）中明确的正式审批层级。我们处理的风险登记册主要有两类：一类是风险评估与标定登记册，另一类是主登记册，几乎所有预先评估的风险都会归入其中。 我们的SOP明确规定了风险审批权限及必须签字确认的责任人。通过平台内的行动和任务追踪系统来执行这一流程。希望以上能快速解答各位的问题。若需要更多细节，我随时可以补充说明。

梅丽莎：太好了。我刚才好像又看到一个弹窗，大概四秒前出现的。那个非上市公司供应商的弹窗，你能看到吗？你们的尽职调查流程会因此调整吗？不确定你是否愿意回答这个问题。

埃里克：非上市公司供应商。嗯，让我思考一下。我不知道那个缩写词，无法理解上下文，但我大概明白问题的核心。当然，对于非上市公司，我们最终无法查看任何公开信息，不过如果你愿意进行尽职调查，还是有途径可循的。谢谢你的理解。嗯，其中一部分涉及评估本身——我们会要求公司提供书面证明，但我们不进行实地检查。但若想深入探究，仍可采取尽职调查等途径。感谢提问。嗯，这部分涉及评估机制本身——我们会要求企业提供自我认证，而非实施检查或审计。我们与企业合作，给予他们自我陈述业务流程及核查方式的机会。不过此时我们只能采信其声明。 后续合同条款将涉及执行机制。目前我们尚未开展实质性审计或现场核查来验证其工作成效。对于非公开信息，我们仍采用相同处理方式。 我们可能要求提供额外的保险证明，比如网络保险或一般商业责任险，以确保我们能看到这些文件，因为我们会让保险公司为我们完成部分尽职调查工作，但目前我们主要就是这样操作的。

梅丽莎：太好了。埃里克，感谢你抽出时间。我知道你很忙，迈克和斯科特也非常感谢你们。最重要的是，感谢所有提问的朋友。这次活动本就旨在实现充分互动，现在我的时钟显示已到整点。所以，我提前把邮箱地址输入进去了，以备后续有问题咨询。 虽然有[email protected]这个邮箱，但这是我的直接邮箱，后续若有疑问请直接联系。期待在未来的网络研讨会再见，各位保重。谢谢。

迈克：谢谢你，埃里克。

斯科特：各位保重。