De Digital Operational Resilience Act (DORA) is op 17 januari 2025 volledig van kracht geworden. Een van de kernverplichtingen is de eis voor financiële entiteiten om een gestructureerd Register of Information bij te houden — een uitgebreid overzicht van alle ICT-dienstverleningsovereenkomsten met derde partijen, inclusief onderaannemers en intragroepsdiensten.
Deze gids legt uit wat het DORA Register of Information is, welke organisaties verplicht zijn dit bij te houden, welke gegevensvelden verplicht zijn en hoe u een duurzaam operationeel model opbouwt. Of u nu een compliance officer bent die zijn eerste rapportage voorbereidt, een risicomanager die de datakwaliteit beoordeelt, of een leveranciersmanager die afdeling-overstijgende verantwoordelijkheden coördineert — deze gids begeleidt u door elke stap.
U leert: wat toezichthouders verwachten, welke entiteiten in scope zijn, wat de verplichte datacategorieën zijn, wie elk veld moet bezitten, de zeven stappen om uw register op te bouwen, de meest voorkomende fouten die leiden tot rapportagefouten, en hoe doelgerichte tools het voortdurend onderhoud kunnen vereenvoudigen.
Wat is het DORA Register of Information?
Het DORA Register of Information (RoI) is een gestructureerde dataset die financiële entiteiten moeten samenstellen en bijhouden op grond van artikel 28(3) van Verordening (EU) 2022/2554. Het registreert elke ICT-dienstverleningsovereenkomst met derde partijen — van cloudinfrastructuurleveranciers tot SaaS-platforms, managed security services, betalingsverwerkers en intragroepse ICT-relaties.
Het doel van het register is toezichtsgericht. Nationale bevoegde autoriteiten (NBA's) en de Europese toezichthoudende autoriteiten (EBA, EIOPA, ESMA) gebruiken het register om het ICT-afhankelijkheidslandschap van een entiteit te beoordelen, concentratierisico's te identificeren en de operationele veerkracht van de financiële sector als geheel te monitoren.
Regulatoir doel
DORA gaat verder dan traditionele uitbestedingsregisters. De vereisten voor het Register of Information zijn vastgelegd in de gezamenlijke RTS betreffende het register van informatie op grond van artikelen 28(9) en 30(5) DORA (JC 2023 84). De RTS specificeert exacte gegevensvelden, kardinaliteit en validatieregels, en schrijft voor dat het register voortdurend actueel wordt gehouden — niet alleen op het moment van rapportage.
Toezichtsrapportage
Financiële entiteiten zijn verplicht hun register jaarlijks aan hun NBA te verstrekken, en op verzoek op elk moment. De NBA kan de gegevens doorsturen naar de relevante ESA. Inzendingen moeten voldoen aan de voorgeschreven gegevenssjablonen (doorgaans CSV- of XBRL-formaat), en validatie zal ontbrekende velden, inconsistente identifiers en referentiële integriteitfouten markeren.
ICT-risicobeheer bij derde partijen
Het register voedt verschillende andere DORA-verplichtingen. Kritikaliteitsbeoordelingen, exitstrategieën en contractbeoordelingen verwijzen allemaal naar hetzelfde inventaris van derde partijen. Het register goed opzetten is daarom geen op zichzelf staande oefening — het verankert uw gehele ICT-risicobeheerkader voor derde partijen.
Operationele veerkracht
In de kern is het DORA Register of Information een instrument voor operationele veerkracht. Door entiteiten te verplichten elke ICT-afhankelijkheid — inclusief vierde partijen — in kaart te brengen en te documenteren, creëert het transparantie die het management en toezichthouders kunnen gebruiken om te beoordelen of een storing bij één leverancier systemische verstoringen kan veroorzaken.
Wie moet een DORA-register bijhouden?
DORA is van toepassing op een breed scala aan financiële entiteiten die actief zijn in de Europese Unie. Artikel 2 van de Verordening definieert de reikwijdte, die de meeste gereguleerde financiële instellingen omvat.
Kredietinstellingen
Banken en hypotheekverstrekkers met een CRD-vergunning.
Beleggingsondernemingen
MiFID II-vergunde beleggingsondernemingen die financiële diensten verlenen.
Betalingsinstellingen
PSD2-vergunde betalings- en e-geldinstellingen.
Verzekeringsondernemingen
Solvency II-vergunde verzekeraars en herverzekeraars.
Cryptoactivadienstverleners
MiCA-vergunde CASP's vanaf hun getoetste onboarding.
CCP's, CSD's & Transactieregisters
Centrale tegenpartijen, centrale effectenbewaarinstellingen en gegevensmeldingsdienstverleners.
Het proportionaliteitsbeginsel
DORA erkent dat een kleine betalingsinstelling niet dezelfde operationele veerkrachtinfrastructuur kan handhaven als een systeemrelevante bank. Artikel 4 introduceert proportionaliteit: micro-ondernemingen en kleine entiteiten profiteren van een vereenvoudigd regime dat bepaalde documentatie- en governancevereisten vermindert, terwijl de kernregisterverplichting behouden blijft.
Uitzonderingen
Micro-ondernemingen (minder dan 10 werknemers en een jaaromzet of balanstotaal onder €2 miljoen) komen in aanmerking voor een vereenvoudigd DORA-regime. Ze zijn nog steeds verplicht een register bij te houden, maar de vereisten voor governance, testen en rapportage zijn minder zwaar.
Welke informatie moet worden opgenomen?
De gezamenlijke RTS specificeert een gedetailleerd gegevensmodel voor het Register of Information. De volgende tabel vat de belangrijkste datacategorieën samen.
| Categorie | Voorbeelden |
|---|---|
| Leveranciersinformatie | Juridische naam, LEI, vestigingsland, groepslidmaatschap |
| ICT-diensten | Hosting, SaaS, MSP, IT-ondersteuning, clouddiensten, betalingsverwerking |
| Kritikaliteitsclassificatie | Kritiek / Niet-kritiek, ondersteunde functie of proces |
| Contractdetails | Begindatum, einddatum, verlengingsvoorwaarden, opzegtermijn |
| Onderaannemers | ICT-leveranciers vierde partij, onderaannemersketens, exploitatieland |
| Exitstrategie | Status exitplan, geïdentificeerde alternatieve leveranciers, migratietijdlijn |
| Risicobeoordeling | Gekoppelde risicobeoordelingen, risicoclassificatie, datum laatste beoordeling |
Leveranciersinformatie
Elke ICT-derde partij moet worden geïdentificeerd met een Legal Entity Identifier (LEI) waar die beschikbaar is. De juridische naam, het land en de groepsstructuur van de leverancier moeten worden geregistreerd. Het gebruik van consistente en gevalideerde entiteitsidentifiers is cruciaal — toezichthouders gebruiken deze om gegevens te aggregeren en concentratierisico's te identificeren.
ICT-diensten
Voor elke overeenkomst moet u de geleverde ICT-diensten beschrijven. De RTS gebruikt een gecontroleerde woordenschat voor diensttypen. Veelvoorkomende categorieën zijn: clouddiensten, gegevensanalyse, datacentercollocatie, softwareonderhoud en -ondersteuning, beheerde IT-diensten, cybersecuritydiensten en betalingsdiensten.
Kritikaliteitsclassificatie
Bepalen of een ICT-dienst een kritieke of belangrijke functie (CIF) ondersteunt, is een van de meest bepalende beslissingen in het register. Kritieke diensten vereisen intensiever toezicht, strengere contractvereisten en verplichte exitstrategiedocumentatie.
Contractdetails
Begin- en einddatums van contracten, verlengingsvoorwaarden en opzegtermijnen moeten nauwkeurig zijn en overeenkomen met uw contractbeheergegevens. Verlopen of automatisch verlengde contracten zonder review zijn een veelvoorkomend kwaliteitsgebrek.
Onderaannemers
DORA breidt de registerverplichting uit naar onderaannemers — vaak vierde partijen genoemd — die betrokken zijn bij de levering van een kritieke of belangrijke ICT-dienst. U moet deze onderaannemers, hun exploitatieland en materiële afhankelijkheden identificeren.
Exitstrategie
Voor elke overeenkomst die een kritieke of belangrijke functie ondersteunt, moet het register vastleggen of er een gedocumenteerde exitstrategie bestaat, wat de status is van de identificatie van alternatieve leveranciers en of het exitplan is getest.
Risicobeoordeling
Het register moet elke overeenkomst koppelen aan een risicobeoordeling. Dit omvat de algehele risicoclassificatie, de datum van de meest recente beoordeling en eventuele openstaande herstelacties.
DORA-register eigendomsmodel
Een van de meest voorkomende oorzaken van slechte registerkwaliteit is het ontbreken van een duidelijk eigendomsmodel. Het DORA Register of Information is van nature functieoverstijgend: de benodigde gegevens omvatten juridische, inkoop-, risico-, informatiebeveiligings- en bedrijfsafdelingen.
Juridisch
Contracteigendom, toepasselijk recht, beëindigingsclausules en contractuele toegangs- en auditrechten. Juridisch moet contractdatums en opzegtermijnen valideren en bevestigen of DORA-vereiste bepalingen aanwezig zijn in elke overeenkomst.
Inkoop & Leveranciersbeheer
Leveranciersidentificatie, LEI-verificatie, verzoeken om openbaarmaking van onderaannemers en het bijhouden van verlengingen. Inkoop heeft doorgaans de centrale leverancierslijst en is het best gepositioneerd om nieuwe overeenkomsten te identificeren voordat ze in het register verschijnen.
Informatiebeveiliging
Risicoclassificaties, beveiligingsbeoordelingen, incidentkoppeling en beveiligingspositie van onderaannemers. Informatiebeveiligingsteams beschikken over de meest recente due-diligence-resultaten en zijn verantwoordelijk voor het valideren van technische risicogegevens.
Bedrijfsverantwoordelijken
Dienstkritikaliteit, ondersteunde functies en operationele afhankelijkheden. Bedrijfsverantwoordelijken zijn het best gepositioneerd om te beoordelen of een dienst een kritieke of belangrijke functie ondersteunt — dit oordeel kan niet centraal worden gemaakt zonder bedrijfsinput.
Compliance & Regelgevend toezicht
Algehele registervolledigheid, voorbereiding van inzendingen en contact met de NBA. Compliance moet het governancekader bezitten — de kwaliteitsregels, reviewcycli en escalatieroutes — ook al bezitten ze niet de afzonderlijke gegevensvelden.
Een effectief eigendomsmodel definieert voor elk gegevensveld welke afdeling de gegevens levert, welke afdeling ze valideert en met welke frequentie. Dit wordt doorgaans gedocumenteerd in een RACI-matrix.
Veelgemaakte DORA-registerfouten
Dit zijn de meest voorkomende oorzaken van registerkwaliteitsfouten en afwijzingen van inzendingen, gebaseerd op implementatie-ervaring bij financiële entiteiten.
1. Ontbrekende onderaannemers
De meeste bedrijven hebben een duidelijk beeld van hun directe ICT-leveranciers, maar een slecht beeld van vierde partijen. Als uw cloudleverancier gegevensverwerking uitbesteedt aan een sub-verwerker, moet die relatie voor kritieke diensten in uw register verschijnen.
2. Dubbele leveranciersvermeldingen
Dezelfde leverancier die verschijnt onder verschillende namen, identifiers of juridische entiteiten is een datakwaliteitsprobleem dat zich door het register verspreidt. Gebruik gevalideerde LEI-codes en een canonieke leveranciersstamlijst om duplicaten te voorkomen.
3. Onjuiste kritikaliteitsclassificaties
Te hoge classificatie van diensten als niet-kritiek vermindert de toezichtslast maar creëert regelgevingsrisico. Te lage classificatie van kritieke diensten is een wezenlijke compliance-fout. Classificaties moeten worden ondersteund door gedocumenteerde impactbeoordelingen.
4. Verouderde contractgegevens
Verlopen contracteinddatums, verlengingsvoorwaarden die niet meer de huidige overeenkomst weerspiegelen, en ontbrekende opzegtermijnen duiden op een register dat niet wordt onderhouden.
5. Geen duidelijk eigendomsmodel
Zonder gedocumenteerd data-eigendom wordt het register niemands verantwoordelijkheid. Wanneer velden onjuist of ontbrekend zijn, is er geen duidelijk pad naar herstel.
6. Ontbrekende exitplannen
Exitstrategiedocumentatie is vereist voor kritieke diensten, maar veel organisaties hebben slechts een algemeen exitbeleid in plaats van dienstspecifieke plannen. DORA vereist dat u een plausibel transitiepad kunt aantonen voor elke kritieke overeenkomst.
Hoe bouwt u stap voor stap een DORA-register op
Het opbouwen van een rapportageklaar DORA Register of Information is een project met zeven afzonderlijke fasen. Elke fase heeft duidelijke deliverables en afhankelijkheden.
Stap 1
Reikwijdte bepalen
Identificeer welke juridische entiteiten in uw groep in scope vallen voor DORA en of geconsolideerde of entiteitsspecifieke rapportage vereist is. Bevestig met uw NBA welk inzendingsformaat vereist is. Documenteer de diensten in scope, inclusief intragroepsovereenkomsten.
Stap 2
ICT-leveranciers inventariseren
Stel een volledige lijst op van alle ICT-dienstverleningsovereenkomsten met derde partijen. Bronnen omvatten: contractregisters, crediteurensystemen, IT-activainventarissen, beveiligingsleverancierslijsten en interviews met bedrijfsverantwoordelijken. Valideer juridische entiteitsnamen aan de hand van LEI-registers.
Stap 3
Diensten classificeren
Bepaal voor elke overeenkomst of deze een kritieke of belangrijke functie ondersteunt. Werk samen met bedrijfsverantwoordelijken om de impact van een verstoring van de dienst te beoordelen. Documenteer de motivering. Pas de gecontroleerde diensttype-woordenschat uit de RTS toe.
Stap 4
Eigendom toewijzen
Maak een RACI-matrix die elk gegevensveld koppelt aan een verantwoordelijke eigenaar. Bevestig eigendom met elke afdeling. Stel de reviewfrequentie vast voor elk veld. Integreer registerupdates in bestaande processen: contractondertekening, inkoopgoedkeuring, leveranciersreviewcycli.
Stap 5
Datakwaliteit valideren
Voer systematische kwaliteitscontroles uit op alle gegevensvelden voordat u het register als rapportageklaar beschouwt. Controles moeten omvatten: volledigheid van verplichte velden, geldige gecontroleerde woordenschatwaarden, datumlogica, referentiële integriteit, detectie van duplicaten en volledigheid van onderaannemers voor kritieke diensten.
Stap 6
Governance instellen
Definieer het doorlopende governancemodel. Dit omvat: een maandelijkse of driemaandelijkse kwaliteitsreview met alle data-eigenaren; een escalatieroute voor onopgeloste kwaliteitsproblemen; een wijzigingsbeheerproces voor nieuwe, gewijzigde of beëindigde overeenkomsten; een jaarlijkse volledige review van kritikaliteitsclassificaties.
Stap 7
Regelgevende inzendingen voorbereiden
Exporteer het register in het formaat dat uw NBA vereist (doorgaans CSV, afgestemd op de JTS-gegevenssjablonen, of XBRL). Voer de ESA-validatieregelset uit op uw export vóór indiening — intern gedetecteerde fouten zijn veel minder kostbaar dan fouten die door uw toezichthouder worden gemarkeerd.
DORA-register sjabloonvoorbeeld
De volgende structuur toont een representatieve rij uit een DORA Register of Information. Elke rij vertegenwoordigt één ICT-dienstverleningsovereenkomst. Een enkele leverancier kan in meerdere rijen verschijnen als ze meerdere afzonderlijke diensten leveren.
| Veld | Voorbeeldwaarde |
|---|---|
| Leverancier | Acme Cloud Services B.V. |
| LEI | 5493001KJTIIGC8Y1R12 |
| Dienst | Cloudinfrastructuur (IaaS) |
| Kritikaliteit | Kritiek |
| Bedrijfsverantwoordelijke | Hoofd IT-operaties |
| Contractbegindatum | 2022-01-01 |
| Contracteinddatum | 2027-12-31 |
| Onderaannemers | DataStore GmbH (DE), NetOps Ltd (IE) |
| Exitstrategie | Gedocumenteerd — alternatief geïdentificeerd, plan laatste getest 2024-11 |
| Risicoclassificatie | Hoog |
| Datum laatste review | 2025-03-15 |
DORA-register vs. traditionele uitbestedingsregisters
Veel financiële entiteiten houden al een vorm van uitbestedingsregister of leveranciersregister bij — vaak gebouwd om te voldoen aan de EBA-uitbestedingsrichtlijnen of interne inkoopvereisten. Het DORA Register of Information is aanzienlijk veeleisender.
| Dimensie | Traditioneel register | DORA-register |
|---|---|---|
| Primair doel | Leveranciersbeheer & uitgavenbeheer | Operationele veerkracht & toezichtsrapportage |
| Reikwijdte | Alle leveranciers of uitbestede diensten | Alle ICT-overeenkomsten, inclusief intragroeps |
| Datagerichtheid | Focus op contract en kosten | Risico-, afhankelijkheids-, onderaannemer- & exitgegevens |
| Rapportage | Alleen intern | Verplichte jaarlijkse toezichtsrapportage |
| Formaat | Vrije vorm (Word, Excel) | Voorgeschreven sjablonen met validatieregels |
| Vierde partijen | Meestal niet vastgelegd | Vereist voor kritieke diensten |
| Kritikaliteit | Beperkt of informeel | Formeel beoordeeld en gedocumenteerd |
| Updatefrequentie | Jaarlijks of projectgebaseerd | Doorlopend, gebeurtenisgestuurd plus periodieke review |
Als uw organisatie al een EBA-uitbestedingsregister bijhoudt, biedt dit een nuttig startpunt — maar het zal doorgaans slechts 60–70% van de DORA-vereisten dekken. De lacunes bevinden zich doorgaans in onderaannemersgegevens, exitstrategiekoppeling, kritikaliteitsformaliteit en het rapportageformaat voor toezichthouders.
Hoe RiskNow helpt bij het bijhouden van een DORA-register
RiskNow is een GRC-platform gebouwd door practitioners die DORA-programma's hebben geïmplementeerd bij financiële entiteiten. Het platform biedt een dedicated Register of Information-module die u helpt een volledig inventaris van derde partijen bij te houden, toeleveringsketenafhankelijkheden te traceren en rapportageklare regulatoire outputs voor te bereiden.
Register van derde partijen
Houd een gestructureerd register bij van ICT-derde partijen met juridische entiteitsgegevens, LEI's, dienstkoppelingen, kritikaliteitsclassificatie, contractlevenscyclusdetails en verantwoordelijke veldeigenaren.
Zichtbaarheid toeleveringsketen
Breng onderaannemers en vierde partijen in kaart in uw ICT-toeleveringsketen, koppel afhankelijkheden aan kritieke diensten en houd een auditeerbare registratie bij van concentratie- en veerkrachtrisico's.
Datakwaliteitsrapportage (100+ controles)
Voer datakwaliteitsrapporten uit met meer dan 100 geautomatiseerde controles voor volledigheid, gecontroleerde waarden, duplicaatdetectie, datumlogica en referentiële integriteit vóór indiening.
Regelgevende exports (XBRL / CSV)
Exporteer registergegevens naar regelgevingsklare XBRL- en CSV-formaten afgestemd op toezichtssjablonen, met pre-exportvalidatie om problemen vóór indiening te detecteren.
Door derde partijen, toeleveringsketenrelaties, contracten, risicobeoordelingen en incidenten in één model te verbinden, vermindert RiskNow handmatige afstemming en helpt teams het register nauwkeurig te houden tussen jaarlijkse inzendingscycli.
Veelgestelde vragen
Wat is een DORA Register of Information?
Het DORA Register of Information is een gestructureerd inventaris van alle ICT-dienstverleningsovereenkomsten met derde partijen die door een financiële entiteit worden bijgehouden op grond van artikel 28(3) van Verordening (EU) 2022/2554. Het omvat leveranciers, diensten, kritikaliteit, contracten, onderaannemers en risicobeoordelingen.
Is het DORA-register verplicht?
Ja. Alle in scope zijnde financiële entiteiten moeten een Register of Information bijhouden en dit jaarlijks of op verzoek aan hun nationale bevoegde autoriteit verstrekken. Niet-naleving kan leiden tot toezichtsmaatregelen, waaronder openbare bekendmaking, boetes en herstelorders.
Hoe vaak moet het DORA-register worden bijgewerkt?
Het register moet voortdurend actueel worden gehouden. In de praktijk betekent dit gebeurtenisgestuurde updates voor nieuwe overeenkomsten, materiële contractwijzigingen en beëindigde diensten — aangevuld met een periodieke (maandelijkse of driemaandelijkse) kwaliteitsreview en een jaarlijkse volledige vernieuwing vóór het toezichtsrapportagevenster.
Wat zijn kritieke ICT-diensten?
Kritieke ICT-diensten zijn diensten die een kritieke of belangrijke functie (CIF) ondersteunen — een functie waarvan het uitvallen of de verslechtering de regelgevende naleving, financiële soliditeit of dienstverlening van de entiteit wezenlijk zou aantasten. Kritikaliteit moet worden beoordeeld via een gedocumenteerde impactanalyse en jaarlijks worden herzien.
Moeten onderaannemers worden opgenomen in het register?
Ja, voor kritieke en belangrijke diensten. U moet onderaannemers (vierde partijen) identificeren die deel uitmaken van de leveringsketen voor een kritieke dienst en ze in het register opnemen. Dit vereist proactieve samenwerking met primaire leveranciers om openbaarmaking van hun toeleveringsketens te verkrijgen.
Hoe verschilt DORA van de EBA-uitbestedingsrichtlijnen?
De EBA-uitbestedingsrichtlijnen richten zich voornamelijk op governance, contractvereisten en meldingsverplichtingen voor materiële uitbesteding. DORA gaat verder: het dekt alle ICT-overeenkomsten (niet alleen materiële uitbesteding), schrijft openbaarmaking van onderaannemers voor kritieke diensten voor, vereist formeel gedocumenteerde exitstrategieën en introduceert een gestandaardiseerd toezichtsrapportageregister met voorgeschreven gegevensvelden.
Kan Excel worden gebruikt om het DORA-register bij te houden?
Technisch gezien ja, maar in de praktijk creëert dit aanzienlijke operationele risico's. Excel-registers hebben problemen met toegangsbeheer, versiebeheer, tabeloverschrijdende referentiële integriteit en audittrails. Voor grotere entiteiten wordt een doelgericht platform sterk aanbevolen.
Welke gegevensvelden zijn vereist door het DORA-register?
De gezamenlijke RTS specificeert verplichte velden, waaronder: juridische entiteitsnaam en LEI van de leverancier, ICT-diensttype, ondersteunde functie, kritikaliteitsclassificatie, begin- en einddatums van het contract, opzegtermijn, onderaannemersdetails (voor kritieke diensten), status exitstrategie en risicobeoordeling. Zie het gedeelte "Welke informatie moet worden opgenomen?" hierboven voor een volledig overzicht.
Wat gebeurt er als het DORA-register onvolledig is bij indiening?
Een onvolledig of onnauwkeurig register kan ertoe leiden dat de NBA de inzending teruggeeft ter correctie, een formele toezichtsdialoog over zwakke punten in databeheer, of — bij aanhoudende gevallen — geëscaleerde toezichtsmaatregelen. Herhaalde fouten worden beschouwd als bewijs van bredere operationele veerkrachtgebreken.