DORA informatieregister: hoe bouw en onderhoud je het met je SASE platform?

Elke financiële entiteit die onder DORA valt, moet een informatieregister indienen bij haar nationale toezichthouder. De eerste indieningsronden begin 2026 brachten een pijnlijke realiteit aan het licht: ruwweg 235.000 validatiefouten bij meer dan 1.000 deelnemende instellingen tijdens de ESR dry run. De meeste fouten kwamen door ontbrekende velden, onjuiste identificatoren en onvolledige contractgegevens. Als je team nog steeds met spreadsheets werkt, zijn de kansen niet in je voordeel.

In deze gids wordt uitgelegd wat het register vereist, hoe het vanaf nul moet worden opgebouwd, welke fouten ertoe leiden dat inzendingen worden afgewezen en hoe je beveiligingsarchitectuur direct bepaalt hoe complex het register wordt. Voor een bredere kijk op hoe SASE past bij alle vijf DORA-pijlers, zie onze gids over SASE voor financiële diensten onder DORA.

Wat is het DORA-informatieregister?

Het DORA-informatieregister is een gestructureerde dataset die financiële entiteiten moeten bijhouden krachtens artikel 28, lid 3, van de Wet Digitale Operationele Weerbaarheid. Het documenteert elke contractuele afspraak met externe ICT-dienstverleners, inclusief contractvoorwaarden, gegevensopslaglocaties, beoordelingen van de kriticiteit, sub-outsourcingketens en exitstrategieën. Nationale toezichthouders gebruiken het register om het concentratierisico in het hele financiële systeem te monitoren. De Europese toezichthoudende autoriteiten kunnen gebruik maken van geaggregeerde registergegevens om kritieke ICT-leveranciers aan te wijzen voor direct toezicht.

Wat DORA Artikel 28 vereist in het register

Artikel 28, lid 3, schrijft voor dat financiële entiteiten een volledig register bijhouden op entiteitsniveau, gesubconsolideerd niveau en geconsolideerd niveau. Dit is geen eenvoudige verkoperslijst. Het is een relationele dataset die 15 onderling verbonden sjablonen omvat die zijn gedefinieerd door de technische uitvoeringsnormen (ITS) van de EBA, gepubliceerd in het Reporting Framework 4.0.

Elk sjabloon beschrijft een andere dimensie van de relatie tussen ICT en derden. De belangrijkste sjablonen en hun aandachtsgebieden:

De sjablonen vormen een relationele structuur. Een contract ID in RT.02.01 linkt naar de dienstverlener in RT.05.01, de functies die het ondersteunt in RT.06.01, en de risicobeoordeling in RT.07.01. Als één veld verkeerd wordt ingevuld, kan dat leiden tot fouten in meerdere sjablonen.

Het uiteindelijke indieningsformaat is xBRL-CSV. Hoewel sommige toezichthouders een tijdelijke conversie op basis van Excel aanboden voor de eerste cyclus, is de verwachting vanaf 2026 dat instellingen direct in het voorgeschreven formaat indienen.

Welke entiteiten moeten een register bijhouden (en wanneer)

DORA is breed van toepassing. Kredietinstellingen, betalingsaanbieders, verzekeringsmaatschappijen, beleggingsondernemingen en aanbieders van crypto-activadiensten vallen allemaal binnen het toepassingsgebied. De definitie van “ICT-dienstverlener” is net zo breed: elk bedrijf dat op permanente basis digitale diensten, datadiensten of hardwareondersteuning levert. Dit omvat je cloud hosting provider, je SaaS HR-systeem, je managed firewall leverancier en je telecomprovider.

Micro-ondernemingen krijgen beperkte vrijstellingen van bepaalde ICT-risicobeheervereisten, maar de registerverplichting zelf geldt voor vrijwel alle gereguleerde entiteiten.

Benelux deadlines voor 2026

De indieningstermijnen verschillen per toezichthouder. Ze gebruiken allemaal 31 december 2025 als referentiedatum voor actieve contracten.

De NBB raadt ten zeerste aan om inzendingen te testen in de OneGate TEST-omgeving vóór de productiedeadline. Gezien de foutenpercentages van de generieke test, is het de moeite waard om dit serieus te nemen.

België telt naar schatting meer dan 200 financiële entiteiten die jaarlijks moeten rapporteren, waaronder kredietinstellingen, verzekeraars, beleggingsondernemingen en betalingsproviders. Voor instellingen met kleine compliance teams concurreert het register om aandacht met NIS2-rapportage, CyFun-verificatie en dagelijkse werkzaamheden.

Stap voor stap: je register vanaf nul opbouwen

Stap 1: Inventariseer elke ICT-dienstverlener

Begin met contracten, niet met technologie. Trek je inkoopgegevens, crediteurengegevens en bestaande leverancierslijsten na. Elke leverancier die een digitale dienst levert, gegevens beheert, software levert of hardware doorlopend ondersteunt, hoort thuis in het register.

Vaak over het hoofd geziene categorieën zijn onder andere cyberbeveiligingstools (VPN-providers, firewallleveranciers, webfilterdiensten, endpointbescherming), SaaS-platforms voor niet-kernprocessen (HR, CRM, ticketing), telecom- en connectiviteitsleveranciers en hardwareleveranciers met lopende onderhouds- of firmware-updateovereenkomsten.

Dit is waar je beveiligingsarchitectuur de eerste invloed heeft op de complexiteit van het register. Een organisatie die aparte producten gebruikt voor VPN-toegang, webfiltering, firewallbeheer en SD-WAN-connectiviteit moet vier beveiligingsleveranciers documenteren. Een organisatie die gebruik maakt van Jimbers uniforme SASE-platform, dat ZTNA, SWG, FWaaS en SD-WAN in één enkele service combineert, hoeft er maar één te documenteren. Alleen al de inventarisatiestap wordt aanzienlijk lichter.

Stap 2: Contractgegevens verzamelen en identificatiecodes toewijzen

Verzamel voor elke provider de begin- en einddatum van het contract, opzegtermijnen, verlengingsvoorwaarden en de Legal Entity Identifier (LEI). De LEI is een alfanumerieke code van 20 tekens die fungeert als een wereldwijde ID voor rechtspersonen. Je toezichthouder gebruikt deze code om het concentratierisico over de hele markt samen te voegen.

Veel ICT-leveranciers in het middensegment van de markt hebben geen LEI. In dat geval staat DORA het gebruik van een European Unique Identifier (EUID) toe, opgebouwd als de ISO-landencode gevolgd door een punt en het nationale registratienummer. Zorg dat het formaat klopt. Een onjuist gestructureerde EUID leidt tot automatische afwijzing.

Met een geconsolideerde beveiligingsstapel wordt deze stap proportioneel kleiner. Eén leverancier betekent één LEI om te verifiëren, één contract om te documenteren, één set van verlengingsvoorwaarden om bij te houden. Met vijf afzonderlijke beveiligingsleveranciers moet je dit proces vijf keer herhalen, elk met zijn eigen risico op fouten bij het invoeren van gegevens.

Stap 3: Breng services in kaart met bedrijfsfuncties

Sjabloon RT.06.01 vereist dat je elke ICT-dienst koppelt aan de gelicentieerde activiteiten die het ondersteunt. Hier moeten compliance officers en IT-managers samenwerken. De compliance officer weet welke activiteiten gelicenseerd zijn. De IT-manager weet welke systemen deze ondersteunen.

Voor een vermogensbeheerbedrijf verwijst het portefeuillebeheersysteem naar beleggingsdiensten. Het e-mailplatform staat voor communicatie met klanten. Een SASE-platform zoals Jimber brengt netwerktoegangscontroles, webbeveiliging en beveiligingsmonitoring in kaart, allemaal gedocumenteerd als functies van één dienst in plaats van drie of vier aparte items in de sjabloon.

Stap 4: De kriticiteit beoordelen en gegevenslocaties documenteren

In sjabloon RT.02.02 wordt gevraagd of elke ICT-dienst een “kritieke of belangrijke functie” ondersteunt. Deze classificatie leidt tot extra vereisten: gedocumenteerde exitstrategieën, auditrechten en meer gedetailleerde risicobeoordelingen in RT.07.01.

Leg voor elke dienst vast waar de gegevens worden opgeslagen en verwerkt. Granulariteit op landniveau wordt verwacht. Als uw leverancier van webbeveiliging verkeer verwerkt via knooppunten in de EU, maar metagegevens opslaat in de Verenigde Staten, dan is dat van belang. Dit brengt aanvullende documentatievereisten met zich mee rond de waarborgen voor gegevensoverdracht.

Jimber verwerkt alle gegevens binnen de EER, waardoor het gegevenslocatieveld in RT.02.02 eenvoudig is: één invoer, één jurisdictie, geen documentatie voor grensoverschrijdende overdracht nodig. Vergelijk dit met een beveiligingsleverancier met hoofdkantoor in de VS, waar je de blootstelling aan de CLOUD Act, standaard contractuele clausules en restrisicobeoordelingen voor elke servicecomponent moet documenteren.

Stap 5: Subuitbesteding en toeleveringsketens documenteren

Sjabloon RT.05.02 heeft betrekking op onderaannemers. Als uw cloudbeveiligingsleverancier een in de VS gevestigde infrastructuurleverancier gebruikt, moet die relatie worden gedocumenteerd. Vraag elke leverancier schriftelijk naar zijn regelingen voor uitbesteding. Velen zullen deze informatie niet vrijwillig verstrekken zonder een rechtstreeks verzoek.

Minder leveranciers betekent minder sub-outsourcingketens om te traceren. Met één SASE-provider met een transparante architectuur hoef je maar één toeleveringsketen te documenteren in plaats van vijf.

Stap 6: Risicobeoordelingen en exitstrategieën voltooien

Voor diensten die als kritiek of belangrijk worden geclassificeerd, vereist RT.07.01 gedocumenteerde risicobeoordelingen en bevestiging dat er exitstrategieën bestaan. De exitstrategie moet meer zijn dan een clausule in een contract. Er moet worden beschreven hoe de overgang naar een alternatieve leverancier of het intern brengen van de functie zal verlopen, met inbegrip van tijdschema’s, mechanismen voor de overdraagbaarheid van gegevens en effectbeoordelingen.

Cloud-native platforms zoals Jimber vereenvoudigen de exitplanning omdat er geen afhankelijkheid is van propriëtaire hardware. Configuratie kan worden geëxporteerd via API, logs volgen gestandaardiseerde formaten en het toegangsbeleid wordt centraal gedocumenteerd. Zet dit eens af tegen een legacy firewallleverancier waar exit betekent dat fysieke appliances op elke locatie buiten gebruik moeten worden gesteld.

Vijf fouten waardoor registers worden afgewezen

De ESA droge run produceerde ruwweg 235.000 validatiefouten. Deze patronen vormden de meerderheid.

Verplichte velden ontbreken. Dit was de grootste foutcategorie, goed voor meer dan 86% van alle validatiefouten. Onvolledige contractrecords, ontbrekende functietoewijzingen en blanco kriticiteitsbeoordelingen zijn de meest voorkomende boosdoeners. De oplossing is systematisch: voer een volledigheidscontrole uit op elk verplicht veld in de ITS specificatie voor indiening.

Ongeldige of verlopen LEI-codes. LEI-codes moeten actueel en correct geformatteerd zijn. Een verlopen LEI of een typefout in de tekenreeks van 20 tekens leidt tot een automatische afwijzing. Controleer elke LEI met de database van de Global LEI Foundation voor indiening. Dit was goed voor ongeveer 6,5% van de fouten.

Niet-standaard waarden in dropdown velden. De ITS templates gebruiken voorgeschreven codelijsten voor velden als servicetype, kritischheidsniveau en landcodes. Het invoeren van vrije tekst waar een dropdown-waarde wordt verwacht, of het gebruik van interne terminologie in plaats van de EBA-taxonomie, leidt tot afwijzing. Ongeveer 4,3% van de fouten viel in deze categorie.

Secundaire ICT-aanbieders over het hoofd zien. Organisaties hebben de neiging om hun core banking provider en cloud host te registreren, maar vergeten de webfilterdienst, de VPN-leverancier, de endpoint protection tool en het SaaS ticketing systeem. Elk van deze is een ICT-dienstverlener onder de brede definitie van DORA. Dit is een van de sterkste praktische argumenten voor leveranciersconsolidatie: als je VPN, firewall, webfilter en SD-WAN allemaal deel uitmaken van één Jimber SASE-abonnement, hoef je niets te vergeten.

Het register behandelen als een eenmalige oefening. Artikel 28, lid 3 vereist voortdurende updates. Wanneer je van provider verandert, een nieuwe SaaS-tool toevoegt of een dienst herclassificeert als kritiek, moet het register die verandering weerspiegelen. Het indienen van een statische momentopname die zes maanden geleden accuraat was, maar sindsdien is veranderd, is een tekortkoming in de naleving.

Hoe een SASE platform je register vereenvoudigt

Het aantal rijen in uw register wordt direct bepaald door uw beveiligingsarchitectuur. Een financiële instelling in het middensegment van de markt met een typische gefragmenteerde stack, met afzonderlijke leveranciers voor VPN, firewall, webfiltering, SD-WAN-connectiviteit en endpointbeheer, moet elk van deze leveranciers afzonderlijk documenteren. Dat betekent vijf aparte vermeldingen in RT.05.01, vijf contracten in RT.02.01, vijf kriticiteitsbeoordelingen, vijf exitstrategieën en vijf sets documentatie voor uitbesteding.

Jimber consolideert ZTNA, SWG, FWaaS en SD-WAN in één cloud managed platform. De impact op het register is onmiddellijk.

Minder invoer betekent minder kans op validatiefouten, minder contractadministratie en een beter beheersbare jaarlijkse updatecyclus.

Gegevenssoevereiniteit en de CLOUD Act-kwestie

Sjabloon RT.02.02 vereist dat u opgeeft waar gegevens worden opgeslagen en verwerkt. Als uw beveiligingsleverancier in de VS is gevestigd, geeft de Amerikaanse CLOUD Act Amerikaanse autoriteiten de bevoegdheid om openbaarmaking van gegevens af te dwingen, ongeacht waar servers zich fysiek bevinden. Voor Europese financiële instellingen creëert dit een extra documentatielaag: je moet de aanwezige beveiligingsmaatregelen uitleggen, meestal standaard contractuele clausules, en het resterende risico beoordelen.

Jimber heeft zijn hoofdkantoor in Europa en verwerkt alle gegevens binnen de EER. Dat betekent dat het gegevenslocatieveld in RT.02.02 eenvoudig is in te vullen en dat de risicobeoordeling in RT.07.01 geen aandacht hoeft te besteden aan grensoverschrijdende gegevensoverdracht. Voor meer informatie over waarom Europese organisaties hun afhankelijkheid van Amerikaanse leveranciers opnieuw evalueren, zie onze analyse van Europese SASE-alternatieven.

Gecentraliseerde registratie als auditbewijs

Het register vereist dat je aantoont dat er controles bestaan voor elke ICT-dienst. Met vijf afzonderlijke beveiligingstools betekent dit dat je bewijs moet verzamelen van vijf dashboards, vijf logformaten en vijf rapportage-interfaces.

De enkelvoudige beheerconsole van Jimber biedt één uniform audittraject voor toegangscontrole (ZTNA), webbeveiliging (SWG), netwerkbeleid (FWaaS) en connectiviteit (SD-WAN). Als je leidinggevende vraagt hoe je de ICT-diensten controleert die in het register zijn vastgelegd, wijs je naar één platform en één logboekstroom. Dat is een fundamenteel ander gesprek dan uitleggen hoe vijf afzonderlijke vendor dashboards samenwerken.

Praktische exitstrategieën

Artikel 28, lid 8, vereist gedocumenteerde exitstrategieën voor ICT-diensten die kritieke functies ondersteunen. Met een cloud-native platform is het aantonen van overdraagbaarheid eenvoudiger dan met hardware-afhankelijke oplossingen. Jimber’s API-gebaseerde configuratie-export, gestandaardiseerde logformaten en de afwezigheid van propriëtaire on-premise appliances betekenen dat je transitieplan concreet kan zijn in plaats van theoretisch. Je kunt een gedocumenteerde testmigratie uitvoeren en de resultaten vastleggen als bewijs voor template RT.07.01.

Een Belgische vermogensbeheerder verlaagde de beveiligingskosten met 58% na de consolidatie van meerdere puntproducten naar het SASE-platform van Jimber. Het voordeel op het gebied van compliance was een neveneffect van de operationele vereenvoudiging: minder leveranciers om te beheren, minder contracten om bij te houden en één enkele leverancier om te documenteren in het register.

Belgische en Benelux-context

DORA is van toepassing als lex specialis voor de financiële sector en heeft voorrang op NIS2 voor entiteiten die binnen haar toepassingsgebied vallen. In de praktijk hebben veel Belgische organisaties met beide regelgevingen tegelijk te maken. Een bank die is geclassificeerd als een essentiële entiteit onder NIS2 moet zowel voldoen aan het CyFun-verificatiekader (deadline: 18 april 2026) als aan de indiening van het DORA-register bij de NBB.

Het Centrum voor Cybersecurity België (CCB) beheert CyFun, terwijl de NBB en de FSMA het toezicht op DORA uitoefenen. De overlapping creëert zowel lasten als opportuniteiten. Organisaties die hun CyFun-inventarisatie van bedrijfsmiddelen en hun beoordeling van de toeleveringsketen hebben voltooid, beschikken al over veel van de basisgegevens die nodig zijn voor het DORA-register. Het activabeheer en de leverancierscontroles in de Identify and Protect-functies van CyFun vertalen zich rechtstreeks naar de leveranciersinventarisaties en kriticiteitsbeoordelingen in de ITS-sjablonen.

Voor NIS2-nalevingsverplichtingen en de praktische NIS2-nalevingschecklist hebben we speciale gidsen die het CyFun-raamwerk in detail behandelen.

Een praktische uitdaging voor Belgische instellingen is de taal. De EBA-sjablonen zijn in het Engels, maar de communicatie van de NBB en de FSMA over validatiefouten kan in het Nederlands of Frans zijn. Internationale teams moeten ervoor zorgen dat de mensen die de templates invullen en de mensen die de feedback van de toezichthouders behandelen, in verschillende talen kunnen werken zonder vertaalfouten in de gegevens te introduceren.

Nederland activeert zijn Cyberbeveiligingswet in Q1 2026, waardoor Nederlandse financiële instellingen onder parallelle NIS2- en DORA-verplichtingen vallen. DNB verwacht xBRL-CSV-formaat voor 2026 indieningen, met beperkte tolerantie voor Excel-gebaseerde workarounds. Nederlandse instellingen die tijdens de eerste cyclus op tijdelijke conversieondersteuning vertrouwden, moeten plannen maken voor directe xBRL-CSV indiening.

Veelgestelde vragen

Wat is het DORA-informatieregister?

Het informatieregister is een gestructureerde dataset die vereist is op grond van artikel 28, lid 3, van de Wet digitale operationele weerbaarheid. Het documenteert alle contractuele regelingen tussen een financiële entiteit en haar externe ICT-dienstverleners. Het register maakt gebruik van 15 onderling verbonden sjablonen die zijn gedefinieerd door de technische uitvoeringsnormen van de EBA en moet jaarlijks worden ingediend bij de desbetreffende nationale toezichthouder.

Hoe vaak moet het register worden bijgewerkt?

Het register is geen statisch jaarverslag. DORA moet voortdurend worden onderhouden. Elke verandering in contractuele afspraken, nieuwe ICT-dienstverleners, herclassificatie van een dienst als kritiek of wijzigingen in subuitbestedingsketens moeten onmiddellijk worden weergegeven. De jaarlijkse indiening bij je supervisor is een momentopname, maar het onderliggende register moet te allen tijde actueel zijn.

Is DORA van toepassing op ICT-dienstverleners zelf?

DORA reguleert rechtstreeks financiële entiteiten, niet hun ICT-leveranciers. ICT-dienstverleners die door de Europese toezichthoudende autoriteiten als “kritiek” zijn aangemerkt, vallen echter onder een direct toezichtkader. Zelfs niet-kritieke leveranciers staan onder indirecte druk: hun klanten uit de financiële sector zullen contractuele bepalingen eisen met betrekking tot auditrechten, melding van incidenten, exitstrategieën en transparantie over de locatie van gegevens.

Wat gebeurt er als we de deadline voor inzending missen?

DORA geeft nationale toezichthouders de bevoegdheid om administratieve sancties en herstelmaatregelen op te leggen. De specifieke sancties verschillen per land en entiteittype. Afgezien van boetes, geeft een gemiste of onvolledige indiening een signaal van zwakke ICT-governance af aan uw toezichthouder, wat kan leiden tot meer toezicht en frequentere rapportagevereisten.

Moeten we cloudinfrastructuurproviders zoals AWS opnemen in het register?

Ja. Elke leverancier die doorlopend ICT-diensten levert, valt binnen het bereik van DORA. Dit omvat aanbieders van infrastructuur-as-a-service, platform-as-a-service, SaaS-applicaties en managed service providers. Als AWS uw kernapplicatie voor bankieren host, hoort deze in het register thuis met volledige contractgegevens, informatie over de gegevenslocatie en een beoordeling van de kriticiteit.

Hoe beïnvloedt het consolideren van beveiligingstools het register?

Rechtstreeks. Elke afzonderlijke ICT-serviceprovider vereist zijn eigen invoer in meerdere sjablonen: providergegevens, contractinformatie, kriticiteitsbeoordeling, risicobeoordeling en documentatie over de exitstrategie. Consolidatie van vijf beveiligingsproducten naar het uniforme SASE-platform van Jimber brengt het aantal invoergegevens terug van vijf naar één. Dat betekent één LEI om te verifiëren, één contract om te documenteren, één risicobeoordeling om in te vullen en één exitstrategie om bij te houden. Voor een instelling in het middensegment van de markt kan dit het veiligheidsgerelateerde deel van het register met wel 80% verminderen.

Een DORA-register samenstellen dat validatie overleeft, is deels gegevensbeheer, deels een architectuurbeslissing. Hoe minder ICT-aanbieders je hoeft te documenteren, hoe eenvoudiger het register wordt en hoe kleiner het risico op fouten bij de jaarlijkse indiening. Als je team zich voorbereidt op de volgende rapportagecyclus, boek dan een demo om te zien hoe het consolideren van je beveiligingsstack met Jimber de vergelijking verandert.