ESAs Issue Operational Instructions to Improve Quality and Consistency of DORA Major ICT Incident Re

Key Takeaways

• On September 16, 2026, ESA staff published 14 operational instructions that clarify how major ICT-related incident data should be completed in DORA reporting templates.
• The instructions are not legal interpretations, but they show what supervisors expect for data quality.
• Compliance teams should align incident reporting procedures now to avoid rejected, inconsistent, or duplicated reports.

Deep Dive

On September 16, 2026, ESA staff published 14 operational instructions that clarify how major ICT-related incident data should be completed in DORA reporting templates. The instructions are not legal interpretations, but they show what supervisors expect for data quality. Compliance teams should align incident reporting procedures now to avoid rejected, inconsistent, or duplicated reports.

The document is issued on a "best efforts" basis by ESA staff and agreed with competent authorities. It does not represent an official ESA position or a legal interpretation, and it will be updated regularly. Even so, it signals clear supervisory expectations. Financial entities still report to their national competent authority through national channels and formats. Authorities then forward the data to the ESAs in English-language templates, so inconsistent entity-level reporting weakens downstream data quality. All 14 items carry the same "last update" date of September 16, 2026, and no separate implementation deadline is stated.

Several items affect lifecycle management. Final reports are due no later than one month after the latest intermediate report, so authorities expect at least one intermediate report per month until the final report is filed. Corrections must be submitted as a new version of the latest report type (for example, a corrected intermediate report). The corrected file must also contain all information from the latest update. Fields 1.3a, 1.3b, and 2.1 must remain unchanged from initial notification through final report, because changes may cause an incident to be double counted.

Other items address data formatting and classification:
- Fields 3.11, 4.13, and 4.14 must be reported in thousands of units (EUR 2,500 is reported as 3 or 2,5) and in the currency specified in Field 1.15.
- Do not enter "not applicable" or "none." Leave non-mandatory, inapplicable fields blank, and follow the wording suggested by the ITS, as in Field 3.27.
-  "Critical services affected" must always be listed explicitly, alongside at least one other criterion.
- Exclude the entity's home country from geographical spread.
-  Where an incident originates from a third-party provider (TPP) or another financial entity, use a semicolon-separated format: legal name; LEI or EUID code; code type; optional additional information. Otherwise leave it blank.
-  Complete it in both intermediate and final reports, regardless of whether the duration criterion was triggered.
- Use "excluding identity theft" wording for the data exfiltration and manipulation option.
-  Complete them only where critical functions are at risk or resolvability is affected. Otherwise leave them blank.
- Always complete it in final reports where economic impact was a classification criterion. It may also be completed voluntarily for incidents classified as major on other criteria.

Recommended actions:
1. Perform a gap analysis of incident reporting playbooks, templates, and tooling against the 14 items.
2. Add validation rules for the monetary format, free-text content, and immutability of identifiers.
3. Set up a monthly reporting cadence tracker so final reports are not missed.
4. Confirm that national authority templates and local-language requirements are handled.
5. Train incident response, ICT risk, and third-party risk teams, especially on Field 2.8 data capture.
6. Monitor for future updates and confirm expectations with your national competent authority.

Risk implications are mainly supervisory and data-integrity related. Poor reporting may prompt follow-up queries, resubmissions, or heightened scrutiny, and it can distort incident counts. The instructions are non-binding, but deviation could be difficult to defend, since the underlying obligations in the ITS and RTS are binding. Manual, multi-entity reporting processes carry the greatest operational burden and error risk.

Source: European Banking Authority