On 16 September 2026 the European Supervisory Authorities published fourteen operational instructions on DORA major incident reporting, every one of them a correction to something firms filled in wrongly. The UK equivalent applies from 18 March 2027.
In brief: on 16 September 2026 the European Supervisory Authorities published operational instructions for DORA major incident reporting, fourteen numbered items whose stated purpose is to enhance data quality and promote greater consistency across jurisdictions. They follow the first full year of the regime, in which 3,383 major incidents were reported and only 10 per cent of them were related to cybersecurity. The UK version of the same obligation, confirmed in FCA PS26/2, applies from 18 March 2027, so boards have one cycle left to decide whether their incident data is assembled or improvised.
When a supervisor publishes a list of the fields firms keep filling in wrongly, it is describing what the next review will examine.
That is what the European Supervisory Authorities did on 16 September 2026. The document is five pages, carries no new rules, and reads as a catalogue of ordinary data failures: identifiers that changed between filings, monetary amounts reported in the wrong units, free-text fields holding information that belongs somewhere else, and the same third-party provider described four different ways by four different firms. Its stated purpose is to support competent authorities in their supervisory engagement with firms, and the authorities say it will be updated regularly, which makes it a standing list rather than a one-off clarification.
Nothing here is a cyber problem. It is a reporting problem, and reporting problems are governance problems wearing a technical costume.
Fourteen items, and what each one reveals
The instructions map neatly onto the questions a data governance function should already be able to answer about any regulatory submission.
What the authorities corrected
Field
What it says about the firm
Identifiers must stay unchanged from the initial notification through to the final report, or an incident may be double counted
1.3a, 1.3b, 2.1
There is no single record of the incident; each submission is rebuilt by hand from whoever is on the bridge call
Monetary fields reported in thousands of units, in the currency named in Field 1.15
3.11, 4.13, 4.14
Cost figures come from finance late and unreconciled, so the unit convention is decided by the person typing
Third-party origin reported in a set order: legal name, identification code, code type, then anything further
2.8
There is no authoritative supplier register with an LEI, so the provider is named from memory rather than looked up
Whether duration and service downtime are actual or estimated must be stated in both intermediate and final reports
3.15, 3.16, 3.17
Downtime is not measured against a defined important business service, so the distinction between fact and estimate is lost
Fields for resolution authorities completed only where the incident genuinely engages critical functions or resolvability
4.10, 4.11
A template is being filled in completely rather than accurately, which is the classic sign of an unowned return
Economic impact thresholds always reported in the final report where economic impact was the classification criterion
4.12, 2.5
The classification decision and the evidence behind it are held in different places and never reconciled
Read that right-hand column as a maturity assessment. Every item is a Critical Data Element with an owner, a definition, a source system and a quality threshold, or it is not. The instructions also require that a correction is filed as a new version of the latest report and carries forward everything already reported, which is only possible where lineage from source to submission is recorded rather than remembered.
The clock is the constraint, not the content
None of this is difficult in slow time. The regime runs on hours.
Stage
DORA, applicable since 17 January 2025
UK, from 18 March 2027
Initial notification
4 hours after classifying the incident as major, and no later than 24 hours after detection
Within 24 hours of determining that a threshold is met; 4 hours from first detection for payment service providers
Intermediate report
72 hours after the initial notification, then at least monthly until the final report
Lifecycle updates for firms in the enhanced reporting population
Final report
No later than one month after the intermediate or latest updated intermediate report
A final submission closing the incident record
Third-party register
Register of ICT third-party arrangements maintained under DORA
Register accurate as at 31 December, submitted within 90 calendar days of the FCA opening the window
Four hours is not enough time to agree a definition. It is barely enough to look one up. The UK thresholds make the same demand in different language: a firm reports where an incident risks intolerable levels of harm to consumers from which they cannot easily recover, threatens its own safety and soundness, or endangers market stability, integrity or confidence in the UK financial system. Deciding that under pressure requires the same customer, service and exposure data that Consumer Duty outcome monitoring and the operational resilience framework already ask firms to hold. Firms that built those separately will answer the question three times and get three answers.
The first year of data is the argument for fixing this
The same authorities published their first annual overview of major ICT-related incidents on 3 June 2026. Financial entities reported 3,383 major incidents in 2025, an average of 0.18 per entity in scope. Around a third had cross-border impact. Only 10 per cent related to cybersecurity, with system failures and external events the main drivers, and the authorities noted that highly capable AI-driven tools should encourage firms to strengthen cybersecurity to maintain resilience.
That profile matters commercially. If nine in ten reportable incidents are operational rather than adversarial, then the supervisory picture of a firm is being built mostly from how well it describes its own failures. A firm whose submissions are internally inconsistent is not judged to have a data problem. It is judged to have a control problem, because the two are indistinguishable from the outside. This is BCBS 239 in a shorter timeframe: accuracy, completeness, timeliness and adaptability, measured against an incident rather than a risk report.
The UK regime gives one cycle of preparation
The FCA confirmed its framework in PS26/2 on 18 March 2026, with finalised guidance FG26/3 on operational incident reporting and FG26/4 on material third party reporting, and gave firms until 18 March 2027 to be ready. Operational incident reporting reaches all firms with Part 4A permission, payment service providers, UK recognised investment exchanges, trade repositories and credit rating agencies. Third party reporting reaches a narrower population including enhanced scope SM&CR firms, banks, designated investment firms, Solvency II firms and large CASS firms.
A year sounds generous until you count what has to exist first: an incident record with a durable identifier, a supplier register keyed to LEI, measured downtime against named important business services, a cost convention agreed with finance in advance, and a named individual whose statement of responsibilities covers the submission. In a regulated firm that person is identifiable under SM&CR, which is the point at which this stops being a reporting project.
Five questions before the next board meeting
Who owns the incident report as a data product, and does their statement of responsibilities say so?
If we filed an initial notification today, could we reproduce the same incident identifier, currency convention and supplier code in the final report a month later without manual reconciliation?
Which of our suppliers could we name, with an LEI, within four hours of classifying an incident that originated with them?
Do we measure service downtime against defined important business services, and can we say whether a reported figure is actual or estimated?
For firms reporting in both the EU and the UK, are we building one incident data set for two regimes, or two data sets that will eventually disagree in front of a supervisor?
The regulators have now told firms exactly which fields they get wrong, which means the next inconsistent submission will not be read as a teething problem.
