ICANN的GRC招标集中记录，不集中风险权力

摘要

ICANN于8月5日发出征求建议书，希望采购一套整合政策管理、企业与第三方风险、内部审计、合规、仪表盘和自动证据采集的SaaS平台。公开时间表要求9月11日前提交方案，目前没有证据显示已经选定供应商、签约或上线。
统一记录不能抹平风险拥有者、控制执行者、证据采集者、测试者、整改负责人和董事会监督者的区别。可迁移的权责—证据对照表，应为每个系统状态保留角色、授权依据、证据来源、质疑与更正历史。

“已关闭”是一个记录状态，不是一项自动生效的权力。

当所有人都看同一块屏幕时，这个区别最容易消失。ICANN在8月5日发布Governance, Risk, and Compliance解决方案招标，希望把政策文件、企业风险登记、第三方评估、内部审计、合规框架、报告和自动采集的证据纳入一个全球可用的托管服务。ICANN称，现有工作分散在多个职能部门，流程大多依赖人工，文档又存放在不同位置，因而影响效率、跨部门可见度和一致性，并增加版本管理风险。

建立共同底账有明显价值。同一项控制不必在三张表中拥有三个名字；审计发现转到业务团队之后，不会与整改责任人脱节；政策审批不再取决于读者碰巧打开哪一份“最终版”；分布式团队也可以使用同一组风险标识。

真正的治理问题出现在第二步：平台里的“已接受”“有效”“已整改”“在风险偏好范围内”，会不会逐渐被当成决定本身？这些词不是纯粹的文书事实。它们是特定角色在一定范围和期间内，根据可能不完整、可能受质疑的证据所作判断。

软件可以做记账人，不能因此成为委托人。

现在仍处于采购阶段

公开项目概览列出的范围很宽。政策管理覆盖起草、审查、批准、发布和流程自动化；企业风险管理要与COSO、ISO 31000对齐，让分散团队使用集中风险登记；第三方风险包括评估、监测与文档；内部审计包括计划、执行、发现、整改跟踪与报告；合规功能覆盖ISO/IEC 27001、SOC 2、SOC 3和隐私要求的映射；集成能力还可在适当情况下持续监测控制并自动收集支持材料。

高层业务要求包括全球可用的全托管SaaS、ISO 27001认证环境、高可用性、基于角色的权限、审计轨迹、API与集成、实施、支持和培训。选择标准则包括功能、自动化、报告、易用性、支持、财务健康、价格、客户参考与利益冲突缓解。

这些是竞争条件，不是已经实现的成果。方案提交截止时间是9月11日23时59分（UTC），评估预计在9月14日至11月13日进行，尽职调查、谈判和可能的授标从11月16日以后开始。ICANN有权修改时间表、拒绝方案、撤回招标或不授标。现有资料没有胜出供应商，也没有已部署平台。

公开概览还明确说明，完整RFP包括SciQuest/Jaggaer采购工具内的补充材料。因此，公众可以追问数据可迁移性、退出协助、数据归属、保留删除、事件处理和证据沿袭如何保障，却不能因为概览没有逐项写出，就断言受限材料、投标方案或未来合同里缺少这些条款。

平台进入的是一张既有权力地图

ICANN在2022年10月发布的风险管理框架概览称，总裁兼首席执行官拥有组织层面的全部风险，并把具体风险的职能责任委派给相关高管；Risk Management职能负责推动框架，本身并不拥有风险；最接近风险来源的职能保留责任；管理层委员会审阅报告和行动计划；董事会及其Risk Committee监督风险框架和组织接受的风险类型与程度。

这份文件反映的是2022年，不能证明每项操作细节到2026年都没有变化。但2026年7月20日获批的现行Board Risk Committee章程确认了当前主要边界：委员会监督风险识别、评估、排序、缓解、风险偏好和容忍度；在内部审计方面，它批准范围、计划和预算，审查外部服务方独立性，接收发现，并接收管理层整改行动的状态报告。

2025年2月的会议记录也用很直接的方式记录了当时的分工：委员会监督审计计划、执行和结果，管理层负责依据发现采取整改行动。

这些角色不能被平台压缩成一个笼统的“用户”。管理风险流程，不等于拥有风险；测试控制，不等于执行控制；监督整改，不等于亲自整改；关闭任务，也不等于推翻原来的审计判断。集中可见度应让差异更清楚，而不是更模糊。

自动采集仍要回答“证明什么”

自动证据采集并非坏事。人工截图和复制导出速度慢、标准不一，也容易丢失来源、覆盖范围与有效期间。连接身份系统、工单平台或云环境的采集器，可以更稳定地保存时间与重复测量。

但证据永远需要一个待证明的命题。停用账户清单可以支持某项离职访问撤销测试，却不能证明所有剩余特权都经过恰当批准；配置值可以显示某项机制存在，却未必覆盖例外系统；工单关闭能证明做过事情，不能单独证明整改有效；实时更新的屏幕，也可能仍在展示陈旧的风险假设。

真正需要记录的是：证据支持什么判断、覆盖哪个总体和期间、来自什么查询或转换、有哪些例外、由谁以何种权力审阅。持续采集提高频率，不能自动生成相关性和判断。

给每个状态配一份权责—证据回执

ICANN不需要向公众开放敏感风险数据库。它需要在受保护系统里，把记录与使记录成立的机构行为连接起来。

每项重大风险、控制、例外、审计发现或整改，应有稳定标识，并写明负责职能和角色，以及正在行使的权力类型：拥有、评估、批准、接受、测试、质疑、监督或整改。记录还应指向产生该项权力的政策、风险偏好声明、审计计划或决策文件。

同一份回执应保存判断的范围与期间，以及证据来源：源系统、采集器或查询、数据转换、时间戳、版本、覆盖度和审阅者。例外和相反证据不能在状态更新时消失。任何变更都要说明谁以什么角色、何时、依据什么理由行动，以及后来如何质疑、更正或取代。

供应商和管理员也要进入轨迹：特权访问、配置修改和证据转换都应可审计。退出时，导出必须保留标识、关系、决策事件与更正历史，使另一系统和独立审阅者仍能理解。若只得到一堆PDF，却丢失文件之间的意义关系，那不是可迁移性。

这份“权责—证据对照表”是Daniel Kade提出的治理控制，不是ICANN已宣布的采购要求。它的目标是让平台保持轻薄：善于保管、编排和检索，却不能吸收使用它的机构和人员所拥有的权力。

对外公开权力结构，不公开敏感风险

问责不等于公开风险登记、漏洞、审计工作底稿、原始控制证据、第三方安全细节、个人资料、法律意见或敏感整改方案。公开层可以回答更克制的问题：权力地图是否获批；风险拥有者是否与流程管理员、证据采集者分开；内部审计能否独立报告和质疑；证据来源与更正历史是否经过测试；脱离现有界面后，完整历史能否被重建；特权访问是否接受独立复核。

逾期整改可以按汇总方式提交给适当监督机构，而无须泄露具体风险。公众需要确认的，是软件状态不能悄悄替代负责任的决定。

集中化用于连接事实时很有价值；若把治理上有意分开的角色合并，就会制造新的权力。未来真正的验收问题不是仪表盘是否漂亮，而是离开平台之后，能否继续回答四件事：谁有权、决定了什么、依据什么证据、谁能质疑或更正。答案若能脱离界面存续，平台就在服务治理；答案若只存在于当前状态，记账人就已经开始改写宪章。

ICANN的GRC招标可以集中记录，不能集中风险权力

为何重要