香港企业为何打包采购MSP、MSSP与HKMA C-RAF支持

摘要： 过去几年，香港采购市场出现了一个共同模式：一些公司——尤其是那些本身就是受香港金融管理局（HKMA）监管的认可机构（AI），或是向此类机构销售技术与服务的公司——开始发出单一份RFP，要求同一家供应商同时交付托管IT（MSP）、托管安全（MSSP），以及HKMA网络安全监管与网络弹性评估框架（C-RAF）相关的支持，而不是拆成三份独立采购。这不是一种营销趋势，而是直接源于香港金融管理局《监管政策手册》将外包、科技风险与网络弹性视为一条受监管机构永远无法完全转移的单一问责链条。本报告解释这一转变背后的监管机制、C-RAF在其自身文件结构中实际要求的内容、这三类采购项目在实务中各自具体意味着什么，以及——同样重要的是——一家技术与安全供应商能够诚实地为客户做什么，与客户自身不可转移的监管责任之间的界线究竟落在哪里。

关键发现

打包采购模式是对HKMA外包监管的理性回应，而不是供应商的销售话术——《监管政策手册》的外包模块明确指出，认可机构可以外包活动，但永远无法外包问责。
C-RAF不是单一测试，而是一个三部分的评估序列——固有风险评估、针对既定控制域的成熟度评估，以及针对高风险机构的网络攻击模拟测试（CAST）。
"MSP"与"MSSP"并不像两家供应商采购模式所暗示的那样可以分离——在实务中，备份/恢复、终端管理、基础设施运维，与终端安全、威胁检测、事件响应是不可分割的。
没有任何供应商能够代表受监管机构完成、证明或提交C-RAF评估——那是该机构董事会与高级管理层自身层面的问责。
负责任地投标一份打包合同，其组织门槛高于单独投标MSP或MSSP：需要一体化运营、将证据内建于日常交付而非事后拼凑，以及在供应商责任边界上有明确的合同约定。

这一模式：一份RFP，三个历来分离的专业领域

香港一家公司近期的一份RFP——这类文件通常在境内的托管服务提供商之间流传，而非面向公众撰写——要求单一供应商在同一份合同下并列覆盖：

MSP服务：托管IT服务、驻场支持、基础设施管理、云端支持、备份与恢复服务。
MSSP服务：SOC即服务、威胁检测与监控、漏洞评估、渗透测试、终端安全、邮件安全、网络安全、安全意识培训。
监管与网络弹性支持：HKMA网络安全相关监管支持、C-RAF评估支持、事件响应计划/手册制定与桌面演练支持、文档与证据准备、差距分析与整改建议，以及协助回应HKMA的查询与审查。

五年前，这很可能会是三份RFP，分别授予三家供应商：一家IT外包商负责桌面与服务器工作，一家安全精品供应商负责SOC与渗透测试，而监管与C-RAF部分则往往交给四大会计师事务所或专业咨询公司，按顾问式的日费率而非托管服务费率计费。如今看到这三者被合并进同一次采购，是一次真实的转变，值得精确地厘清其发生原因，因为这个原因决定了一家负责任的供应商在响应时可以承诺什么、不可以承诺什么。

本报告将这一模式视为方向性上真实存在，依据是博讯自身在被要求响应此类RFP过程中的经验，而非一份公开调查——目前已知不存在此类香港IT采购结构的公开调查。凡本报告描述的是趋势而非有文献记录的统计数据之处，均会明确说明。

为何是现在：HKMA的监管框架究竟如何催生这一诱因

要理解为什么一家公司会将这三个类别打包进一份合同，有必要跳出RFP本身，看看催生这种采购行为的监管机制。

《监管政策手册》将科技风险视为单一问责链条

HKMA主要通过其《监管政策手册》（SPM）——一套涵盖从资本充足率到公司治理再到科技风险的模块化监管指引——对认可机构（根据《银行业条例》获发牌照的银行与接受存款公司）进行监管。这里最相关的是两个SPM模块，而本报告在多大程度上能就其内容作出准确表述，也值得说清楚：HKMA会不定期修订模块内容，较少见地也会修订模块编号与标题，因此以下描述反映的是持续、公开有据可查的结构，而不主张对任一模块当前具体修订日期的准确性。

通常被称为TM-G-1、题为"科技风险管理的一般原则"的模块，确立了一项基线预期：无论实际科技运营中有多少部分由第三方承担，认可机构的董事会与高级管理层始终对科技风险负责——这正是"你可以外包工作，但外包不了问责"这一表述在HKMA科技风险指引中反复出现的源头。
通常被称为SA-2、题为"外包"的模块，规定了认可机构在将任何重大职能交给第三方之前、期间与之后必须做什么——对供应商的尽职调查、保留机构（及监管机构）审计与查阅记录权利的书面协议、供应商失灵时的应急计划，以及对供应商表现与内控环境的持续监控。关键在于，SA-2的逻辑并不止步于机构自身的外包决策：由于机构仍须为被外包职能的风险负责，其尽职调查与监控义务延伸到理解*其*供应商如何管理安全与弹性，而不仅仅是供应商是否按时交付合同约定的服务。

综合来看，这两个模块意味着，在HKMA眼中，一家银行的MSP与其MSSP并非简单地是两份并行运行的服务合同。它们都属于SA-2模块所规范的同一种外包关系，也都落在TM-G-1所描述的同一董事会层面科技风险问责范围之内。银行内部的合规与风险团队日益认识到这一点，与其对两家运营上本就相互交织的供应商分别跑两套外包尽职调查流程，不如合并跑一套。

网络安全强化计划为这一问责链条提供了一个具体的评估工具

2016年5月，HKMA推出网络安全强化计划（CFI），该计划专门针对当时区域内银行遭受网络攻击活动上升的时期，旨在提升香港银行业的网络弹性。CFI围绕三大支柱构建，这一三支柱结构在HKMA自身的公开材料中有着良好而一致的记录：

网络弹性评估框架（C-RAF）——一套结构化的、以自评为基础的方法论，供银行评估自身的网络弹性，详情见下文。
专业人才培育计划（PDP）——与香港银行学会及香港应用科技研究院（ASTRI）共同开发的认证与培训体系，旨在为银行业培育一批合格的网络安全从业人员。
网络安全资讯分享平台（CISP）——供银行之间以及银行与HKMA之间分享网络威胁情报的平台，其前提是没有任何单一机构能够独自看清整个威胁全貌。

自2016年以来，HKMA持续完善CFI与C-RAF；业界评论有时非正式地将后续版本称为"C-RAF 2.0"或类似说法。本报告不主张任何具体的当前版本号或修订日期，因为该细节会随时间变化，任何依赖它进行实际提交的读者都应直接向HKMA已发布的材料核实当前要求。自2016年以来，在该框架公开描述中始终保持稳定的，是C-RAF自身的三组成部分结构，详见下文。

为何即便自身并非受监管实体，供应商也会被纳入监管视野

相当一部分发出与本报告所依据的RFP形状相似的公司，本身并不是银行——它们是向银行销售服务、软件或基础设施的公司，或是在相邻的受监管领域运营、希望向提出要求的交易对手展示可比控制态势的公司。SA-2的传导逻辑正是原因所在：如果一家银行自身的外包尽职调查通常会问其供应商"你能否展示你自己的安全运营与证据链"，那么任何向香港银行业销售的公司都有商业上的理由要能可信地回答这个问题——这也让它自身有理由从第一天起就以C-RAF式证据为目标来构建MSP/MSSP安排，而不是等到银行客户的尽职调查问卷送到桌上时才事后拼凑。

C-RAF究竟是什么：三个组成部分，而非一次测试

C-RAF常被非正式地称为"HKMA网络安全评估"，这种说法低估了它实际的内容。按HKMA自身的公开描述，它由三个不同的组成部分构成，依序应用，每个部分产出不同类型的成果。

组成部分一：固有风险评估

固有风险评估确立了一家机构就其本质而言承载了多少网络风险——在考虑其已有的任何控制措施之前。它考察的因素包括机构的科技足迹（连接的数量与类型、交付渠道以及所使用的技术）、其提供的产品与服务（尤其是任何涉及支付或第三方连接的部分）、其组织特征（人员配置、既往事件记录、并购活动），以及其所处的外部威胁环境。产出结果是一个风险等级——通常在公开材料中被描述为低、中、高固有风险分类——决定该机构需要以多严格的程度完成后续两个部分。

组成部分二：成熟度评估

成熟度评估将机构实际的网络安全控制措施与一套既定的控制域进行比对，并按既定的成熟度等级对每个控制域评级（HKMA材料及业界评论中通常将其描述为从基线级别经中级到高级成熟度的递进）。这是最接近传统安全控制评估的组成部分，在结构上与业界其他地方使用的控制域成熟度模型类似，例如美国FFIEC的网络安全评估工具，HKMA自身的框架据公开描述曾从其中获得概念启发。机构在每个控制域所需达到的成熟度等级，会依据组成部分一所确立的固有风险等级进行校准——固有风险高的机构被期望展示出比低风险机构更高的成熟度。

组成部分三：网络攻击模拟测试（CAST）

对于固有风险与成熟度状况使其落入相应范围的机构，C-RAF的第三个组成部分是网络攻击模拟测试——由具备资质、通常独立的测试团队针对机构实际生产环境进行的一场实时、由威胁情报驱动的模拟攻击，旨在复现真实对手的战术，而非一次普通的渗透测试。这在概念上与其他监管机构在国际上使用的、基于威胁情报的红队测试框架相关（英国的CBEST与欧盟范围内的TIBER-EU框架是最常被引用的类似框架），HKMA自身材料也以类似措辞描述它——由情报驱动、基于情景，旨在测试真实的检测与响应能力，而非仅仅罗列漏洞。并非每家机构都被要求运行CAST；它通常仅保留给依据组成部分一与二的风险状况而落入其中的机构，并且理解上需要机构、其内部团队以及其引入的任何外部测试与响应支持之间的密切协调。

这一三部分结构对支持性供应商意味着什么

每个组成部分对支持该流程的供应商提出了不同的要求，将它们混为一谈，是RFP响应中最常见的、夸大供应商实际交付能力的方式之一：

固有风险评估主要是机构自身业务与科技足迹相关的内部工作。供应商在此的诚实贡献，是就其运营或支持的科技环境提供事实性输入——而不是判定该机构的风险等级，那是机构自身应作出的判断。
成熟度评估是供应商能够贡献最多的地方，前提是它对机构的实际技术环境拥有深入的可视性——提供控制措施落实的证据、协助将现有工具与流程与所评估的控制域进行映射，并识别差距。评估仍然是机构自身的评估；供应商提供的是其下的证据与技术基础工作。
CAST在适用的情况下，通常由专业、往往是独立的测试供应商执行，正是因为独立于日常运营对该演练的可信度至关重要——日常运营该环境的MSP/MSSP，通常不是同时模拟攻击它的合适一方，尽管它非常适合担任检测与响应模拟攻击的一方，因为那正是CAST所要测试的响应能力。

拆解三个RFP类别：每一项实际要求什么

RFP的条目用寥寥数语压缩了大量的运营现实。有必要拆解"驻场支持"或"SOC即服务"实际上要求供应商建设与配备什么样的人力与能力。

MSP服务：运营的骨干

托管IT服务与基础设施管理意味着对服务器、网络设备、目录服务以及业务所运行应用程序健康状况的持续负责——不是一个被动响应工单的服务台，而是一个持续监控容量、补丁级别与配置漂移的团队，并针对常规请求与故障均设有明确的服务水平。
驻场支持意味着一种实体在场模式——无论是专属驻场工程师、排班轮值，还是快速派遣安排——用于那些真正无法远程解决的问题类别：硬件故障、网络布线、新办公室搭建，以及监管机构或审计师希望看到真人而非远程会话的场合。
云端支持意味着对机构所运行的Microsoft 365、Azure、AWS或其他云平台组合的运营所有权——身份与访问配置、云端数据的备份（许多机构错误地以为云供应商默认已经处理好这一点）、成本与容量管理，以及云租户本身的安全配置。
备份与恢复服务意味着经过测试、有据可查的恢复能力，而不只是一个运行并报告成功的备份作业。在受监管机构的语境下，这具体意味着供应商能够——以证据而非保证——证明一次恢复确实经过测试，以及耗时多久，因为恢复时间目标与恢复点目标，正是C-RAF成熟度评估或HKMA审查会询问的那种控制细节。

MSSP服务：安全运营层

SOC即服务意味着对整个环境中安全事件的持续（通常是7x24小时，但确切的覆盖模式应在合同中明确规定，而非默认假定）监控，并配有明确的分流与升级流程——真正的SOC与营销标签之间的区别，通常体现在供应商能否展示一份真实的升级手册与真实的历史响应时间数据，而不仅仅是一个仪表盘。
威胁检测与监控意味着一种技术能力——通常是终端检测与响应（EDR）平台，结合日志聚合与关联（SIEM或同等系统）——能够真正看到终端、网络与云端中的异常活动，而不仅仅是收集无人查看的日志。
漏洞评估意味着在机构整个技术资产范围内持续进行（而非一次性）扫描与优先级排序，产出一份被跟踪的整改积压清单，而不是一份被归档束之高阁的时点报告。
渗透测试意味着针对特定系统或网络边界的周期性、有界限范围的对抗性测试——不同于上文讨论的CAST，通常范围更窄、对威胁情报的依赖更少，尽管这两种专业互为补充。
终端安全既意味着预防性工具（防病毒/EDR），也意味着让其在整个设备群中保持部署、更新并实际正常运作的运营纪律——这是一项声称起来容易、但在任何真实设备群中相当比例上悄然失效却屡见不鲜的控制措施。
邮件安全意味着针对钓鱼攻击、商业邮件诈骗与恶意附件的分层防御——值得专门点名的一个类别，因为邮件在业界广泛共识中，仍是C-RAF与HKMA事件报告要求最终关切的那类事件最常见的初始入侵渠道之一。
网络安全意味着防火墙管理、分段，以及对网络边界乃至日益向内部延伸的流量监控，鉴于现代入侵在多大程度上依赖横向移动。
安全意识培训意味着一个持续的项目，而不是一年一度的幻灯片演示——钓鱼演练、可衡量的完成率跟踪，以及随威胁态势变化而更新的内容，因为这是C-RAF成熟度模型与大多数控制框架中，明确期望以持续项目而非一次性完成的任务形式被证明的少数几项控制之一。

监管与网络弹性支持：最需要诚实的类别

这是合法的供应商支持与越界之间的界线最为要紧的类别，值得比一份条目清单更审慎地讨论。

HKMA网络安全相关监管支持，诚实地讲，可以意味着供应商帮助机构理解某项HKMA指引对其技术环境意味着什么，并协助将其转化为具体的技术与流程变更。它不能诚实地意味着供应商以监管或法律权威的身份解读HKMA指引，或在监管层面代表该机构。
C-RAF评估支持，诚实地讲，可以意味着供应商提供技术证据、将现有控制措施与C-RAF的控制域进行映射，并协助机构自身的合规与风险人员理解差距所在。它不能诚实地意味着供应商代表机构完成或证明该评估——按HKMA自身的设计，C-RAF是一项机构董事会与高级管理层需对其负责的自评。
事件响应计划/手册制定与桌面演练支持，诚实地讲，可以意味着供应商协助设计并主持该计划与演练，带来支持过其他事件所积累的模式识别经验。它不应意味着机构将自身事件响应决策权外包出去——无论具体技术响应由谁执行，这一决策权都需要保留在机构自身指定的事件指挥官手中。
文档与证据准备，诚实地讲，可以意味着供应商就其运营与保护的环境，制作准确、带时间戳的技术文档——这可以说是一个运营良好的MSP/MSSP能够增添最真实价值的地方，因为良好的文档与证据本应是环境日常运营方式的副产品，而不是为迎接一次审查而临时拼凑的特别项目。
差距分析与整改建议，诚实地讲，可以意味着供应商依据某一具名框架识别控制差距，并提出其有能力执行的具体整改步骤。它应被呈现为供机构自身风险职能审阅并采纳的一项建议，而不是供应商发出的合规裁定。
协助回应HKMA的查询或审查，诚实地讲，可以意味着供应商提供机构准确及时作答所需的事实性技术信息，并随时解答审查人员针对运营环境提出的技术问题。它不能诚实地意味着供应商代表机构与监管机构沟通，或在那场对话中替代机构自身负责的高级职员。

这对供应商究竟提出了什么要求

要可信地响应一份这种形状的打包RFP，其门槛在实质上高于单独响应一份MSP RFP或一份MSSP RFP，原因有三，均属组织与流程层面，而不仅仅是技术层面。

在组织层面，供应商需要将其托管IT运营与安全运营整合为一个负责的单一职能，而不是两支各自向同一销售部门汇报的团队。当银行的尽职调查团队问及一次事件从检测、升级到整改的端到端流程时，一个需要拼凑两支独立团队各自的独立工具与独立工单系统才能给出的答案，本身就是一项值得注意的控制薄弱环节——而老练的买方会注意到这一点。

在技术层面，供应商的工具需要将证据生成作为日常运营的自然副产品，而不是在审计前临时拼凑的特别项目。如果供应商的备份验证、补丁合规、终端覆盖与访问日志在日常运营中并非已经可查询、可导出，那么在C-RAF成熟度评估或HKMA审查实际提出要求时，该供应商在时间压力下将难以拿出可信的证据。

在流程层面，供应商需要有据可查、在合同中明确的边界，说明其责任在何处结束、客户自身的监管责任从何处开始——这既是为了保护客户，也同样是为了保护供应商自身。一家将自己包装成能让C-RAF或HKMA合规变得"轻松"、或暗示自己能够代客户承担监管风险的供应商，作出的是一个它实际无法兑现的承诺，任何评估此类合同供应商的买方都应将这样的说法视为警讯，而非卖点。

供应商如何在运营上履行双重MSP/MSSP角色

与其抽象地描述这一点，不如具体说明一个一体化MSP/MSSP运营模式在实务中究竟是什么样子，让读者能够想象并对照真实供应商的运营进行核实，而不是单凭信任接受。

一套工单与监控系统，而非两套。 基础设施告警、安全告警与终端用户支持请求进入同一套运营系统，因此处理某起事件的工程师能够在一处看到受影响设备或账户的完整技术历史——其支持工单、补丁状态、近期安全事件——而不需要向另一支使用另一平台的独立安全团队索取该信息。
IT运营与安全之间共享的值班与升级路径。 例如，一起勒索软件事件同时是一起基础设施事件（系统宕机、需要恢复备份）和一起安全事件（遏制、取证、根因分析）——一种将这两者分流给真正独立的团队、各自拥有独立升级链条的运营模式，恰恰会在最需要争分夺秒时损失时间。
在可行之处，由同一代理程序服务于两种职能的终端工具。 让支持工程师能够远程协助用户的同一个轻量级代理程序，也可以是持续、可生成证据的安全态势数据——加密状态、补丁级别、防病毒健康状况——的来源，而无需部署第二个与之争夺同一终端资源的、独立管理的安全代理程序。
一条运营团队与合规/审计相关方都能取用的单一证据链。 会话日志、变更记录与安全遥测数据作为交付服务的副产品持续积累，因此当客户的合规团队需要证明某项控制在某个审查周期内确实有效运行时，证据已经存在，无需事后重新拼凑。

一个具体的交付流程

对于此类打包合同而言，一次站得住脚的交付会经历若干阶段，客户自身的风险与合规相关方应当能够观察并核实这些阶段，而不只是听信供应商的一面之词。

1. 基线发现与固有风险相关的事实调查（通常是最初几周）。 供应商详细盘点科技环境——资产、云服务、第三方连接、数据流——产出机构自身固有风险评估所依赖的事实性输入，而不由供应商自己作出风险等级判断。
2. 依据机构适用框架进行控制映射与差距分析。 现有控制措施（备份、终端保护、访问管理、监控）与相关的C-RAF控制域或机构所选框架进行映射，差距被记录并排出优先级——这是构成机构自身成熟度评估提交内容之下的技术基础工作。
3. 依据优先级差距清单交付整改。 这正是MSP与MSSP职能实际执行的地方——弥合补丁差距、部署或调优终端与邮件安全控制、将备份测试正式化、扩建SOC监控覆盖范围——按机构风险职能可见并可追踪的进度表进行。
4. 制定事件响应计划与手册，随后进行桌面演练。 供应商协助起草或完善该计划，并主持一次针对真实情景进行测试的桌面演练，演练发现被记录下来，并反馈回该计划及更广泛的差距整改积压清单。
5. 持续生成证据的稳态托管运营。 持续的MSP/MSSP交付——工单处理、监控、补丁管理、SOC覆盖——作为正常运营进行，供应商的工具持续产出审计轨迹（会话记录、补丁合规历史、安全事件历史、备份测试结果），供机构合规职能用于其自身的C-RAF成熟度评估更新以及回应HKMA的查询，而无需每次都进行一次特别的证据收集工作。
6. 定期审查与重新建立基线。 鉴于C-RAF自身的各组成部分本就应被定期重新审视（随着机构的科技与产品组合演变，固有风险状况也会变化），此项交付应包含一个周期性节奏——通常为每年一次，或与机构自身的内部审计周期对齐——重新运行差距分析，确认控制环境仍与最近一次记录的内容相符。

本报告不主张的内容

这不是法律或监管建议，也不能替代机构自身的法律顾问、合规职能，或与HKMA的直接沟通。任何依据本报告所述模式采取行动的公司，都应直接向当前的HKMA公开文件核实其具体义务，并在适当情况下寻求合格的法律意见。
本报告不主张任何特定HKMA《监管政策手册》模块当前确切的措辞、编号或修订日期，也不主张C-RAF当前确切的版本或术语。HKMA会随时间修订其指引；此处的结构性描述反映的是持续、公开有据可查的内容，而不是对最新修订具有时效性的主张。
本报告无法接触任何特定机构与HKMA之间的机密监管往来，对任何具体的监管审查、查询或检查在实务中究竟提出了什么要求，不作任何主张。
本报告不主张博讯或任何技术与安全供应商能够代表受HKMA监管的机构完成、证明或提交C-RAF评估，或以其他方式承担该机构自身的监管责任。按照设计，这一责任落在机构董事会与高级管理层身上，任何外包安排都无法改变这一点。
本报告不将"打包采购"这一模式呈现为一项有文献记录的行业统计数据。目前已知不存在此类需要具体数字支撑的香港IT采购结构公开调查。本报告所描述的模式，是基于博讯观察到的香港市场上真实RFP的形态，以及会预测出恰好这类采购行为的监管逻辑（SA-2、TM-G-1）——这是一种经过推理的推断与一项直接的运营观察，而非一项统计数据，也以此方式呈现。
本报告的范围限定于受HKMA监管的认可机构以及向该行业销售的公司。它不涉及保险业监管局或证券及期货事务监察委员会各自平行（且结构不同）的科技风险与外包制度。
本报告不主张监管压力是打包模式的唯一成因。常规的采购效率考量——更少的供应商关系、更少需要续签的合同、单一的问责点——很可能是一个真实存在、与之并存的动机，本报告并不试图权衡各成因的相对贡献。

博讯如何交付这一切

博讯是一家总部位于新加坡的托管IT与网络安全服务供应商，在香港设有稳固的办事处（自2016年起在该地区运营），其渊源可追溯至2007年在北京的创立。博讯的两项运营特点与本报告所描述的模式直接相关，两者在此均以可核实的运营事实、而非营销话术的方式加以描述。

第一，博讯将托管IT服务与网络安全服务作为一体化运营来运行，而不是在合同签署时才拼凑起来的独立业务线。这正是本报告所论证的、一份打包MSP/MSSP/监管支持合同要具备可信度所实际需要的组织模式——具体这种整合如何构建，参见托管IT与安全服务；底层的支持交付方案与覆盖模式，参见托管IT支持。

第二，博讯自有的终端平台BCS Beam，恰好生成了本报告所描述的、对C-RAF相关文档具有价值的那类证据性副产品——这是提供远程支持与终端安全监控的正常功能的一部分，而不是一次特别的合规演练。BCS Beam促成的每一次远程支持会话，都会被写入一份审计台账，记录谁连接了、连接到哪台设备、何时连接、以何种模式连接，以及对应哪张支持工单；同一代理程序的安全健康侧则持续检查磁盘加密、防病毒与防火墙状态、补丁态势，以及针对CIS对齐基准的已知漏洞暴露情况，产出可报告的、按设备划分的证据，而不是一次性的时点证明。这种连接层面与态势层面的审计轨迹，正是本报告所论证的、供应商要负责任地支持C-RAF相关文档工作所需要的"证据作为正常运营的副产品生成，而非在审计前拼凑"这一原则的一个直接、具体的例子。

与本报告始终明确的边界保持一致：博讯并非HKMA持牌机构，也不受HKMA监管，也不会代表任何客户，承担该客户自身在C-RAF完成、证明或与HKMA正式沟通方面的监管责任。博讯在一份打包MSP/MSSP/监管支持合同中的角色，是技术执行、证据生成，以及文档与差距分析支持——由一支一体化团队交付，而不是由一堆彼此割裂的工具与供应商拼凑而成。