Het DORA-informatieregister (DORA RoI) is het gestructureerde overzicht dat elke financiële entiteit in de EU moet bijhouden van al haar contractuele regelingen met ICT-dienstverleners die derde partij zijn, met een aanduiding van de regelingen die kritieke of belangrijke functies ondersteunen. Het is vereist door artikel 28(3) van DORA, gestandaardiseerd door de 15 templates van Uitvoeringsverordening (EU) 2024/2956 en wordt elk jaar opgevraagd door de nationale bevoegde autoriteiten.
Het is niet zomaar een extra bijlage bij het leveranciersdossier: de Europese toezichthoudende autoriteiten (ESA's) hebben deze registers gebruikt om op 18 november 2025 de eerste 19 kritieke ICT-dienstverleners die derde partij zijn aan te wijzen. En de datakwaliteit blijft het zwakke punt: bij de dry run van 2024 doorstond slechts 6,5% van de geanalyseerde registers alle controles. Deze gids behandelt wat het register bevat, waarom indieningen worden afgewezen en hoe u het actueel houdt.
De versie in 30 seconden
- Rechtsgrond: artikel 28(3) van DORA; formaat vastgelegd door Uitvoeringsverordening (EU) 2024/2956 (15 templates, van B_01.01 tot B_99.01).
- Toepassingsgebied: elke regeling voor ICT-diensten, intragroepsregelingen inbegrepen, op entiteitsniveau en, voor groepen, op gesubconsolideerd en geconsolideerd niveau.
- Rapportering: jaarlijks, met als referentiedatum 31 december van het voorgaande jaar.
- Afwijzingen: vooral lege verplichte velden, ongeldige LEI's of EUID's en verweesde verwijzingen tussen templates.
- Methode: houd het register bij naarmate contracten wijzigen, niet één keer per jaar.
Wie moet een DORA-informatieregister bijhouden, en op welk niveau?
Artikel 28(3) van DORA, van toepassing sinds 17 januari 2025, verplicht financiële entiteiten om:
- het register bij te houden en te actualiseren op entiteitsniveau en op gesubconsolideerd en geconsolideerd niveau;
- de regelingen voor ICT-diensten die kritieke of belangrijke functies ondersteunen te onderscheiden;
- minstens jaarlijks te rapporteren over het aantal nieuwe regelingen, de categorieën van dienstverleners, het type regelingen en de geleverde ICT-diensten en functies;
- het volledige register of bepaalde delen ervan op verzoek ter beschikking te stellen;
- de autoriteit tijdig te informeren over elke geplande regeling die een kritieke of belangrijke functie ondersteunt, en wanneer een functie kritiek of belangrijk wordt.
Elke financiële entiteit binnen het toepassingsgebied van DORA valt hieronder: banken, verzekeraars, beleggingsondernemingen, betalings- en e-geldinstellingen, aanbieders van cryptoactivadiensten, vermogensbeheerders. Een vaak verkeerd begrepen punt: artikel 28(2) stelt micro-ondernemingen en entiteiten onder het vereenvoudigde kader vrij van het vaststellen van een formele strategie voor ICT-derdepartijrisico, maar artikel 28(3) bevat geen vrijstelling voor het register.
In een groep bepaalt de moederonderneming de perimeter, en het geconsolideerde register omvat alle financiële entiteiten en ICT-dienstverleners binnen de groep (artikel 6 van Verordening 2024/2956). Het register omvat elke rechtstreekse leverancier, plus de onderaannemers die een dienst ter ondersteuning van een kritieke of belangrijke functie daadwerkelijk ondersteunen. En "ICT-diensten" is een ruim begrip: SaaS, cloud, marktgegevens, managed services, licenties met onderhoud, diensten geleverd door een dochteronderneming van de groep. Registers worden opgevraagd door elke nationale bevoegde autoriteit (NCA); significante kredietinstellingen die rechtstreeks onder toezicht van de ECB staan, volgen de instructies van de ECB.
Wat bevat het register? De 15 RoI-templates van ITS 2024/2956
Uitvoeringsverordening (EU) 2024/2956 van 29 november 2024, gepubliceerd in het Publicatieblad op 2 december 2024, legt de standaardtemplates vast. Bijlage I beschrijft er 15, opgevat als relationele tabellen: vaste kolommen, onbeperkt aantal rijen, één waarde per cel.
| Template | Inhoud | Aandachtspunt |
|---|---|---|
| B_01.01 | Entiteit die het register bijhoudt | Geïdentificeerd door haar LEI |
| B_01.02 | Entiteiten binnen de consolidatiekring | LEI verplicht voor elke financiële entiteit |
| B_01.03 | Bijkantoren buiten het land van herkomst | Vaak vergeten |
| B_02.01 | Contractuele regelingen: algemene informatie | Uniek referentienummer, jaarlijkse kost |
| B_02.02 | Contractuele regelingen: specifieke informatie | Ondersteunde functie, data, opzegtermijnen, toepasselijk recht, locatie van de gegevens |
| B_02.03 | Intragroepscontractuele regelingen | Koppelt het intragroepscontract aan het externe contract |
| B_03.01 tot B_03.03 | Ondertekenaars van de regelingen | Wie tekent als afnemer, wie tekent als aanbieder |
| B_04.01 | Entiteiten die de ICT-diensten gebruiken | Niet noodzakelijk de ondertekenaar |
| B_05.01 | ICT-dienstverleners die derde partij zijn | LEI of EUID, land van de hoofdzetel, jaarlijkse uitgave, uiteindelijke moederonderneming |
| B_05.02 | Toeleveringsketen van ICT-diensten | Rang 1 voor de rechtstreekse leverancier, hoger voor onderaannemers |
| B_06.01 | Identificatie van functies | Gedateerde, gemotiveerde kriticiteit, RTO en RPO in uren |
| B_07.01 | Beoordelingen van de ICT-diensten | Vervangbaarheid, laatste audit, exitplan, alternatieven |
| B_99.01 | Definities | Interne betekenis van de gesloten keuzelijsten |
De vier sleutels die de templates verbinden
Vier sleutels verbinden de templates met elkaar: het referentienummer van de contractuele regeling, de identificatiecode van entiteiten en leveranciers, de functie-identificatiecode en het type ICT-dienst (een code van S01 tot S19, opgesomd in bijlage III). Elke sleutel moet, identiek, voorkomen in de template waarnaar ze verwijst: vermeldt u een contract in B_07.01 dat ontbreekt in B_02.01, dan mislukt de indiening.
De moeilijkst te verzamelen gegevens
- Identificatiecodes. Elke leverancier die een rechtspersoon is, moet worden geïdentificeerd door een geldige en actieve LEI of door een EUID, en door beide indien beschikbaar; financiële entiteiten uitsluitend door hun LEI. Een LEI telt 20 tekens (ISO 17442), waarvan de laatste twee controlecijfers zijn, berekend volgens ISO/IEC 7064 (MOD 97-10).
- Functies. Een gedateerde, gemotiveerde beoordeling van de kriticiteit, plus een RTO en RPO in uren. Een "0" betekent "niet gedefinieerd": een register vol nullen wijst vooral op een ontbrekende bedrijfsimpactanalyse.
- Beoordeling van kritieke diensten: vervangbaarheid op vier niveaus, exitplan, mogelijkheid tot herinternalisering, geïdentificeerde alternatieve leveranciers.
Hoe gebruiken toezichthouders het register?
Op nationaal niveau gebruiken de NCA's het om toezicht te houden op derdepartijrisico. De Franse ACPR verklaarde bijvoorbeeld in een webinar in januari 2026 dat ze de registers gebruikt om kaders voor derdepartijrisico te beoordelen, onderlinge afhankelijkheden in kaart te brengen, concentratie te meten en incidenten te beheren die bij een derde partij ontstaan.
Op EU-niveau bezorgen de NCA's de registers elk jaar aan de ESA's. De criteria voor het aanwijzen van kritieke leveranciers (artikel 31(2)) sluiten rechtstreeks aan op de templates: systemische impact, belang van de entiteiten die op de leverancier steunen, afhankelijkheid voor kritieke of belangrijke functies (ook via onderaanneming) en vervangbaarheid.
Op 18 november 2025 publiceerden de ESA's de eerste lijst van kritieke ICT-dienstverleners die derde partij zijn: 19 namen, waaronder Amazon Web Services, Microsoft, Google Cloud, Oracle, SAP, IBM, Accenture, Capgemini, Orange en Deutsche Telekom. De lijst wordt jaarlijks bijgewerkt (artikel 31(9)). Een leverancier die slecht geïdentificeerd is in uw register, is een leverancier die slecht geaggregeerd wordt in de Europese analyse.
Wanneer en hoe wordt het register ingediend?
Het besluit van de ESA's over de verzameling (ESA 2024 22) legt het principe vast: jaarlijkse rapportering, een referentiedatum van 31 december van het voorgaande jaar en doorgifte van de NCA's aan de ESA's uiterlijk op 31 maart. Het eerste jaar was een uitzondering.
| Cyclus | Referentiedatum | Indiening bij de NCA | Doorgifte aan de ESA's |
|---|---|---|---|
| 2025 (eerste) | 31 maart 2025 | Nationale vensters, vóór 30 april | 30 april 2025 |
| 2026 | 31 december 2025 | Nationale vensters in Q1 (Frankrijk: 1 januari tot 31 maart; Luxemburg: 11 februari tot 31 maart) | 31 maart 2026 |
| 2027 | 31 december 2026 | Te bevestigen door elke NCA | 31 maart 2027, volgens het besluit van de ESA's |
Het formaat. Het rapporteringspakket is een .zip-archief met één CSV-bestand per template plus JSON-metadata, in xBRL-CSV ("plain CSV" in EBA-terminologie). De EBA publiceert het datapuntmodel (DPM), de taxonomie, de validatieregels en de FAQ op haar DORA-voorbereidingspagina. De conversietool van Excel naar CSV die tijdens de dry run werd aangeboden, wordt niet langer onderhouden: elke entiteit kiest haar eigen oplossing. Elke NCA heeft haar eigen portaal (OneGate voor de ACPR in Frankrijk, eDesk voor de CSSF in Luxemburg), en sommige bieden een testomgeving aan. Gebruik die, en dien tijdig in.
Welke fouten leiden tot de afwijzing van een register?
Drie publieke bronnen vertellen hetzelfde verhaal. Bij de dry run van 2024 (rapport van de ESA's van 17 december 2024) waren ontbrekende verplichte velden goed voor ongeveer 86% van de mislukte controles. Voor de eerste officiële indieningen somt het overzicht van de EBA van april 2025 (bijgewerkt in mei) schendingen van vreemde sleutels op, ontbrekende primaire sleutels, LEI's die niet in de GLEIF-databank voorkomen en wijdverspreide misvormde EUID's: 58.170 met een ongeldig formaat, tegenover 2.717 die werden teruggevonden in het systeem voor de koppeling van ondernemingsregisters in de EU. Voor de campagne 2026 vermeldde de ACPR verkeerde referentiedata, slecht gestructureerde archieven en bestanden die niet in UTF-8 waren gecodeerd.
| Fout | Typisch voorbeeld | Preventie |
|---|---|---|
| Leeg verplicht veld | Leverancierscode ontbreekt in B_02.02 | Volledigheidscontrole per template |
| Verweesde verwijzing | Contract vermeld in B_07.01, ontbreekt in B_02.01 | Eén uniek contractnummer, overal hergebruikt |
| Ongeldige LEI | Nationaal registratienummer ingevoerd in plaats van de LEI | Controle van formaat en controlecijfers, daarna opzoeking in GLEIF |
| Misvormde EUID | LEI gerapporteerd als EUID | Formaatregel bij invoer |
| Waarde buiten de lijst | Optie die niet in het DPM staat | EBA-lijsten met toegestane waarden |
| Technische fout | Codering, mappenstructuur, referentiedatum | Testindiening |
Let op: een register dat het ene jaar wordt aanvaard, kan het volgende jaar worden afgewezen. Voor 2026 kondigde de Luxemburgse CSSF aan dat ze dezelfde validatieregels op meer velden zou toepassen.
Het register opbouwen en bijhouden in 7 stappen
Stap 1 — Wijs een eigenaar aan
Het register combineert gegevens die niemand alleen beheert: contracten (aankoop), diensten (IT), kriticiteit en herstelobjectieven (bedrijfscontinuïteit), concentratie (risico), clausules (juridische dienst). Wijs één eigenaar van het register aan en één verantwoordelijke per gegevensblok.
Stap 2 — Inventariseer elke ICT-regeling
Breng drie bronnen met elkaar in overeenstemming: de contractendatabank, de leveranciersboekhouding en de applicatie-inventaris. De verschillen brengen met de kaart betaalde SaaS-abonnementen, vergeten raamovereenkomsten en diensten van een dochteronderneming zonder schriftelijk contract aan het licht.
Stap 3 — Verzamel en verifieer identificatiecodes
Per leverancier: LEI gecontroleerd in de publieke GLEIF-databank, EUID indien geregistreerd in de EU, land van de hoofdzetel, uiteindelijke moederonderneming. Maak van deze gegevens een contractuele verplichting, ook voor kritieke onderaannemers: de ESA's waarschuwden al in 2024 dat identificatiecodes van leveranciers mogelijk niet onmiddellijk beschikbaar zijn.
Stap 4 — Koppel elke dienst aan de functies die ze ondersteunt
Een functie is kritiek of belangrijk wanneer de verstoring ervan de financiële prestaties van de entiteit, de degelijkheid of continuïteit van haar diensten of haar naleving wezenlijk zou aantasten (artikel 3(22) van DORA). Hergebruik de lijst uit uw BIA, met de bijbehorende RTO's en RPO's: hier raakt het register het bedrijfscontinuïteitsplan, dat dezelfde functies en dezelfde herstelobjectieven moet bevatten.
Stap 5 — Breng de onderaannemingsketen in kaart
Vraag voor elke kritieke dienst aan de rechtstreekse leverancier de lijst van onderaannemers van wie een uitval de beveiliging of continuïteit van de dienst zou aantasten, en ken hun een rang toe. Gedelegeerde Verordening (EU) 2025/532 bepaalt wat de entiteit moet beoordelen alvorens dergelijke onderaanneming te aanvaarden.
Stap 6 — Beoordeel vervangbaarheid, exit en alternatieven
Kan de leverancier worden vervangen? Kan de dienst opnieuw intern worden uitgevoerd? Is er een alternatief geïdentificeerd? "Ja" antwoorden op de vraag over het exitplan is een engagement: het plan moet bestaan, gedocumenteerd zijn en getest worden.
Stap 7 — Controleer, dien in en houd daarna continu bij
Vóór elke indiening: volledigheid, formaat, uniciteit van sleutels, kruisverwijzingen, daarna een testindiening. Koppel vervolgens de updates aan de levenscyclus van contracten: nieuwe regeling, wijziging, beëindiging, gewijzigde locatie van de gegevens, nieuwe onderaannemer, functie die als kritiek wordt geherclassificeerd (wat ook aan de autoriteit moet worden gemeld). Een driemaandelijkse afstemming met de leveranciersboekhouding vangt op wat tussen de mazen glipte.
Register, artikel 30, concentratie en exit: één dossier
Clausules van artikel 30. Elk contract voor ICT-diensten moet onder meer de diensten beschrijven, de voorwaarden voor onderaanneming, waar diensten worden verleend en gegevens worden verwerkt, de serviceniveaus en de beëindigingsrechten met opzegtermijnen. Voor kritieke of belangrijke functies komen daar gekwantificeerde serviceniveaus bij, geteste noodplannen bij de leverancier, auditrechten en exitstrategieën. Verschillende kolommen van het register worden rechtstreeks uit deze clausules ingevuld: opzegtermijnen, toepasselijk recht, land van dienstverlening, locatie van de gegevens. Een veld dat u niet kunt invullen, wijst vaak op een ontbrekende clausule. Voor leveranciers van digitale producten komen daar de contractclausules van de Cyber Resilience Act nog bij.
Concentratierisico (artikel 29). Alvorens een kritieke regeling aan te gaan, gaat de entiteit na of die haar afhankelijk zou maken van een leverancier die niet gemakkelijk vervangbaar is, of het aantal kritieke regelingen met dezelfde of nauw verbonden leveranciers zou vermenigvuldigen. Groepeer regelingen op identificatiecode en uiteindelijke moederonderneming, en concentraties worden zichtbaar; met handmatig ingetikte namen ("AWS", "Amazon Web Services EMEA") blijven ze onzichtbaar.
Exitstrategieën (artikel 28(8)). Voor diensten die kritieke of belangrijke functies ondersteunen, heeft de entiteit gedocumenteerde, geteste en periodiek herziene exitplannen nodig, zodat ze een leverancier kan verlaten zonder haar activiteiten te verstoren. Dit is bedrijfscontinuïteit: het falen van een derde partij is een van de onbeschikbaarheidsscenario's die een bedrijfscontinuïteitsplan moet dekken.
Spreadsheet of gespecialiseerde tool?
Een werkmap volstaat voor een entiteit met enkele tientallen contracten en geen groep om te consolideren. Daarboven worden vijftien handmatig consistent gehouden tabbladen onbeheersbaar, en verwordt het register tot een kopie van aankoop-, IT- en continuïteitsgegevens die de dag na de indiening al afwijkt. De echte vraag is niet de tool, maar waar de gegevens zich bevinden. Zie ook: spreadsheet vs ResiPlan.
Wat ResiPlan concreet doet
- Register samengesteld uit bestaande gegevens, zonder dubbele invoer: leveranciers, contracten, kritieke of belangrijke functies en hun koppelingen met leveranciers voeden de templates die vandaag worden ondersteund, namelijk 5 van de 15 templates (B_01.02, B_02.02, B_05.01, B_06.01, B_07.01); de andere staan op de roadmap.
- Validatiecontroles vóór indiening: verplichte velden, toegestane waarden, LEI-formaat en controlecijfers (ISO 17442), landcodes, verweesde verwijzingen tussen templates.
- Migratie: import van een bestaand registerbestand.
- Groepsoverzicht: geconsolideerd register op groepsniveau en een concentratieoverzicht per leverancier.
- Contracten: een checklist met contractuele clausules van artikel 30 voor elk contract.
- Export van het register naar Excel en CSV, plus een xBRL-CSV-pakket om te valideren in de testomgeving van uw autoriteit vóór elke indiening.
Bedrijfsgegevens worden gehost in de Europese Unie. Voor alle duidelijkheid: software maakt niemand compliant en certificeert niemand, en ResiPlan dient niets in bij de autoriteiten in uw naam. Ontdek de module informatieregister of start een gratis proefperiode van 7 dagen, zonder kredietkaart.
Checklist: is uw register klaar voor de volgende indiening?
- Een eigenaar van het register en één verantwoordelijke per gegevensblok zijn aangewezen.
- De inventaris is afgestemd op de leveranciersboekhouding en de applicatie-inventaris.
- Elke financiële entiteit heeft een geldige LEI; elke leverancier die een rechtspersoon is, heeft een geverifieerde LEI of EUID, en de uiteindelijke moederonderneming is geïdentificeerd.
- Elke dienst is gekoppeld aan haar functies, met een gedateerde en gemotiveerde beoordeling van de kriticiteit.
- RTO's en RPO's komen uit de BIA, en geen enkele "0" verbergt een onbekende waarde.
- Onderaannemers die kritieke diensten ondersteunen, zijn opgelijst met hun rang.
- Elk "ja" op de vraag over het exitplan stemt overeen met een gedocumenteerd, getest plan.
- Controles op volledigheid, formaat en kruisverwijzingen verlopen zonder fouten.
- Er is een testindiening uitgevoerd in de testomgeving van uw autoriteit.
Voor een bredere diagnose: de DORA-readinesschecklist en de snelle check leveranciersrisico.
FAQ
Heeft elke ICT-leverancier een LEI nodig?
Leveranciers die rechtspersonen zijn, hebben een geldige en actieve LEI of een EUID nodig, en beide indien beschikbaar. Financiële entiteiten kunnen alleen door hun LEI worden geïdentificeerd. Enkel natuurlijke personen die in het kader van een beroepsactiviteit handelen, mogen met een andere code worden geïdentificeerd, voorafgegaan door de landcode.
Moeten niet-kritieke leveranciers in het register staan?
Ja. Het register omvat elke regeling over het gebruik van ICT-diensten. Het onderscheid verandert alleen het detailniveau: de beoordeling in B_07.01 en het oplijsten van onderaannemers gelden enkel voor diensten die kritieke of belangrijke functies ondersteunen.
Vallen intragroepsregelingen onder het toepassingsgebied?
Ja. ICT-dienstverleners binnen de groep zijn volwaardige leveranciers. Wanneer een IT-dochteronderneming diensten aankoopt bij een derde partij namens de groep, koppelt template B_02.03 het intragroepscontract aan het externe contract, zodat de volledige keten zichtbaar is.
Wanneer is de volgende indiening?
Volgens het besluit van de ESA's gebruikt de volgende cyclus als referentiedatum 31 december 2026, met doorgifte aan de ESA's uiterlijk op 31 maart 2027. Elke NCA bepaalt haar eigen verzamelvenster, meestal in het eerste kwartaal: in 2026 liep dat van Frankrijk van 1 januari tot 31 maart. Volg de aankondigingen van uw toezichthouder vanaf het einde van het jaar.
Hoe lang duurt het om het register op te bouwen?
Dat hangt af van het aantal regelingen, van hoe vlot leveranciers hun identificatiecodes aanleveren en van het bestaan van een actuele BIA. In de praktijk kan een entiteit met een propere contractendatabank en een recente BIA in enkele weken een eerste register opleveren; een groep die vertrekt van verspreide spreadsheets moet op meerdere maanden rekenen.
Verder lezen
- DORA-gids 2026: verplichtingen voor financiële entiteiten
- DORA 2026: eerste auditcyclus, wat u kunt verwachten
- DORA vs NIS2: welke is van toepassing op uw organisatie?
- Bedrijfscontinuïteitsplan: gids in 8 stappen voor 2026
- Gids voor de bedrijfsimpactanalyse
Een informatieregister is geen jaarlijkse oplevering: het is een momentopname, op een bepaalde datum, van leveranciersrelaties die u het hele jaar door beheert.