Template voor het DORA-informatieregister (ITS 2024/2956)

Deze template voor het DORA-informatieregister zet de 15 modellen (templates) van Uitvoeringsverordening (EU) 2024/2956 uiteen, van B_01.01 tot B_99.01, met hun officiële kolomcodes, een ingevuld fictief voorbeeld en de consistentiecontroles waarop een indiening het vaakst mislukt. De uitvoeringsverordening geeft uitvoering aan artikel 28, lid 3, van DORA, dat het register vereist op entiteits-, gesubconsolideerd en geconsolideerd niveau.

Het informatieregister is een geheel van 15 gekoppelde tabellen die elke contractuele overeenkomst voor ICT-diensten beschrijven die een financiële entiteit, of haar groep, heeft met derde aanbieders van ICT-diensten, aanbieders van ICT-diensten binnen de groep inbegrepen. De tabellen worden verbonden door vier sleutels: het referentienummer van de contractuele overeenkomst, de identificatiecode van entiteiten en aanbieders (LEI of EUID), de functie-identificatiecode en de soort ICT-diensten (overweging 8 van de ITS).

Deze pagina is de template zelf. Toepassingsgebied, governance, de stappen om het register op te bouwen en het indieningsproces komen aan bod in de bijbehorende gids voor het DORA-informatieregister; het volledige kader wordt samengevat op de DORA-pagina.

Downloaden, gratis en zonder registratie: Excel-werkmap (.xlsx).

Uit welke modellen bestaat het informatieregister?

De primaire sleutels komen uit het Data Model for DORA RoI van de Europese toezichthoudende autoriteiten (ETA's), gepubliceerd bij het rapporteringspakket. Een sleutelkolom mag in een ingediend bestand nooit leeg zijn.

Welke kolommen bevat elk model?

De onderstaande tabellen nemen de kolomcodes en -namen van bijlage I bij de ITS over. "Vereist" vat de keuzemogelijkheid voor invullen van de ITS samen; gesloten lijsten staan in bijlage I (soorten entiteiten, hiërarchie, redenen voor beëindiging), bijlage II (vergunde activiteiten) en bijlage III (soorten ICT-diensten S01 tot S19).

B_01.01 – Entiteit die het informatieregister bijhoudt

B_01.02 – Lijst van entiteiten binnen de consolidatiekring

B_01.03 – Lijst van bijkantoren

B_02.01 – Contractuele overeenkomsten – algemene informatie

B_02.02 – Contractuele overeenkomsten – specifieke informatie

B_02.03 – Lijst van contractuele overeenkomsten binnen de groep

B_03.01, B_03.02 en B_03.03 – Ondertekenaars

B_04.01 – Entiteiten die van de ICT-diensten gebruikmaken

B_05.01 – Derde aanbieders van ICT-diensten

B_05.02 – Toeleveringsketen van ICT-diensten

B_06.01 – Functie-identificatie

De bijlage bij de ITS slaat code 0050 in dit model over, terwijl de geannoteerde tabelopmaak en het datamodel van de ETA's dezelfde kolommen zonder onderbreking nummeren van c0010 tot c0100. De kolom "CSV" geeft de kop die in het rapporteringsbestand wordt verwacht.

B_07.01 – Beoordelingen van de ICT-diensten

B_99.01 – Definities van entiteiten die van de ICT-diensten gebruikmaken

B_99.01 bevat één interne definitie voor elke keuzemogelijkheid van zes gesloten lijsten: soort contractuele overeenkomst (B_02.01.0020), gevoeligheid van de gegevens (B_02.02.0170), impact van stopzetting van de functie (B_06.01.0110), substitueerbaarheid (B_07.01.0050), mogelijkheid om opnieuw te integreren (B_07.01.0090) en impact van stopzetting van de ICT-diensten (B_07.01.0100). De ITS deelt het model in als rijen R0010 tot R0190 met kolommen C0010 tot C0040; de rapporteringsopmaak van de ETA's maakt er één rij van 19 kolommen (0010 tot 0190) van, één per keuzemogelijkheid.

Hoe ziet een ingevuld register eruit?

Het onderstaande voorbeeld is fictief. Example Bank SA is een Belgische kredietinstelling die een geconsolideerd register bijhoudt voor zichzelf en haar dochteronderneming Example Tech Services SRL, een aanbieder van ICT-diensten binnen de groep. De bank maakt gebruik van twee ICT-aanbieders: Example Tech Services SRL, die het kernbankplatform beheert, en Nimbus Cloud Europe BV, een externe infrastructuuraanbieder die door Example Tech Services SRL is gecontracteerd om dat platform te hosten.

De LEI's zijn voor dit voorbeeld verzonnen: ze doorstaan de formaatcontrole (18 tekens plus twee controlecijfers), maar bestaan niet in de GLEIF-databank en mogen nooit worden ingediend.

B_01.01 (entiteit die het register bijhoudt)

B_01.02 (entiteiten binnen de consolidatiekring)

De moederonderneming herhaalt haar eigen LEI in 0060: de rapporterings-FAQ van de ETA's vraagt dat wanneer een entiteit geen directe moederonderneming heeft (DORA Q&A 2024_7278). De totale activa blijven leeg voor de niet-financiële entiteit.

B_02.01 (overeenkomsten) en B_02.03 (koppeling binnen de groep)

CA-2023-001 is het contract binnen de groep tussen de bank en Example Tech Services SRL; CA-2023-002 is het contract tussen Example Tech Services SRL en Nimbus Cloud Europe BV. Beide moeten in B_02.01 staan, en B_02.03 koppelt ze.

B_02.02 (één rij per overeenkomst, entiteit, aanbieder, functie en dienst; belangrijkste kolommen weergegeven)

Het platform ondersteunt twee functies, dus elke overeenkomst krijgt twee rijen (artikel 4, lid 2, van de ITS: één waarde per veld, één extra rij per extra waarde). "Niet van toepassing" vult de sleutelkolom 0150 wanneer er geen gegevens worden opgeslagen (DORA Q&A 2024_7280). De andere kolommen (opzegtermijnen, toepasselijk recht, gevoeligheid van de gegevens) staan in het downloadbare bestand.

B_03.01, B_03.02, B_03.03 en B_04.01 (wie ondertekent, wie levert, wie gebruikt)

B_05.01 (aanbieders en uiteindelijke moederondernemingen) en B_05.02 (toeleveringsketen)

Example Bank SA staat in B_05.01 omdat de bank de uiteindelijke moederonderneming van een ICT-aanbieder is: de code van de uiteindelijke moederonderneming in 0110 moet als aanbiedersrij bestaan (regel 807). Nimbus Cloud Europe BV heeft met een groepsentiteit getekend om de bank te bedienen en is dus een directe aanbieder (artikel 1, punt 1, b), van de ITS) met rang 1. Voor rang 1 vragen de ETA's om de code van de aanbieder in 0060 te herhalen in plaats van de sleutel leeg te laten (DORA Q&A 2024_7284).

B_06.01 (functies, ITS-codes) en B_07.01 (beoordeling, belangrijkste kolommen)

RTO en RPO worden uitgedrukt in uren: 1 bij minder dan een uur, 0 wanneer niet gedefinieerd. Elke combinatie van LEI, vergunde activiteit en functie krijgt een eigen identificatiecode (F1, F2…).

In een rapporteringsbestand worden waarden uit gesloten lijsten en landen vervangen door de codes van de ETA's (bijvoorbeeld eba_GA:BE voor België, eba_GA:qx2007 voor "Niet van toepassing").

Door welke consistentiecontroles mislukt een indiening?

De ETA's voeren op elk bestand drie lagen controles uit: technische controles, DPM-validatieregels en inhoudelijke controles aan de hand van referentiegegevens. Bij technische fouten wordt het bestand afgewezen; de andere bevindingen zijn waarschuwingen, maar de autoriteiten verwachten een gecorrigeerde nieuwe indiening. De regelcodes hieronder zijn die welke de ETA's hebben gepubliceerd en de CSSF heeft toegelicht.

Welke sleutels moeten tussen de modellen overeenkomen?

Wat leerden de dry run en de eerste indieningen?

• Bij de dry run van de ETA's in 2024 doorstond 6,5 % van de 947 geanalyseerde registers alle 116 datakwaliteitscontroles; ontbrekende verplichte informatie veroorzaakte 86 % van de fouten, waarbij B_02.02 en B_07.01 de meeste lacunes bevatten.
• Bijna 9.000 ongeldige LEI's werden gerapporteerd voor de financiële entiteiten zelf, vaak nationale codes die in LEI-velden waren ingevoerd.
• In hun observaties van mei 2025 over de eerste officiële rapportering telden de ETA's 58.170 EUID's met een ongeldig formaat, tegenover 2.717 die in BRIS werden teruggevonden en 258 die niet werden gevonden.
• De ACPR stelde vast dat de validatieregels tijdens het indieningsvenster van 2025 wijzigden, en dat de afwijzingen van 2026 voortkwamen uit verkeerde referentiedata (2025-12-31 werd verwacht, niet de indieningstermijn), onvolledige archiefstructuren en bestanden die niet in UTF-8 waren gecodeerd.
• Voor 2026 verklaarde de CSSF dat de controles van de ETA's sinds april 2025 niet waren gewijzigd, maar op meer gegevensvelden zouden worden toegepast.

Hoe houdt u het register bij op groepsniveau (geconsolideerd)?

• Toepassingsgebied. De moederonderneming bepaalt de perimeter volgens de sectorale consolidatieregels; een gesubconsolideerd of geconsolideerd register omvat alle financiële entiteiten en aanbieders van ICT-diensten binnen de groep (artikel 6 van de ITS).
• Eén register, drie niveaus. Een groep mag één register bijhouden dat dient voor het entiteits-, gesubconsolideerde en geconsolideerde niveau, op voorwaarde dat elke entiteit haar eigen deel kan extraheren en rapporteren (overweging 2 van de ITS).
• Wat naar de ETA's gaat. Registers worden op individueel niveau gerapporteerd voor entiteiten die niet tot een groep behoren of waarvan de moederonderneming buiten de Unie gevestigd is zonder moederonderneming in de Unie, en anders op het hoogste consolidatieniveau in de Unie (rapporterings-FAQ van de ETA's).
• Hiërarchie. B_01.02.0050 plaatst elke entiteit: uiteindelijke moederonderneming, moederonderneming van een gesubconsolideerd deel, dochteronderneming, geen deel van een groep, of dienstverlener aan wie alle operationele activiteiten zijn uitbesteed; kies het hoogste niveau dat van toepassing is.
• Gedeelde identificatiecodes. Houd voor alle entiteiten één contractreferentie, één aanbiederscode en één functie-identificatiecode per object aan; consistentie tussen het entiteits- en het geconsolideerde niveau is een uitdrukkelijke verplichting (artikel 3, lid 3, van de ITS).
• Ketens binnen de groep. Rapporteer het contract binnen de groep en het externe contract in B_02.01, en koppel ze in B_02.03. Groepsentiteiten die buiten de Unie gevestigd zijn en EU-entiteiten bedienen, gelden als aanbieders van ICT-diensten binnen de groep.

Voor het bredere geheel aan controles behandelt de DORA-readinesschecklist (Excel, 45 vereisten) de andere DORA-pijlers.

FAQ

Bestaat er een officiële Excel-template?

De wettelijke modellen staan in de bijlage bij de ITS. Voor de rapportering publiceren de ETA's een pakket in plain CSV (taxonomie, datamodel, validatieregels); de Excel-werkmap en de conversietool die voor de dry run van 2024 werden verspreid, waren voorbereidingsinstrumenten.

Moeten ICT-diensten die geen kritieke functies ondersteunen, worden geregistreerd?

Ja. Artikel 28, lid 3, heeft betrekking op alle contractuele overeenkomsten voor ICT-diensten. Verschillende kolommen, en model B_07.01, gelden alleen voor diensten die kritieke of belangrijke functies ondersteunen.

Welke onderaannemers worden in het register opgenomen?

Alleen de onderaannemers die daadwerkelijk ten grondslag liggen aan ICT-diensten die kritieke of belangrijke functies ondersteunen (artikel 3, lid 2, punt b), van de ITS).

Wat als een aanbieder geen LEI heeft?

Rechtspersonen uit de EU worden geïdentificeerd met een LEI of een EUID; rechtspersonen buiten de Unie alleen met een LEI; alternatieve codes (CRN, btw-nummer, paspoort, nationaal identificatienummer) zijn bedoeld voor individuen die in een zakelijke hoedanigheid handelen. De ETA's aanvaarden een andere identificatiecode voor een aanbieder uit een derde land zonder LEI; die wordt als datakwaliteitsprobleem gemarkeerd in plaats van afgewezen.

Hoe vaak wordt het register bijgewerkt en gerapporteerd?

Het wordt doorlopend bijgehouden, minstens jaarlijks gerapporteerd en op verzoek volledig ter beschikking gesteld (artikel 28, lid 3, van DORA). De volgende referentiedatum is 31 december 2026.

Bronnen

• Verordening (EU) 2022/2554 (DORA), artikel 28, lid 3
• Uitvoeringsverordening (EU) 2024/2956 van de Commissie, modellen voor het informatieregister
• EBA – Voorbereiding van de rapportering van DORA-informatieregisters (datamodel, taxonomie, validatieregels)
• ETA's – FAQ over de rapportering van het DORA-informatieregister, versie van 28 maart 2025
• ETA's – Observaties uit de rapportering van het informatieregister: belangrijkste gemeenschappelijke problemen (bijgewerkt op 16 mei 2025)
• ETA's – Samenvattend rapport van de dry run 2024 (17 december 2024)
• EBA Q&A 2024_7278 (directe moederonderneming), 2024_7280 (locatie van de gegevensopslag), 2024_7284 (code van de ontvanger bij rang 1)
• CSSF – Richtsnoeren over de foutmeldingen van de ETA's voor het DORA-register (15 mei 2025)
• CSSF – Indieningstermijn 2026
• NBB – OneGate-domein DOR (DORA_ROI)
• ACPR – DORA-webinar van 23 januari 2026