合规指南
72 小时这个数字是真实的，而且其范围比通常报道的更窄。它来自 VARA《技术与信息规则手册》规则 I.K.1，从发现时开始计算，并由两类特定事件触发。凡涉及个人数据时，另一个更短的 24 小时时钟会同时启动。
2026 年 7 月 14 日更正：本文早前版本将这些规则归入《公司规则手册》（它们实际上在《技术与信息规则手册》中），称 BCDR 计划必须涵盖七个领域（规则 I.H.1 列出八个），并引用了一段声称时钟从事件发生时而非您发现事件时开始计算的文字。规则 I.K.1 从发现时开始计算。此前编造的“重大”事件类别清单和编造的报告模板，已替换为规则原文。
规则全文
《技术与信息规则手册》规则 I.K.1 只有一句话，其中每一部分都很重要：
“除《合规与风险管理规则手册》中的相关要求外，一旦发现发生以下任何情形：（i）重大网络安全事件，或（ii）触发实施 BCDR 计划且对 VASP 业务运营产生重大影响的事件，VASP 应在合理可行的情况下尽快向 VARA 报告该事件，并且无论如何不得晚于自发现起七十二（72）小时，报告应包含该事件性质、范围和影响的所有相关详情，以及 VASP 正在或将要采取的用于缓解该影响的步骤，包括但不限于是否已向 VARA 以外的主管机构作出任何通知或报告。”
这句话可以拆出四点。
- 时钟从发现时开始。无论事件实际何时开始，也无论您何时对其进行分类或确认，72 小时都从发现那一刻起算。
- 72 小时是最后期限。首要义务是“在合理可行的情况下尽快”。72 小时是在此之上的外部上限。七十二小时看起来很宽裕，直到您把批准步骤也算进去。若一份报告在对外提交前需要 CISO、法务审阅和签批，就必须在调查仍在进行时开始起草；任何计划在最后一天上午才动笔的人，最终提交的内容都会很单薄。
- 有两个触发条件。重大网络安全事件，以及另一个独立情形：任何触发 BCDR 计划且对业务运营产生重大影响的事件。第二个触发条件与攻击者无关。数据中心故障导致提现下线，即使没有人攻击您，也可能需要报告。
- 报告有明确的内容清单。事件的性质、范围和影响，您正在采取或将要采取的缓解步骤，以及是否已向 VARA 以外的主管机构作出任何通知或报告。最后这一项经常被遗漏。
“重大”的含义：规则手册没有定义它，也没有发布任何 VARA 认可的合格事件类型清单。任何给您一份清单的人，都是自己编的。规则手册确实提供了一个边界更硬的相邻义务，见《合规与风险管理规则手册》规则 I.I.2：“VASPs shall submit a report to VARA immediately upon the discovery of any violation or breach of any law, Regulation, Rule or Directive related to the conduct of any VA Activity.” 重大性需要由您判断并形成文档记录，并且您应预期需要为该判断而非结果进行辩护。让这个词保持未定义，是可以辩护的起草方式。封闭式的合格事件清单会被规避，也会很快过时。成本落在您身上：写下您适用的重大性测试，保持一致适用，并接受这样一个事实：第一次在压力下使用它时，会让人感到不适。
VASP 实际运行的多个时钟
72 小时规则最容易成为标题。它不是规则手册中唯一的通知截止期限，也不是最紧的一个。
| 截止期限 | 规则 | 触发条件 |
|---|---|---|
| 发现后 72 小时内 | TIR I.K.1 | 重大网络安全事件，或触发 BCDR Plan 且对业务运营产生重大影响的事件。 |
| 24 小时 | TIR II.C.2 | 从您就影响或可能影响个人数据的事件通知数据监管机构或数据主体时开始计算。随后，您有 24 小时通知 VARA，并附上该报告的摘要；如果监管机构位于 UAE，还需附上报告副本。 |
| 一经发现立即 | CRM I.I.2 | 与开展 VA Activity 相关的任何法律、Regulation、Rule 或 Directive 的任何违规或违约。 |
| 立即 | Company Rulebook VI.F.1 | 未能维持实缴资本、净流动资产、保险或储备资产，并须每日向 VARA 更新，直至该未达标事项得到纠正。 |
请仔细阅读 Rule II.C.2，因为其触发条件是您对其他人的通知。24 小时从您通知数据监管机构或数据主体时开始计算。因此，如果您在调查第 5 天通知 UAE Data Office，VARA 必须在此后 24 小时内收到您的通知，这与您在第 3 天依据 Rule I.K.1 提交的内容是相互独立的。这个组合常常让原本运转良好的团队出错，因为第二个计时在只跟踪事件本身的事件时间线上并不可见。请把该触发条件放入运行手册中，紧邻隐私通知步骤，这样发送其中一项通知的人会被提示发送另一项通知。
BCDR Plan：八个必备领域，而不是七个
Rule I.H.1 要求 VASP “implement, maintain, test and update on an annual basis an adequate Business Continuity and Disaster Recovery Plan”。该规则随后列出了该计划必须涵盖的领域。共有八项，标注为 (a) 至 (h)。
| 编号 | 领域 | 规则 I.H.1 的要求 |
|---|---|---|
| (a) | 触发事件 | 可能触发实施 BCDR 计划的事件，例如网络安全事件和技术故障，以及用于评估事件性质、范围和影响的程序。 |
| (b) | 资源要求 | 包括高级管理层和员工、系统及其他资产。 |
| (c) | 恢复优先级 | 适用于 VASP 的运营，包括保护必要数据和关键职能，并维护这些数据和职能。 |
| (d) | 沟通安排 | 面向受影响的内部和外部相关方。 |
| (e) | 完整性验证 | 用于验证任何中断所影响信息完整性的流程。 |
| (f) | 运营影响缓解和职能转移 | 用于缓解运营影响并转移运营职能的程序，包括将响应和恢复活动升级至指定人员和管理层。这是按通用 IT 模板编写的 BCDR 计划中最常缺失的领域。 |
| (g) | 备用场所 | 足以在合理期间内恢复并持续运营的备用场所。 |
| (h) | 事件后补救 | 在稳定运营恢复后，用于补救已识别或已被利用的漏洞，或升级相关协议，以防止类似事件发生的程序。 |
请注意规则中没有什么。规则没有提到恢复时间目标和恢复点目标。也没有提到季度故障切换测试、强制的可用性数字，或规定的桌面推演频率。测试义务是年度性的，并且适用于整个计划。设定 RTO 是良好实践，也是满足 (c) 中恢复优先级要求的自然方式，但不要告诉自己 VARA 要求必须设定 RTO，也不要因为某个模板没有 (f) 就跳过它。对了解业务的人来说，围绕这八个领域起草计划需要几周时间。每年测试一次，并如实记录哪些地方失败，才是真正耗费时间的部分，也是 VARA 可以要求查看的部分。
DLT 部分是“should”，并点名了三件事
规则 I.H.2 规定，BCDR 计划“should take into consideration and address factors and issues specific to Virtual Assets and DLT including, but not limited to, network malfunction, loss of data or compromise in data integrity, and key storage and maintenance of authorisation layers”。
这里点名了三类事项，其表述是指导而非硬性要求，并且是开放式的。分叉处理、跨链桥漏洞利用和共识停滞都是值得规划的合理场景，也完全可以纳入这些类别之内，但它们是您自行选择的示例，不是 VARA 写入规则的要求。应在您的计划中说明这一点。声称 VARA 强制要求分叉策略的 BCDR 计划，是在引用一条并不存在的规则。
看不见时钟，就无法启动时钟
72 小时从检测到事件起算，这使检测能力成为关键支撑控制措施。《技术和信息规则手册》附表 1 风险类别 3 列出了 VASP 应满足的七项标准。这是关于技术治理和风险评估框架的指引，而不是第 I 部分中的规则，但它最清晰地表明了 VARA 期望 VASP 具备哪些能力。
| 标准 | 附表 1 的预期 |
|---|---|
| 交易监控 | 通过行为分析发现异常模式，基于规则监控已知可疑活动，运用机器学习能力进行高级威胁检测，对可疑交易进行实时告警，并定期优化检测方法。 |
| 内部用户活动监控 | 认证尝试和失败、用于发现内部人威胁的模式分析、对敏感或关键系统访问及管理活动的监控，以及将监控职能与运营团队隔离。 |
| 增强监控 | 针对开发人员系统和签名系统：进程创建和终止、网络连接分析、文件系统变更检测、软件安装和执行控制，以及用户行为分析。 |
| 战术加固 | 在检测到入侵后快速限制攻击者的能力：紧急撤销访问权限，包括单个终端，网络分段，系统隔离程序，预先批准的紧急变更程序，以及对这些能力进行定期测试。 |
| 调查能力 | 专门的取证资源，无论内部还是外包，能够实时或接到即时通知后部署和响应，安全收集证据，形成保管链文档，采用根因分析方法，并开展定期培训。 |
| 链上分析 | 交易追踪工具、钱包归因、与其他 VASP 合作追踪资金，以及定期发展能力。 |
| 补救 | 事件发生后，对所有秘密组件进行完整轮换，包括密码、密钥和密钥分片；基于安全基线重建系统；事件后增强监控；正式验证攻击者已被清除；并进行事件后复盘。 |
补救标准值得反复阅读。它要求在事件发生后“对所有秘密组件（包括但不限于密码、密钥和密钥分片）进行完整轮换”。不是只轮换被攻破的那些。是全部。写起来容易，在事件过程中执行起来却非常艰难。如果您从未演练过完整轮换，就不知道需要多长时间，也不知道会破坏什么，因此它更适合作为您下一次演练的内容，而不是策略中的又一段文字。
这对您的事件程序意味着什么
以下每一项都可追溯到规则。以下没有任何时间表是某个人自行编造的。如果您本周只做一件事，就先做第一项。添加一个检测时间戳字段只需要一个下午的工具配置，但它决定了之后关于及时性的每一次争论是否有胜算。
- 将发现时间戳作为一等字段记录。 72 小时从该时间开始计算，因此它是事件记录中最重要的元数据。如果您无法提供发现时间的证据，就无法证明您按时报告。
- 明确作出重大性判断并标注日期。 规则手册没有给出定义，因此可辩护的材料是一项有记录的决定，由具名人员作出，并说明理由。
- 按照规则的内容清单起草。 性质、范围、影响、已采取或计划采取的缓解措施，以及是否已通知其他主管机构。
- 不要等待确定性。 义务是在合理可行的情况下尽快报告，并且无论如何不得晚于 72 小时。该规则并未将调查完成作为报告条件。
- 将 24 小时时钟与通知其他人的行为联动。 一旦数据监管机构或数据主体被告知，单独的 VARA 截止期限即开始计算。
- 确保可检索证据。 规则 I.E.3 要求测试和审计的证据须“由 VASP 记录成文，并在 VARA 要求时立即提供给 VARA 检查”。
- 每年测试 BCDR 计划并保留记录。 规则 I.H.1 将测试列为强制性义务的一部分。
常见问题
VARA 的 72 小时时钟何时开始？
从发现时开始。《技术与信息规则手册》规则 I.K.1 要求在“发现”事件时报告，并且“无论如何不得晚于发现后七十二（72）小时”。它不是从事件开始时计算，也不是从您分类或确认事件时计算。底层义务是在合理可行的情况下尽快报告，72 小时是最外层期限。
哪些事件必须在 72 小时内向 VARA 报告？
规则 I.K.1 下有两类：重大网络安全事件，以及触发 BCDR 计划实施并对 VASP 业务运营产生重大影响的事件。第二类不要求存在攻击者。规则手册没有定义“重大”，也没有发布符合条件的事件类型清单。
向 VARA 提交的报告必须包含什么？
规则 I.K.1 要求包含“此类事件的性质、范围和影响的所有相关详情，以及 VASP 正在或将要采取以缓解该影响的措施，包括但不限于是否已向 VARA 以外的主管机构作出任何通知或报告”。
个人数据事件是否有单独的截止期限？
有，而且更短。规则 II.C.2 要求 VASP 在向数据监管机构或数据主体通知任何影响或可能影响个人数据的事件后，“尽快并且无论如何在二十四（24）小时内”通知 VARA，并附上该报告的摘要；如果监管机构位于 UAE，还须附上报告副本。
BCDR 计划必须覆盖多少个领域？
八个，在规则 I.H.1 中以 (a) 至 (h) 标示：触发事件、资源要求、恢复优先级、沟通安排、完整性验证流程、缓解运营影响并转移运营职能的程序、替代场所，以及事件后补救程序。
BCDR 计划必须多久测试一次？
每年一次。规则 I.H.1 要求 VASP “每年实施、维护、测试并更新充分的业务连续性和灾难恢复计划”。规则手册没有规定测试方法、季度故障切换测试或恢复时间目标。
在 Venvera 中运行这些时钟
Venvera 不提供 VARA 框架模块，因此没有预加载的 VARA 72 小时计时器。平台提供的是这些时钟所需的机制：
- 事件登记册记录事件及其通知截止期限，并显示每个报告步骤的剩余小时数，同时标记逾期步骤（已在产品中验证）。预加载的监管时间线包括 EU DORA 和NIS2，因此 VARA 72 小时或 24 小时截止期限会作为您在事件上设置的截止期限进行跟踪。
- 主管机构报告生成器会根据已记录的事件数据，为监管机构生成事件报告，因此事件性质、范围、影响和缓解叙述只需汇总一次（已在产品中验证）。
- 证据库保存 BCDR 测试记录和审计报告，即 Rule I.E.3 要求在被请求时必须立即提供的资料（已在产品中验证）。
- 董事会视图报告未关闭事件和逾期行动，这使未经测试的计划能在事件发生前就被看见（已在产品中验证）。
如果您希望快速了解自身韧性计划的现状，请运行一次免费合规检查。
主要来源
以上每项截止期限均引用自 VARA 已发布的规则手册。在依赖特定规则前，请确认当前文本。
- 《技术与信息规则手册》，第 I 部分 K 节：向 VARA 通知 - Rule I.K.1，自检测起 72 小时截止期限。
- 《技术与信息规则手册》，第 I 部分 H 节：业务连续性、网络安全事件与风险 - Rule I.H.1，八个 BCDR 领域，以及 Rule I.H.2，DLT 因素。
- 《技术与信息规则手册》，第 II 部分 C 节：向 VARA 提供信息 - Rule II.C.2，24 小时个人数据截止期限。
- 附表 1，风险类别 3：检测与响应 - 七项检测、调查和补救标准。
- 《合规与风险管理规则手册》 - Rule I.I.2，对任何违规或泄露进行即时报告。
最后更新：2026 年 7 月。本文为一般信息，不构成法律意见。请向 VARA 或合格法律顾问确认您的义务。
