Het incidentrapport en het leveranciersregister beschrijven dezelfde storing.

Wat er gebeurde

De verordening digitale operationele weerbaarheid (Verordening (EU) 2022/2554, DORA) geldt sinds 17 januari 2025 voor banken, verzekeraars, betalings- en e-geldinstellingen, beleggingsondernemingen en andere financiële entiteiten. Ernstige ICT-gerelateerde incidenten moeten in drie stappen gemeld worden aan de bevoegde autoriteit: een eerste melding binnen vier uur nadat het incident als ernstig is geclassificeerd en uiterlijk 24 uur nadat de entiteit ervan op de hoogte is, een tussentijds rapport binnen 72 uur na de eerste melding, en een eindrapport uiterlijk een maand na het laatste tussentijdse rapport. De classificatiecriteria en de inhoud van de rapporten staan in de gedelegeerde verordeningen (EU) 2024/1772 en 2025/301 van de Commissie.

Daarnaast houdt elke financiële entiteit een informatieregister bij van haar contractuele afspraken met externe ICT-dienstverleners, en dient ze dat jaarlijks in bij haar toezichthouder. Voor de cyclus van 2026 vroeg De Nederlandsche Bank het register uiterlijk op 20 maart 2026 op, met 31 december 2025 als referentiedatum. In België zijn de Nationale Bank van België en de FSMA de bevoegde autoriteiten, elk voor de entiteiten waarop ze toezicht houden.

Op 18 november 2025 publiceerden de drie Europese toezichthoudende autoriteiten (EBA, EIOPA en ESMA) de eerste lijst van kritieke externe ICT-dienstverleners: 19 aanbieders van cloud-, datacenter-, telecom-, data- en IT-diensten die nu onder rechtstreeks Europees toezicht vallen. De aanwijzing was gebaseerd op de registers die financiële entiteiten hadden ingediend.

Wat het eerste jaar liet zien

Op 3 juni 2026 publiceerden de Europese toezichthouders hun eerste jaarrapport over ernstige ICT-incidenten. Financiële entiteiten in de EU meldden in 2025 3.383 ernstige incidenten. Systeemfouten en externe gebeurtenissen waren de belangrijkste oorzaken; slechts ongeveer 10% had met cyberbeveiliging te maken. Bijna een derde ontstond door een fout bij een derde partij, zoals een ICT-dienstverlener, een andere financiële entiteit of een infrastructuuraanbieder, en ongeveer een derde had grensoverschrijdende gevolgen. Twee derde veroorzaakte geen of slechts beperkte hinder voor klanten en transacties.

Het rapport is openhartig over de gegevens. Voor ongeveer 15% van de ernstige incidenten die in 2025 werden gemeld, was op de peildatum van 5 februari 2026 nog geen eindrapport binnen, en de toezichthouders zien nog uiteenlopende meldpraktijken tussen sectoren en landen. Ze zeggen ook waar ze heen willen: incidentmeldingen koppelen aan het informatieregister, om incidenten bij kritieke dienstverleners te herkennen en te zien waar ICT-risico zich concentreert.

Eén storing, twee documenten

Binnen een financiële entiteit is die koppeling al tijdens het incident nodig. Valt de dienst van een leverancier uit, dan moet het incidentteam weten welke contracten, functies en bedrijfsdiensten ervan afhangen, vaak binnen het venster van vier uur. Die informatie staat in het register, meestal bijgehouden door aankoop, risicobeheer of een team voor leveranciersbeheer. De tijdlijn van het incident ontstaat intussen in tickets, chatkanalen en gesprekken. Dit zijn typische patronen, geen bevindingen over een bepaalde instelling.

• Classificeren onder tijdsdruk. Of een incident ernstig is, hangt af van de getroffen klanten, transacties, duur, gegevens en kritieke diensten. Die feiten komen uit verschillende systemen tegelijk.
• De leverancier achter de storing. Het register zegt welke functies een leverancier ondersteunt. Tijdens een incident zoekt iemand dat met de hand op.
• Drie rapporten, één verhaal. De eerste melding, het tussentijdse en het eindrapport moeten met elkaar en met de feiten overeenkomen. Dat achteraf uit het geheugen reconstrueren is waar fouten insluipen.

Wat verandert met één verbonden beeld

De nuttige stap is de incidenttijdlijn en het register als één gegevensgeheel te behandelen. Staan het register, de lijst van kritieke of belangrijke functies en het incidentdossier in één datalaag, dan toont een lopend incident meteen welke leverancier, welk contract en welke functie betrokken zijn. Elke stap in de tijdlijn behoudt zijn bron: het ticket, het monitoringalarm, de gespreksnotitie. De drie rapporten putten dan uit hetzelfde dossier in plaats van uit drie afzonderlijke reconstructies.

Meridian Platform plaatst een eigen datalaag in uw omgeving, gevoed door alleen-lezen-connectoren, zodat de bronsystemen de referentie blijven. Dossiers en tijdlijnen in Meridian Platform zijn bestaande functionaliteit; het koppelen van uw ticket-, monitoring- en registerbronnen is een projectintegratie. Meridian AI kan de tijdlijn samenvatten en een conceptrapport opstellen met een verwijzing naar elke bron; een medewerker controleert elk cijfer en beslist over classificatie en indiening. Meridian is ontworpen om DORA-processen te ondersteunen. Het maakt een entiteit niet in orde met DORA en dient niets zelfstandig in bij een toezichthouder. Dit artikel is geen juridisch advies en suggereert niet dat een in de bronnen genoemde organisatie Meridian gebruikt.

Begin met één afgesloten incident

Een praktische eerste stap neemt één afgesloten incident, ernstig of bijna, en bouwt de tijdlijn opnieuw op uit de oorspronkelijke bronnen, naast de registergegevens van de betrokken leveranciers. Meet hoe lang het vandaag duurt om drie vragen te beantwoorden: welke kritieke functies werden getroffen, welke leverancier was betrokken, en kloppen de drie rapporten met elkaar. Vergelijk daarna met een verbonden dossier. Ga pas naar lopende incidenten als het resultaat standhoudt bij uw incident- en risicoteams.

Een storing bij een leverancier is één gebeurtenis. Het incidentrapport en het register moeten haar op dezelfde manier vertellen.