DORA ICT Risk and Resilience Operations — Articles 7–23

Articles 7 to 23 of DORA, Regulation (EU) 2022/2554, give obligations of financial entities, and also tasks of the ESAs and the competent authorities. Articles 7 to 14 give parts of the ICT risk management framework “referred to in Article 6(1)”. Article 15 tells the ESAs to make regulatory technical standards for that framework. See Article 5 on management body governance and Article 6 on the ICT risk management framework. Chapter III of DORA, Articles 17 to 23, is about ICT-related incidents: the ICT-related incident management process, the classification, and the reports.

Articles 7 to 14 — parts of the ICT risk management framework

DORA Articles 7 to 14 give obligations of financial entities that are parts of the ICT risk management framework of Article 6(1). For Article 16(1) entities, Article 16(1)(a) to (h) and Article 16(2) and Delegated Regulation (EU) 2024/1774, Title III, give obligations, and Articles 5 to 15 do not apply.

Many paragraphs of Articles 7 to 14 apply only to financial entities other than microenterprises. Each section below names these paragraphs.

Article 7 — ICT systems, protocols and tools

DORA Article 7 tells financial entities to use and keep “updated ICT systems, protocols and tools” that are:

• (a) “appropriate to the magnitude of operations supporting the conduct of their activities, in accordance with the proportionality principle as referred to in Article 4”
• (b) “reliable”
• (c) of sufficient capacity to “accurately process the data necessary for the performance of activities and the timely provision of services”, and to “deal with peak orders, message or transaction volumes, as needed, including where new technology is introduced”
• (d) “technologically resilient in order to adequately deal with additional information processing needs as required under stressed market conditions or other adverse situations”.

Article 8 — Identification

DORA Article 8(1) gives the first obligation:

As part of the ICT risk management framework referred to in Article 6(1), financial entities shall identify, classify and adequately document all 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. Financial entities shall review as needed, and at least yearly, the adequacy of this classification and of any relevant documentation.

The other paragraphs of Article 8 give these obligations:

• Article 8(2): financial entities identify all sources of ICT risk continuously, “in particular the risk exposure to and from other financial entities”. They continuously “assess cyber threats and ICT vulnerabilities relevant to their ICT supported business functions, information assets and ICT assets”. They examine their risk scenarios “on a regular basis, and at least yearly”.
• Article 8(3): financial entities other than microenterprises do a risk assessment “upon each major change in the network and information system infrastructure, in the processes or procedures affecting their ICT supported business functions, information assets or ICT assets”.
• Article 8(4): financial entities identify all information assets and ICT assets, “including those on remote sites, network resources and hardware equipment”. They map “those considered critical”. They also map “the configuration of the information assets and ICT assets and the links and interdependencies between the different information assets and ICT assets”.
• Article 8(5): financial entities must “identify and document all processes that are dependent on ICT third-party service providers”. They also identify the “interconnections with ICT third-party service providers that provide services that support critical or important functions”.
• Article 8(6): for paragraphs 1, 4, and 5, financial entities keep inventories. They must “update them periodically and every time any major change as referred to in paragraph 3 occurs”.
• Article 8(7): financial entities other than microenterprises do a “specific ICT risk assessment on all legacy ICT systems” “on a regular basis, and at least yearly”, and “in any case before and after connecting technologies, applications or systems”.

Article 9 — Protection and prevention

DORA Article 9(1) tells financial entities to “continuously monitor and control the security and functioning of ICT systems and tools”. It also tells them to “minimise the impact of ICT risk on ICT systems through the deployment of appropriate ICT security tools, policies and procedures”. The other paragraphs give these obligations:

• Article 9(2): financial entities “design, procure and implement ICT security policies, procedures, protocols and tools that aim to ensure the resilience, continuity and availability of ICT systems, in particular for those supporting critical or important functions, and to maintain high standards of availability, authenticity, integrity and confidentiality of data, whether at rest, in use or in transit”.
• Article 9(3): financial entities use “ICT solutions and processes that are appropriate in accordance with Article 4”. These must “ensure the security of the means of transfer of data” (point (a)). They must “minimise the risk of corruption or loss of data, unauthorised access and technical flaws that may hinder business activity” (point (b)). They must “prevent the lack of availability, the impairment of the authenticity and integrity, the breaches of confidentiality and the loss of data” (point (c)). They must “ensure that data is protected from risks arising from data management” (point (d)).
• Article 9(4), first subparagraph: as part of the ICT risk management framework of Article 6(1), financial entities must:
  • (a) “develop and document an information security policy defining rules to protect the availability, authenticity, integrity and confidentiality of data, information assets and ICT assets, including those of their customers, where applicable”
  • (b) “establish a sound network and infrastructure management structure”, “following a risk-based approach”
  • (c) “implement policies that limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only, and establish to that end a set of policies, procedures and controls that address access rights and ensure a sound administration thereof”
  • (d) “implement policies and protocols for strong authentication mechanisms, based on relevant standards and dedicated control systems, and protection measures of cryptographic keys whereby data is encrypted based on results of approved data classification and ICT risk assessment processes”
  • (e) “implement documented policies, procedures and controls for ICT change management, including changes to software, hardware, firmware components, systems or security parameters, that are based on a risk assessment approach and are an integral part of the financial entity’s overall change management process, in order to ensure that all changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner”
  • (f) have “appropriate and comprehensive documented policies for patches and updates”.

For point (b) of Article 9(4), financial entities “shall design the network connection infrastructure in a way that allows it to be instantaneously severed or segmented”. For point (e), the ICT change management process “shall be approved by appropriate lines of management and shall have specific protocols in place”.

Article 10 — Detection

DORA Article 10 gives these obligations:

• Article 10(1): financial entities have mechanisms “to promptly detect anomalous activities, in accordance with Article 17”, for example “ICT network performance issues and ICT-related incidents”. The mechanisms also identify “potential material single points of failure”. Financial entities test all detection mechanisms at regular intervals, as Article 25 tells them.
• Article 10(2): the detection mechanisms “enable multiple layers of control”. They set alert thresholds and criteria to “trigger and initiate ICT-related incident response processes”. These include automatic alert mechanisms “for relevant staff in charge of ICT-related incident response”.
• Article 10(3): financial entities give “sufficient resources and capabilities to monitor user activity, the occurrence of ICT anomalies and ICT-related incidents, in particular cyber-attacks”.
• Article 10(4): data reporting service providers also have systems that “can effectively check trade reports for completeness, identify omissions and obvious errors, and request re-transmission of those reports”.

Article 11 — Response and recovery

DORA Article 11(1) tells financial entities to have “a comprehensive ICT business continuity policy”. This policy is part of the ICT risk management framework of Article 6(1), and it is “based on the identification requirements set out in Article 8”. The policy is “an integral part of the overall business continuity policy of the financial entity”. The other paragraphs give these obligations:

• Article 11(2): financial entities apply the ICT business continuity policy through “dedicated, appropriate and documented arrangements, plans, procedures and mechanisms”. These must:
  • (a) “ensure the continuity of the financial entity’s critical or important functions”
  • (b) “quickly, appropriately and effectively respond to, and resolve, all ICT-related incidents”
  • (c) “activate, without delay, dedicated plans that enable containment measures”
  • (d) “estimate preliminary impacts, damages and losses”
  • (e) “set out communication and crisis management actions”, as Article 14 tells them, and report to the competent authorities as Article 19 tells them.
• Article 11(3): financial entities have ICT response and recovery plans. For financial entities other than microenterprises, these ICT response and recovery plans are “subject to independent internal audit reviews”.
• Article 11(4): financial entities “put in place, maintain and periodically test appropriate ICT business continuity plans, notably with regard to critical or important functions outsourced or contracted through arrangements with ICT third-party service providers”.
• Article 11(5): financial entities do a business impact analysis (BIA) “of their exposures to severe business disruptions”. They must “assess the potential impact of severe business disruptions by means of quantitative and qualitative criteria, using internal and external data and scenario analysis, as appropriate”. The BIA must “consider the criticality of identified and mapped business functions, support processes, third-party dependencies and information assets, and their interdependencies”. Financial entities must “ensure that ICT assets and ICT services are designed and used in full alignment with the BIA, in particular with regard to adequately ensuring the redundancy of all critical components”.
• Article 11(6): financial entities test the ICT business continuity plans and the ICT response and recovery plans “in relation to ICT systems supporting all functions at least yearly”. They also test them after “any substantive changes to ICT systems supporting critical or important functions”. They also test the crisis communication plans of Article 14. Financial entities other than microenterprises “shall include in the testing plans scenarios of cyber-attacks and switchovers between the primary ICT infrastructure and the redundant capacity, backups and redundant facilities”. All financial entities “regularly review their ICT business continuity policy and ICT response and recovery plans, taking into account the results of tests carried out in accordance with the first subparagraph and recommendations stemming from audit checks or supervisory reviews”.
• Article 11(7): financial entities other than microenterprises have a crisis management function.
• Article 11(8): financial entities keep “readily accessible records of activities before and during disruption events when their ICT business continuity plans and ICT response and recovery plans are activated”.
• Article 11(9): central securities depositories give the competent authorities “copies of the results of the ICT business continuity tests, or of similar exercises”.
• Article 11(10): financial entities other than microenterprises report to the competent authorities, “upon their request, an estimation of aggregated annual costs and losses caused by major ICT-related incidents”.

DORA Article 11(11) told the ESAs to make “common guidelines” on how to estimate these costs and losses. The ESAs had to do this through the Joint Committee by 17 July 2024. The ESAs Joint Guidelines JC 2024 34 are these guidelines. They are guidelines, not a Commission Regulation (see ESAs Joint Guidelines JC 2024 34).

Article 12 — backup, restoration, and recovery

DORA Article 12 gives these obligations:

• Article 12(1): as part of their ICT risk management framework, financial entities “develop and document” backup policies and procedures, and restoration and recovery procedures and methods. The backup policies and procedures give “the scope of the data that is subject to the backup and the minimum frequency of the backup”.
• Article 12(2): financial entities must have backup systems that they can activate “in accordance with the backup policies and procedures, as well as restoration and recovery procedures and methods”. When the entity starts these systems, it must not “jeopardise the security of the network and information systems or the availability, authenticity, integrity or confidentiality of data”. They test the backup procedures and the restoration and recovery procedures and methods at intervals.
• Article 12(3): “When restoring backup data using own systems”, financial entities use ICT systems that are “physically and logically segregated from the source ICT system”. These systems must be “securely protected from any unauthorised access or ICT corruption” and “allow for the timely restoration of services making use of data and system backups as necessary”. “For central counterparties, the recovery plans shall enable the recovery of all transactions at the time of disruption”. Data reporting service providers also have “back-up and restoration facilities”.
• Article 12(4): financial entities other than microenterprises keep redundant ICT capacities. Microenterprises must “assess the need to maintain such redundant ICT capacities based on their risk profile”.
• Article 12(5): central securities depositories keep “at least one” secondary processing site. The secondary processing site must be:
  • (a) “located at a geographical distance from the primary processing site to ensure that it bears a distinct risk profile and to prevent it from being affected by the event which has affected the primary site”
  • (b) “capable of ensuring the continuity of critical or important functions identically to the primary site, or providing the level of services necessary to ensure that the financial entity performs its critical operations within the recovery objectives”
  • (c) “immediately accessible to the financial entity’s staff to ensure continuity of critical or important functions in the event that the primary processing site has become unavailable”.
• Article 12(6): financial entities set recovery time objectives and recovery point objectives for each function. They “take into account” if the function is a critical or important function, and “the potential overall impact on market efficiency”. These “time objectives” must “ensure that, in extreme scenarios, the agreed service levels are met”.
• Article 12(7): “When recovering from an ICT-related incident”, financial entities do the “necessary checks, including any multiple checks and reconciliations, in order to ensure that the highest level of data integrity is maintained”.

Article 13 — Learning and evolving

DORA Article 13 gives these obligations:

• Article 13(1): financial entities have the “capabilities and staff” to collect information on vulnerabilities, cyber threats, and ICT-related incidents, “in particular cyber-attacks”. They “analyse the impact they are likely to have on their digital operational resilience”.

• Article 13(2): financial entities do post ICT-related incident reviews “after a major ICT-related incident disrupts their core activities”. These reviews include “analysing the causes of disruption and identifying required improvements to the ICT operations or within the ICT business continuity policy referred to in Article 11”. They must “determine whether the established procedures were followed and the actions taken were effective, including in relation to the following”:

  • (a) “the promptness in responding to security alerts and determining the impact of ICT-related incidents and their severity”
  • (b) “the quality and speed of performing a forensic analysis, where deemed appropriate”
  • (c) “the effectiveness of incident escalation within the financial entity”
  • (d) “the effectiveness of internal and external communication”.

  Financial entities other than microenterprises tell the competent authorities, “upon request”, the changes that they made after these post ICT-related incident reviews.

• Article 13(3): financial entities must continuously include these inputs in the ICT risk assessment process:

  • “Lessons derived from the digital operational resilience testing carried out in accordance with Articles 26 and 27 and from real life ICT-related incidents, in particular cyber-attacks”
  • “challenges faced upon the activation of ICT business continuity plans and ICT response and recovery plans”
  • “relevant information exchanged with counterparts and assessed during supervisory reviews”.

  These results must be “the basis for appropriate reviews of relevant components of the ICT risk management framework referred to in Article 6(1)”.

• Article 13(4): financial entities “monitor the effectiveness of the implementation of their digital operational resilience strategy set out in Article 6(8)”.

• Article 13(5): “Senior ICT staff shall report at least yearly to the management body on the findings referred to in paragraph 3 and put forward recommendations.”

• Article 13(6): financial entities have “ICT security awareness programmes and digital operational resilience training as compulsory modules in their staff training schemes”. These must apply to “all employees and to senior management staff” and have “a level of complexity commensurate to the remit of their functions”. “Where appropriate”, they include ICT third-party service providers, as Article 30(2), point (i), tells them.

• Article 13(7): financial entities other than microenterprises monitor “relevant technological developments on a continuous basis”.

Article 14 — Communication

DORA Article 14 gives 3 obligations. Only Article 14(1) is about crisis communication:

• Article 14(1): as part of the ICT risk management framework of Article 6(1), financial entities have 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”.
• Article 14(2): financial entities have “communication policies for internal staff and for external stakeholders”.
• Article 14(3): “At least one person in the financial entity shall be tasked with implementing the communication strategy for ICT-related incidents and fulfil the public and media function for that purpose.”

Articles 15 and 16(3) — technical standards for the framework

DORA Article 15 told the ESAs to make common draft regulatory technical standards, through the Joint Committee and “in consultation with” ENISA. These standards give more requirements for these items:

• (a) the “ICT security policies, procedures, protocols and tools referred to in Article 9(2)”
• (b) the “controls of access management rights referred to in Article 9(4), point (c)”
• (c) the detection mechanisms of Article 10(1) and the criteria of Article 10(2)
• (d) the ICT business continuity policy of Article 11(1)
• (e) the tests of the ICT business continuity plans of Article 11(6)
• (f) the ICT response and recovery plans of Article 11(3)
• (g) “the content and format of the report on the review of the ICT risk management framework referred to in Article 6(5)”.

Article 15 lets the Commission adopt these standards. The result is Title II of Delegated Regulation (EU) 2024/1774 of 13 March 2024. Article 16(3) gave the ESAs the same type of task for the simplified ICT risk management framework of Article 16(1). The result is Title III of the same Regulation. For the full name of the Regulation, see the eight Commission Regulations. For the simplified ICT risk management framework, see Article 16.

The ESAs statement on ICT risks from frontier AI models

In ESA Statement JC 2026 25 of 31 July 2026, the ESAs “encourage financial entities, taking into account the expectations of their supervisory authorities, to adjust ICT risk management processes, procedures and controls” with “prevention”, “detection”, and “management”. The statement tells financial entities: “It is expected that financial entities implement measures in a proportionate manner”, and its Annex “does not establish additional requirements”. For the EU AI Act, see EU AI Act.

Article 17 — ICT-related incident management process

DORA Article 17(1) gives the obligation of financial entities:

Financial entities shall define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents.

Article 17(2) tells financial entities to record all ICT-related incidents and significant cyber threats. It also tells them to have procedures “to ensure a consistent and integrated monitoring, handling and follow-up of ICT-related incidents, to ensure that root causes are identified, documented and addressed”.

In Article 17(3), the ICT-related incident management process must:

• (a) “put in place early warning indicators”
• (b) “establish procedures to identify, track, log, categorise and classify ICT-related incidents according to their priority and severity and according to the criticality of the services impacted, in accordance with the criteria set out in Article 18(1)”
• (c) give the roles and responsibilities “for different ICT-related incident types and scenarios”
• (d) “set out plans for communication to staff, external stakeholders and media in accordance with Article 14”, for the notification of clients, for “internal escalation procedures, including ICT-related customer complaints”, and for information to “financial entities that act as counterparts, as appropriate”
• (e) make sure that “at least major ICT-related incidents are reported to relevant senior management”, and tell the management body about them, “explaining the impact, response and additional controls to be established”
• (f) “establish ICT-related incident response procedures to mitigate impacts and ensure that services become operational and secure in a timely manner”.

For financial entities that apply the ICT risk management framework of Article 6(1), Delegated Regulation (EU) 2024/1774, Article 22, adds an “ICT-related incident policy”. With this policy, the entity must “document the ICT-related incident management process” of Article 17. In Article 22(d), the entity must keep “all evidence relating to ICT-related incidents”. The period must be:

• “no longer than necessary for the purposes for which the data are collected”
• “commensurate with the criticality of the affected business functions, supporting processes, and ICT and information assets”
• “in accordance with Article 8(2) of Commission Delegated Regulation (EU) 2024/1772”, as corrected on 15 May 2025 (OJ L, 2025/90420)
• “with any applicable retention requirement pursuant to Union law”.

In the last subparagraph of Article 22, the entity must “retain the evidence referred to in that point in a secure manner”.

Article 18 — classification of ICT-related incidents and cyber threats

DORA Article 18(1) gives the criteria for the classification of ICT-related incidents:

Financial entities shall classify ICT-related incidents and shall determine their impact based on the following criteria:

(a) the number and/or relevance of clients or financial counterparts affected and, where applicable, the amount or number of transactions affected by the ICT-related incident, and whether the ICT-related incident has caused reputational impact;

(b) the duration of the ICT-related incident, including the service downtime;

(c) the geographical spread with regard to the areas affected by the ICT-related incident, particularly if it affects more than two Member States;

(d) the data losses that the ICT-related incident entails, in relation to availability, authenticity, integrity or confidentiality of data;

(e) the criticality of the services affected, including the financial entity’s transactions and operations;

(f) the economic impact, in particular direct and indirect costs and losses, of the ICT-related incident in both absolute and relative terms.

Article 18(1) gives no other criteria. Article 18(2) tells financial entities to “classify cyber threats as significant” with 3 criteria: “the criticality of the services at risk”, the “number and/or relevance of clients or financial counterparts targeted”, and “the geographical spread of the areas at risk”.

Article 18(3) told the ESAs to make common draft regulatory technical standards, through the Joint Committee and “in consultation with the ECB and ENISA”. These standards give:

• the criteria of Article 18(1), with the materiality thresholds for major ICT-related incidents and major operational or security payment-related incidents
• “the criteria to be applied by competent authorities for the purpose of assessing the relevance of major ICT-related incidents”, or of major operational or security payment-related incidents, to competent authorities in other Member States
• “the details of reports of major ICT-related incidents”, or of major operational or security payment-related incidents, “to be shared with other competent authorities pursuant to Article 19(6) and (7)”
• the criteria of Article 18(2), with the “high materiality thresholds for determining significant cyber threats”.

The result is Delegated Regulation (EU) 2024/1772 (see the eight Commission Regulations).

DORA Article 18 gives criteria, but no materiality thresholds. Delegated Regulation (EU) 2024/1772 gives the materiality thresholds.

Article 6 of that Regulation identifies the “critical services” for this test. Financial entities must “assess whether the incident”:

• (a) “affects or has affected ICT services or network and information systems that support critical or important functions of the financial entity”
• (b) “affects or has affected financial services provided by the financial entity that require authorisation, registration or that are supervised by competent authorities”
• (c) “constitutes or has constituted a successful, malicious and unauthorised access to the network and information systems of the financial entity”.

Article 8 gives these classification rules:

• Article 8(1): an incident is a major incident if it “has affected critical services as referred to in Article 6”, and one of these conditions applies:
  • the materiality threshold of Article 9(5), point (b), “is met”. This materiality threshold applies where “any successful, malicious and unauthorised access not covered by point (a) occurs to network and information systems, where such access may result in data losses”
  • 2 or more of the other materiality thresholds of Article 9(1) to (6) “are met”.
• Article 8(2): recurring incidents that are not major incidents one by one are one major incident if all of these conditions apply:
  • they “have occurred at least twice within 6 months”
  • they have “the same apparent root cause”
  • they “collectively fulfil the criteria for being considered a major incident set out in paragraph 1”.
• Article 8(2), last subparagraphs: financial entities find recurring incidents “on a monthly basis”. Article 8(2) “does not apply to microenterprises and to financial entities listed in Article 16(1)” of DORA.
• Article 9 gives a materiality threshold for each criterion. Article 10 gives the conditions for a significant cyber threat.

Article 16(1) entities and the incident rules

Articles 5 to 15 do not apply to the financial entities that DORA Article 16(1) names. Articles 17 to 19 are not in that range. Thus these entities also have an ICT-related incident management process and classify ICT-related incidents. They also report major ICT-related incidents in the time limits of Delegated Regulation (EU) 2025/301. These entities do not apply the same rules in all points:

• The rule on recurring incidents of Delegated Regulation (EU) 2024/1772, Article 8(2), does not apply to them or to microenterprises.
• Article 16(1), point (f), and Title III of Delegated Regulation (EU) 2024/1774 give their business continuity, backup, and restoration obligations. Articles 11 and 12 do not apply to them.

DORA does not tell financial entities if the digital operational resilience testing program of Article 24 applies to the entities of Article 16(1) that are not microenterprises. For the provisions, see the tests of Article 16(1) entities.

Article 19 — Reporting of major ICT-related incidents and voluntary notification of significant cyber threats

DORA Article 19(1) gives the report obligation:

Financial entities shall report major ICT-related incidents to the relevant competent authority as referred to in Article 46 in accordance with paragraph 4 of this Article.

The other parts of Article 19 give these rules:

• Article 19(1), second subparagraph: “Where a financial entity is subject to supervision by more than one national competent authority referred to in Article 46, Member States shall designate a single competent authority as the relevant competent authority”.
• Article 19(1), third subparagraph: credit institutions “classified as significant, in accordance with Article 6(4) of Regulation (EU) No 1024/2013” report to the national competent authority of Article 4 of Directive 2013/36/EU. That authority “shall immediately transmit that report to the ECB”.
• Article 19(1), fourth subparagraph: financial entities use the templates of Article 20 for the initial notification and the reports. They send them to the competent authority. If “a technical impossibility prevents the submission of the initial notification using the template”, the entity tells the competent authority “via alternative means”.
• Article 19(1), fifth subparagraph: the initial notification and the reports “include all information necessary for the competent authority to determine the significance of the major ICT-related incident and assess possible cross-border impacts”.
• Article 19(2): financial entities “may, on a voluntary basis, notify significant cyber threats to the relevant competent authority when they deem the threat to be of relevance to the financial system, service users or clients”. Article 19(2), second subparagraph, adds: “Credit institutions classified as significant, in accordance with Article 6(4) of Regulation (EU) No 1024/2013, may, on a voluntary basis, notify significant cyber threats to relevant national competent authority, designated in accordance with Article 4 of Directive 2013/36/EU, which shall immediately transmit the notification to the ECB.”
• Article 19(3): if a major ICT-related incident “has an impact on the financial interests of clients”, financial entities tell their clients about the incident and about the measures that decrease its effects, “without undue delay as soon as they become aware of it”. For a significant cyber threat, financial entities tell their clients “that are potentially affected” about “any appropriate protection measures”, “where applicable”.
• Article 19(4): financial entities send 3 reports to the “relevant competent authority”, in the time limits of Article 20, first paragraph, point (a), point (ii):
  • (a) an initial notification
  • (b) an intermediate report, “as soon as the status of the original incident has changed significantly or the handling of the major ICT-related incident has changed based on new information available”. The financial entity then sends “updated notifications”, “as appropriate”, “every time a relevant status update is available, as well as upon a specific request of the competent authority”
  • (c) 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”.
• Article 19(5): financial entities can outsource the reports to a third-party service provider “in accordance with Union and national sectoral law”. In that condition, “the financial entity remains fully responsible for the fulfilment of the incident reporting requirements”.
• Article 19(6): when the competent authority receives the initial notification and each report, it must “in a timely manner, provide details of the major ICT-related incident to the following recipients based, as applicable, on their respective competences”:
  • (a) EBA, ESMA, or EIOPA
  • (b) the ECB, for the financial entities of Article 2(1), points (a), (b), and (d)
  • (c) the competent authorities, single points of contact, or CSIRTs of Directive (EU) 2022/2555
  • (d) the resolution authorities and the Single Resolution Board, on the conditions of point (d)
  • (e) “other relevant public authorities under national law”.
• Article 19(7) and (8) give the next steps of EBA, ESMA, EIOPA, the ECB, and the competent authorities.

In DORA Article 22(1), the competent authority must “acknowledge receipt” of the initial notification and of each report. “Where feasible”, it can give “relevant and proportionate feedback or high-level guidance”. Financial entities “shall remain fully responsible for the handling and for consequences of the ICT-related incidents reported pursuant to Article 19(1)”.

Implementing Regulation (EU) 2025/302 gives “the standard forms, templates, and procedures for financial entities to report a major ICT-related incident and to notify a significant cyber threat”.

Time limits for the reports

Delegated Regulation (EU) 2025/301, Article 5, gives the time limits for the reports of DORA Article 19(4):

Report	Time limit	Provision
Initial notification	“as early as possible, but in any case, within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours from the moment the financial entity has become aware of the ICT-related incident”	Article 5(1), point (a)
Initial notification, if the entity classifies the incident as a major ICT-related incident more than “24 hours” after it knows about the incident	“within four hours from the classification of the ICT-related incident as a major incident”	Article 5(2)
Intermediate report	“at the latest within 72 hours from the submission of the initial notification, even where the status or the handling of the incident have not changed”	Article 5(1), point (b)
An “updated intermediate report”	“without undue delay, and in any case when the regular activities have been recovered”	Article 5(1), point (b)
Final report	“no later than one month after either the submission of the intermediate report, or, where applicable, after the latest updated intermediate report”	Article 5(1), point (c)

Article 5 also gives these rules:

• Article 5(3): if a financial entity cannot send a notification or report in its time limit, it tells the competent authority “without undue delay, but no later than the respective time limits”. It “shall explain the reasons for the delay”.
• Article 5(4): if a time limit is on a weekend day or a bank holiday in the Member State of the financial entity, the entity can send the notification or report “by noon of the next working day”.
• Article 5(5): Article 5(4) does not apply to the initial notification or the intermediate report of credit institutions, central counterparties, and “operators of trading venues”. It also does not apply to the initial notification or the intermediate report of “other financial entities identified as essential or important entities pursuant to Article 3 of Directive (EU) 2022/2555”.
• Article 5(6): competent authorities “may decide” that Article 5(4) does not apply to the initial notification or the intermediate report of other financial entities that “are significant or have a systemic character for the financial sector at national or Union level”. The decision applies only to incidents that the entity reports after the competent authority tells it about the decision.

Reports to NIS2 authorities

NIS2 is Directive (EU) 2022/2555. For financial entities that national law identifies as essential or important entities, as NIS2 Article 3 tells them, DORA Article 1(2) makes DORA a “sector-specific Union legal act for the purposes of Article 4” of NIS2. For the effect, and its condition that the DORA requirements are “at least equivalent in effect”, see Article 1(2) on Applicability and governance. DORA and Delegated Regulation (EU) 2025/301 give these rules that connect the DORA reports to NIS2:

• DORA Article 19(1), sixth subparagraph: a Member State can tell some or all financial entities to send the initial notification and each report also to the competent authorities or CSIRTs of NIS2. They use the templates of Article 20.
• DORA Article 19(2), third subparagraph: a Member State can let financial entities that notify a significant cyber threat “on a voluntary basis” send the notification also to the CSIRTs of NIS2.
• Delegated Regulation (EU) 2025/301, Article 5(5): the extension in Article 5(4) does not apply to the initial notification or the intermediate report of “other financial entities identified as essential or important entities pursuant to Article 3 of Directive (EU) 2022/2555”.
• DORA Article 47(2): “Where appropriate, competent authorities may consult and share information with the single points of contact and the CSIRTs designated or established in accordance with Directive (EU) 2022/2555.”

To compare DORA with NIS2 and with the EU AI Act, see NIS2 and DORA and the EU AI Act and DORA.

The Digital Omnibus proposal

The proposal of the European Commission COM(2025) 837 of 19 November 2025 (the Digital Omnibus) can change DORA Article 19. It is a proposal and, as of October 2026, it is not law. If it becomes law, its Article 8 replaces 2 subparagraphs:

• The first subparagraph of Article 19(1): financial entities report major ICT-related incidents to the “relevant competent authority” “via the single-entry point established pursuant to Article 23a of Directive (EU) 2022/2555”.
• The first subparagraph of Article 19(2): the voluntary notification of significant cyber threats also goes through that single-entry point.

Until a change is law, DORA Article 19, Delegated Regulation (EU) 2025/301, and Implementing Regulation (EU) 2025/302 give the rules for the reports.

Article 20 — technical standards for reports and notifications

DORA Article 20 told the ESAs to make 2 sets of standards, through the Joint Committee and “in consultation with ENISA and the ECB”:

• Point (a): common draft regulatory technical standards that give:
  • (i) the contents of the reports for major ICT-related incidents
  • (ii) the time limits for the initial notification and for each report of Article 19(4)
  • (iii) the contents of the notification for significant cyber threats.
• Point (b): common draft implementing technical standards that give “the standard forms, templates and procedures for financial entities to report a major ICT-related incident and to notify a significant cyber threat”.

The result of point (a) is Delegated Regulation (EU) 2025/301. The result of point (b) is Implementing Regulation (EU) 2025/302 (see the eight Commission Regulations).

Article 23 — operational or security payment-related incidents

DORA Article 23 applies the requirements of Chapter III also “to operational or security payment-related incidents and to major operational or security payment-related incidents”. It applies only “where they concern credit institutions, payment institutions, account information service providers, and electronic money institutions”.

In DORA Article 3, point (9), an operational or security payment-related incident is “a single event or a series of linked events unplanned by the financial entities referred to in Article 2(1), points (a) to (d), whether ICT-related or not”. The incident “has an adverse impact on the availability, authenticity, integrity or confidentiality of payment-related data, or on the payment-related services provided by the financial entity”. Thus the incident does not have to be ICT-related. Recital 23 tells financial entities that “the requirement for the incident reporting pursuant to Directive (EU) 2015/2366” “should cease to apply to payment service providers that fall within the scope of this Regulation”. Recital 54 adds that DORA “should require” these four types of institution to report all operational or security payment-related incidents, “previously reported under Directive (EU) 2015/2366”, “irrespective of the ICT nature of the incident”.

A recital gives no duty. Article 23 applies the requirements of Chapter III to these incidents. The reporting duty of Article 19(1) applies to major operational or security payment-related incidents.

Articles 7 to 23 in Modulos

In Modulos, the Requirements for Articles 7 to 23 are in the Organization Framework OFF-16 and the AI System Framework MFF-16. For the Requirement of each provision and the sequence of the work, see Requirements of the DORA Frameworks.

Where to go next

Applicability and governance

Articles 1 to 6 and 16: who DORA applies to, NIS2, the management body, and the simplified ICT risk management framework

Testing and third-party risk

Articles 24 to 44: digital operational resilience testing, TLPT, ICT third-party risk, and the register of information

Information sharing and Level 2 acts

Article 45, the eight Commission Regulations, and the ESAs Joint Guidelines JC 2024 34

Operationalizing in Modulos

The two DORA Frameworks, the decisions before you add them, the steps, and the Requirements

NIS2 vs DORA

The DORA reports and the NIS2 Article 23 reports, side by side

Sources of this page

• DORA — Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 “on digital operational resilience for the financial sector”, OJ L 333, 27.12.2022: Articles 1(2), 3, points (8) to (13), 6(1), 7 to 23, 46, and 47(2), and recitals 23 and 54. EUR-Lex.
• Delegated Regulation (EU) 2024/1772 of the Commission of 13 March 2024, OJ L, 2024/1772, 25.6.2024, on the classification of ICT-related incidents and cyber threats: Articles 6, 8, 9, and 10. EUR-Lex.
• Delegated Regulation (EU) 2024/1774 of the Commission of 13 March 2024, OJ L, 2024/1774, 25.6.2024, “specifying ICT risk management tools, methods, processes, and policies and the simplified ICT risk management framework”: Article 22, and Titles II and III. EUR-Lex. Article 22, point (d), as corrected on 15 May 2025, OJ L, 2025/90420. EUR-Lex.
• Delegated Regulation (EU) 2025/301 of the Commission of 23 October 2024, OJ L, 2025/301, 20.2.2025, on the contents and time limits of the reports: Article 5. EUR-Lex.
• Implementing Regulation (EU) 2025/302 of the Commission of 23 October 2024, OJ L, 2025/302, 20.2.2025, on “the standard forms, templates, and procedures” of the reports. EUR-Lex.
• ESAs Joint Guidelines JC 2024 34, “Joint Guidelines on the estimation of aggregated annual costs and losses caused by major ICT-related incidents”, Final Report of 5 June 2024. See ESAs Joint Guidelines JC 2024 34.
• ESA Statement JC 2026 25 of 31 July 2026, “Toward a consistent and risk-based approach for ICT risks from frontier AI models”: paragraphs 5 and 6, and the Annex. ESMA.
• Digital Omnibus proposal — the proposal of the Commission COM(2025) 837 of 19 November 2025, procedure 2025/0360(COD): Article 8. EUR-Lex, Legislative Observatory.
• NIS2 — Directive (EU) 2022/2555: Articles 3 and 4. EUR-Lex.

Disclaimer

This information is general. It is not legal advice. DORA applies directly in all Member States. The binding obligations come from DORA and from the Commission Regulations that supplement it. In Article 46, the competent authorities make sure that financial entities obey DORA.