DORA incident reporting in practice – the ESAs’ operational instructions and the new Fidac version

Published 14 October 2026

Summary: DORA’s incident reporting requirements are not new. What is new is that their application is maturing. On 16 September 2026 the EBA, EIOPA and ESMA published operational instructions for reporting major ICT-related incidents, built on experience from the first year of reports, and on 1 October Finansinspektionen (the Swedish FSA) drew attention to them while announcing a new version of incident reporting in Fidac from 19 October. The instructions change neither the obligation nor the deadlines. They do show where reporting fails in practice: inconsistent amounts, incident identifiers that change between reports, final reports that never arrive. An organisation that wants to report correctly under time pressure needs to have decided who classifies, who owns the report and where the data lives, before the incident happens.

Reporting moves from regulation to operation

DORA has applied since 17 January 2025, and financial entities have now been reporting major ICT-related incidents for more than a year and a half. The first joint European annual report was based on 3,383 major incidents in 2025, which we covered in our insight on DORA’s first incident data. There is real experience to build on, and that is exactly what the European Supervisory Authorities are now doing.

On 16 September 2026 the EBA, EIOPA and ESMA published DORA Incident Reporting – Operational Instructions. The aim is more consistent reporting across the EU and better quality in the data submitted. Finansinspektionen highlighted the instructions on 1 October, noting that they contain clarifications on language, the reporting of monetary values and other practical aspects of individual fields in the incident reports.

Two things are worth being clear about. The instructions are provided on a best-efforts basis by ESA staff. They are neither a legal interpretation nor an official position of the authorities, and they do not change DORA’s reporting obligation, classification criteria or deadlines. The document is also formally written to support national competent authorities in their engagement with firms. But the content lands with whoever reports, and it has been agreed with the national authorities. The instructions will be updated regularly as experience grows.

What the instructions actually say

The document is short, fourteen items on five pages, and every item starts from a problem the authorities have seen in real reports. That makes it an unusually concrete list of where reporting goes wrong. The items that matter most in practice:

Area	What the authorities have seen	What is expected
Incident identity	The unique identification fields change between the initial notification, intermediate and final reports, which can cause double counting	The same identifier throughout the life cycle, unchanged from initial notification to final report
Classification criteria	Different practices on whether “critical services affected” is listed as a criterion	The criterion must always be met for a major incident and should therefore always be listed, together with at least one other criterion
Geographical spread	The home country is included in the list of affected countries	The field refers to impact in other Member States; the entity’s own country should not be included
Monetary amounts	Inconsistent units	All monetary fields reported in thousands of units and in the same currency as specified for the incident
Free-text fields	“Not applicable”, “none” and similar entries	Leave the field blank if it is not mandatory and not applicable; follow the suggested structure where one exists
Third-party origin	Information on the third-party provider is hard to interpret	Standardised format: full legal name; identification code; code type (LEI or EUID); any other information, separated by semicolons
Final reports	Final reports missing for notified incidents	Final report no later than one month after the latest intermediate report; at least one intermediate report per month expected until the final report is submitted
Corrections	Corrections submitted in the wrong form	A correction is submitted as a new version of the latest report, containing all information from the latest update
Language	Templates translated into local languages when authorities pass reports on	Headers and selectable values follow the English version of ITS 2025/302; free text may be provided in the national language

The remaining items cover, among other things, that the indication of whether duration and downtime are actual or estimated must be completed in both intermediate and final reports, that the fields for resolution authorities are completed only when the incident has actually been assessed as affecting critical functions or resolvability, and that information on economic impact is always expected in the final report when that criterion was used for classification.

Read as a whole, almost every item is about the same thing: the reports do not hold together over time, or a piece of information has no clear owner. Those are process questions, not regulatory ones.

The deadlines are not the hard part

Most people working with DORA know the deadlines, as Finansinspektionen summarises them:

Report	Deadline
Initial notification	As early as possible, within four hours of classification as major and no later than 24 hours after the entity became aware of the incident
Intermediate report	No later than 72 hours after the initial notification, and an updated intermediate report as soon as regular operations have resumed
Final report	No later than one month after the intermediate report or the latest updated intermediate report

But a working process needs to answer questions that no deadline answers:

• Who classifies the incident as major, and who records the time that starts the four-hour clock?
• Who owns the report through its whole life cycle, so that identifiers, criteria and amounts stay consistent from initial notification to final report?
• Where does the information on affected services, systems, clients and countries come from, and who is responsible for its accuracy?
• Who is allowed to assess and state economic impact, and in which currency and unit?
• How are the provider’s legal name and LEI retrieved when the incident originates with a third party?
• Who quality-assures the report before it is sent, and who makes sure the intermediate and final reports are actually submitted?

How the assessment of the reporting duty fits into the rest of incident management, and why it has to be made while the incident is ongoing, is covered in our insight on incident triage. This article is about the step after triage: the reporting itself.

Data quality is part of incident capability

Finansinspektionen states explicitly that the instructions are meant to improve the quality of the data reported. It is easy to read that as a matter of care at the keyboard. In practice it is a matter of preparation. To report correctly within four hours, the organisation needs to know, before the incident, where the information lives and who is responsible for it:

• which services are critical and which clients and counterparties use them,
• in which countries the services are delivered,
• which ICT systems support each service,
• which third-party providers are involved, with legal name and LEI or EUID,
• how economic impact is calculated and who signs off the figure,
• the times of detection, classification, recovery and resumption of regular operations,
• the root cause, once it has been established.

Much of this information should already be documented in, or be retrievable from, the organisation’s ICT risk management: the register of information on ICT third-party providers, the documentation of critical or important functions and the systems behind them, and the business impact analysis from continuity work. The reporting process needs to point to them, not rebuild the same information during a live incident.

Test the reporting before the incident

It is only when a real incident occurs that the organisation discovers whether the reporting process works. The four-hour window is the wrong moment to find out who has access to Fidac, who can assess economic impact or where the details of a critical provider are kept.

A simple tabletop exercise goes a long way. A scenario:

• 09:10 A critical service stops working.
• 10:00 The provider confirms a major incident on its side.
• 12:30 The impact turns out to be larger than first assessed, and more clients are affected.
• 14:00 The incident is assessed as meeting the criteria for a major ICT-related incident.

And then the questions:

• Who takes the classification decision, and who records the time?
• Who opens the report, and does the access work?
• What information is already at hand, and what is missing?
• How is the provider entered in the correct format?
• How is the new impact information handled in the intermediate report, without changing the incident identifier?
• Who makes sure the final report is submitted within a month, when the incident is long resolved and attention has moved on?

The silence where answers are missing is the result of the exercise. Our offer incident preparedness and tabletop exercise is built for exactly this kind of walk-through.

A new version of Fidac on 19 October

For Swedish reporters the practical interface changes too. Finansinspektionen announced on 1 October that DORA incident reporting in its reporting system Fidac gets a new version from Monday 19 October 2026:

• the form changes layout, from horizontal to vertical,
• the fields on which financial entities are affected (1.4–1.6) move to a separate table, used when the affected entity is different from the reporting entity and for aggregated reporting,
• a reminder function is introduced that emails when an intermediate or final report is missing after the deadline,
• it becomes possible to filter on the reference code in field 3.1 for intermediate and final reports,
• an updated JSON schema applies from the same date, and an updated quick guide is published.

None of this changes the DORA requirements. But organisations with internal instructions, screenshots in the playbook, JSON integrations with Fidac or report templates should check that they still hold after 19 October. The reminder function is also a clear signal of what the FSA sees: intermediate and final reports that fail to arrive.

Five things to check now

1. Classification. Is it clear who decides whether an ICT incident is major, against which criteria, and how the time is recorded?
2. The reporting team. Do incident management, risk and compliance, the business and the provider owners know who does what, and is there a deputy for every role?
3. The information sources. Can data on services, systems, countries, providers and economic impact be produced quickly and traceably, in the right unit and format?
4. Reporting over time. Do the initial notification, intermediate reports, corrections and final report hold together as one and the same incident, and does someone make sure the final report is submitted?
5. Exercise and maintenance. Has the process been tested, and is there a routine for updating it when the ESAs’ instructions, the FSA’s guide or Fidac change?

How Kristensson i Skåne can help

Kristensson i Skåne helps financial organisations turn DORA’s incident requirements into a practical, testable process, as part of our work on DORA and financial regulations. Support can include:

• a classification and reporting process for ICT incidents,
• roles, responsibilities and escalation paths, including deputies,
• DORA-aligned incident triage,
• a reporting playbook with field-level guidance,
• mapping of information sources and owners,
• provider escalation and third-party provider details,
• a tabletop exercise of the incident reporting,
• a review against the current ESA and FSA instructions,
• follow-up and improvement after an incident or exercise.

Our starting point is that the reporting has to work at 14:00 on a Tuesday when the service is down, not just look complete in a process description.

Frequently asked questions

Want to know whether your reporting process holds when the clock is running? Read more about our offer incident preparedness and tabletop exercise or contact us for a no-obligation conversation.

Sources: EBA, EIOPA and ESMA, DORA Incident Reporting – Operational Instructions, 16 September 2026; Finansinspektionen, Operativa instruktioner för rapportering av allvarliga IKT-relaterade incidenter enligt Dora-förordningen, 1 October 2026; Finansinspektionen, Ändringar i Dora incidentrapportering i Fidac, 1 October 2026; Finansinspektionen, IKT-risker (Dora), deadlines under Delegated Regulation (EU) 2025/301; Regulation (EU) 2022/2554 (DORA), Article 19. Verified 1 October 2026.

This text is general information, not legal advice. Which requirements apply to you depends on the type of financial entity, the scale of your operations and your supervisory authority’s instructions.