Many small and medium-sized financial entities have not yet started preparing for the new European Digital Operational Resilience Act: DORA, published as Regulation (EU) 2022/2554. The aim of DORA is to ensure that companies and institutions active in the EU financial sector are prepared to withstand operational disruption and cyberattacks.
The European financial supervisory authorities – ESMA, EIOPA and EBA – still have to develop the relevant sets of regulatory technical standards (RTSs)(1). However, DORA will go into effect no later than January 17, 2025 and what needs to be implemented by then is not only complex but also involves a degree of change in terms of culture and ways of working, and requires cooperation between several departments such as Risk (ISM, BCM), IT, Legal, procurement and central outsourcing management. Last but not least, all required changes for DORA come on top of ongoing projects and existing change initiatives of financial entities and their (critical) suppliers.
Especially the aforementioned financial entities should therefore not wait for the various RTSs but would instead do well to analyze the current situation and start making practical improvements now. That’s why in this article we provide some tips for getting started with DORA today in the form of ‘no-regret moves’ and quick wins.
What is DORA
In an earlier article, we wrote more extensively about the reasons why DORA is needed and the main timelines and key requirements. So, here we only provide a summary.
The Digital Operational Resilience Act (DORA) for the financial sector is EU legislation that went into force on January 16, 2023. Its purpose is to strengthen the resilience of EU financial entities and reduce their vulnerability to ICT risks like IT failures and cyberattacks. DORA tackles such issues by introducing standard security requirements for Information & Communication Technology. The regulation applies not only to the financial sector itself but also to many of the ICT service providers in this sector.
All entities subject to DORA have until January 17, 2025 to become compliant.
DORA covers the five main areas shown in the figure below:
Overview of the 5 focus points of the Digital Operational Resilience Act DORA
Large Credit Institutions
For credit institutions – banks – a lot of the subjects mentioned in DORA are already covered in other regulations applicable for them. But DORA adds to or deviates from these regulations. We performed a comparison and depicted the high level differences:
Overview of the 5 focus points of the Digital Operational Resilience Act DORA
As is clear from the above only some subjects remain completely the same. Our advice for banks is therefore to perform a GAP analysis for DORA, to determine the required effort well in advance.
No-regrets moves and quick wins for non-credit institutions
The situation for non-credit institutions can be different, since the strict regulations applicable to banks, do not or not always apply to them. Of course, the larger the organization, the more likely it is that good practices and professional standards have already been applied. But especially the smaller and medium sized organizations frequently do not meet the DORA requirements. And because this could mean they have to modify (among other things) processes, procedures, technical implementations, contracts and even cultural aspects within the organization, it is in our opinion not wise to wait until the RTSs have been published. Only between 6 and 12 months would remain for analysis, plan and implementation and that could be too much to handle in the then-remaining time.
Below, we have therefore highlighted a few areas that those financial entities can start working on straightaway.
I. Governance and organization (Chapter 2, Article 5 )
DORA requires the management of a financial entity to define, approve, oversee and be responsible for the implementation of all arrangements related to the entity’s ICT risk management framework. This means that the entire managing body of an organization must have the necessary understanding of ICT and ICT risk management. It is not enough to have only one person with the relevant knowledge. Our first no-regrets moves are therefore:
- No-regrets move 1: If the management body as a whole has insufficient knowledge of ICT and ICT risk management, organize master classes on those subjects. Include a DORA awareness session in the master classes.
- No-regrets move 2: If the management body has not yet discussed regularly the ICT risks and corresponding mitigating measures, add a page to the risk report explaining, for example, the ICT risks, ICT major incidents and ICT measures. This will allow management to get used to the complexity of ICT, which over time increases their understanding of the complexity of the measures set down in DORA. Again, this will sooner be an issue in smaller companies than in larger ones.
- No-regrets move 3: If the Three Lines of Defense Model is yet to be fully implemented (in a non-credit institution), do this now. Under DORA, roles such as who is responsible for monitoring ICT third-party service providers, for example, will need to be clearly assigned. The new Three Lines Model published by the IIA (2) is a widely accepted standard, so it is likely that regulators and auditors will expect it to be used as foundation for DORA.
II. Policies, procedures, strategies, protocols (Chapter 2, incl. Articles 9 and 11).
DORA includes requirements for the procedures, tools, strategies, etc., that companies must have in place to ensure their cyber resilience. These procedures and the like must be demonstrable, meaning they have to be documented and approved at the appropriate level (regarding policies). Although the detailed RTS are unknown until now, you can already prepare and save time for implementation.
- No-regrets move 4: Collect all ICT-related policies, procedures, guidelines and carry out a pre-assessment. Determine whether the body that currently approves policies, etc., meets the DORA requirements (Article 5) and if all topics mentioned in DORA, such as Article 9(3) and (4), and Article 11(2), are covered by the existing documents. If any shortcomings are revealed, document them now so that when more details become available later, the basics are already there.
III. Backup and recovery procedures (Chapter 2, Article 12 ).
The requirements for financial entities regarding backup policies and procedures, restoration and recovery procedures and methods are set down in Article 12 of DORA. Most companies will have Business Continuity Management (BCM) in place, but now is the time to check if it meets the requirements as set out in DORA. Requirements such as non-modifiable backups as well as a physically and logically separate restoration environment, a secondary processing site, and the periodic testing of backup and restore procedures will have to be met soon enough.
- No regrets-move 5: Organize a tabletop exercise reenacting a ransomware attack on systems and data. In addition to asking who does what, ask questions such as: How do you know that the systems you bring back up will not immediately be re-infected? How can you be sure that your backups have not been compromised? How do you determine the point in time when the systems (and data) were infected? How will you restore the data and systems after that point in time?
IV. Communication policies and plans for internal staff and external stakeholders (Chapter 2 , Article 14)
In case of a major disruption, DORA requires communication plans to be in place that include what will be communicated – and when – to internal staff and external stakeholders. Moreover, responsibility for communication tasks should be assigned to at least 1 person.
- No regrets-move 6: Draw up communication plans or review the existing ones. This is always a wise move – with or without DORA. If it’s not completely clear where responsibility lies, clarify matters. In this regard, take into account alignment with the Business Continuity Plan which also includes communication.
V. Threat-led penetration testing (red team testing) (Chapter 4, Article 26)
Article 26 of DORA sets out requirements for threat-led penetration testing . This involves using a red team to target the production environment and building security, and test staff awareness as well as, in principle (3), the supplier environment. Apart from a few exceptions (4), red team testing should be carried out by third party testers that meet the requirements set down in Article 27 (5).
- No regrets-move 7: Do a scan of the external threat intelligence service providers that can be called on. Investigate what suitable external penetration testing providers are out there.
- No-regrets move 8: If no red team testing has ever been performed, do it now! It’s a different way of working, requires a lot of preparation and in our experience takes quite some getting used to.
- No regrets-move 9: Contact your main ICT suppliers now and start discussing how they plan to meet these requirements.
VI. ICT Third Party Risk (Chapter 5, Article 28 et seq.) -outsourcing –
DORA sets out a lot of requirements for outsourcing critical (and other) ICT services. The basis is having a good overview of what ICT services have been outsourced, which of those are critical and to whom those suppliers have in turn outsourced the services (6). According to the European Banking Authority Guidelines on outsourcing arrangements, published in February 2019 (EBA Guidelines), and those of the European Insurance and Occupational Pensions Authority (EIOPA), such an overview should already be in place and maintained in a register.
- No-regrets move 10: Check whether all outsourced ICT services – that concern critical or important functions – are in this register and are up to date.
- No-regrets move 11: Check whether the contractual terms in your model contracts meet the requirements of DORA Article 28 et seq.
- No-regrets move 12: Some service providers can already be considered to be systemically critical pursuant to Article 31(1) point (a) and Article 31(2). Examples include large cloud service providers (Amazon, Microsoft). Such critical service providers must have a subsidiary in the EU. Identify in advance which suppliers these are likely to be and ask how they are preparing for DORA.
DORA is an important legislation for the EU, especially with all the cyberattacks and political turmoil going on in the world these days. We therefore expect regulators to quickly move on to strict enforcement after DORA becomes applicable in early January 2025. That being said, it will take a long time for the various sets of regulatory technical standards to be finalized. We propose to start now with at least the no-regrets moves and quick wins mentioned above. In that way, you won’t be faced with an impossible task in the final 6 to 12 months of the phase-in period.
Our experts look forward to welcoming DORA and will be happy to answer any questions you or your organization may have. If you want to learn more about Eraneos’ expertise in the financial services sector, check out this page.
Footnotes
- The expectation is that the standards will be published twelve to eighteen months after DORA entered into force. The RTSs will set down requirements for, among other things, a simplified risk management framework (draft: January 2024), specifying ICT services policy (draft: January 2024) and specifying elements when sub-contracting critical or important functions (draft: June 2024).
- IIA. (2020). The IIA’s Three Lines Model. An Update of the Three Lines of Defense.
- Here too an exception applies for the entities as mentioned in article 16 (1) as well as the micro enterprises: Article 26(1).
- See Article 27(1) point (a).
- In brief: they are highly suitable with a good reputation; have technical and organizational capabilities; are certified or adhere to formal codes of conduct; can provide an independent assurance or audit report and are fully covered by relevant professional indemnity insurances.
- Insight into the entire chain, so that concentration risk, among other things, can be determined.
