学习DORA 01｜一次系统中断，为什么会引出一整套欧盟法规

银行是一个我以前从未涉足过的行业。我现在在卢森堡一家银行的欧洲总部从事信息安全相关工作，日常接触的事情包括漏洞管理、资产清查、安全告警、风险跟踪和一些审计检查。

Solarwinds是我每天都要监控的系统，偶然一些系统告警，比如CPU飚到了100%，硬盘不足等，会让公司的运维团队紧急处理。但如果发生某个系统中断就不是这么简单了，不仅仅是我们这边部门领导和直属公司班子领导会关注，总部那边的信息中心都回立即介入。所以这里跟我以前经历过的IT很不一样，也是在这里，我第一次听说了一个天天挂在领导嘴边的词：DORA。

稍微了解了一下，发现这法案还真挺重要。我们现在做的很多工作，往回一追，基本都能追到DORA。所以从今天开始，我打算系统地学习一下。

因为我的职责是网安，我一开始先入为主地把DORA理解成了一部网安法。

DORA当然涉及网络安全，但它真正关注的似乎不只是银行能不能阻止一次攻击，而是当系统故障、网络攻击、供应商中断或者其他ICT问题真的发生时，银行还能不能继续提供关键金融服务，能不能及时恢复，以及整个过程中有没有清楚的责任、流程和证据。

换句话说，它关注的不只是单纯的“安全”，而是所谓的 operational resilience，也就是数字运营韧性。

我也发现，自己虽然已经接触了不少DORA相关的局部工作，但对它的完整体系其实并不清楚。

例如：

• ICT风险的最终责任为什么会被放在管理层，而不是IT部门？这多少有点倒反天罡，在国内单位里干过活的人应该懂。
• 什么样的系统中断会被认定为重大ICT事件？
• 漏洞扫描、恢复演练和渗透测试，在DORA里面分别处于什么位置？
• 银行把系统交给云服务商之后，相关风险是不是也一起转移出去了？
• 为什么一张看起来很完整的供应商Excel，仍然无法直接满足Register of Information的要求？

这些问题显然不是背几个法规编号就能回答的。而且我根本看不懂，领导让我学学法案，我看到第一页就直接晕菜了，那玩意根本不是人读的。

所以我把DORA相关的十几份正式文件都下载了下来，准备丢给AI，让它先作为咨询专家，带我把整个体系一点点啃完。

当然，AI也会胡说。它给出的解释到底对不对，最后还是得回到法规原文。

今天读的是DORA主法规。

光是找到这份所谓的“主法规”，我就先理解了半天。一开始以为DORA就是一个PDF，结果弯弯绕绕找出了十来份文件。

后来才搞明白，主法规 Regulation (EU) 2022/2554 更像是总纲。它先把整体框架、主要责任和基本要求定下来，后面再通过一系列授权法规、实施法规和监管指引，把事件报告、风险管理、第三方、测试这些东西分别展开。

今天AI给我的任务不多，只读主法规的Article 1和Article 5。

为了理解这两条，它先给了我一个简单场景：

一家银行的支付系统因为供应商更新失败，中断了两个小时。没有黑客攻击，没有数据泄露，系统最后也恢复了。

按照我以前的理解，这甚至未必算网络安全事件，更像是一次普通的IT故障。

技术团队先把系统恢复，然后分析更新为什么失败，最后做一次复盘，这件事差不多也就结束了。

但看完Article 1以后，我发现DORA看待这件事的角度要宽得多。

Article 1的标题是 Subject matter，主要是在说明DORA到底要管些什么。它关注的不只是攻击，也包括可能影响金融机构业务运行的各种ICT问题。

也就是说，即使没有黑客，没有数据泄露，只要ICT故障影响到了金融服务的持续运行，它就已经进入了DORA关注的范围。

于是，这件事就不再只是“服务器挂了两个小时”。

还要继续问： 支付服务受到了多大影响？ 有没有客户无法完成交易？ 这是不是一项关键业务？ 银行用了多长时间才恢复？ 同样的问题以后还会不会再次发生？

当然，Article 1本身还没有告诉我，这次事件到底严不严重、要不要向监管机构报告。后面还有专门的事件分类和报告规则来判断这些问题。

但至少第一点已经很清楚了，DORA关注的范围，要比传统意义上的网络安全大得多。

更让我意外的是Article 5。 Article 5把ICT风险的最终责任放在了 management body 层面。放在银行里，可以先粗略理解为董事会或者承担最高治理职责的管理机构。

我一开始看到这里，确实觉得有点倒反天罡。在国内单位里上过班的一定懂…..责任都是向基层压实再压实 系统明明是IT部门在维护，安全策略是安全部门在执行，为什么最后要管理层负责？

我理解，IT部门可以决定一个漏洞怎么修、一台服务器怎么恢复，却不能独立决定银行愿意承担多大的风险。

哪些业务必须优先恢复，需要投入多少预算，要不要继续使用某个高风险供应商，发生重大事件后接受多大程度的业务损失，这些本来就不是技术部门能够自己拍板的事情。

所以，Article 5当然不是要求董事会亲自修服务器。

IT和安全团队仍然负责具体的技术控制和事件处置，风险、合规和审计部门也有各自的监督和检查职责。

但管理层不能把ICT风险整个扔给IT，然后只在发生严重事故时出来问一句：

“为什么之前没有发现？”

DORA要求management body定义、批准并监督ICT风险管理框架，同时对它的实施承担最终责任。

具体工作可以委派，最后的治理责任不能跟着一起下放。

第一天其实没有读多少内容，就Article 1和Article 5，我核心的理解是，我原来以为DORA主要是在告诉银行的IT和安全部门应该怎样做网络安全。现在看来，它更像是在要求整个银行把ICT风险当成一个经营和治理问题，而不只是技术问题。在国外这两年确实接触这这种概念会更多，国内往往更关注增长。

今天先学到这里。