《数字运营韧性法案》（DORA）适用于欧盟范围内的银行、保险公司、支付机构、加密资产服务商，以及它们的关键 ICT 供应商。与你自愿采纳的框架不同，DORA 是一部带有明确生效日期的法规——它自 2025 年 1 月 17 日起已开始适用。大多数合规团队把它读作一项日志记录与事件报告的要求。若读得更仔细，它同时也是一项证据要求，而缺口恰恰落在证据这一半上。
第9条究竟要求什么
DORA 第9条要求金融实体落实相应的策略与工具，确保数据的“真实性、完整性、可用性和保密性”——包括用于重建事件的日志和审计追踪中的数据。监管层面的期望并不是你保留了这些记录，而是当监管机构或处置当局问起时，你能够证明这些记录就是原始记录、未经篡改。
大多数实现方式里都暗含一个无声的假设：生成日志的系统，同时也是该日志完整性的可信见证者。DORA 的韧性视角打破了这一假设。如果 ICT 系统本身已被攻破——而这正是 DORA 存在所要应对的场景——那么它对自身日志完好无损的自我背书，几乎一文不值。
“我们记录了一切”为何不够
全面的日志记录是必要的，大多数受监管机构也做得不错。缺口出现在监管者最在意的三个时刻：
- 事件后重建——DORA 期望你重建事件发生的顺序。如果日志就存放在被攻破的系统内部，那么这种重建所依赖的数据，攻击者本就有可能动过手脚。
- 第三方与 ICT 供应商记录——DORA 的适用范围延伸至关键供应商。当双方都能对照一个共享的、外部的参照点进行验证，而非互相交换日志导出文件时，证明供应商的记录完好无损就容易得多。
- 独立举证——监管机构没有义务凭你一面之词，相信你的留存与不可篡改控制确实生效了。任何人都能对照外部锚点加以验证的完整性，能把一句声明变成可被证实的事实。
截止日期已过——为什么这仍是一个采购触发点？
2025 年 1 月是适用之日，而非执法的终点平台期。监管当局在第一年里主要用于梳理受监管实体、评估基线。如今正在发生的转变，是从“你有没有制度”转向“把证据拿给我们看”——而后一个问题，正是完整性证明能直接回答的。
率先行动的机构，并不是日志记录做得最差的那些，而是那些审计师和监管机构已开始追问第二个问题、且宁愿用一个可验证的锚点而非一张留存策略截图来回答的机构。
完整性证明如何嵌入 DORA 工作流
增加一层验证并不会取代你的 SIEM、日志管线或事件处理流程。它与它们并行运行，为这些系统已经产出的记录加上封印：
当监管者要求你证明某条审计记录就是原始记录时，你拿出一份证明包：该记录的哈希、它在默克尔树中的位置，以及在已知时间点锚定该树根的公链引用。这些都不需要监管机构信任那个生成日志的系统——而这恰恰是 DORA 的要义所在。
机构内部谁来负责这件事
DORA 把 ICT 风险推到了管理机构身上，因此越来越多追问完整性证据的人并非工程师：
- 合规负责人 — 负责与监管机构的关系，必须把“我们有控制措施”翻译成“这就是可证实的证据”。
- CISO / ICT 风险 — 负责韧性态势，深知在事件重建中，自我背书的日志正是最薄弱的一环。
- 内部审计 — 负责保证职能，当完整性无需依赖被审计系统即可验证时，他们将从中受益。
面对 DORA 对话时诚实的表述方式
DORA 并没有点名区块链、默克尔树或任何特定技术——任何声称它点名了的供应商，你都该警惕。DORA 要求的，是你能够向独立第三方证实的完整性。把记录锚定到公链，是提供这一点的一种结构上稳健的方式，因为该证明并不依赖于被审查系统持续保持良好行为。带进你下一次 DORA 评审的问题很简单：对每一条关键审计追踪，我们能否向监管机构证明它没有发生变化——而无需要求他们信任那个产出它的系统？
DORA 问的不是你有没有保留记录，而是你能否证明它们就是原始记录——向一个没有任何理由去信任产出它的系统的人证明。