The incident report and the supplier register describe the same outage.

What happened

The Digital Operational Resilience Act (Regulation (EU) 2022/2554, DORA) has applied since 17 January 2025 to banks, insurers, payment and e-money institutions, investment firms and other financial entities. Major ICT-related incidents must be reported to the competent authority in three steps: an initial notification within four hours of classifying the incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report no later than one month after the latest intermediate report. The classification criteria and the content of the reports are set out in Commission Delegated Regulations (EU) 2024/1772 and 2025/301.

In parallel, every financial entity keeps a register of information on its contractual arrangements with ICT third-party providers and submits it each year to its supervisor. For the 2026 cycle, De Nederlandsche Bank asked for the register by 20 March 2026, with 31 December 2025 as reference date. In Belgium, the National Bank of Belgium and the FSMA are the competent authorities, each for the entities it supervises.

On 18 November 2025 the three European Supervisory Authorities (EBA, EIOPA and ESMA) published the first list of critical ICT third-party providers: 19 providers of cloud, data-centre, telecom, data and IT services that now fall under direct European oversight. The designation was based on the registers that financial entities had submitted.

What the first year showed

On 3 June 2026 the ESAs published their first annual report on major ICT-related incidents. Financial entities in the EU reported 3,383 major incidents in 2025. System failures and external events were the main drivers, and only about 10% were related to cybersecurity. Almost one third originated from a failure at a third party, such as an ICT provider, another financial entity or an infrastructure provider, and around one third had a cross-border impact. Two thirds caused no or only minor disruption to clients and transactions.

The report is frank about the data. For about 15% of the major incidents notified in 2025, no final report had arrived by the cutoff date of 5 February 2026, and the ESAs still see divergent reporting practices across sectors and countries. They also say where they want to go next: linking incident reports with the register of information, to identify incidents that start at critical providers and to understand where ICT risk is concentrated.

One outage, two documents

Inside a financial entity, that link is needed during the incident itself. When a provider’s service fails, the incident team has to know which contracts, functions and business services depend on it, often within the four-hour window. That information sits in the register, usually kept by procurement, risk or a third-party management team. The incident timeline, meanwhile, is built in tickets, chat channels and calls. These are typical patterns, not findings about any particular institution.

• Classification under time pressure. Whether an incident is major depends on the clients, transactions, duration, data and critical services affected. Those facts come from several systems at once.
• The provider behind the outage. The register says which functions a provider supports. During an incident, someone looks that up by hand.
• Three reports, one story. The initial, intermediate and final reports must agree with each other and with what happened. Rebuilding that afterwards from memory is where errors creep in.

What changes with one connected picture

The useful step is to treat the incident timeline and the register as one data set. When the register, the list of critical or important functions and the incident record sit in one data layer, an open incident shows directly which provider, contract and function are involved. Each step in the timeline keeps its source: the ticket, the monitoring alert, the call note. The three reports then draw on the same record instead of three separate reconstructions.

Meridian Platform places its own data layer in your environment, fed by read-only connectors, so the source systems stay the system of record. Cases and timelines in Meridian Platform are existing capabilities; connecting your ticketing, monitoring and register sources is a project integration. Meridian AI can summarise the timeline and prepare a draft report text with a reference to each source; a person checks every figure and decides on classification and submission. Meridian is designed to support DORA processes. It does not make an entity compliant with DORA and it submits nothing to a supervisor on its own. This article is not legal advice and does not suggest that any organisation named in the sources uses Meridian.

Start with one past incident

A practical first step takes one closed incident, major or close to it, and rebuilds its timeline from the original sources next to the register entries of the providers involved. Measure how long it takes today to answer three questions: which critical functions were affected, which provider was involved, and whether the three reports agree. Then compare with a connected record. Move to live incidents only once the result holds up with your incident and risk teams.

An outage at a provider is one event. The incident report and the register should tell it the same way.