DORA：第一年的经验教训

作者：Jonas Osman Abdelghafour。

《数字运营韧性法案(Digital Operational Resilience Act, DORA)》下完整一轮的事件报告实践，呈现出一个清晰的规律：真正的制约瓶颈很少是检测技术。而是在事件仍处于应对之中时，能否正确分类事件、汇总准确的影响数据，并在紧迫的时限内完成申报的能力。遇到困难的机构，其原因多是组织层面的，而非技术层面的。

分类才是难点

DORA的分类标准——受影响的客户与交易对手、服务中断的持续时间与停机时长、地理分布范围、数据损失、受影响服务的关键程度，以及经济影响——每一项单独来看都合乎情理，但在时间压力下综合评估却颇为苛刻。要评估这些标准，需要知道哪些业务服务依赖于受影响的组件、这些服务背后有多少客户，以及实际的停机时间是多少。

那些维护着从业务服务到应用程序再到基础设施的映射关系的机构，能够在数小时内作出答复。而没有这种映射的机构，则不得不在申报窗口期内，从"部门经验记忆"中重建这份映射——这既缓慢又不可靠。第一年经验中最有价值的投入，并非工具本身，而是一份作为常态化管控手段持续维护、而非为应付审计才更新一次的服务依赖关系图。

第二条分类方面的经验教训与聚合相关。单独看均低于阈值的重复性事件，一旦关联起来就可能达到可报告标准。这需要一套结构化的事件记录，能够识别根本原因的共性，而许多工单系统默认并不支持这一点。

时限要求倒逼形成预先建立的流程

分阶段报告模型——初次通报、中期报告、最终报告——假定机构能够迅速形成一个站得住脚的初步判断，随后再加以完善。有两种行为会导致失败。其一是在通报前等待确定性，而该框架在初始阶段并不要求确定性。其二是法务与传播审核链条本身是为审慎披露而设计的，而非为应对监管时限而设计。

补救办法枯燥但有效：预先填入静态企业数据的模板、拥有非工作时间授权申报权限的委托审批人、独立于事件指挥官之外专设的事件报告责任人，以及在每一次重大韧性演练中进行的彩排。那些在真正需要之前就已在模拟中演练过报告流程的机构，报告了最平顺的第一年经验。

第三方登记册物有所值

关于ICT第三方安排的信息登记册，此前被普遍视为一项数据收集负担。而一旦某起事件涉及某家提供商，它立即就变成一项资产，因为它能马上回答涉及哪些合同、哪些服务、何种关键程度，以及适用何种退出安排。反复出现的数据质量问题也并不令人意外：实体标识不一致、分包链条仅记录到第一层，以及关键程度评估是继承而来而非重新评估的结果。

第四方集中度是这一演练暴露出的、而鲜有机构着手解决的风险。多家提供商共同依赖同一个云区域或同一个身份提供商，构成了单点故障，而逐一供应商评估无法看到这一点。这种分析必须跨整个登记册进行，而非局限于每一条记录内部。

能产生真正有价值发现的测试

DORA下的韧性测试，只有在情景足够严峻且真实可信时才有价值：关键供应商的丧失、数据的损坏（而不仅仅是不可用）、以及用于应对事件的工具本身遭到攻陷。对纳入范围的机构而言，威胁驱动的渗透测试应当针对业务服务，而不仅仅是基础设施。发现的问题应以与验证发现同等的纪律追踪至闭环，韧性规划中所使用的恢复时间假设应加以测试，而非仅凭断言。

第二年的优先事项

• 将服务到资产的依赖关系图作为一项有专人负责的实时管控措施持续维护。
• 实现从监控与CRM数据源中提取分类数据的自动化。
• 委托申报授权，并在非工作时间彩排报告流程。
• 清理第三方登记册，并跨登记册分析集中度，包括分包商在内。
• 测试数据损坏与供应商丧失情景，并验证所声称的恢复时间。
• 以业务服务而非系统数量为口径，向董事会报告韧性状况。

DORA的根本问题在于，机构能否在中断中持续提供关键服务。报告机制不过是使这个诚实答案得以显现的手段。

主要资料来源： (EU) 2022/2554号条例（DORA）及其关于事件分类、报告与信息登记册的相关技术标准(RTS/ITS)；欧洲银行管理局(EBA)风险评估报告，2026年6月。