DORA: A Complete Guide to Compliance for the Financial Sector

What is the DORA Regulation?

The DORA Regulation (No. 2022/2554), or Digital Operational Resilience Act, is a major piece of European Union legislation on cybersecurity for financial entities, such as banks or credit institutions.

Which law prevails between DORA and NIS2?

If you’re aware of the DORA Regulation, you couldn’t miss the NIS2 Directive. It was adopted on the same day, and strengthens cybersecurity requirements across the EU, including for banks and financial market infrastructures.

So, which prevails between DORA and NIS2 when it comes to digital finance? Well, it’s simple: DORA is “lex specialis” of NIS2, a principle which states that a specific law takes precedence over a general one. In reality, DORA clarifies and complements NIS2 more than it supplants it.

“This Regulation constitutes lex specialis with regard to Directive (EU) 2022/2555. At the same time, it is crucial to maintain a strong relationship between the financial sector and the Union horizontal cybersecurity framework as currently laid out in Directive (EU) 2022/2555” – DORA, Recital 16

What is the purpose of DORA?

DORA’s objective is clearly stated in its Recital 105 (a preamble that precedes a piece of legislation and explains its motivations): “to achieve a high level of digital operational resilience for regulated financial entities”.

That’s all well and good, but what does “digital operational resilience” mean? Well according to the text of DORA itself, it is:

“the ability of a financial entity to build, assure and review its operational integrity and reliability by ensuring, either directly or indirectly through the use of services provided by ICT third-party service providers, the full range of ICT-related capabilities needed to address the security of the network and information systems which a financial entity uses, and which support the continued provision of financial services and their quality, including throughout disruptions” – DORA, Article 3(1)

Defense is good, resilience is better!

What does this definition of digital operational resilience mean? Quite simply, financial entities must no longer just defend themselves, they must resist. The real challenge of DORA is the reliability and integrity of financial services, even in case of disruptions, incidents, attacks… In other words, if something goes wrong! The financial sector should be able to defend its assets (data, software and hardware), but it is no longer an end in itself. With DORA, defense serves a higher purpose: resilience.

When will the DORA Regulation come into force?

The DORA Regulation will come into force on the 17th of January 2025, i.e. 24 months after its publication in the Official Journal of the EU. Should you want to check for yourself, the date is clearly stated in Article 64.

Towards a clarification of regulatory technical standards by ESAs and ENISA in early 2024

As you will see, some of the policies and procedures introduced by DORA are, to date, still a bit nebulous. Nevertheless, this should become clearer by early 2024.

Article 15 states that the European Supervisory Authorities (ESAs) and the European Union Agency for Cybersecurity (ENISA) must propose common draft regulatory technical standards by January 17, 2024. These drafts will specify different parts of the legislation, from the components of the ICT response and recovery plans to the testing of ICT business continuity plans.

However, the regulation is already quite extensive and there’s no need to wait until 2024. There’s no shortage of challenging projects and it’s best to get started as soon as possible.

DORA Compliance: A 17-Step Action Plan

At this point, we’ve already covered the “when” and “why” of DORA compliance. But as you might expect, it’s the “how” that represents the bulk of the work. As always with compliance matters, it’s all about taking it one step at a time. These few pages are here to help you get started.

Without further ado, let’s get down to business with our action plan to prepare DORA as well as possible before January 17, 2025.

1. Know if you are affected by the DORA Regulation

Before worrying about DORA compliance, you should know if you’re affected. The Digital Operational Resilience Act applies to 21 types of entities. Here they are as described in Article 2:

• credit institutions;
• payment institutions, including payment institutions exempted pursuant to Directive (EU) 2015/2366;
• account information service providers;
• electronic money institutions, including electronic money institutions exempted pursuant to Directive 2009/110/EC;
• investment firms;
• crypto-asset service providers and issuers of asset-referenced tokens;
• central securities depositories;
• central counterparties;
• trading venues;
• trade repositories;
• managers of alternative investment funds;
• management companies;
• data reporting service providers;
• insurance and reinsurance undertakings;
• insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries;
• institutions for occupational retirement provision;
• credit rating agencies;
• administrators of critical benchmarks;
• crowdfunding service providers;
• securitisation repositories;
• ICT third-party service providers. (Yes, it’s broad.)

DORA: the list of exceptions

Certain entities are explicitly excluded from the scope of DORA by Article 2(3). We encourage you to read the list below to see if you are among the lucky ones.

A word of caution: the exceptions mentioned in DORA often echo exceptions in other legislations, which themselves have countless ramifications. In order to keep it short, we won’t go into the details of all the legislations mentioned by DORA. Nevertheless, you will find links to the laws in question if you need to know more about a particular sector.

Are excluded from the scope of DORA:

• managers of alternative investment funds as referred to in Article 3(2) of Directive 2011/61/EU;
• insurance and reinsurance undertakings as referred to in Article 4 of Directive 2009/138/EC;
• institutions for occupational retirement provision which operate pension schemes which together do not have more than 15 members in total;
• natural or legal persons exempted pursuant to Articles 2 and 3 of Directive 2014/65/EU;
• insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries which are microenterprises or small or medium-sized enterprises The definition is given in Article 4(60) of DORA: which employs fewer than 10 persons and has an annual turnover and/or annual balance sheet total that does not exceed 2 million euros;
• post office giro institutions as referred to in Article 2(5), point (3), of Directive 2013/36/EU.

It should be noted that Member States may choose to exclude from the scope of DORA some very specific national credit or investment entities, as referred to in Article 2(5) of Directive 2013/36/EU. In France, for example, the State could choose to spare the “Caisse des dépôts et consignations”.

2. Know the requirements set by DORA

As previously seen, the goal of DORA is to elevate the digital operational resilience of financial organizations. To achieve this, Article 1 sets specific requirements for the security of network and information systems, namely:

• requirements applicable to financial entities in relation to:
  • information and communication technology (ICT) risk management;
  • reporting of major ICT-related incidents to the competent authorities and notifying, on a voluntary basis, of significant cyber threats;
  • reporting of major operational or security payment-related incidents to the competent authorities;
  • digital operational resilience testing;
  • information and intelligence sharing in relation to cyber threats and vulnerabilities;
  • measures for the sound management of ICT third-party risk;
• requirements in relation to the contractual arrangements concluded between ICT third-party service providers and financial entities;

As you might expect, these requirements are the focus of the rest of this article.

3. Create an ICT risk management framework

This is a BIG piece of the legislation. The Digital Operational Resilience Act highlights the absolute necessity of having an ICT risk management framework.

“Financial entities shall have a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system, which enables them to address ICT risk quickly, efficiently and comprehensively and to ensure a high level of digital operational resilience.” – DORA, Article 6(1)

For information, is defined as an ICT risk:

“Any reasonably identifiable circumstance in relation to the use of network and information systems which, if materialised, may compromise the security of the network and information systems, of any technology dependent tool or process, of operations and processes, or of the provision of services by producing adverse effects in the digital or physical environment;” – DORA, Article 3(5)

DORA: protecting software, hardware and data

The framework must detail the elements put in place to protect the organization’s ICT and information assets. Again, let’s refer to Article 3 for definitions:

• “information asset”: a collection of information, either tangible or intangible, that is worth protecting;
• “ICT asset”: a software or hardware asset in the network and information systems used by the financial entity;

In other words, financial sector players must protect not only their software and physical equipment (servers, endpoints, etc.), but also the data. This is a logical and welcome legislative shift. After all, attacking a data center is never an end in itself: the true goal is the access to the data.

When we will talk about assets in the rest of this article, it is to be understood as “information assets” and “ICT assets” according to the previous definitions.

What must you include in the ICT risk management framework?

Still under Article 6, the mandatory ICT risk management framework must include at least:

• the strategies, policies, procedures, ICT protocols and tools that are necessary to protect:
  • all information and ICT assets, including softwares, hardware, servers, etc.;
  • all physical components and infrastructures relevant to the protection of these assets, such as premises or data centers.

As you will soon realize, DORA operates like a Russian doll of policies. This risk management framework will itself be fueled by the creation of other policies specific to different topics, from business continuity to recovery plans.

It should be noted that organizations must keep this documentation available to the relevant authorities, who may request access to it. They can also request a report on the review of the framework, which brings us to the next point.

Update the framework at least once a year

No way to write the framework and then let it gather dust in corners. It needs to be updated:

• at least once a year (or periodically for microenterprises);
• or upon the occurrence of major ICT-related incidents;
• or following supervisory instructions;
• or conclusions derived from relevant digital operational resilience testing or audit processes.

Implement an ISMS with DORA in mind

If you have not already done so, it is essential to implement an ISMS to support the risk management framework introduced by DORA. Having an Information Security Management System (ISMS) helps to reduce digital risks, by structuring the entity’s information security management through a systemic approach.

ISO 27001, a standard for certification

NIS2 suggests future European certification frameworks for cybersecurity. But until then, the international standard ISO 27001 remains a reference for the creation of an ISMS. Achieving ISO 27001 certification requires hard work, organization and most of all, time. Therefore, it should be one of the priorities of any CISO dealing with DORA.

A simplified ICT risk management framework for designated entities

Some entities are entitled to a “simplified ICT risk management framework” pursuant to Article 16 of DORA. This is a lighter version of the mandatory management framework required by the Regulation.

Here is the list of entities that qualify for this simplified framework:

• small and non-interconnected investment firms;
• payment institutions exempted pursuant to Directive (EU) 2015/2366;
• institutions exempted pursuant to Directive 2013/36/EU – see our section on DORA’s scope exceptions;
• electronic money institutions exempted pursuant to Directive 2009/110/EC;
• and small institutions for occupational retirement provision – those operating pension schemes with fewer than 100 members in total.

4. Audit the ICT risk management framework on a regular basis

The ICT risk management framework “shall be subject to internal audit by auditors on a regular basis” (Article 6.6). There should be a clear segregation between ICT risk management functions, control functions, and internal audit functions To this end, Article 6(4) of DORA directs financial entities to adopt the Three Lines of Defense (3LoD) model.

Adopt the Three Lines of Defense (3LoD) model

The 3LoD model allows for an organizational separation of responsibilities and risk governance. In practice:

• A first line of defense by the operational teams, those who are on the ground. They are responsible for simplifying risk management for the next lines, by taking into account the risk factors. For instance, for a development team, this may involve clearly defining the responsibilities of each person, or adopting a culture of cybersecurity by design with secure development methods.
• A second line of defense by the risk management and compliance functions, such as the CISO. This second line is responsible for controlling the first. This involves creating monitoring processes, implementing the entity’s overall risk management strategy, or ensuring that all the company’s functions are working in accordance with risk management policies – so HR, sales, marketing, C-Levels, everyone!
• A third line of defense by independent internal auditors. They must ensure that the defenses put in place by the previous two lines are bulletproof. In other words: a holistic control of the risk management application. The auditors must verify the processes and their correct execution, and then write detailed audit reports. DORA states the obvious, but internal auditors must have “sufficient knowledge, skills and expertise” in ICT risk management.

For the 3LoD model to succeed, each line must be completely independent – especially the last. As such, DORA states that organizations must ensure “adequate separation and independence of ICT risk management functions, control functions and internal audit functions” to avoid conflicts of interest. It’s time to revisit Montesquieu and the separation of powers!

It’s difficult to detail a universal 3LoD model that can be replicated everywhere, since it must be intrinsically tied to the business, the structure and the functions of each organization. However, you’ll find many resources on the web to guide you in the implementation of your fortifications. The latest model from the IIA (Institute of Internal Auditors) is a good starting point.

Entity responsibility even when outsourcing

The DORA allows for the outsourcing of “the tasks of verifying compliance with ICT risk management requirements”, whether to external or internal actors. However, the financial entity remains fully responsible for this verification. Simply put: don’t expect to pass the buck for negligence to a vendor, the liability lies with the financial entities.

5. Define a “digital operational resilience strategy”

The ICT risk management framework must come with a digital operational resilience strategy. These are two sides of the same coin: where the risk management framework has a holistic approach, the resilience strategy has a practical approach. It should specify the methods put in place to address risks and attain specific objectives.

According to Article 6(8), this resilience strategy must:

• explain how the framework supports the financial entity’s business strategy and objectives;
• establish the risk tolerance level for ICT risk, in accordance with the risk appetite of the financial entity, and by analyzing the impact tolerance for ICT disruptions;
• set out clear information security objectives, including key performance indicators and key risk metrics;
• explain the ICT reference architecture and any changes needed to reach specific business objectives;
• outline the different mechanisms put in place to detect ICT-related incidents, prevent their impact and provide protection from it;
• evidence the current digital operational resilience situation on the basis of the number of major ICT-related incidents reported and the effectiveness of preventive measures;
• implement digital operational resilience testing;
• and outline a communication strategy for ICT-related incidents that require disclosure.

Depending on the scale of the group, it’s fully possible to set up a global multi-vendor strategy. The strategy should then explain the rationale behind this choice, and detail the key dependencies on different suppliers.

Monitor and improve the effectiveness of the strategy over time

Article 13 calls on financial entities to monitor the effectiveness of the implementation of their digital operational resilience strategy. This includes mapping the evolution of ICT risk over time, and analyzing the frequency, types, magnitude and evolution of incidents. Emphasis is placed on the follow-up of cyber attacks and their patterns, in order to understand the evolution of the entity’s risk exposure level, especially for critical or important functions.

The strategy should be continuously improved by lessons learned from: 

• mandatory reviews after a major incident – see #11;
• difficulties encountered in activating business continuity plans and response and recovery plans – see #8 and #9;
• surveillance of cyber threats and information-sharing arrangements – see #13;
• operational resilience tests – see #14 and #15.

A report must be made to the management body of the entity at least once a year (Article 13.5). It should include the findings of the previous points, as well as recommendations.

6. Deploy mechanisms for asset protection and resilience

The resilience strategy should “outline the different mechanisms put in place to detect ICT-related incidents, prevent their impact and provide protection from it.” There is no secret here, you will need to rely on a range of appropriate procedures and tools.

Minimum protection and resilience requirements

To protect assets in line with Article 9, the solutions and processes in place must at least:

• ensure the security of the means of transfer of data;
• minimize the risk of corruption or loss of data, unauthorized access and technical flaws that may hinder business activity;
• prevent the lack of availability, the impairment of the authenticity and integrity, the breaches of confidentiality and the loss of data;
• ensure that data is protected from risks arising from data management, including poor administration, processing-related risks and human error.
• ensure sound network and infrastructure management, that may include automated mechanisms to isolate affected information assets in the event of cyberattacks;

To prevent contagion, the network connection infrastructure must be designed in a way that allows it to be instantaneously severed or segmented, especially for interconnected financial processes. In other words, everything has to be able to be disconnected on the fly if something goes south.

More and more policies to document

Financial entities must also document:

• an information security policy defining rules to protect the availability, authenticity, integrity and confidentiality of assets and data, including those of their customers, where applicable;
• policies that restrict access (physical or logical) to assets and data based on functions, roles and missions;
• policies and protocols for strong authentication mechanisms and encryption key protection measures. There are many paths forward, starting with the adoption of 2FA as the default authentication method for all employees;
• policies, procedures and controls for ICT change management, including changes to software, hardware, firmware components, systems or security parameters. They should be based on a risk assessment approach and be an integral part of the financial entity’s overall change management process. The ICT change management process must be approved by the proper hierarchical body;
• appropriate and comprehensive documented policies for patches and updates.

7. Install detection solutions

Proper asset protection requires proper detection capabilities for anomalies, incidents and cyber attacks. This means EDRs, XDRs, scanners, SIEMs, etc. Article 10 of DORA specifies that financial entities must allocate “sufficient resources and capabilities”.

To meet the requirements of the Regulation, the detection mechanisms must:

• enable multiple layers of control, define alert thresholds and criteria to trigger and initiate incident response processes, including automatic alert mechanisms for relevant staff (the SOC for example);
• and be tested regularly.

We recommend you to read our article about EDR solutions as well as the one on SIGMA rules, a collaborative tool that allows to standardize detections whatever the SIEM. Useful if you decide to migrate to another solution in the context of DORA.

8. Draft an ICT business continuity policy

The DORA Regulation requires that:

“Financial entities shall put in place a comprehensive ICT business continuity policy, which may be adopted as a dedicated specific policy, forming an integral part of the overall business continuity policy.” – DORA, Article 11

This ICT business continuity policy must allow for:

1. the continuity of the financial entity’s critical or important functions;
2. a quick and effective response to all ICT-related incidents in a way that limits damage and prioritizes the resumption of activities and recovery actions;
3. the activation of dedicated plans to contain each type of incident and prevent further damage, as well as tailored response and recovery procedures – cf. #9;
4. the estimation of preliminary impacts, damages and losses;
5. proper crisis management and communication measures for internal teams, external stakeholders and relevant authorities – cf. #10.

Again, it’s critical to prevent, contain and remediate, but most of all to ensure the resilience of services.

Test continuity plans at least once a year

Once again, DORA’s text is very down to earth. Measures must be documented, but also tested for effectiveness. Article 11(6) requires financial organizations to test : 

• ICT business continuity plans and ICT response and recovery plans :
  • at least once a year;
  • as well as when there are substantial changes to ICT systems that support critical or important functions.
• as well as crisis communication plans. 

Testing plans must incorporate cyberattacks and switchover scenarios between the primary ICT infrastructure and the redundant capacity, backups and redundant facilities enforced by DORA.

Keep a record of activities in the event of a disruption

Should these plans be activated, entities must keep “readily accessible records of activities before and during disruption events” as per Article 11(10). If requested by the competent authorities, organizations must also provide an estimate of the aggregate annual costs and losses incurred by major incidents.

9. Provide backup, restoration and recovery procedures (and related policies)

The Digital Operational Resilience Act seeks to minimize disruption and downtime to systems and data. Concretely, this translates into three work streams: backup, restoration and recovery. These are broken down into policies, which are themselves part of the ICT business continuity policy.

Financial entities must therefore put in place:

• backup policies and procedures that specify:
  • the scope of the data covered by the backup;
  • and its minimum frequency, depending on the criticality of the information or the confidentiality level of the data;
• restoration and recovery procedures and methods.

Activating a backup system must not compromise the availability, authenticity, integrity or confidentiality of the data. This means no freezing of services while rolling back the system. Furthermore, DORA (Art. 12.4) introduces an obligation of redundant ICT capacities. They must be duplicated in order to ensure a relay if the original system should fail.

Regarding restoration, if an entity decides to restore backup data using its own systems, it must ensure that they are physically and logically segregated from the source system.

Finally, all backup, restoration and recovery procedures must be tested periodically pursuant to Article 12(2).

It should be noted that most of these requirements do not apply to micro-enterprises, or may be assessed according to their risk profile. On the other hand, central securities depositories are subject to additional requirements, such as having a secondary data processing site. If necessary, everything is outlined in Article 12(5).

10. Prepare crisis communication plans

Article 14 of DORA is short but to the point. It clarifies the obligations of financial entities regarding communication during incidents.

“Financial entities shall have in place crisis communication plans enabling a responsible disclosure of, at least, major ICT-related incidents or vulnerabilities to clients and counterparts as well as to the public, as appropriate.” – DORA, Article 14(1)

In addition to these externally-focused communication plans, organizations should have similar plans for internal use and external stakeholders. In the event of an incident, the internal communication policy should distinguish between: 

• staff who need to be informed;
• and staff who are actively involved in ICT risk management, especially with respect to response and recovery.

Designate a crisis communications officer

DORA requires that at least one person be designated as responsible for this matter. It may be wise to sync up with the legal, comm and marketing teams on the posture to be taken, and the processes to be implemented.

“At least one person in the financial entity shall be tasked with implementing the communication strategy for ICT-related incidents and fulfill the public and media function for that purpose.” – DORA, Article 14(3)

The communication plan brings us right to the next point, as it must be part of the incident management process.

11. Establish an incident management process

With DORA, it is mandatory for financial entities to implement an incident management process – ICT related of course, which is meant throughout this paper. This incident management process feeds into the ICT business continuity policy (see #8) and the resilience strategy (#5), which are themselves part of the ICT risk management framework (#3). When we told you that DORA was organized like a matryoshka of policies…

DORA: an obligation to record all incidents

This process is not an end in itself: it must record all significant cyber threats and all incidents (not just the most important ones). It goes without saying that recording all incidents is impossible without a flawless detection capability – see #6 of this article.

Pursuant to Article 17, the incident management process shall:

• put in place early warning indicators;
• establish procedures to identify, track, log, categorize and classify incidents according to their priority and severity, and according to the criticality of the services impacted;
• assign roles and responsibilities that need to be activated for different incident types and scenarios;
• set out plans for communication to staff, external stakeholders and media;
• ensure that at least major incidents are reported to relevant senior management, and inform the management body of at least major incidents, explaining the impact, response and additional controls to be established;
• establish incident response procedures to mitigate impacts and ensure that services become operational and secure in a timely manner.

Classification of incidents under DORA

According to Article 18 of DORA, financial entities must classify incidents based on the following criteria:

1. the number and/or relevance of clients or financial counterparts affected and, where applicable, the amount or number of transactions affected by the incident, and whether it has caused reputational impact;
2. the duration of the incident, including the service downtime;
3. the geographical spread with regard to the areas affected by the incident, particularly if it affects more than two Member States;
4. the data losses that the incident entails, in relation to availability, authenticity, integrity or confidentiality of data;
5. the criticality of the services affected, including the financial entity’s transactions and operations;
6. the economic impact, in particular direct and indirect costs and losses, in both absolute and relative terms.

Organizations must also determine whether or not a cyberthreat is significant on a similar basis to the list above.

DORA sets the broad guidelines for incident classification, but the exact thresholds are still unclear. They will be defined by the ESAs, the ECB and ENISA, which have until January 17, 2024 to submit their recommendations to the Commission. So, we’ll have to wait and see, even if common sense and the knowledge of your organization should allow you to set a first classification grid that is personal to you.

Mandatory post-incident reviews

Article 13 requires organizations to conduct mandatory post-incident reviews after the occurrence of a major incident that disrupts their core activities.

These reviews must determine :

• if the established procedures were followed;
• and whether they were effective in terms of :
  • the promptness in responding to security alerts and determining the impact of the incident and its severity;
  • the quality and speed of performing a forensic analysis;
  • the effectiveness of incident escalation within the financial entity;
  • the effectiveness of internal and external communication.

What is a “major incident”?

Ah, that’s a million-dollar question ! Here’s the definition as given by the regulation:

“Major ICT-related incident”: an ICT-related incident that has a high adverse impact on the network and information systems that support critical or important functions of the financial entity; – DORA, Article 3(10)

Let’s also slip in the definition of a “significant cyber threat” : 

“Significant cyber threat”: a cyber threat the technical characteristics of which indicate that it could have the potential to result in a major ICT-related incident or a major operational or security payment-related incident; – DORA, Article 3(13)

12. Write and document your incident response plan

One of the first things you should do to fuel the incident management process is to draft (or revise) your Incident Response Plan (IRP). It will prove invaluable when faced with an obligation to respond – whether to partners, customers, or competent authorities.

There are many useful resources on the web for creating your IRP. Keep in mind that it must comply with the response obligations introduced by DORA, which brings us directly to the next point.

Find out which “competent authority” you should report to

First of all, it should be noted that the competent authorities are not the same for all financial entities. The subject is far too broad for us to detail them all here. Therefore, we refer you to Article 46 of DORA, the aptly named “Competent Authorities“, which will clarify your own situation. Please note that the principle of proportionality that we discussed earlier applies here. If you are subject to more than one national authority, the State will have to decide which one prevails.

Furthermore, under Article 19(1), States are free to impose on one or more of the financial entities on their territory a dual response obligation:

• to the competent authority under DORA;
• but also to the competent authorities or to the Computer Security Incident Response Centers (CSIRT) designated under NIS2.

This is not mandatory, but possible. It is therefore up to each entity to verify its own situation.

Response obligations to competent authorities

By now, you should know which competent authority you are dealing with; the question remains as to when to contact it.

In the event of a major incident, Article 19(4) provides that financial entities must submit to the relevant competent authority:

• an initial notification;
• an intermediate report as soon as the status of the original incident has changed significantly or the handling of the major incident has changed based on new information available
  • if appropriate, updated notifications every time a relevant status update is available, as well as upon a specific request of the competent authority;
• a final report, when the root cause analysis has been completed, regardless of whether mitigation measures have already been implemented, and when the actual impact figures are available to replace estimates.

Financial entities may also notify, on a voluntary basis, significant cyber threats to the relevant competent authority where they believe it is relevant to the financial system, service users or customers.

Note also that the DORA Regulation allows for outsourcing of reporting obligations to a third party service provider – see Article 19(5). Nevertheless, the financial entity remains fully responsible for complying with its requirements. Here again, no way to put the blame on a vendor!

What are the timelines for DORA response obligations?

The timeframes that apply to each notification are still unknown, and must be specified by the ESAs, ENISA and the ECB by January 17, 2024. Nevertheless, we believe it is safe to assume that the timelines under DORA will be similar to those introduced by the NIS2 Directive, which requires:

• an initial notification within 24 hours after the occurrence of the major incident;
• an intermediate notification within 72 hours;
• a final report at the latest one month after the first notification.

Again, there is no indication that DORA will align with NIS2, this is just a guess on our part. If you want to know more about those response obligations, we recommend you to read our NIS2 compliance guide.

Response obligations to customers

DORA does not only bring response obligations to the competent authorities, but also to customers! Here is the excerpt in question, which is perfectly clear:

“Where a major ICT-related incident occurs and has an impact on the financial interests of clients, financial entities shall, without undue delay as soon as they become aware of it, inform their clients about the major ICT-related incident and about the measures that have been taken to mitigate the adverse effects of such incident.

In the case of a significant cyber threat, financial entities shall, where applicable, inform their clients that are potentially affected of any appropriate protection measures which the latter may consider taking.” – DORA, Article 19(3)

This customer outreach will obviously need to be based on your crisis communication plans – a matter addressed in section 10.

13. Monitor cyber threats

Knowledge is a weapon, in cybersecurity perhaps even more than elsewhere. Attackers compete in ingenuity to achieve their goals, and underestimating them would be a big mistake. A CISO therefore needs to be aware of the shifting cyber threat landscape. The annual OWASP Top 10 is a good start, but it is far from sufficient to understand all the risks. Monitoring must be assiduous, collective and continuous.

Cyber intelligence is a topic brought up by DORA in its Article 13. It states that financial entities must have the capacity and manpower to gather information on vulnerabilities and cyber threats. They must also continuously monitor technological developments to determine the impact their deployment may have on cybersecurity and digital operational resilience requirements.

Our recommendation is to set up an internal intelligence unit, composed of the most aware individuals on cyber topics, with regular sharing of findings. But this is just one of many avenues to explore.

An annual report published by the ESAs on major incidents in the financial sector

Article 22 of DORA requires ESAs to publish an annual, anonymized, aggregated report on major ICT incidents. The report should include, at a minimum, the number of major incidents, their nature and impact, the corrective actions taken and the costs. It will be accompanied by warnings and “high-level statistics”.

It is safe to assume that this annual report will be a staple of cyber intelligence in the financial sector.

Cyber threat information sharing arrangements between financial institutions

Mutual assistance within the banking system is encouraged by DORA. Chapter VI provides that financial entities may create arrangements to share information and intelligence on cyber threats among themselves, including indicators of compromise, techniques and tactics, and procedures and tools.

This information sharing between financial institutions should: 

• aim to enhance the digital operational resilience of entities;
• take place within trusted communities of financial entitiest;
• be based on mechanisms that protect the potentially sensitive nature of the information shared. These exchanges must be conducted in full respect of business confidentiality, GDPR and guidelines on competition policy.

The sharing arrangements must define the concrete modalities of sharing (where, how?) and the conditions of participation to be respected – for financial entities as well as for public authorities and ICT service providers. In addition, any financial entity participating in such a scheme must notify the relevant authorities.

14. Conduct “digital operational resilience testing”

We’re tackling another big piece of the regulation here. Digital operation resilience testing is an integral part of the digital operation resilience strategy, and DORA devotes its entire Chapter IV to it. We will refer to them as “resilience tests” or “security tests” for ease of reference.

Let’s be clear from the outset that most of these requirements do not apply to microenterprises. If this is your case, we invite you to read Chapter IV (especially Article 25.3) to determine what is applicable or not. There’s no need to drag out the suspense any longer, so let’s get down to business.

A 60-Page Guide to Dora Security Testing

We have written a comprehensive 60-page guide dedicated solely to the subject of security testing for DORA-regulated entities. We will therefore cover the subject only briefly in this article.

You can read our full guide to DORA security testing in the form of articles on our blog, or download it in PDF format below for easier reading.