DORA - frequently asked questions

The European Supervisory Authorities (ESAs) have been calling on Financial Entities (FEs) and third-party providers to advance their preparations to ensure their readiness. The Digital Operational Resilience Act (DORA) together with the technical standards and guidelines developed by the ESAs in January and July 2024 will apply from 17 January 2025. DORA does not provide for a transitional period. The majority of the requirements as specified in the level 1 regulation (EU 2022/2554) have been in force since January 2022. Therefore, the ESAs emphasise the importance of FEs adopting a robust, structured approach in order to meet their obligations in a timely manner.

The Central Bank expect firms to put in place a purposeful approach and have clearly and comprehensively identified gaps to compliance. The firm should be moving proactively to close those gaps, without delay. We will assess firms’ performance including by having regard to their starting point, the quality of their approach, and their ongoing track record of the timely closing of any gaps.

The Central Bank acknowledge that the efforts to comply with DORA may be higher for some FEs because they have been subject to less sectoral requirements regarding digital operational resilience management so far. Special attention may be required in areas such as advanced Threat Led Penetration Testing (TLPT), comprehensive ICT third party risk management framework, and registers of information.

The Central Bank expects FEs to prioritise the implementation of an ICT incident management process to detect, manage and to notify stakeholders of ICT incidents including identifying their root causes. This includes the reporting major ICT-related incidents in any case to the Central Bank from the 17 of January 2025. In addition,  FEs need to have their registers of ICT third-party providers’ contractual arrangements available for the Central Bank by 4 April 2025.

Under DORA a proportional approach does not mean that the requirements should be ignored, but that they should be implemented by Financial Entities (FEs) in a proportionate manner mindful of the risks and intended outcomes involved.

FEs are expected under DORA to understand their ICT-supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions and their roles and dependencies in relation to ICT risk. It is important to understand that when the Central Bank are applying proportionality – we will consider the risk from the perspective of not only the impact of individual firm, but also the nature of the risk.  For example, the nature of the risk can be characterised by its potential level of interconnectedness across sectors, or its connection to the ongoing provision of critical or important services across the sector.

DORA Proportionality in compliance with DORA is provided for in a number of ways 

1. Certain smaller size entities are out of scope along the lines of existing financial sector legislation;
   
   
2. The European Supervisory Authorities (ESAs) have reduced the scope of mandatory weekend reporting by focusing only on credit institutions, trading venues, central counterparties, other FEs within the scope of NIS2 designated at national level, and entities with significant and systemic impact at national level;
   
   
3. Only major incidents are required to be reported, and only a small subset of FEs are required to perform advanced Threat Lead Penetration Testing (TLPT);
   
   
4. The rules relating to the ICT Risk Management Framework (RMF) are required to be implemented proportionally, taking into account their size and overall risk profile and the nature, scale, and complexity of their activities and operations;
   
   
5. A simplified RMF is provided for certain types of FEs;
   
   
6. Some specific requirements do not apply for microenterprises;
   
   
7. With regard to Digital Operational Resilience (DOR) testing (chapter IV), DORA envisages that scoping of the DOR testing programme is based on a risk based approach with account of proportionality, considering the evolving threat landscape, any specific risks and the criticality of the information assets involved. For microenterprises DORA goes even further to recognise the balance between resources and time, versus urgency and type of risk when planning ICT testing;
   
   
8. Several requirements focus specifically on the Critical or Important functions of the FEs in scope and the information and ICT assets that support them; and
   
   
9. A number of the Level 2 texts (RTS on ICT RMF, RTS on Third Party Providers and Subcontracting) allow entities to consider elements of increased or reduced complexity of its services, activities and operations.

The Central Bank would also note that, under article 6(5) of DORA, FEs are required to document and review their risk management framework at least once a year, or periodically in the case of microenterprises, and that the ESAs have helpfully provided a template of the report on the ICT risk management framework review in article 27 of the RTS on the ICT Risk management framework (EU 2024/1774). 

We expect FEs to demonstrate that they have duly considered and documented their assessment of these aspects of proportionality: critical functions, dependence on in-house and contracted ICT services and systems and the implications a total loss or severe degradation of such systems would have in terms of Critical or Important functions and market efficiency.

Article 2 of DORA sets out which Financial Entities (FEs) are in scope for DORA and which are excluded. FEs should consider the authorisation they hold, and carefully read article 2, in conjunction with the definitions of entity types in Article 3 to understand if they are directly in scope of DORA.

If your FE type is listed in those circa 20 entity types in Article 2, and if you are not exempt under Article 2(3), then the requirements of DORA apply. So, whether your FE is a credit institution, or a crowdfunding service provider – if your FE type is on the list, it is in scope.  

For example, the Central Bank has been asked if “Fund Administrators and Depositories” are in the full scope for DORA?  A blanket yes/no answer to that question cannot be given.  The scope of DORA applies to types of FE, not the activities they carry out.  Therefore, if you are wondering, whether a FE is within the scope of DORA – as above, check your FE’s authorisation to confirm the type of entity.  Then check this against the list of entity types in Article 2. When doing so, you will need to read the definitions in Article 3. Our current understanding is that fund administrators who are authorised solely under the national Investment Intermediaries Act will not be in the direct scope of DORA.

Entities which passport into Ireland, under European freedom of establishment, are regulated by the Central Bank for conduct of business rules, and Ireland is the “Host” country. The requirements under DORA will be supervised by the Competent Authority (CA) responsible for prudential supervision, the “Home” country. Therefore, for example, when completing the Register of Information (RoI), a branch operating in Ireland is not required to submit a RoI to the Central Bank.  However, if the legal entity that oversees that branch is established elsewhere in the EU, it is that entity that will be required to submit a RoI capturing any relevant information in relation to the branch and submit it to the “Home” CA. This is without prejudice to responsibilities under national rules of conduct.

Even if a FE falls outside the scope for DORA, FEs are still encouraged to use DORA as a benchmark of effective practice. DORA is an excellent framework and source of information, which can support any FE in looking to manage its ICT risks as best it can, for their own and clients’ benefit.  This is complemented by three Central Bank Cross Industry guidance documents on IT & Cyber security risk management, Operational Resilience and Outsourcing.

A small number of Financial Entities (FEs) are currently subject to the original Network and Information Systems (NIS) regulations. Both NIS2 and Critical Entities Resilience Directive (CER) are pieces of legislation that focus on increasing operational resilience across a wide range of sectors including energy, telecoms, digital infrastructure, and certain elements of the financial sector. NIS2 focusses on cybersecurity and CER focusses on physical infrastructure.

DORA operates as lex specialis for NIS2 and Article 11 and Chapters III, IV and VI of CER so in specific areas, DORA will override other directives.  Specifically, this means that the incident reporting and risk management measures in NIS2 and CER will not apply for FEs, and DORA will apply instead. Also when NIS2 is transposed, which will not be before DORA, the existing incident reporting requirements to the Computer Security Incident Response Team (CSIRT) in the National Cyber Security Centre (NCSC), which currently apply to less than 10 FEs will cease.

While NIS2 requirements therefore will not apply to FEs, which are in scope of DORA, the Central Bank will be a Competent Authority (CA) under both pieces of legislation. The Central Bank continues to have strong engagement with the other relevant CAs for NIS2 and CER in Ireland.  One very important area of NIS2 collaboration is with ComReg who will be the CA responsible for supervising digital infrastructure. This is likely to overlap somewhat with the oversight regime in DORA for Critical ICT Third Party Providers.  The Central Bank are also engaging with the Department of Defence on CER and will be working with them on the identification of critical entities.

Article 3 of DORA defines an ‘ICT third-party service provider’ as an undertaking providing ICT services. ‘ICT services’ are defined as digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis.  This includes hardware as a service, including the provision of technical support via software, or firmware updates by the hardware provider. However, this excludes traditional analogue telephone services.

A number of queries have been received by the Central Bank as to whether various entity types, which provide financial services, are also considered ICT Third Party Providers (TPP) under DORA. This is an open question at the joint ESAs’ Q&A, which has been prioritised. The Central Bank will align its approach to the European position on this approach when it is available.  In the meantime, please refer to the joint Q&As on the ESAs websites for further developments.

Chapter II of DORA provides the key principles of ICT risk management and Chapter V of DORA provides the key principles for a sound management of ICT third party risk, the key steps of which are summarised below.

Step 1

As required by Chapter II of DORA, identify, classify and document all the:

• ICT supported business functions;
• Roles and Responsibilities, and
• The information and ICT assets supporting those functions and their roles and dependencies in relation to ICT risk.

Financial Entities (FEs) need to perform an annual review of the adequacy of the classification and of any relevant documentation. A core outcome of this review is that FEs are clear, which of these functions are considered critical and who the providers are of these functions.

When documenting their methodology for the classification, FEs should refer to the Central Bank’s Cross Industry guidance on outsourcing. This provides guidance in determining the criticality or importance of the activity or service outsourced.

Step 2

Identify all sources of ICT risk in relation to those ICT supported business functions, and continue to monitor, manage and assess these risks on a continuous basis.  As part of this, FEs will:

• Set a clear risk appetite;
• Including impact tolerances for ICT disruptions.

Step 3

As required in DORA chapter V on ICT third-party risk, ensure that your FE has taken necessary steps to manage ICT third-party risk as an integral component of ICT risk within a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system. Two key principles in doing this are that

a.   FEs that have in place contractual arrangements for the use of ICT services to run their business operations shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under DORA and applicable financial services law;

b.   FEs’ management of ICT third-party risk shall be implemented in light of the principle of proportionality, taking into account:

• i. the nature, scale, complexity and importance of ICT-related dependencies;

• ii. the risks arising from contractual arrangements on the use of ICT services concluded with ICT third-party service providers, taking into account the criticality or importance of the respective service, process or function, and the potential impact on the continuity and availability of financial services and activities, at individual and at group level. Specific key contractual provisions to be ensured are listed in article 30 of DORA.

As a key element of the ICT risk management framework, the Central Bank expects FEs to have developed a clear strategy on ICT third-party risk, which shall include a policy on the use of ICT services supporting critical or important functions provided by ICT third-party service providers.

Step 4

You should ensure that you have strong oversight of your FE’s third party providers and develop a good working relationship with them.  You will need to work with your FE’s third party provider to:

• Identify any systems in the third party that your FE is reliant upon, and which underpin critical and important services;
• Ensure such systems are appropriately protected;
• Put in place regular reporting of performance, for example changes to subcontractors;
• Ensure that the necessary mechanisms are in place to promptly detect unusual activity;
• Ensure there are processes in place, with third party providers, so that the FE is informed of incidents promptly, so that they can be appropriately managed and that the FE is in a position to be compliant with the reporting requirements of DORA; and
• Ensure that the third party provider has plans and capabilities in place to ensure recovery of the FEs activities within a reasonable timeframe, depending on the service.That plan may include your FE providing direct assistance to restore service.

In order to underpin this oversight, FEs should look to strengthen the contractual agreements in place with TPPs, and when reviewing these contracts ensure to include, in particular, the following:

• Contractual requirements in relation to audit rights;
• The inclusion of the TPP in the digital operational resilience testing of the FE, advanced Threat Led Penetration Testing (TLPT) where relevant, and business continuity tests; and
• Transparency of the subcontracting chain and changes to this.

The Central Bank does not plan to introduce new Pre-Approved Controlled Functions (PCF) roles specific to DORA compliance as part of DORA coming into application in January 2025. The Individual Accountability Framework (IAF) has recently been introduced, and as part of this process the Central Bank undertook a review of the PCF roles. The IAF requires in-scope firms and their senior management to implement an effective governance framework by identifying how the business and its risks are being managed. The role of PCF-49 – Chief Information Officer in October 2020 should be noted.

At time of writing in December 2024, there are a number of different reporting requirements in place including Payment Services Directive 2 (PSD2) major incident reporting. Each of these reporting requirements applies to a different range of Financial Entities (FEs). For a number of FE types there are no formal reporting requirements for ICT related incidents. DORA aims to introduce a harmonised and streamlined regime for major incident reporting for all FE types with consistent timelines, templates and guidance supported by inbuilt proportionality in areas like reporting thresholds and weekend reporting. Therefore DORA will replace existing reporting requirements and FEs will only need to report to their home authority, who will forward it to other relevant supervisory authorities as set out in DORA.

The incident reporting templates have also been designed so that the amount of information required at the initial stages of an incident focuses on key information, with more information required in subsequent reports as the incident evolves. This approach aims to reduce the burden on FEs of reporting different information to multiple authorities, particularly in the initial stages of an incident.

DORA sets out the criteria Financial Entities (FEs) should use to classify and assess the impact of incidents, looking at metrics such as number of clients/financial counterparts/transactions affected, duration of the incident, geographical spread, criticality of services affected and data losses. These criteria help FEs determine the actions and resources required to manage and resolve an incident.

The type of incidents that should be classified as major and reported to the Central Bank are outlined in the Regulatory Technical Standards (RTS) on criteria for the classification for ICT related incidents. This RTS sets out the materiality thresholds for each of the criteria and how many need to be met for an incident to be considered major.  There is a graphical summary and table of these criteria on page 8 of the European Supervisory Authorities’ (ESAs) final report on the technical standards specifying the criterion for the classification of ICT related incidents under DORA – JC 2023 83 – which may be support understanding the classification criteria.

It is recognised that it can be challenging in the early stages of an incident to be exact on impacts and therefore classification as ‘major’, the RTS suggests using estimates or data from comparable periods (e.g. based on previous incidents and existing knowledge on services).

It is important for the Central Bank to know at the earliest possible stages of an incident that could be major, especially where multiple entities or sectors could be affected. The timely mitigation of risks stemming from an incident will likely require close collaboration between the Central Bank and the financial entity. Therefore, firms are encouraged to consider the potential impact of an incident and look beyond reporting as a purely compliance exercise and engage early with their supervisory teams in the Central Bank.

Also where a major incident is reported, FEs can reclassify an incident as non-major when further information becomes available.

The major incident reporting criteria and materiality thresholds apply to each Financial Entity (FE) individually regardless of where the incident occurred (i.e. within the FE’s systems or those of a third party providers). Therefore, if the impact of an incident meets the materiality thresholds set out in the RTS on the criteria for the classification for ICT related incidents , then it should be reported as a major incident, notwithstanding that the root cause may be in a third party.

DORA introduces a new reporting template, for submitting Registers of Information (RoI). Critical third party providers should be captured at a minimum in the first submission and the Financial Entity (FE) should look through the chain to understand the significant third parties in terms of operational resilience. Where it is difficult for a firm to have oversight of the full chain, the Central Bank and European Supervisory Authorities (ESAs) will work with you to continuously improve quality.  The core objective being to manage providers in a holistic way and focus on key providers.

The Registers of Information (RoI) template will have changed from that used in the Dry Run for the next submission. The best course of action to understand how to fill in the RoI templates is to ensure you watch the European Supervisory Authorities (ESAs) website for information on the workshop they will be holding on 18 December 2024 and ensure that you register and attend the workshop to get the most up-to-date information.

DORA is specific on the use of internal or external testers for advanced Threat Led Penetration Testing (TLPT) for that subset of entities that are in scope of TLPT under DORA

Chapter IV of DORA sets out the conditions for when using internal testers for TLPT, which are:

• Such use has been approved by the relevant competent authority or by the single public authority designated in accordance with Article 26(9) and (10);
• The relevant competent authority has verified that the financial entity has sufficient dedicated resources and ensured that conflicts of interest are avoided throughout the design and execution phases of the test;
• Ensured that conflicts of interest are avoided throughout the design and execution phases of the test; and
• The threat intelligence provider is external to the financial entity.

Many existing compliance certificates are focused on assuring compliance with specific, minimal requirements and potentially focussed on a limited set of ICT systems – e.g. the systems used to produce the financial statements. DORA is different - DORA places responsibility for ensuring the Digital Operational Resilience of the activities of Financial Entities (FEs) at the heart of their operations. It requires the resources including activities, organisation, policies, procedures, tools, processes and personnel to be in place to enable FEs to maintain their Digital Operational Resilience in a continually evolving environment. FEs need to be able to absorb shocks, bend and recover without breaking when disruption occurs. It is not a point in time certification.

The Central Bank expects FEs to apply DORA in order to ensure their Digital Operational Resilience, which is in their own interest.

In respect of advanced Threat-Led Penetration Testing (TLPT), the Central Bank will engage directly with in-scope firms in the coming weeks.

Please note this will only apply on a mandatory basis to a limited number of firms that meet the criteria under DORA.

For TLPT specific queries, please contact [email protected].