Exploring DORA

Nicholas Evans, Research Analyst
July 2021
9 mins read

The European Commission’s Digital Operational Resilience Act (DORA) is coming, and financial organizations—alongside some technology companies—will have to change their practices to comply. For now, good preparation means adopting the spirit of DORA rather than its inconsistent details. Organizations that embrace operational resilience as the structuring principle behind their cyber security will likely find that they are better able to meet DORA’s eventual requirements, while improving their ability to prevent, defend and recover from attacks.

If you’ve already looked through the draft proposal for DORA, you’ll know that it’s a complex piece of legislation that aims to achieve multiple goals—some of which have a political angle (e.g., reducing EU reliance on US hyperscalers), and some of which are deeply technical. One goal of DORA is to harmonize the existing rulesets governing financial entities in the EU. It also introduces legislation without precedent in Europe, such as a proposal to regulate third-party information and communications technology (ICT) suppliers to the banking sector.

May 18, 2021, was the final day of public consultation on DORA. While the feedback that the commission received was largely diplomatic, there’s tension beneath the surface. Many organizations who will be regulated by DORA think that, in its current form, will not achieve what it sets out to do. Some even fear it may harm their security.

Lifting the lid on panDORA’s box

Alright. Dramatic wordplay aside, DORA isn’t the box of all evil, but there are parts of it that some would rather didn’t make it out. The potential implications of these require consideration.

The part of DORA that has caused the most concern in the EU’s financial services community is a single article, 28(9). This prohibits financial entities from using critical third-party ICT service providers that do not have a business presence in the EU. Many organizations are worried that this will prevent them from using cutting-edge services coming out of Silicon Valley, or force them to put their trust in unproven services that happen to have a local presence. The objection, cropping up again and again, is that this will make the European financial sector less secure and less competitive.

Moreover, a number of financial entities have expressed worry that article 28(9) not only restricts what they can do, but also creates confusion over how they can do it. Big players like the European Association of Co-operative Banks (EACB) have been left scratching their heads about whether intra-group third-party ICT providers will be covered by article 28(9). Other organizations (including the publishing and analytics company RELX) have asked why the commission has provided such a broad definition of what a ‘critical’ third party provider is, and they have asked for more supplier involvement in the designation process: “as the DORA proposal is currently drafted, a third-party service provider could be deemed critical as a result of how a particular Financial Entity has designed and built its systems.”

That’s not all. A number of respondents to the public consultation have pointed out that DORA does not even achieve its own goal of harmonizing existing legislation. Currently there is a conflict between DORA and the Commission’s own proposed NIS2 (Network and Information Systems) directive, in that each would place ICT service providers under different regulatory authorities. Likewise, DORA proposes a new framework for threat-led penetration testing of financial entities, but at present makes no direct reference to how this will harmonize with the ECB’s flagship TIBER-EU framework.

In light of there being many questions left to answer, we wouldn’t advise you or any of our clients to start changing your service providers or altering testing programs just yet. DORA needs further work, and the European Commission has so far failed to clarify exactly what it is they hope to achieve with the Act.

Exploring DORA

The good news is that you can prepare for DORA by embracing the spirit of the legislation. In practice, this means adopting the focus on operational resilience which underlies DORA’s individual requirements. This mindset is driving regulatory changes in the US, UK, Singapore, and Australia. And since its adoption by the Basel Committee, it is almost certainly going to be the next big thing in discussions about cyber security in the EU.

Let’s go back to basics then. What is operational resilience? In a nutshell, it’s a way of thinking and working that emphasizes the hardening of systems so that when—not if—an organization is attacked, it has the means to respond, recover, learn, and adapt.

Organizations that do not adopt this mindset are likely to experience DORA as an almost impossibly long checklist of disconnected requirements, the fulfillment of which will result in little practical improvement to their security. To take just one example from the list of requirements made by DORA, identifying and documenting all processes that are dependent on ICT third-party service providers is just going to create paperwork if not connected to a broader philosophy of operational resilience.

Because resilience is unique to each organization, there’s no fixed path to achieve it. However, there are 3 principles that every business can consider to form a solid foundation:


  1. Mapping: It may seem obvious, but do you understand all the processes necessary to serve your customers, plus the interdependencies that make these processes vulnerable? And do you understand the tangible impact of these vulnerabilities? The first step to resilience is to map these processes and understand how data flows through your environment. There are exercises that exist specifically to map your organization’s attack surfaces so you can see attack paths and areas of weakness as an attacker would.

  2. Hardening: Once you know what assets you have and how they are critical to the delivery of your services, you can harden them by identifying and mitigating exploitable vulnerabilities as well as implementing additional security measures. The first mapping step is essential to focus this testing on the assets which pose the biggest business risk. Methodologies exist to do this (we call ours risk-prioritized testing). The important thing is that your chosen process balances business risk against cyber risk.

  3. Feedback loops: Resilience relies on security tests being used as learning opportunities through which organizations improve defense and detection. For example, the EU’s own TIBER framework includes a mandatory red team/blue team replay, during which defenders study the steps they took and learn from any mistakes. Likewise, the Australian regulators’ CORIE framework includes an exercise known as purple teaming, in which a red team replays attacks side-by-side with a blue team to refine and improve detection and defense. We make no secret of how effective purple teaming can be. Many other security testers feel the same way, because it usually provides a rich learning experience for their organizations.

DORA is not yet a mature piece of legislation and it is inconsistent with other EU rules. Organizations can nonetheless get ahead of the Act’s adoption by building resilience in its own right, because of its necessity for your security posture. This will not only help you adhere to DORA (whatever it may look like), it will aid your future regulatory compliance in other markets where operational resilience thinking has already taken hold. In the future, a resilient firm is one that will be able to move across regulatory borders with ease.

Accreditations & Certificates

F-Secure Consulting (F-Secure Cyber Security (Pty) Ltd) is a level 4 contributor to B-BBEE with a procurement recognition level of 100%. Learn more and download our B-BBEE certificate. Click here to read the press release.

Follow us
@fsecure_consult F-Secure-Consulting f-secure-foundry fsecurelabs