Naar de hoofdinhoud
FromNine
Menu

CloudArchitectuur

DORA en ICT-dienstverleners: wat financiële entiteiten van hun leveranciers nodig hebben

DORA maakt van digitale operationele weerbaarheid een reeks concrete plichten voor financiële entiteiten, en de meeste daarvan komen via het contract bij hun ICT-dienstverleners terecht. Wat de verordening vraagt, wat er veranderde met de eerste kritieke aanbieders, en wat een leverancier klaar moet hebben.

Door
Redactie FromNine
Gepubliceerd
Leestijd
10 min. leestijd

De kern

  1. DORA geldt sinds 17 januari 2025 rechtstreeks. Financiële entiteiten blijven volledig verantwoordelijk voor hun ICT-risico, wat ze ook uitbesteden.
  2. Elk ICT-contract moet de bepalingen van artikel 30 bevatten, en contracten voor kritieke of belangrijke functies nog meer: auditrechten, deelname aan tests en een exitstrategie met een overgangsperiode.
  3. Een ernstig incident moet binnen vier uur na de classificatie en uiterlijk 24 uur na de ontdekking worden gemeld. Leveranciers moeten logs, contactpersonen en procedures klaar hebben voordat het gebeurt.
Inhoud

Waar DORA staat in het najaar van 2026

De verordening digitale operationele weerbaarheid (opent een externe website), Verordening (EU) 2022/2554, beter bekend als DORA, is sinds 17 januari 2025 van toepassing. Als verordening geldt ze rechtstreeks in elke lidstaat; de nationale wet wijst vooral de bevoegde autoriteiten aan en regelt de sancties. De details staan in technische normen die de Commissie heeft vastgesteld, over het kader voor ICT-risicobeheer, de classificatie en melding van incidenten, het informatieregister, het contractbeleid, onderaanneming en dreigingsgestuurde penetratietests.

Voor financiële entiteiten is DORA de sectorspecifieke handeling die in de plaats komt van de NIS2-regels over ICT-risicobeheer, incidentmelding en toezicht. Op 18 november 2025 publiceerden (opent een externe website) de drie Europese toezichthoudende autoriteiten (EBA, EIOPA en ESMA) de eerste lijst van kritieke derde aanbieders van ICT-diensten waarop zij rechtstreeks toezicht houden.

Tabel 1De vijf pijlers van DORA
PijlerArtikelenWat de verordening vraagt
ICT-risicobeheer5 tot en met 16Een gedocumenteerd kader dat het leidinggevend orgaan goedkeurt: identificatie, bescherming, detectie, respons en herstel, back-up, lessen trekken en communicatie.
ICT-gerelateerde incidenten17 tot en met 23Een proces voor incidentbeheer, classificatie volgens gemeenschappelijke criteria en melding van ernstige incidenten aan de bevoegde autoriteit.
Testen van de weerbaarheid24 tot en met 27Een risicogebaseerd testprogramma, jaarlijkse tests van systemen die kritieke of belangrijke functies ondersteunen, en dreigingsgestuurde penetratietests (TLPT) voor aangewezen entiteiten.
Risico van ICT-derden28 tot en met 44Een strategie voor derden, een informatieregister van alle ICT-contracten, verplichte contractbepalingen, exitstrategieën en Europees toezicht op kritieke aanbieders.
Informatie-uitwisseling45Vrijwillige regelingen om informatie en inlichtingen over cyberdreigingen te delen.

Financiële entiteiten en hun ICT-dienstverleners

DORA geldt voor twintig soorten financiële entiteiten, van kredietinstellingen, betalings- en elektronischgeldinstellingen en beleggingsondernemingen tot aanbieders van cryptoactivadiensten, handelsplatformen, fondsbeheerders, verzekeraars, verzekeringstussenpersonen, instellingen voor bedrijfspensioenvoorziening, ratingbureaus en crowdfundingplatformen. Evenredigheid is ingebouwd: artikel 4 stemt de eisen af op omvang, risicoprofiel en complexiteit, en artikel 16 voorziet in een vereenvoudigd kader voor sommige kleinere entiteiten.

Een derde aanbieder van ICT-diensten is elke onderneming die ICT-diensten verleent, en DORA omschrijft die ruim: digitale en datadiensten die via ICT-systemen doorlopend aan interne of externe gebruikers worden geleverd. Hosting, beheerde diensten, software as a service, applicatieonderhoud en -ondersteuning en datadiensten vallen er doorgaans onder. Leveranciers staan onder DORA niet zelf onder toezicht, tenzij ze als kritiek zijn aangewezen, maar hun klanten nemen de verplichtingen mee in elk contract.

Het leidinggevend orgaan draagt het ICT-risico

Artikel 5 legt de eindverantwoordelijkheid voor het ICT-risico bij het leidinggevend orgaan. Dat orgaan bepaalt het kader voor ICT-risicobeheer, keurt het goed en houdt er toezicht op, stelt de strategie voor digitale operationele weerbaarheid en de risicotolerantie vast, keurt het bedrijfscontinuïteitsbeleid en de respons- en herstelplannen goed, en keurt het beleid voor het gebruik van ICT-diensten van derde aanbieders goed en herziet het. De leden moeten hun kennis op peil houden, onder meer met regelmatige opleiding.

Ernstige incidenten: vier uur, 72 uur, één maand

Financiële entiteiten classificeren ICT-gerelateerde incidenten op basis van de criteria van artikel 18, uitgewerkt in Gedelegeerde Verordening (EU) 2024/1772 (opent een externe website): getroffen cliënten en transacties, duur en uitvaltijd, geografische spreiding, gegevensverlies, het belang van de getroffen diensten en de economische impact. Een ernstig incident wordt in drie stappen aan de bevoegde autoriteit gemeld, binnen de termijnen van Gedelegeerde Verordening (EU) 2025/301 (opent een externe website):

Tabel 2Melding van een ernstig ICT-gerelateerd incident volgens artikel 19 van DORA en Gedelegeerde Verordening (EU) 2025/301
StapTermijn
Eerste kennisgevingBinnen vier uur na de classificatie van het incident als ernstig, en uiterlijk 24 uur nadat de entiteit er kennis van kreeg.
Tussentijds verslagUiterlijk 72 uur na de eerste kennisgeving, daarna onverwijld bijgewerkt en in elk geval wanneer de normale activiteiten zijn hersteld.
EindverslagUiterlijk één maand na het laatst bijgewerkte tussentijdse verslag, zodra de analyse van de onderliggende oorzaken is afgerond.

Cliënten van wie de financiële belangen geraakt worden, moeten onverwijld worden geïnformeerd. Een financiële entiteit mag de melding zelf aan een derde uitbesteden, maar blijft er volledig verantwoordelijk voor (artikel 19, lid 5).

Voor leveranciers is dit heel concreet. Elk ICT-contract moet de verplichting van de aanbieder bevatten om bijstand te verlenen bij een incident dat met zijn dienst samenhangt, zonder extra kosten of tegen vooraf bepaalde kosten (artikel 30, lid 2, punt f). Het venster van vier uur bij de klant werkt alleen als de monitoring, logs en contactpersonen van de leverancier klaarstaan voordat het incident zich voordoet.

Testen, tot dreigingsgestuurde penetratietests

Artikel 24 vraagt een risicogebaseerd testprogramma, uitgevoerd door onafhankelijke interne of externe testers, met ten minste jaarlijks passende tests van alle ICT-systemen en -toepassingen die kritieke of belangrijke functies ondersteunen. Entiteiten die de bevoegde autoriteit aanwijst, voeren daarnaast ten minste om de drie jaar een dreigingsgestuurde penetratietest uit op live productiesystemen, volgens Gedelegeerde Verordening (EU) 2025/1190 (opent een externe website), die aansluit op het TIBER-EU-kader.

Vallen diensten van een leverancier binnen de reikwijdte van een TLPT, dan zorgt de financiële entiteit ervoor dat de leverancier deelneemt (artikel 26, lid 3), en contracten voor kritieke of belangrijke functies moeten die verplichting bevatten (artikel 30, lid 3, punt d). Kan de deelname van een leverancier zijn andere klanten schaden, dan staat DORA een gepoolde test toe, waarbij de leverancier zelf een externe tester contracteert voor meerdere financiële entiteiten samen (artikel 26, lid 4).

Risico van ICT-derden: strategie, register en exit

Artikel 28 maakt het risico van ICT-derden deel van het kader voor ICT-risicobeheer, en de financiële entiteit blijft volledig verantwoordelijk voor de naleving, wat ze ook uitbesteedt. De belangrijkste plichten:

  • Een strategie voor het risico van ICT-derden, met een beleid voor ICT-diensten die kritieke of belangrijke functies ondersteunen, dat het leidinggevend orgaan regelmatig herziet.
  • Een informatieregister van alle contractuele regelingen voor ICT-diensten, op het niveau van de entiteit en van de groep, met een onderscheid voor regelingen die kritieke of belangrijke functies ondersteunen. De modellen staan in Uitvoeringsverordening (EU) 2024/2956 (opent een externe website). Entiteiten rapporteren er ten minste jaarlijks over aan hun bevoegde autoriteit en bezorgen het volledige register op verzoek.
  • Zorgvuldigheid vóór de ondertekening: of de dienst een kritieke of belangrijke functie ondersteunt, de risico’s inclusief het concentratierisico, de geschiktheid van de leverancier en mogelijke belangenconflicten. Leveranciers moeten passende normen voor informatiebeveiliging toepassen, en voor kritieke of belangrijke functies de meest actuele en hoogwaardige.
  • Opzeggingsrechten, onder meer bij een ernstige inbreuk door de leverancier, aangetoonde zwakke punten in zijn ICT-risicobeheer, of omstandigheden die doeltreffend toezicht verhinderen.
  • Exitstrategieën voor ICT-diensten die kritieke of belangrijke functies ondersteunen, gedocumenteerd en getest, zodat de entiteit kan overstappen zonder haar bedrijfsvoering te verstoren, haar naleving te beperken of de dienstverlening aan cliënten te schaden.

Wat er in het contract moet staan

Artikel 30 legt de minimale contractbepalingen vast. Elk ICT-contract wordt schriftelijk vastgelegd, in één document met de dienstverleningsniveaus, en bevat ten minste:

  • een volledige beschrijving van de functies en diensten, en of, en onder welke voorwaarden, onderaanneming is toegestaan;
  • de locaties waar diensten worden verleend en gegevens worden verwerkt en opgeslagen, met voorafgaande melding van wijzigingen;
  • beschikbaarheid, authenticiteit, integriteit en vertrouwelijkheid van gegevens, ook van persoonsgegevens;
  • toegang tot, herstel en teruggave van gegevens in een gemakkelijk toegankelijk formaat bij insolventie, stopzetting of beëindiging;
  • beschrijvingen van de dienstverleningsniveaus;
  • bijstand bij ICT-incidenten die met de dienst samenhangen, zonder extra kosten of tegen vooraf bepaalde kosten;
  • volledige medewerking met de bevoegde autoriteiten en de afwikkelingsautoriteiten;
  • opzeggingsrechten en minimale opzegtermijnen;
  • deelname aan de programma’s voor ICT-beveiligingsbewustzijn en de opleidingen over weerbaarheid van de entiteit.

Voor diensten die kritieke of belangrijke functies ondersteunen, voegt artikel 30, lid 3, daar nauwkeurige kwantitatieve en kwalitatieve prestatiedoelen aan toe, meld- en rapportageplichten, bedrijfscontinuïteitsplannen die de leverancier uitvoert en test, deelname aan TLPT, onbeperkte rechten op toegang, inspectie en audit voor de entiteit en haar toezichthouder, en een exitstrategie met een verplichte overgangsperiode. Gedelegeerde Verordening (EU) 2025/532 (opent een externe website) bepaalt wat de entiteit moet beoordelen wanneer zulke diensten worden uitbesteed aan onderaannemers.

Kritieke derde aanbieders van ICT-diensten

Volgens artikel 31 wijzen de Europese toezichthoudende autoriteiten de ICT-aanbieders aan die kritiek zijn voor de financiële sector, op basis van hun systemische impact, het belang van de financiële entiteiten die op hen steunen, hun rol bij kritieke of belangrijke functies en hun vervangbaarheid. Elke kritieke aanbieder krijgt een lead overseer, een van de drie autoriteiten, die informatie kan opvragen, onderzoeken en inspecties kan uitvoeren en aanbevelingen kan doen.

De eerste lijst (opent een externe website), gepubliceerd op 18 november 2025, wees 19 aanbieders aan, van cloud- en datacenterbedrijven tot telecom, IT-dienstverlening, marktdata en bedrijfssoftware. De aanwijzing neemt geen enkele plicht weg bij de financiële entiteit: die houdt voor elk van deze aanbieders het register, de contractbepalingen en een exitstrategie bij.

Wat een ICT-dienstverlener klaar moet hebben

De meeste leveranciers van financiële entiteiten zullen nooit als kritiek worden aangewezen, maar allemaal krijgen ze met DORA te maken via contracten, due diligence en audits. Een leverancier die het volgende op orde heeft, verkort de aanbesteding en maakt het gesprek van zijn klant met de toezichthouder eenvoudiger:

  • Registergegevens. Wat de klant nodig heeft voor zijn informatieregister: juridische entiteit en identificatiecodes, de geleverde diensten en de functies die ze ondersteunen, locaties en de onderaannemers in de keten.
  • Contractbepalingen die aansluiten op artikel 30. Bij voorkeur een standaard DORA-addendum dat beide lijsten dekt, in plaats van elke clausule opnieuw te onderhandelen.
  • Bewijs bij incidenten. Monitoring, logs met betrouwbare tijdstempels en een meldprocedure waarmee de klant binnen enkele uren kan classificeren en melden.
  • Geteste continuïteit. Bedrijfscontinuïteitsplannen en hersteltests, met data en resultaten.
  • Aantoonbare beveiliging. Normen voor informatiebeveiliging, toegangsbeheer, een veilige ontwikkelcyclus en behandeling van kwetsbaarheden, waar mogelijk met onafhankelijk bewijs.
  • Klaar voor audits en tests. Een werkbare manier om audits en inspecties te ontvangen en deel te nemen aan TLPT, ook aan gepoolde tests waar dat past.
  • Een exitplan. Teruggave van gegevens in bruikbare formaten, documentatie en ondersteuning bij de overgang gedurende een afgesproken periode.

Zo werken wij als ICT-leverancier van financiële entiteiten: wij spreken de contractbepalingen af die DORA vereist, melden incidenten via het afgesproken kanaal, documenteren exitplannen, nemen deel aan weerbaarheidstests en leveren de informatie die uw register nodig heeft. Onze pagina over vertrouwen en compliance beschrijft hoe wij werken, met een managementsysteem voor informatiebeveiliging dat gecertificeerd is volgens ISO/IEC 27001.

Een praktisch plan voor beide partijen

  1. Vervolledig het register. Koppel elk ICT-contract aan de functies die het ondersteunt en markeer de kritieke of belangrijke.
  2. Dicht de leemtes in de contracten. Vergelijk elk contract met artikel 30 en spreek een addendum af waar bepalingen ontbreken.
  3. Stem de incidentaanpak af. Spreek met elke kritieke leverancier de gegevens voor classificatie, de contactpersonen en de meldtermijnen af, en test ze.
  4. Plan de tests met leveranciers. Neem ze op in het testprogramma en, waar relevant, in de afbakening van een TLPT.
  5. Schrijf en test exitstrategieën. Per kritieke of belangrijke functie: alternatieven, teruggave van gegevens en overgangsperiode.
  6. Bewaak de concentratie. Meerdere kritieke functies bij dezelfde aanbieder is een risico dat u documenteert en beheert (artikel 29).

Uw bevoegde autoriteit

DORA is overal dezelfde tekst, maar het toezicht is voor de meeste financiële entiteiten nationaal: de centrale bank, de prudentiële toezichthouder of de markttoezichthouder, afhankelijk van het soort entiteit, en voor significante banken de ECB. Het formaat en het kanaal voor het informatieregister en voor incidentmeldingen, en de autoriteit die bevoegd is voor TLPT, worden nationaal geregeld. Volg de richtsnoeren van uw eigen autoriteit.

Wat u de komende maanden volgt

  • De toezichtsprioriteiten en bevindingen van uw bevoegde autoriteit over het informatieregister en de incidentmelding.
  • Het toezicht van de lead overseers op kritieke derde aanbieders van ICT-diensten, en aanbevelingen die diensten raken die u gebruikt.
  • Het voorstel voor een Digitale Omnibus (opent een externe website) van de Commissie, COM(2025) 837, dat meldingen van ernstige incidenten onder DORA via één centraal meldpunt van ENISA zou laten verlopen. In oktober 2026 lag het nog bij het Europees Parlement; tot het is aangenomen en van toepassing wordt, gelden de huidige kanalen en termijnen.

Organisaties buiten de financiële sector krijgen vergelijkbare plichten voor de toeleveringsketen onder NIS2; zie ons artikel over NIS2 en softwareleveranciers. De Europese toezichthoudende autoriteiten houden een overzicht van de technische normen en het toezichtskader bij op hun DORA-pagina’s (opent een externe website).

Bronnen

  1. EUR-Lex. Verordening (EU) 2022/2554 (DORA) (geraadpleegd )
  2. EUR-Lex. Gedelegeerde Verordening (EU) 2024/1772 van de Commissie (classificatie van ICT-gerelateerde incidenten) (geraadpleegd )
  3. EUR-Lex. Gedelegeerde Verordening (EU) 2025/301 van de Commissie (inhoud en termijnen van incidentmeldingen) (geraadpleegd )
  4. EUR-Lex. Uitvoeringsverordening (EU) 2024/2956 van de Commissie (modellen voor het informatieregister) (geraadpleegd )
  5. EUR-Lex. Gedelegeerde Verordening (EU) 2025/532 van de Commissie (onderaanneming van ICT-diensten) (geraadpleegd )
  6. EUR-Lex. Gedelegeerde Verordening (EU) 2025/1190 van de Commissie (dreigingsgestuurde penetratietests) (geraadpleegd )
  7. ESMA. European Supervisory Authorities designate critical ICT third-party providers (geraadpleegd )
  8. ESMA, namens het Gemengd Comité van de ESA’s. List of designated critical ICT third-party service providers (geraadpleegd )
  9. EUR-Lex. Voorstel voor een verordening over de vereenvoudiging van het digitale wetgevingskader (Digitale Omnibus), COM(2025) 837 (geraadpleegd )
  10. ESMA. Digital Operational Resilience Act (DORA) (geraadpleegd )

Levert of beheert u ICT-diensten onder DORA?

Wij helpen Belgische banken, verzekeraars en hun ICT-dienstverleners DORA in de praktijk te brengen: registergegevens, bewijs bij incidenten, geteste herstelprocedures, ondersteuning bij weerbaarheidstests en exitplannen, vanuit Antwerpen en Gent. De juridische beoordeling blijft bij uw juristen.