摘要

  • ICANN 风险委员会 2025 年 12 月的会议纪要明确记载：拟议章程把内部审计活动评估的时间要求从“五年”改为“定期”。
  • 2026 年 7 月通过的现行章程要求依照专业标准开展外部评估；ICANN 已说明其内部审计职能采用 Global Internal Audit Standards，而该标准第 8.4 条仍规定至少每五年评估一次。
  • 2025 年 8 月 25 日，风险委员会批准内部审计职能章程，这是公开材料中最有力的计时起点候选。只有在该前提成立且此后没有评估重置周期时，外部上限才可条件式推算为 2030 年 8 月 25 日。
  • ICANN 无须公开敏感审计底稿，只需发布一个最小化的标准与鉴证台账，记录版本、采用行为、推算期限、评估方式、独立性、结论和整改状态。

被删掉的是数字，不一定是期限

治理文件最容易造成误读的地方，往往不是它明确拒绝了什么，而是它把一个可计算的条件挪到了别处。

ICANN 风险委员会 2025 年 12 月 8 日会议纪要留下了一条罕见而具体的线索。委员会当时继续审议自身章程修订稿。纪要列出四类调整：重新排列条文；让内部审计监督用语与专业标准对齐；使职责表述更符合实际流程；以及把内部审计活动评估的时间要求从“五年”改成简单的“定期”。

ICANN 董事会后来通过了2026 年 7 月 20 日版风险委员会章程。现行文本没有出现“五年”，而是要求委员会确保内部审计活动接受定期外部评估，并遵循专业标准。

若只看到这两个页面，结论很容易滑向指控：一个可以核算、可以逾期的期限，被一个没有数字的形容词取代。五年有截止日，“定期”却可能被解释成任何间隔。

但“定期”后面还有半句话——依照专业标准。引用外部规范的条款，不能只读引用动作，不读被引用的内容。真正的问题因此变成：是哪一套标准、哪一个版本、从哪一天开始适用，它又如何定义“定期”？

沿着这条链继续查，故事出现了反转。五年没有消失，它只是离开了委员会章程的正文。

两份“章程”不能混为一谈

这一问题涉及两份名称相近、功能不同的文件。

风险委员会章程分配董事会层面的监督权：委员会可以审查什么、批准什么、接收什么、向董事会建议什么。内部审计职能章程则定义审计职能本身的使命、权限、独立性、汇报关系和专业依据。前者是监督机关的权限边界，后者是被监督职能的运行宪章。

2025 年 3 月 13 日董事会决议说明了制度起点。董事会把内部审计列为风险委员会的新监督领域。理由是 ICANN 的规模和复杂性增加，内部审计的范围可能超出财务控制与报表，因此风险委员会比单纯的财务审计委员会更适合承担这一工作。

2025 年 3 月通过的风险委员会章程体现了初始安排。委员会向董事会建议内部审计人员的选任；如采用外包模式，委员会定期检查服务商的表现、资格和独立性，并向董事会建议续用或解聘。委员会还审查内部审计职能的独立性、权限、计划、范围和预算，接收已完成审计的发现与计划进度。

这份已经通过的 2025 年章程并没有写外部质量评估，也没有写五年周期。因此，不能把 2026 年修订描述成废除了上一版章程里已有的五年条款。12 月纪要所说的“五年”，存在于之后的修订草案中，而该草案的完整红线版本并未出现在本次核验的公开材料里。

证据允许得出的结论更窄，也更可靠：某个拟议文本曾使用五年要求；委员会把它改成依照专业标准的定期评估；董事会最终通过了后者。

“专业标准”把五年重新带了回来

外部标准的身份并不神秘，ICANN 自己的会议纪要已经给出答案。

在2025 年 6 月 30 日风险委员会会议上，管理层提交了内部审计职能章程草案。纪要说，草案包含职能的目的、使命、权限、责任、独立性、汇报关系、范围，以及对 Global Audit Standards 的符合要求。同一份纪要还明确表示，内部审计手册与方法采用 Global Internal Audit Standards，并结合其他领先框架。

经过修订与管理层反馈后，委员会在2025 年 8 月 25 日批准了内部审计职能章程。当日还批准了 ICANN 对主要和备用内部审计服务商的建议，以及方法体系的总体结构。

IIA 发布的 Global Internal Audit Standards于 2025 年 1 月 9 日生效。第 8.4 条对外部质量评估的要求非常具体：首席审计执行官必须制定评估计划并与董事会讨论；评估至少每五年进行一次；评估者或团队必须具备资格并保持独立；也可以用“自我评估加独立验证”的方式满足要求。

标准还要求董事会参与范围和频率的讨论，批准计划，直接接收完整结果，批准针对缺陷的行动方案，并监督完成进度。换言之，五年只是外边界，不是全部控制。真正的制度包含计划、独立挑战、结果直达和整改闭环。

所以，“定期”并不天然意味着没有期限。如果 ICANN 所采用的正是这套标准，五年上限仍然约束整个系统。章程只是把数字隐藏在引用关系里。

时钟从哪一天开始

任何五年期限都需要一个零点。

IIA 的质量鉴证说明指出，周期从内部审计职能正式采用标准时开始。可用的证据包括审计委员会会议纪要、内部审计章程更新以及符合性表述。

ICANN 的公开时间线提供了一个相当有力、但尚不能视为最终认定的日期。2025 年 6 月，内部审计职能章程仍是草案，委员会要求继续修改。8 月 25 日，委员会批准了它。6 月纪要已经说明，该章程包含对全球审计标准的符合要求。

如果 8 月 25 日的批准就是第 8.4 条意义上的正式采用行为，而且此后没有完成外部评估并重置周期，那么首次外部上限可以推算到 2030 年 8 月 25 日。

这里的每个条件都必须保留。公开材料没有附上获批内部审计职能章程全文，也没有一份 ICANN 发布的标准采用台账。可能存在另一项更早或更晚的正式行为，也可能存在影响周期的评估。ICANN 并未在本次核验的资料中宣布“2030 年 8 月 25 日”为正式期限。

这并不是推算失败，而是透明度边界。制度不应让外部读者靠拼接三份纪要来找到零点。采用日期与周期重置规则属于治理元数据，不属于必须保密的审计发现。

新章程同时改变了批准权的距离

盯着“五年”与“定期”，容易错过 2026 年章程更实质的变化。

旧章程让风险委员会向董事会建议审计人员的选任以及外包服务商的续用或解聘。新章程则写明，委员会依据内部审计负责人的建议，审查并批准外包内部审计服务商的选择或续聘。它还审查并批准拟议的审计范围、计划及相关预算，并要求使用基于风险的方法。

委员会获得的信息面也更宽。除了已完成审计的发现和计划偏差，新条文还包括重大风险暴露、控制问题、治理关切以及管理层整改状态。

12 月纪要同时记载，委员会讨论了如何澄清：对于提交董事会批准的建议事项，董事会保留最终批准权。现行章程在总体风险偏好问题上明确采用“委员会建议、董事会批准”的结构；在内部审计计划与服务商条款中，则直接使用委员会“批准”的措辞。

这不能证明董事会放弃了公司治理中的剩余权力，却足以说明为什么状态记录必须写明批准者和权限来源。只写“已批准”，而不写是谁依哪一条规定批准，仍然会让权限边界模糊。

为“定期”辩护的最强理由

把外部标准中的每个数字抄进委员会章程，未必是最稳健的治理。

专业标准会更新。若 IIA 改变评估频率、资格条件或验证方式，而 ICANN 章程仍保留旧句子，两个文本反而会冲突。引用专业标准能够吸收一整套要求，也允许组织在领导层、服务商、方法或风险状况发生重大变化时提前评估。

这一辩护成立。第 8.4 条的价值远超过一个五年提醒。它把董事会参与、评估者独立性、结果直达和整改责任连接起来。章程不必逐字重复这些内容。

但动态引用有一个不可免除的成本：版本纪律。ICANN 必须说明新版本是自动纳入，还是需要新的内部采用行为；必须保存每个期间实际适用的文本；必须记录哪次评估或哪项修订改变了下一到期日。

否则，灵活性会变成事后选择标准的能力。今天的解释可以把昨天的义务重新包装，而公众无法确认当时真正生效的规则。

最强的辩护因此不是反对台账，而是支持台账。

目前的证据没有证明违规

2026 年 7 月 20 日董事会决议把修订解释为让章程符合当前治理要求与实际做法。在此之前，董事会治理委员会于 6 月 30 日建议通过。ICANN 的风险委员会页面也已把 2026 年版本标为现行章程，把 2025 年版本列为已被取代。

内部审计职能本身仍在成熟。2026 年 5 月 29 日会议纪要说，最新风险登记将用于识别审计对象总体、制定基于风险的审计计划和多年规划；外包服务商安排仍在最后讨论。

这些材料没有证明评估逾期，也没有证明计划不存在，更没有证明服务商缺乏独立性。即便采用 2025 年 8 月作为起点，推算的外部上限也尚有数年。

目前可以确认的问题只是：公众无法从一个权威页面直接找到标准版本、正式采用日期与下一外部期限。弥补这个缺口，不需要披露任何具体控制弱点。

一份小台账足够

标准与鉴证台账不应成为审计底稿仓库。它只需要记录可验证的制度状态。

第一组字段是规则：标准制定机构、标准全名、条款、版本、发布日期、生效日期。第二组是采用：ICANN 内部采用文件、作出决定的机关、采用日期、开始或重置周期的事件、推算的最晚日期以及更早的内部目标。

第三组是评估：选择完整外部评估，还是自评加独立验证；已批准的范围和频率；评估者资格；独立性与利益冲突审查；谁在何时批准计划。

第四组是处置：完成日期、评估方式、哪个机关直接收到结果、可公开的符合性等级或有限结论、是否存在整改、责任人、期限与关闭状态。

敏感系统、可被利用的控制缺陷、个人资料、法律特权内容和详细测试步骤可以继续保密。公众需要的不是底稿，而是义务确实进入了独立评估并产生可追责处置的证据。

最后，台账必须保留历史。新标准、新章程或已完成评估可以改变时钟，但不能覆盖旧记录，仿佛过去从未受另一版本约束。

时钟其实是一条权限链

最终日期只是整条链最容易看见的一端。

IIA 制定最低要求。ICANN 正式采用。内部审计负责人制定计划。委员会与董事会分别作出授权行为。独立评估者检查职能。管理层回应缺陷。委员会监督整改。下一次评估或标准更新重新计算周期。

任何一个节点失去日期、作者或权限依据，时钟都会失真。没有采用行为的五年只是数字；没有版本的采用无法解释；没有独立性的评估只是自我陈述；没有整改责任人的结论只是仪式。

“定期”可以留在章程里，但它背后的现实状态必须能够被验证。