How to report a major incident under DORA

DORA, the EU’s Digital Operational Resilience Act (Regulation (EU) 2022/2554), requires financial entities to report every major ICT-related incident to their competent authority. Article 19 sets the duty and names three reports. The deadlines and the content of each report are not in DORA itself. They are in two Commission acts made under Article 20: Delegated Regulation (EU) 2025/301 for the content and time limits, and Implementing Regulation (EU) 2025/302 for the forms. A third act, Delegated Regulation (EU) 2024/1772, decides which incidents count as major.

This article brings the three together: what makes an incident major, when each report is due, who receives it, and what to have ready before the first hour of an incident. It is written from the Official Journal texts. Check the current versions on EUR-Lex for later amendments before you rely on any deadline.

What counts as a major incident

Article 3 defines a major ICT-related incident as one that “has a high adverse impact on the network and information systems that support critical or important functions of the financial entity”. Delegated Regulation 2024/1772 turns that into a test.

It sets seven classification criteria:

• clients, financial counterparts and transactions affected
• reputational impact
• duration and service downtime
• geographical spread
• data losses
• criticality of the services affected
• economic impact

Each criterion except criticality has a materiality threshold in Article 9 of 2024/1772. An incident is major when it has affected critical services and either:

• it meets the data-loss threshold for successful, malicious and unauthorised access to network and information systems, or
• it meets two or more of the other thresholds.

“Critical services” has its own meaning in Article 6 of 2024/1772. It covers ICT services or systems that support critical or important functions, financial services that need authorisation or registration or are supervised, and any successful, malicious and unauthorised access to the entity’s systems. An intrusion therefore passes the first gate on its own.

Recurring incidents can also add up to one major incident. Incidents that are not major on their own count as one major incident when they happen at least twice within six months, share the same apparent root cause and together meet the test above. Entities assess this monthly. The recurring rule does not apply to microenterprises or to the entities listed in Article 16(1) of DORA.

This article does not reproduce the thresholds. Read them in Article 9 of 2024/1772, and put them in your own classification worksheet so the people on call do not have to look them up.

The three reports and their deadlines

Article 19(4) requires an initial notification, an intermediate report and a final report. Article 5 of Delegated Regulation 2025/301 sets when each is due.

Four points in the text are easy to get wrong.

The final report runs from the latest intermediate report. It is not one month after the initial notification, and it is not one month after the incident. Each updated intermediate report moves the final report’s deadline. Several published guides get this wrong.

Late classification has its own rule. If an incident is classified as major only after the first 24 hours, the initial notification is due within 4 hours of that classification (Article 5(2) of 2025/301). The 24-hour limit does not make a late classification unreportable.

Weekends and bank holidays. Where a deadline falls on a weekend day or a bank holiday in the reporting entity’s Member State, the report may be submitted by noon on the next working day (Article 5(4)). This relief does not apply to the initial notification or the intermediate report of credit institutions, central counterparties, operators of trading venues, or financial entities identified as essential or important entities under NIS2. A competent authority may also withdraw the relief from other significant or systemic entities, but only for incidents reported after it has notified them of that decision. The final report keeps the relief for every entity.

Missing a deadline needs a notice before the deadline. An entity that cannot submit on time must tell the competent authority without undue delay, no later than the deadline itself, and explain why (Article 5(3)).

DORA also sets when the reports are triggered, not only when they are due. The intermediate report is required as soon as the incident’s status or handling has changed significantly, with updates each time there is a relevant status update and whenever the authority asks. The final report is due once the root cause analysis is complete and actual impact figures can replace estimates, whether or not mitigation measures are already in place. The time limits above are the latest those reports may arrive.

Two shortcuts are allowed. Under Article 2 of 2025/302, an entity may submit two or all three reports together, once regular activities are recovered or the root cause analysis is complete, provided each deadline is still met. And where accurate data is not yet available, the initial notification and the intermediate report must carry estimates, as far as possible, based on the data that is available (Article 1(3) of 2025/302).

Who you report to, and telling affected clients

Reports go to the relevant competent authority under Article 46 of DORA, the authority that supervises your type of financial entity. Where an entity is supervised by more than one national competent authority, its Member State designates a single one for incident reporting. Credit institutions classified as significant report to their national competent authority, which passes the report straight to the ECB.

A Member State may also require some or all financial entities to send copies of the same reports to the authorities or CSIRTs set up under NIS2. Check whether yours does.

The competent authority shares the details onward as its competences require: with the EBA, ESMA or EIOPA, with the ECB for the entity types concerned, with NIS2 authorities and CSIRTs, with resolution authorities, and with other public authorities under national law. You report once, to your authority, and do not send the report to each of these yourself.

Submission is through the secure electronic channel your competent authority provides (Article 4 of 2025/302). If you cannot use it, inform the authority through other secure means you have agreed with it, and resubmit through the channel later if the authority asks. Arrange that fallback before you need it.

You may outsource the reporting to a third-party service provider (Article 19(5)), but you stay fully responsible for it. Tell your competent authority about the arrangement as soon as it is agreed and before the first report, giving the provider’s name, contact details and identification code (Article 6 of 2025/302).

If an incident turns out not to be major after all, because it never met the classification criteria, notify the authority that you have reclassified it as non-major (Article 5 of 2025/302).

Clients. Where a major incident affects the financial interests of clients, Article 19(3) requires you to tell them without undue delay once you become aware of it. Tell them about the incident and the measures you have taken to limit its effects. This duty runs alongside the reports to the authority and has no fixed number of hours.

What to tell your own management

Reporting to the authority is not the only duty. Under Article 17(3)(e), your incident management process must make sure that at least major incidents are reported to the relevant senior management and that the management body is informed of them. The briefing should explain three things: the impact, the response, and the additional controls to be put in place as a result.

In practice, that means two briefings. Senior management needs to know early, usually before the initial notification goes out, so that the decision that the incident is major, and what the authority receives, rest with someone who has the authority to make them. DORA does not require that sequence. It is common practice. The management body needs a fuller account once the facts are known, in time to approve any new controls. The final report’s root cause and cost figures are a natural basis for that second briefing.

What to prepare before an incident

The initial notification is due 4 hours after classification. That is not enough time to find an LEI code, work out who is allowed to log in to the authority’s portal, or agree who decides that an incident is major. Settle these in advance:

• A named owner for the clock. Decide who records the moment of awareness and the moment of classification, because both start deadlines.
• Decision rights. Name who classifies an incident as major and who approves each submission, with deputies for nights, weekends and holidays.
• A classification worksheet built on the seven criteria and the thresholds in 2024/1772, with your critical or important functions and your supervised services already listed.
• Access to the authority’s channel. That means accounts, credentials and a tested login for more than one person, and an agreed fallback for when the channel is down.
• The general information every report repeats (Article 1 of 2025/301): your legal name, LEI code, entity type, parent undertaking, and the contact people for the authority. Keep it current.
• Your weekend position. Record whether the weekend and bank-holiday relief applies to you, and keep the bank-holiday calendar for your Member State.
• Cost tracking. Set up a way to capture the direct and indirect costs and losses as the incident runs. The final report asks for them, and economic impact is also one of the classification criteria.
• Client messages. Prepare draft wording and a sign-off route for telling clients whose financial interests are affected.
• Any outsourcing notice to the authority, if a third party will submit the reports for you.
• A practice run. Run a tabletop exercise that classifies a scenario as major and fills in the initial notification against the clock.

If you run an ISO/IEC 27001 information security management system, three Annex A controls in the 2022 edition cover much of this ground. A.5.5 (Contact with authorities) is about keeping working contacts with the relevant authorities. A.5.24 (Information security incident management planning and preparation) is about defining roles, processes and responsibilities before an incident happens. A.5.26 (Response to information security incidents) is about responding in line with documented procedures. These controls help with the preparation. Having them in place does not by itself meet DORA’s reporting duties, which set their own content and deadlines.

The Security Incident Management pack holds the reporting clocks for DORA alongside other regimes. The Regulatory Incident Notification & Reporting pack covers the reporting decision, who drafts, reviews, approves and submits, and the content of each report.

Template: what to have ready for each report

The official template is in Annex I of Implementing Regulation 2025/302, with a data glossary and instructions in Annex II. The same template serves all three reports. Each report fills in its own fields, may fill in later fields early if the information exists, and updates what earlier reports said. Your competent authority’s portal may present the template in its own format. The lists below are not the official form. They show what to have gathered for each report, drawn from Articles 1 to 4 of 2025/301.

Every report

• Type of submission (initial, intermediate or final)
• Financial entity’s name, LEI code and type of entity
• Name and identification code of whoever submits, if it is not the entity itself
• Names and LEI codes of every entity covered, if the report is aggregated
• Contact details of the people dealing with the authority
• Parent undertaking of the group, where there is one
• Currency used for any amounts

Initial notification

• Your incident reference code
• Date and time of detection, and the classification
• Description of the incident
• The classification criteria that made it major
• Member States affected
• How the incident was discovered
• Its origin, where known
• Whether a business continuity plan has been activated
• Any reclassification from major to non-major
• Any other relevant information

Intermediate report

• The authority’s incident reference code, where it has given one
• Date and time the incident occurred
• Date and time regular activities were recovered, where they have been
• How each classification criterion was met
• Type of incident
• Threats and techniques used by the threat actor, where applicable
• Functional areas and business processes affected
• Infrastructure components affected
• Impact on clients’ financial interests
• Reporting to other authorities
• Temporary actions taken or planned to recover
• Indicators of compromise, where applicable

Final report

• Root causes
• Dates and times the incident was resolved and the root causes addressed
• How the incident was resolved
• Information relevant to resolution authorities, where applicable
• Direct and indirect costs and losses, and financial recoveries
• Recurring incidents, where applicable

For a step-by-step walk through completing each report, see the Guidance question How do we complete DORA’s initial notification, intermediate report and final report on a major incident?. More incident questions are in Incidents and regulatory notification.

Sources

• Regulation (EU) 2022/2554 (DORA), Articles 3, 17, 19 and 20
• Commission Delegated Regulation (EU) 2024/1772, Articles 1 to 9 (classification criteria and major incidents)
• Commission Delegated Regulation (EU) 2025/301, Articles 1 to 5 (content and time limits)
• Commission Implementing Regulation (EU) 2025/302, Articles 1 to 7 and Annexes I and II (forms, templates and procedures)

This article explains the reporting duties. It is not legal advice and does not decide whether a particular incident is major. That decision belongs to the financial entity, applying 2024/1772.