Hoe voert u een DORA-lacuneanalyse uit: een stappenplan voor FinTechs

Begin met een lacuneanalyse, niet met een programma

Uw instinct kan zijn om DORA-naleving te starten door beleid op te stellen. Die aanpak zet uitkomsten voor de input. Een lacuneanalyse komt eerst: die identificeert waar u blootgesteld bent, iets wat beleid u niet kan vertellen.

De vijf pijlers van DORA creëren vereisten op het gebied van ICT-risicobeheer, incidentrapportage, operationeel testen, risico van derde partijen en informatie-uitwisseling. De meeste FinTechs hebben gedeeltelijke controles op sommige van deze gebieden en niets op andere. De lacuneanalyse brengt in kaart wat er bestaat, scoort dit ten opzichte van de DORA-vereisten en levert een geprioriteerde actielijst. Zonder die analyse bouwt u programma's op aannames en ontdekt u de lacunes pas wanneer een toezichthouder ernaar vraagt.

Voor de analyse: bevestig uw toepassingsgebied

DORA (Verordening EU 2022/2554) is van toepassing op financiële entiteiten die in de EU actief zijn in 20 gedefinieerde categorieën. Dit omvat onder meer kredietinstellingen, betalingsinstellingen, beleggingsondernemingen, verzekerings- en herverzekeringsondernemingen, aanbieders van cryptoactivadiensten, crowdfundingdienstverleners en kritieke ICT-dienstverleners van derde partijen.

Het toepassingsgebied is voor FinTechs niet altijd vanzelfsprekend. Een bedrijf dat een betalingsinitiatiedienst levert, is een betalingsinstelling. Een bedrijf dat verzekeringsproducten in een platform integreert, kan een verzekeringsdienstenentiteit zijn. Een aanbieder van cryptowallets is een aanbieder van cryptoactivadiensten onder MiCA, wat het binnen het toepassingsgebied van DORA brengt. Bevestig uw classificatie met uw juridisch adviseur voordat u een lacuneanalyse uitvoert. De classificatie bepaalt welke verplichtingen op welk detailniveau gelden.

DORA past een proportionaliteitsbeginsel toe. Micro-ondernemingen (minder dan 10 medewerkers, jaaromzet onder €2 miljoen) komen in aanmerking voor een vereenvoudigd regime voor meerdere pijlers. Als uw organisatie dicht bij deze drempel zit, bevestig dan of het vereenvoudigde of het volledige regime op u van toepassing is.

DORA vereist dat elke financiële entiteit in het toepassingsgebied een gedocumenteerd ICT-risicobeheerkader onderhoudt dat de volledige levenscyclus van een risico bestrijkt: identificatie, bescherming, detectie, respons en herstel. Het kader moet worden goedgekeurd door het beheersorgaan en ten minste jaarlijks worden herzien.

Doorloop bij het beoordelen van uw lacune op deze pijler de volgende vragen:

• Bestaat er een gedocumenteerd ICT-risicobeheerkader, of zijn uw controles informeel? DORA vereist dat het kader schriftelijk is, door uw bestuur is goedgekeurd en versiegecontroleerd is.
• Dekt het alle vijf functies? Identificatie (activainventaris, mapping van kritieke functies), bescherming (toegangscontroles, patchbeheer), detectie (logging, monitoring), respons (incidentafhandelingsprocedures) en herstel (back-up- en herstelprocedures, RTO/RPO-doelstellingen).
• Heeft uw bestuur het goedgekeurd? DORA artikel 5 plaatst het ICT-risicobeheerkader direct op de agenda van het beheersorgaan. Als uw bestuur het kader niet expliciet heeft goedgekeurd, is dat een lacune, ongeacht hoe goed het document is geschreven.
• Is uw activainventaris compleet? U kunt niet beschermen wat u niet heeft gecatalogiseerd. Breng alle ICT-activa in kaart die kritieke of belangrijke functies ondersteunen, inclusief die bij derde partijen worden gehost.
• Weerspiegelen uw bedrijfscontinuïteits- en herstelplannen de huidige infrastructuur? Plannen die verwijzen naar verouderde systemen of niet-geteste herstelprocedures voldoen niet bij een audit.

De meest voorkomende lacune bij deze pijler is niet de afwezigheid van controles, maar de afwezigheid van documentatie. De meeste FinTechs hebben technici die weten hoe de systemen werken; minder hebben schriftelijke kaders die een toezichthouder kan lezen en beoordelen.

DORA stelt verplichte meldingstermijnen in voor grote ICT-gerelateerde incidenten. Een incident kwalificeert als ernstig wanneer het aan een of meer materialiteitsdrempels voldoet:

Zodra een incident als ernstig wordt geclassificeerd, gelden drie meldingstermijnen vanaf die classificatie:

• 4 uur: eerste melding aan de bevoegde autoriteit, over de aard van het incident, de impact en de genomen inperkingsmaatregelen.
• 72 uur: tussenrapport met een uitgebreidere beoordeling van de oorzaak, de omvang van de impact en de status van het herstel.
• 1 maand: eindrapport met analyse van de hoofdoorzaak, corrigerende maatregelen en eventuele grensoverschrijdende effecten.

Controleer bij het beoordelen van uw lacune hier of uw incidentrespons-runbooks een classificatiestap bevatten aan de hand van de DORA-materialiteitsdrempels en een benoemde persoon die verantwoordelijk is voor de melding aan de toezichthouder. De meeste incidentresponsprocessen van FinTechs stoppen bij inperking. De meldingsplicht begint bij classificatie, niet bij oplossing.

DORA vereist dat alle entiteiten in het toepassingsgebied een programma voor het testen van operationele veerkracht uitvoeren. De vereisten zijn opgesplitst naar entiteitsomvang en significantie.

Alle entiteiten in het toepassingsgebied moeten ten minste jaarlijks kwetsbaarheidsbeoordelingen, scenario-gebaseerde tests en netwerkbeveiligingsbeoordelingen uitvoeren. Deze bestrijken ICT-tools en -systemen die kritieke of belangrijke functies ondersteunen, niet het gehele technologielandschap.

Significante entiteiten (aangemerkt door bevoegde autoriteiten op basis van criteria in de TLPT Regulatoire Technische Normen, Gedelegeerde Verordening EU 2025/1190 van de Commissie, van toepassing vanaf juli 2025) moeten daarnaast ten minste om de drie jaar Dreigingsgestuurde Penetratietesten (TLPT) uitvoeren. TLPT volgt het TIBER-EU-kader en vereist een onafhankelijke provider van bedreigingsinformatie en een aparte red team-provider. Uitkomsten worden aan de bevoegde autoriteit gerapporteerd met een voltooiingscertificaat.

Voor uw lacunebeoordeling op deze pijler:

• Maak een lijst van welke tests uw organisatie de afgelopen 12 maanden heeft uitgevoerd en tegen welke systemen.
• Controleer of het toepassingsgebied specifiek ICT-diensten dekte die kritieke of belangrijke functies ondersteunen, niet alleen perimeteractiva.
• Als uw bevoegde autoriteit u heeft meegedeeld dat u in aanmerking komt voor TLPT, bevestig dan de datum van uw laatste test en wanneer de volgende driejaarsperiode begint.
• Beoordeel of testresultaten zijn gedocumenteerd, herstelacties worden bijgehouden en uitkomsten aan het beheersorgaan worden gerapporteerd.

De meeste FinTechs hebben hun grootste DORA-lacune bij risico van derde partijen. De vereisten van DORA gaan ver verder dan een leveranciersvragenlijst.

Het centrale element is het Informatieregister (ROI), vereist op grond van artikel 28(3). Het ROI is een gestructureerde inventaris van elke contractuele regeling die uw organisatie heeft met ICT-dienstverleners van derde partijen. Het moet onderscheid maken tussen regelingen die kritieke of belangrijke functies ondersteunen en regelingen die niet-kritieke functies ondersteunen, en het moet worden bijgehouden op entiteit-, sub-geconsolideerd en geconsolideerd niveau. Het ROI wordt jaarlijks bij bevoegde autoriteiten ingediend, waarbij de cyclus van 2026 een referentiedatum van 31 december 2025 hanteert.

In de ESA-droogoefening in 2024 slaagde slechts 6,5% van de bijna 1.000 deelnemende bedrijven voor alle 116 datakwaliteitscontroles. De meest voorkomende fouten waren onvolledige contractgegevens, ontbrekende informatie over onderaannemers en onjuiste CIF-classificaties (Common Information Framework). Als u nog niet begonnen bent met het opbouwen van uw ROI, begin dan nu.

Naast het ROI moet uw lacunebeoordeling op deze pijler het volgende omvatten:

• Due diligence. Voert u gedocumenteerde risicobeoordelingen uit vóór het aan boord nemen van ICT-dienstverleners die kritieke functies ondersteunen? DORA vereist precontractuele due diligence, niet alleen jaarlijkse reviews.
• Contractvoorwaarden. Bevatten uw ICT-contracten met aanbieders van kritieke of belangrijke functies de verplichte bepalingen op grond van DORA artikel 30? Dit omvat: duidelijke beschrijvingen van diensten en SLA's, beveiligingsvereisten, auditrechten, verplichtingen voor incidentrapportage en exitbepalingen.
• Onderaannemers. Weet u aan wie uw kritieke aanbieders uitbesteden? DORA vereist dat u materiële onderaannemingsketens bijhoudt, niet alleen directe leveranciersrelaties.
• Concentratierisico. Heeft u meerdere kritieke functies die afhankelijk zijn van één aanbieder? DORA verwacht van entiteiten dat ze ICT-concentratierisico op zowel bedrijfs- als sectoraal niveau identificeren en beheren.

De vijfde pijler van DORA staat financiële entiteiten toe deel te nemen aan regelingen voor informatie-uitwisseling over cyberdreigingen, bedreigingsinformatie en aanvalsindicatoren. Deelname is vrijwillig en vereist dat uitwisselingsregelingen voldoen aan verplichtingen inzake gegevensbescherming en het mededingingsrecht niet schenden.

Voor de meeste FinTechs in de lacuneanalysefase heeft deze pijler een lagere prioriteit dan de eerste vier. De te beoordelen lacune is simpelweg of uw organisatie een standpunt heeft over informatie-uitwisseling, weet welke forums in uw sector bestaan en de vertrouwelijkheids- en juridische parameters van deelname heeft overwogen.

De herstelroadmap opstellen

Een lacuneanalyse levert een lijst van bevindingen over vijf pijlers. Die lijst omzetten naar een roadmap vereist drie zaken: een ernstbeoordeling voor elke lacune, een realistische inspanningsraming en een volgordlogica.

Gebruik deze aanpak voor de volgorde:

1. Los eerst regelgevingsblootstelling op. Lacunes in incidentrapportageprocedures en het ROI dragen het hoogste onmiddellijke handhavingsrisico. Breng die tot een verdedigbare staat voordat u uw ICT-risicobeheerkader verfijnt.
2. Documenteer wat al werkt. De meeste FinTechs hebben controles die bestaan maar niet zijn opgeschreven. Informele praktijk omzetten in gedocumenteerd beleid gaat sneller dan nieuwe controles bouwen en vermindert uw lacunetal.
3. Plan werk bij derde partijen vroeg in. Het heronderhandelen van leverancierscontracten en het opbouwen van uw ROI vereisen allebei doorlooptijd die u niet in de hand heeft. Start die werkstromen parallel aan uw interne beleidswerk, niet erna.
4. Stem testen af op uw volgende cyclus. Als uw jaarlijkse penetratietest over drie maanden is gepland, plan dan uw herstel van de testlacune zo dat het in die cyclus valt in plaats van een aparte beoordeling in te plannen.

De roadmap moet eigenaren benoemen voor elke actie, een einddatum hebben en worden beoordeeld door uw beheersorgaan. De verplichtingen van het beheersorgaan onder DORA betekenen dat uw bestuur dit document moet zien en het herstelplan formeel moet goedkeuren, niet alleen een samenvatting ontvangt.

Toezichthouders behandelden 2025 als een overgangsjaar, waarbij kaders werden beoordeeld en verwachtingen werden gesteld in plaats van onmiddellijke sancties te nemen. Die periode sluit. Organisaties die bij een regelgevingsreview komen met een voltooide lacuneanalyse en een door het bestuur goedgekeurde roadmap staan wezenlijk sterker dan organisaties die werk in uitvoering presenteren.