Artifact GuideEU DORA

DORA Major ICT Incident Reporting

Classify ICT-related incidents, decide whether they are major, and prepare the initial notification, intermediate report, and final report required by DORA.

Based on DORA Article 19, the incident-classification RTS, the reporting-content RTS, and the standard reporting template ITS.

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
Overview

Since 17 January 2025, DORA reporting has required covered financial entities to classify the incident, notify the relevant competent authority, and update it through intermediate and final reporting as facts mature. An ICT third-party provider may supply facts, support response, or submit a report under an outsourced reporting arrangement, but the financial entity retains responsibility for Article 19 reporting. Use a classification file that ties affected services, clients, transactions, Member States, data losses, downtime, economic impact, recovery actions, and root-cause evidence to the DORA reporting template.

Section 2

What to submit in the initial notification

The initial notification is the fast supervisory alert. It should contain the shared general fields required across all three reporting stages, then the specific facts available at classification time.

The reporting-content RTS requires general information such as the type of submission, entity name, LEI code, submitting entity, aggregated entities where applicable, competent-authority contact details, parent undertaking where applicable, and reporting currency where monetary impact exists. The initial notification then adds the entity's incident reference code, detection and classification timestamps, incident description, classification criteria, impacted Member States, discovery method, available origin information, business-continuity activation, reclassification information where applicable, and other relevant information.

  • Start the clock from awareness and classification: submit as early as possible, within four hours from classification as major, and no later than 24 hours from awareness of the ICT-related incident.
  • If the incident is classified as major only after the first 24 hours from awareness, submit the initial notification within four hours from that later classification.
  • If the template cannot be submitted because of technical impossibility, DORA allows notification to the competent authority through alternative means.
  • Use the Implementing Regulation (EU) 2025/302 template and mark values as estimates where accurate data is not yet available.
Section 3

What to update in intermediate and final reports

The intermediate report updates the competent authority on occurrence time, recovery status, fulfilled classification criteria, incident type, threat actor techniques where applicable, affected business processes and infrastructure, client financial-interest impact, other authority reporting, recovery measures, and indicators of compromise where applicable.

Submit the final report once root cause analysis is complete and actual impact figures are available to replace estimates, within the applicable final-report deadline. It must cover root causes, resolution and root-cause remediation dates and times, incident resolution, resolution-authority information where applicable, direct and indirect costs and losses, recoveries, and recurring-incident information where applicable.

Can DORA reporting stages be combined?

Yes. Implementing Regulation (EU) 2025/302 allows a financial entity to combine the initial notification, intermediate report, and final report where regular activities have recovered or the root cause analysis has been completed, provided the Article 5 time limits in Delegated Regulation (EU) 2025/301 are still met.

Can a reported be reclassified as non-major?

Yes. If further assessment shows that the incident never met the Delegated Regulation (EU) 2024/1772 classification criteria and thresholds, Implementing Regulation (EU) 2025/302 requires the financial entity to notify the competent authority of the reclassification in the reporting template.

  • Submit the intermediate report no later than 72 hours after the initial notification, even if status or handling has not changed.
  • Submit updated intermediate reports without undue delay when regular activities have recovered or when relevant status updates are available.
  • Submit the final report no later than one month after the intermediate report or, where applicable, the latest updated intermediate report.
  • If a reporting deadline cannot be met, inform the competent authority without undue delay and no later than the missed deadline, explaining the reason.
  • A weekend or bank-holiday deadline may move to noon on the next working day in the reporting financial entity's Member State. That extension does not apply to initial or intermediate reports by credit institutions, central counterparties, operators of trading venues, or financial entities identified as NIS2 essential or important entities. A competent authority may also disapply it prospectively for other significant or systemic entities by notifying them.
Section 4

Competent authority route and information sharing

DORA reporting goes to the relevant competent authority. Where a financial entity is supervised by more than one national competent authority under DORA Article 46, Member States must designate a single relevant competent authority for Article 19 reporting. Significant credit institutions report to the relevant national competent authority, which immediately transmits the report to the ECB.

After receiving the initial notification and each report, the competent authority provides incident details to the relevant ESA, the ECB for specified financial entities, NIS2 competent authorities, single points of contact or CSIRTs, resolution authorities where the incident concerns critical functions, and other public authorities under national law. The ESAs and ECB then assess whether the incident is relevant for competent authorities in other Member States.

  • Keep the competent-authority channel, fallback secure channel, and emergency contacts in the incident runbook before an incident occurs.
  • If reporting is outsourced, notify the competent authority of the arrangement before the first notification or report and provide the third party's name, contact details, and identification code.
  • The financial entity remains fully responsible for DORA incident reporting even when a third party submits notifications or reports.
  • Aggregated reporting by a third-party service provider is limited to the conditions in Implementing Regulation (EU) 2025/302, including same-Member-State impact, same competent authority supervision, and explicit competent-authority permission.
Section 5

Significant cyber threats and client communications

DORA treats significant cyber threat notifications differently from major incident reports. A financial entity may notify a significant cyber threat voluntarily when it considers the threat relevant to the financial system, service users, or clients. The classification RTS treats a cyber threat as significant where it could affect critical or important functions or other relevant parties, has a high probability of materialisation, and could meet specified major-incident criteria or thresholds if it materialised.

The voluntary notification content is narrower than major-incident reporting. It covers general entity information, detection timestamps, threat description, potential impact, classification criteria that would have triggered a major report if the threat materialised, threat status, actions taken to prevent materialisation, and notification to other financial entities or authorities.

  • For a significant cyber threat, inform potentially affected clients of appropriate protection measures where applicable.
  • For a affecting clients' financial interests, inform clients without undue delay once aware of the incident and describe mitigation measures taken.
  • Use the significant cyber threat template in Annex III of Implementing Regulation (EU) 2025/302 when making a voluntary notification.
  • Keep indicators of compromise, threat source, threat actor capability and intent where known, vulnerabilities, persistence, and preventive actions with the evidence file.
Section 6

Evidence to keep with the reporting file

A useful DORA evidence file lets a reviewer reconstruct the classification and every report without reopening raw incident tooling. Keep the incident chronology, classification worksheet, evidence for each threshold, the submitted template versions, competent-authority acknowledgements or guidance, client communications, and the final root-cause and impact record together.

The evidence should distinguish estimates from actual values because the reporting template permits estimates in initial and intermediate stages, while the final report is expected once root cause analysis is complete and actual impact figures are available to replace estimates.

What is the minimum practical DORA incident reporting file?

Keep the classification record, the completed standard template for each submitted stage, timestamp evidence for awareness, classification and reporting, competent-authority communications, client communications where applicable, and the final root-cause, resolution, cost, loss and recovery evidence.

Which deadlines apply to DORA major-incident reports?

Submit the initial notification as early as possible, within four hours of major classification and no later than 24 hours after awareness. If classification happens after those first 24 hours, submit within four hours of that later classification. The intermediate report is due within 72 hours of the initial notification; the final report is due within one month of the intermediate or latest updated intermediate report. Check the limited weekend and bank-holiday extension before calculating the deadline.

  • Classification worksheet: critical services, clients, financial counterparts, transactions, duration, downtime, geography, data losses, economic impact, reputational impact, and recurring-incident assessment.
  • Timing evidence: awareness time, detection time, classification time, submission times, missed-deadline notice if any, recovery time, root-cause remediation time, and final resolution time.
  • Template evidence: initial notification, intermediate reports and updates, final report, competent-authority reference code, and any reclassification notice.
  • Operational evidence: business-continuity activation, affected business processes and infrastructure, temporary recovery actions, indicators of compromise, other authority reports, and client communications.
  • Financial evidence: gross direct and indirect costs and losses, recoveries, and whether the EUR 100,000 economic-impact threshold was exceeded or likely to be exceeded.
Primary sources

References and citations

eur-lex.europa.eu6 citations
Referenced sections
  • ITS source for standard forms, templates, secure channels, combined submissions, reclassification, outsourcing notification, aggregated reporting, and significant cyber threat templates.
  • Requires use of the standard reporting template and permits estimated values where accurate data is not yet available.
  • Sets procedures for combined submissions, updates, complete and accurate template data, and reclassification notices.
Show 3 more
  • Specifies secure electronic channels, outsourcing notification, and aggregated reporting procedures.
  • Requires use of the Annex III template for voluntary significant cyber threat notifications.
  • Provides the template fields and data instructions that shape the evidence file.
"standard forms, templates, and procedures"
More quoted passages
"provide estimated values"
"update any information that was submitted previously"
"secure electronic channels"
"template laid down in Annex III"
"complete and accurate"
eur-lex.europa.eu5 citations
Referenced sections
  • RTS source for the content and time limits of initial notifications, intermediate reports, final reports, and voluntary significant cyber threat notifications.
  • Specifies the required initial-notification content and the four-hour and 24-hour timing rules.
  • Specifies intermediate-report and final-report content and the 72-hour and one-month reporting deadlines.
Show 2 more
  • Specifies the content of voluntary significant cyber threat notifications.
  • Identifies the information required across initial notifications, intermediate reports, final reports, and significant cyber threat notifications.
"content and time limits"
More quoted passages
"within four hours from the classification"
"at the latest within 72 hours"
"Content of the voluntary notification"
"General information to be provided"
eur-lex.europa.eu4 citations
Referenced sections
  • RTS source for classifying major ICT-related incidents, recurring incidents, materiality thresholds, significant cyber threats, and cross-border relevance.
  • Defines the DORA major-incident classification criteria, recurring-incident rule, and materiality thresholds used before reporting.
  • Defines when a major incident is relevant for competent authorities in other Member States and requires shared reports to contain the same level of information without anonymisation.
Show 1 more
  • Defines high materiality thresholds for determining significant cyber threats.
"classification of ICT-related incidents and cyber threats"
More quoted passages
"An incident shall be considered a major incident"
"same level of information"
"high probability of materialisation"
eur-lex.europa.eu4 citations
Referenced sections
  • Primary DORA text for Article 19 reporting duties, competent-authority routing, outsourcing responsibility, voluntary significant cyber threat notification, and client communication.
  • Article 19 establishes reporting to the relevant competent authority and permits alternative notification where template submission is technically impossible.
  • Article 19 defines the relevant competent authority route, information-sharing flow, ECB transmission for significant credit institutions, and continued responsibility when reporting is outsourced.
Show 1 more
  • Article 19 allows voluntary significant cyber threat notifications and requires client communications for major incidents and, where applicable, significant cyber threats.
"major ICT-related incidents"
More quoted passages
"an initial notification"
"relevant competent authority"
"voluntary basis"
Show all related guides (33)

DORA Register of Information Import and Build Workflow

Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks.

DORA Register of Information Template: ICT Provider Fields and Evidence

Map DORA register fields to official templates for ICT contracts, provider chains, critical functions, dates, statuses, reporting, and evidence.

DORA vs EBA outsourcing guidelines: ICT third-party risk comparison

Compare binding DORA ICT third-party risk duties with the EBA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence.

DORA vs ISO 22301: ICT resilience and business continuity compared

Compare DORA's binding ICT operational resilience duties for financial entities with ISO 22301's business continuity management system requirements.

DORA vs ISO/IEC 27001: legal ICT resilience obligations and ISMS controls

Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps.

DORA vs NIS2: financial-sector obligations, overlap, and evidence

Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence.

DORA vs PSD2 incident reporting: major ICT and payment incidents

Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence.

EU DORA Applicability Test for Financial Entities and ICT Providers

Test DORA applicability against official sources for financial-entity scope, ICT services, critical or important functions, exclusions, proportionality, and evidence.

EU DORA Compliance Checklist for Financial Entities

Check DORA operating evidence against official sources for ICT risk governance, major-incident reporting, resilience testing, TLPT, third-party contracts, and the register of information.

EU DORA Compliance Obligations and Evidence Guide

Map DORA obligations to official sources and operating evidence for ICT risk management, incident reporting, testing, third-party risk, registers, governance, and oversight.

EU DORA FAQ: scope, incidents, ICT contracts, testing, and evidence

Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence.

EU DORA ICT risk management control baseline

An official source DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence.

EU DORA ICT subcontracting chain controls for critical functions

DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence.

EU DORA penalties and fines: enforcement powers and limits

Official source guide to DORA enforcement: competent-authority powers, administrative penalties, remedial measures, publication rules, and Lead Overseer penalty payments for critical ICT third-party providers.

EU DORA Register of Information Data Model: templates, fields, and evidence

Field-level guide to the EU DORA register of information data model: templates B_01 to B_07, provider identifiers, contract links, subcontracting chains, critical-function assessments, dates, and export evidence.

EU DORA Requirements Overview: ICT risk, incidents, testing, and third-party risk

An official source overview of the main EU DORA requirements for financial entities: governance, ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, register of information, oversight, proportionality, and evidence.

EU DORA Scope and Covered Entities: financial entities and ICT providers

Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency.

EU DORA Scope and Proportionality Workflow

Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals.

EU DORA testing and TLPT readiness guide

An official source DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence.

EU DORA TLPT eligibility workflow for financial entities

Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance.

EU DORA TLPT Runbook: scope, providers, reports, and remediation

Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation.

How to build a DORA register of information

Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.

DORA ICT Third-Party Contracts FAQ

What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence.

DORA major ICT incident thresholds: what triggers reporting?

FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs based on EU DORA RTS and ITS texts.

DORA Register of Information FAQ: ICT Third-Party Arrangements

FAQ on the DORA register of information: who maintains it, which ICT third-party arrangements it covers, template fields, critical functions, reporting, data quality, and evidence.

DORA TLPT selection: who can be required to test?

FAQ on DORA threat-led penetration testing selection: who identifies financial entities, what criteria are used, what the TLPT authority validates, and what evidence to keep.

How does proportionality work under EU DORA?

DORA proportionality explained from official sources: what can be scaled, simplified-framework eligibility, supporting evidence, and duties that remain mandatory.