DORA Major Incident Reporting: The ESAs’ Filing Instructions

On 16 September 2026 the three European Supervisory Authorities, the EBA, EIOPA and ESMA, published joint operational instructions for DORA major incident reporting. Short and technical, the document addresses something narrow and, for reporting teams, immediate: how selected fields of the major-incident template are expected or recommended to be populated, so that the data reaching competent authorities and then the ESAs is consistent across jurisdictions. The deadlines for major incident reporting and the classification thresholds are unchanged.

The document arrives after the first reporting year under Regulation (EU) 2022/2554 (DORA), which has applied since 17 January 2025. It reflects real inconsistencies the authorities saw in 2025 filings, and it is explicit that it will be revised as experience accumulates. Fourteen points are addressed. Most look like housekeeping until you map them against your own template configuration and find the field that your team has been filling the other way.

The framing matters before the detail does. These are staff-level operational instructions, agreed with the competent authorities, provided on a best-efforts basis. They are not a delegated act, they carry no new legal obligation, and they are addressed to supervisors for use in their engagement with financial entities. Their practical relevance is that they are intended to support competent authorities in their supervisory engagement with financial entities and were agreed with the relevant competent authorities.

Related reading: DORA ICT Incident Reporting: Obligations Explained

The reporting clock the instructions assume

The operational instructions sit on top of a fixed timeline, and none of that timeline moved on 16 September 2026. The time limits come from Commission Delegated Regulation (EU) 2025/301, the regulatory technical standards on the content and time limits for major-incident reports. A reporting officer building an internal escalation calendar works from these dates:

• Initial notification: as early as possible, and in any case within 4 hours of classifying an ICT-related incident as major, and no later than 24 hours from the moment the financial entity became aware of it. Where classification as major occurs more than 24 hours after awareness, Article 5(2) of RTS 2025/301 sets the initial notification deadline at four hours from the moment of classification.
• Intermediate report: within 72 hours of submitting the initial notification, even where the status or handling of the incident has not changed.
• Final report: no later than one month after the intermediate report, or, where applicable, after the latest updated intermediate report.
• Weekend and bank-holiday relief: where a submission deadline falls on a weekend or a bank holiday in the reporting entity’s Member State, the report may be filed by noon of the next working day.
• Background enactment: RTS 2025/301 and its companion implementing standards were adopted on 23 October 2024 and published in the Official Journal on 20 February 2025; the classification RTS was published on 25 June 2024.

The weekend relief carries a carve-out that a large institution can easily miss. Under Article 5(5) of RTS 2025/301, the extension is withheld for initial notifications and intermediate reports submitted by credit institutions, central counterparties, operators of trading venues, and entities identified as essential or important under the NIS2 Directive (Directive (EU) 2022/2555); competent authorities may also exclude entities that are significant or systemic at national or Union level under Article 5(6). Final reports remain eligible for the extension to noon of the next working day under Article 5(4), regardless of entity type. If your firm sits in any of those categories, a Saturday classification runs the four-hour and 24-hour initial-notification clock without weekend relief, and intermediate-report submissions are similarly unextended. The operational instructions assume this calendar throughout; they do not reopen it.

What the 16 September instructions are, and what they leave untouched

One reading of the publication treats it as a new rule with a compliance date. The document describes itself as operational instructions issued by ESAs staff to support competent authorities, agreed with those authorities, and updated regularly based on supervisory experience. Every one of the fourteen points carries the same last-update stamp of 16 September 2026; the document was published as a single release.

That status has two practical consequences. First, it provides best-efforts operational instructions on existing ITS 2025/302 template fields, with no separate application date. Second, the instructions will be updated regularly based on the experience of the ESAs and competent authorities, so reporting teams should re-check the current version when updates are issued. The document expressly states that the instructions do not represent a legal interpretation or the official stance of the ESAs.

The legal stack behind DORA major incident reporting

DORA major incident reporting runs on three technical standards that a filer has to keep straight, because the operational instructions cross-reference all three by field. Article 19 of DORA sets the obligation: a financial entity that detects an ICT-related incident it has classified as major reports it to its competent authority through an initial notification, an intermediate report and a final report. Commission Delegated Regulation (EU) 2025/301 defines the content and time limits of those three submissions. Commission Implementing Regulation (EU) 2025/302 provides the standard forms, templates and procedures, and it is that implementing regulation that numbers the fields the instructions discuss. Commission Delegated Regulation (EU) 2024/1772 sets the classification criteria and materiality thresholds that decide whether an incident is major in the first place.

Scope follows DORA’s own perimeter. The reporting duty falls on financial entities within the meaning of Article 2 of DORA, a list that runs from credit institutions and payment institutions through investment firms, crypto-asset service providers, central securities depositories and insurers. Proportionality shapes the reporting calendar as much as entity type does: microenterprises and other non-significant entities were meant to be shielded from disproportionate burden, which is part of why the weekend relief exists. The financial entity reports to its relevant competent authority using the channel and format set at national level. Under Article 19(6) of DORA, the competent authority then provides incident details, as applicable, to the relevant ESA, the ECB for entities referred to in Article 2(1)(a), (b) and (d), and the other recipients listed in Article 19(6)(c) to (e). For the competent-authority notification to the ESAs, the operational instructions state that the pre-defined template headers and elements and the values in closed-ended questions are expected to use the terminology in the English version of ITS 2025/302, while free-text fields may be provided in the applicable national language. That relay is why the language and consistency points in the instructions exist at all.

For the entities that face DORA’s lighter testing route, our note on DORA resilience testing for smaller firms walks through how proportionality is drawn elsewhere in the regulation.

Critical services affected is the classification gate

The instructions spend their seventh point on a classification question that changes what a filer writes in Field 2.5, and it is the point most likely to correct an existing habit. Under Article 8(1) of RTS 2024/1772, an incident is major where it has affected critical services, as defined in Article 6, and where one of two further conditions is met: either the specific threshold in Article 9(5)(b) of that regulation is met (that provision concerns successful malicious and unauthorised access to network or information systems, outside Article 9(5)(a), that may cause data losses) or at least two of the other materiality thresholds in Article 9(1) to (6) are met. Critical services affected therefore holds a different place from the other criteria. It is the one condition that has to be present in every major incident, whatever secondary thresholds sit beside it.

The operational instruction draws the reporting consequence out. Because the critical-services criterion must always be fulfilled for an incident to be major, the ESAs expect every report to identify “critical services affected” explicitly among the criteria listed in Field 2.5. A team that records only the secondary triggers it happened to notice first, say a duration or service-downtime threshold being met plus a client-impact threshold being met, and omits the critical-services flag, produces a report that is internally inconsistent with the reason the incident was classified as major at all. The classification criteria themselves come from Article 18(1) of DORA and cover client and counterparty impact, reputational impact, duration and service downtime, geographical spread, data losses, criticality of services and economic impact, with the euro and percentage thresholds set in RTS 2024/1772. The full threshold detail sits in our DORA incident reporting guide; the operational instruction is narrower, and it is about making Field 2.5 tell the truth about the gate.

The three fields expected to remain unchanged once you file

Fields 1.3a, 1.3b and 2.1 identify the incident across its life-cycle. Operational instruction 6 states that the values reported in those fields should remain unchanged from the initial notification through to the final report. The reasoning is mechanical: the ESAs use those identifiers to stitch the initial notification, the intermediate updates and the final report into a single incident record. Amend one of them mid-cycle and the system can read the corrected report as a new event, double-counting a single incident in the aggregated statistics.

This is a discipline that lives in template configuration. If your reporting tool regenerates an incident reference on each submission, or lets an analyst overwrite the incident identifier when they open the file to add root-cause detail, the resulting report would not follow operational instruction 6. Locking those three fields at first notification is the safer default.

Monetary fields are reported in thousands of units

Three fields carry money: Field 3.11, Field 4.13 and Field 4.14. The implementing standard requires monetary data points to be reported “in units using a minimum precision equivalent to thousands of units”, and the operational instructions turn that phrase into worked examples. EUR 2,500 is reported as 3, or as 2,5 if decimal precision is added. EUR 2,500,382 is reported as 2500, or as 2500,382 with precision. The unit is thousands, not the raw figure, which is the opposite of what a preparer transcribing a cost estimate would instinctively type.

The instructions add a currency constraint that matters for cross-border groups. All amounts in those monetary fields have to be expressed in the same currency as the one declared in Field 1.15. A firm that captures direct losses in local currency and indirect losses in euro, and reports both at face value, would not follow the operational instruction on currency consistency or the thousands-based reporting convention. The safer build validates the currency against Field 1.15 and applies the thousands conversion before the number ever reaches the template.

Your home country is excluded from geographical spread

Field 2.6 records geographical spread, and the instructions correct a specific over-inclusion. As specified in Article 4 of RTS 2024/1772, geographical spread refers to the impact of the incident across other Member States. The country of the affected financial entity is therefore not entered in that field. A Luxembourg entity hit by an incident that stayed within Luxembourg does not list Luxembourg as its geographical spread; the field captures the additional Member States the incident reached, if any.

Geographical spread is one of the classification criteria. Operational Instruction 8 states that Field 2.6 concerns impact across other Member States and expects the affected financial entity’s home country to be excluded. The separate cross-border relevance assessment under Article 19(7) of DORA is governed by Article 11 of RTS 2024/1772, which looks to a root cause originating in another Member State or significant impact there on specified persons or infrastructures.

When the resolution and economic-impact fields apply

Several fields are conditional, and the instructions are precise about the condition, which is where teams tend to over-report by entering “not applicable” or “none” where the field should simply stay empty. Field 4.10 is completed only where it has been determined that the incident poses a risk to critical functions as defined in Article 2(1), point 35, of the Bank Recovery and Resolution Directive (Directive 2014/59/EU). Field 4.11 is completed only where the incident has affected the resolvability of the entity or the group. Where the assessment concludes there is no such risk, or the field does not apply, the instructions expect it to be left blank.

Field 4.12, the materiality threshold for the economic-impact criterion, follows a different rule. The implementing standard makes it mandatory in final reports, and the instructions expect it to be completed in the final report of any incident where economic impact was identified as a classification criterion in Field 2.5. Field 4.12 records alphanumeric threshold information rather than a monetary figure; the monetary amounts for gross direct and indirect costs and losses are captured in Field 4.13. Where economic impact was not the classification trigger but the information about the economic-impact threshold is nonetheless available, the entity can still report it in Field 4.12. This conditional logic determines whether Fields 4.10, 4.11 and 4.12 are populated consistently with the ITS and the operational instructions.

The report cadence: monthly updates until the file is closed

The final report is due within one month, but the instructions clarify what happens in the gap between the intermediate report and a resolution that takes longer than a month. RTS 2025/301 requires the final report no later than one month after the submission of the intermediate report or the latest updated intermediate report. The instructions read that to mean the authorities expect at least one intermediate report per month, updating the incident, until the root-cause analysis is complete and actual impact figures are available for the final report. The monthly cadence is a minimum, not the only trigger: under DORA Article 19(4)(b), intermediate reports are also required following relevant changes in the incident and in response to supervisory requests. Article 19(4)(c) of DORA ties the final report to completed root-cause analysis and the availability of actual impact figures, irrespective of whether all remedial measures have been implemented. Under RTS Article 5(1)(b), an updated intermediate report is also required without undue delay when regular activities recover; where a reporting deadline cannot be met, Article 5(3) of RTS 2025/301 requires the entity to inform the competent authority without undue delay, and no later than the applicable submission deadline, and to explain the reasons for the delay.

Corrections follow their own convention. When a submitted report needs fixing, the instructions expect the correction to go in as a new version of the latest report submitted, and the instructions expect that new version to carry all the information from the latest update, with the corrected data point folded into an otherwise complete file. If the last submission was an intermediate report, the correction is a corrected intermediate report that still contains everything the prior version held. The effect is that the most recent version on file is always complete and current, which is exactly what the aggregated reporting depends on. That aggregation is not abstract: the ESAs’ first annual report on major ICT-related incidents drew its 2025 dataset from final reports submitted by a 5 February 2026 cutoff, chosen precisely because December incidents can still be within their one-month final-report window.

Frequently Asked Questions

Do the operational instructions create a new reporting obligation or a new deadline?

These are staff-level operational instructions issued by the EBA, EIOPA and ESMA on a best-efforts basis, agreed with competent authorities, to promote consistent completion of the existing template. They add no obligation and move no deadline set in RTS 2025/301. Their stated purpose is to support competent authorities in their supervisory engagement with financial entities and to enhance data quality and consistency across jurisdictions.

If an incident is classified as major only after the 24-hour awareness window has already passed, when is the initial notification due?

The four-hour clock runs from classification. Under Article 5(2) of RTS 2025/301, where an incident is classified as major more than 24 hours after the moment of awareness, the initial notification is due within four hours of that classification. Firms should confirm the precise trigger against Article 5 of the RTS.

Can one submission cover several entities in a group?

Under Article 7 of ITS 2025/302, aggregated reporting is available where a third-party service provider to whom the reporting obligations have been outsourced under DORA Article 19(5) submits the notification or report on behalf of all impacted financial entities and all Article 7 conditions are met: the major incident originates from or is caused by a third-party ICT service provider serving more than one financial entity or a group; each entity covered has independently classified the incident as major; the affected entities are within a single Member State and supervised by the same competent authority; and that competent authority has explicitly permitted aggregation for that type of financial entity. Article 7(2) excludes credit institutions considered to be of significant relevance as referred to in Article 2(16) of Regulation (EU) No 468/2014, operators of trading venues and central counterparties, which must report individually. Under Article 7(3), the competent authority may also require an individual notification or report.

How is a monetary amount below one thousand units reported?

In thousands, with decimal precision permitted where available. The instructions give EUR 2,500 as 3, or 2,5 with the extra precision. A figure below one thousand may be reported with decimal precision as a fraction of a thousand, in the currency declared in Field 1.15.

Does a purely domestic incident populate the geographical-spread field?

Field 2.6 captures other Member States affected, per Article 4 of RTS 2024/1772, and excludes the home country. A domestic-only incident records no additional spread in that field.

Must Field 4.12 be completed for every incident?

It is mandatory in final reports and is expected wherever economic impact was a classification criterion recorded in Field 2.5. An entity that classified the incident as major on other criteria can still report the economic-impact threshold information in Field 4.12 where the threshold information is available.

How should a correction to an already-submitted report be filed?

As a new version of the latest report submitted, carrying all the information from the latest update and not only the changed field. If the last file was an intermediate report, the correction is a corrected intermediate report that remains complete on its own.

Do microenterprises follow the same reporting timeline?

The four-hour, 72-hour and one-month time limits in RTS 2025/301 are set for a consistent approach across financial entities, but the standard was written to avoid a disproportionate burden on microenterprises and other non-significant entities, which is part of why the weekend and bank-holiday extension exists. That extension is unavailable for initial notifications and intermediate reports submitted by credit institutions, central counterparties, trading-venue operators and NIS2 essential or important entities; final reports remain eligible for the extension regardless of entity type.

Related Articles

• DORA ICT Incident Reporting: Obligations Explained: the full obligation, the classification thresholds, and the template structure behind these operational instructions.
• ESAs 2025 Report on Major ICT-Related Incidents: what the aggregated 2025 dataset showed once the final reports were in.
• DORA Resilience Testing for Smaller Firms: how proportionality and the microenterprise route are drawn elsewhere in DORA.
• DORA Threat-Led Penetration Testing Explained: the adjacent DORA testing regime and the entities it captures.
• CSSF Circular 26/915: DORA and Third-Country Branches: how one national competent authority frames DORA scope in its own channel.

Key Takeaways

• The ESAs’ operational instructions of 16 September 2026 add no deadline and no obligation; they standardise how the ITS 2025/302 major-incident template is completed, and they will be updated as supervisory experience grows.
• File the initial notification within 4 hours of classifying an incident as major and within 24 hours of awareness; where classification occurs more than 24 hours after awareness, Article 5(2) of RTS 2025/301 sets the deadline at four hours from classification. File the intermediate report within 72 hours of the initial notification and the final report within one month of the last intermediate report.
• Field 2.5 is expected to identify critical services affected in every report, because Article 8(1) of RTS 2024/1772 makes affected critical services the mandatory gate, joined by either the Article 9(5)(b) threshold (successful malicious and unauthorised access to network or information systems that may cause data losses) or at least two of the other materiality thresholds in Article 9(1) to (6).
• Lock Fields 1.3a, 1.3b and 2.1 at first notification and keep them unchanged to the final report, or the incident risks being double-counted.
• Report monetary Fields 3.11, 4.13 and 4.14 in thousands of units and in the currency declared in Field 1.15.
• Leave your home Member State out of the geographical-spread Field 2.6; it records other Member States affected.
• Fill Fields 4.10 and 4.11 only where their ITS conditions are met. Annex II to ITS 2025/302 marks Field 4.12 as mandatory for final reports; operational instruction 14 states that economic-impact threshold information is expected in Field 4.12 whenever economic impact was identified as a classification criterion in Field 2.5, and that entities can also report that information, where available, for incidents classified as major on other criteria.
• The weekend and bank-holiday extension to noon the next working day is unavailable for initial notifications and intermediate reports submitted by credit institutions, central counterparties, trading-venue operators, and NIS2 essential and important entities; final reports remain eligible for the extension regardless of entity type.

Sources and References

• ESAs (EBA, EIOPA, ESMA), “DORA Incident Reporting – Operational Instructions”, 16 September 2026: esma.europa.eu
• Regulation (EU) 2022/2554 (DORA), Article 19: data.europa.eu/eli/reg/2022/2554/oj
• Commission Delegated Regulation (EU) 2025/301 (RTS on content and time limits): data.europa.eu/eli/reg_del/2025/301/oj
• Commission Implementing Regulation (EU) 2025/302 (ITS on forms, templates and procedures): data.europa.eu/eli/reg_impl/2025/302/oj
• Commission Delegated Regulation (EU) 2024/1772 (RTS on classification criteria and materiality thresholds): data.europa.eu/eli/reg_del/2024/1772/oj
• ESAs (EBA, EIOPA, ESMA), JC 2026 16, “2025 report on major ICT-related incidents”, methodology section, paragraph 6: esma.europa.eu (JC 2026 16)

What to reconcile before your next incident filing

None of the fourteen points is hard to satisfy on its own. The exposure is that each describes a configuration risk: a way a template can be populated incorrectly by default, without any analyst making a deliberate mistake on the day. Among the patterns worth testing: monetary fields that transmit raw figures rather than thousands-converted values; identifier fields that regenerate on each submission; a geographical-spread field configured to include the home country; and conditional fields set to populate “not applicable” where the instructions expect them left blank.

Three further points address specific field formats. Operational instruction 9 recommends a semicolon-delimited structure for identifying third-party providers and other financial entities in Field 2.8. Instruction 10 states that Field 3.17, which indicates whether the duration and service-downtime values are actual or estimates, is expected to be completed in both intermediate and final reports, not only when ‘duration and service downtime’ is reported as a criterion in Field 2.5. Instruction 11 addresses Field 3.25, ‘Threats and techniques used by the threat actor’, and states that ‘data exfiltration and manipulation, excluding identity theft’ should be used as the reference wording because identity theft is a separate predefined option.

The practical task is to assess both template configuration and reporting procedures against all fourteen points before the next major incident forces the review under a four-hour clock. A structured walk-through should cover: Fields 1.3a, 1.3b and 2.1 locked from first notification through to the final report; monetary fields converted to thousands in the currency declared in Field 1.15; Field 2.5 configured to always carry the critical-services flag; Field 2.6 excluding the home country; and the conditional logic for Fields 4.10, 4.11 and 4.12 wired to their respective triggers.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.