DORA - frequently asked questions

Page last updated 12 February 2026

Supervisory Approach

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 2024 and July 2025 have applied since those dates. 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, including the Central Bank of Ireland, emphasise the importance of FEs adopting a robust, structured approach in order to meet their obligations in a timely manner.

In 2025 financial entities (FEs) should have put in place a purposeful approach and clearly and comprehensively identify gaps to compliance. These gaps should now be substantially addressed. We will assess firms’ performance the quality of their approach to addressing any gaps and their ongoing track record of the timely closing of any remaining 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 prior to DORA. Special attention may have  been required in areas such as advanced Threat Led Penetration Testing (TLPT), comprehensive ICT third party risk management framework, and registers of information. As Dora has now been in full application for more than one year, the Central Bank would expect that Financial Entities will readily be able to share a copy of their individual reports on the review of the ICT risk management framework required to be completed annually as per Article 6(5) and Article 16 of DORA and whose contents are specified in the RTS on the ICT risk management framework.

FEs should also remember that DORA is not a ‘once and done’ activity. They should have implemented ongoing activities to ensure they continue to enhance their capabilities to adequately assess, monitor, defend against, and respond to and learn from ICT risks and cyber threats.

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;

  4. Only a small subset of FEs are required to perform advanced Threat Lead Penetration Testing (TLPT);

  5. 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;

  6. A simplified RMF is provided for certain types of FEs;

  7. Some specific requirements do not apply for microenterprises;

  8. With regard to Digital Operational Resilience (DOR) testing (chapter IV), DORA envisages that scoping of the DOR testing programme is based on a  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;

  9. 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

  10. 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 the required content 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.

Scope of Application of DORA

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.

FEs are advised to regularly monitor the Q&A published by the ESAs as this will provide up to date clarification on the scope of entities for DORA. For example, in December 2025 the ESAs published a Q&A specifically dealing with DORA application to third-country branches

ICT Third Party Risk Management

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.

The ESAs have provided clarification in their Q&A to assist financial entities in identifying whether a particular third-party service provider should be considered an ICT third-party service provider.

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; and
  • 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, including 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 or 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, 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 - should be noted.

Major Incident Reporting & Cyber Threat Intelligence Sharing

DORA aims to introduce a harmonised and streamlined regime for major incident reporting for all in-scope FEs with consistent timelines, templates and guidance supported by inbuilt proportionality in areas like reporting thresholds and weekend reporting. Therefore, DORA will replace existing PSD2 operational or security incident 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.

Submission of Registers of Information (Rol)

DORA introduces a reporting template, for submitting Registers of Information (RoI). Critical third party providers should have been captured, at a minimum, in the first submission in 2025. The Financial Entity (FE) should understand the significant third parties in their chain 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.

Digital Operational Resilience Testing

Only a subset of FEs are required to perform advanced TLPT under DORA.

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. These include but are not limited to:

  • 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;
  • Ensuring 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) are 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 should posses the ability 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 has engaged directly with in-scope firms. An identification exercise is carried out annually and any additional firms identified will be engaged with on a timely basis.

Please note this will only apply to firms that meet the specific DORA TLPT selection criteria.

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

DORA Register of Information Feb 2026 Briefing FAQs

We would advise Financial Entities to check EBA FAQs 52 and 53 in this regard.

The EBA advised that the LEI requirement would be a non-blocking rule in the early register submissions (we believe this still applies for 2026). Per their FAQ 47, there are number of values which can be reported in B_05.01.0020 if you do not yet have an LEI for a TPP. However, the aim though, is for all TPPs to have an LEI/ EU-ID.

No. As per EBA FAQ 69, Article 28(3) of DORA requires the financial entities to maintain and update a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers (ICT TPPs), so all such providers should be identified in template B_05.01.

Digital Operational Resilience Testing

Only a subset of FEs are required to perform advanced TLPT under DORA. DORA is specific on the use of internal or external testers for advanced Threat Led Penetration Testing (TLPT) for that subset of entities.

Chapter IV of DORA sets out the conditions for when using internal testers for TLPT. These include but are not limited to:

  • 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;
  • Ensuring 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) are 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 should possess the ability 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 has engaged directly with in-scope firms. An identification exercise is carried out annually and any additional firms identified will be engaged with on a timely basis.

Please note this will only apply to firms that meet the specific DORA TLPT selection criteria.

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