Veel organisaties kijken naar third party risk management vanuit een verplichting. Er moet een leveranciersregister zijn. Contracten moeten op orde zijn. Voor DORA moet verplicht een Register of Information worden bijgehouden. Maar dat is niet de enige reden om dit te doen. Het register heeft namelijk heel veel waarde als je het gebruikt als stuurinstrument.
Estimated reading time: 9 minuten
Van cloudproviders en softwareleveranciers tot datacenters, betaalproviders en outsourcingspartners: vrijwel elke organisatie leunt op een keten van externe partijen. Als één van die partijen uitvalt, onvoldoende beveiligd is of zijn afspraken niet nakomt, kan jouw organisatie daar direct door in de problemen komen. DORA (Digital Operational Resilience Act) maakt die afhankelijkheid zichtbaarder, maar veroorzaakt haar niet. De risico’s waren er al.
Leveranciers zijn onderdeel van je weerbaarheid
Organisaties werken steeds meer digitaal en steeds meer in ketens. Vrijwel geen enkele organisatie levert haar diensten nog volledig zelfstandig. Systemen draaien in de cloud. Data staat bij externe partijen. Kritieke processen leunen op software, koppelingen, API’s, supportafspraken en onderaannemers.
Daarmee verschuift ook het risicoprofiel. Je kunt intern alles goed geregeld hebben, maar toch kwetsbaar zijn door een leverancier die:
- geen passende continuïteitsmaatregelen heeft,
- onvoldoende grip heeft op onderaannemers,
- wijzigingen doorvoert zonder goede afstemming,
- incidenten te laat meldt,
- onduidelijke exitafspraken hanteert,
- een dienst levert die kritischer is dan vooraf werd gedacht.
Third party risk management gaat daarom niet over leveranciersadministratie. Het gaat over de vraag: weten we van welke partijen we afhankelijk zijn, hoe kritisch die afhankelijkheid is en wat er gebeurt als er iets misgaat?
Wat DORA hierin verandert
De DORA richt zich op digitale operationele weerbaarheid binnen de financiële sector. DORA bundelt eisen voor ICT-risicomanagement, incidentrapportage, testen van digitale weerbaarheid en het beheersen van ICT-risico’s bij derde partijen.
Een belangrijk onderdeel daarvan is het Register of Information. Financiële entiteiten moeten een informatieregister bijhouden voor contractuele afspraken met ICT-dienstverleners. Dit register moet inzicht geven in de ICT-diensten waarvan de organisatie afhankelijk is, de contractuele afspraken die daarbij horen en de functies die door deze diensten worden ondersteund.
Daarin zit de echte waarde. Want het register dwingt je om fundamentele vragen te beantwoorden:
- Welke leveranciers ondersteunen onze kritieke of belangrijke functies?
- Welke ICT-diensten zijn essentieel voor onze operationele continuïteit?
- Welke contracten horen daarbij, en wat is daarin afgesproken?
- Waar zitten concentratierisico’s?
- Welke contracten missen afspraken over security, continuïteit, auditrechten of exit?
Als je deze vragen niet kunt beantwoorden, ben je niet echt in control. Dan weet je misschien wel welke leveranciers je betaalt, maar niet welke leveranciers je organisatie overeind houden.
Het Register of Information is geen rapportagebestand, maar een stuurinstrument
Wie het DORA Register of Information alleen ziet als verplichte rapportage, maakt het zichzelf onnodig moeilijk. Dan wordt het register een administratieve exercitie: velden vullen, informatie najagen, contracten verzamelen en hopen dat alles klopt op het moment van aanlevering.
Maar het register heeft veel meer waarde als je het gebruikt als stuurinstrument. Het laat zien hoe je organisatie afhankelijk is van ICT-dienstverleners. Het maakt zichtbaar waar kritieke diensten worden ondersteund door externe partijen. Het helpt om contractuele afspraken, onderaannemers, locaties, entiteiten, processen en risico’s met elkaar te verbinden.
Daarmee verschuift de vraag van „Hebben we het register gevuld?” naar „Begrijpen we onze afhankelijkheden en beheersen we de risico’s die daarbij horen?” Dat is de essentie van volwassen third party risk management.
Van register naar risicosturing
Een goed Register of Information is geen statische lijst. Het is de basis voor risicogestuurd leveranciersmanagement. Daarvoor moet je verder kijken dan alleen naam, contractnummer en leverancierstype. Je wilt per leverancier en per ICT-dienst kunnen bepalen:
- hoe kritisch de dienst is,
- welke processen of functies geraakt worden bij uitval,
- welke data wordt verwerkt,
- welke wettelijke of contractuele eisen van toepassing zijn,
- welke maatregelen de leverancier heeft getroffen,
- welke assurance beschikbaar is, zoals certificeringen of ISAE- en SOC-rapportages,
- welke incidenten of bevindingen eerder zijn opgetreden,
- welke verbeteracties openstaan,
- of er alternatieven of exitmogelijkheden zijn.
Pas dan ontstaat een werkend beeld. Niet alleen: „deze leverancier staat in het register”, maar: „dit is de afhankelijkheid, dit is het risico, dit is wat we hebben afgesproken en dit is wat we moeten blijven toetsen.”
De fout: het register achteraf vullen
Veel organisaties proberen het Register of Information achteraf samen te stellen. Ze verzamelen contracten, vragen data op bij inkoop, zoeken in Excelbestanden, mailen contracteigenaren en proberen ontbrekende velden vlak voor de deadline nog aan te vullen. Dat leidt tot drie problemen.
- Het register wordt een momentopname. Op het moment van aanleveren lijkt het misschien compleet, maar kort daarna is de informatie alweer verouderd.
- Er ontstaat weinig eigenaarschap. Als het register vooral door compliance, risk of procurement wordt gevuld, maar niet door contracteigenaren, proceseigenaren en leveranciersmanagers wordt gebruikt, blijft het een administratieve exercitie.
- Je mist de verbeterwaarde. Je ziet misschien dat informatie ontbreekt, maar niet automatisch welke contracten moeten worden aangescherpt, welke leveranciers opnieuw beoordeeld moeten worden of waar continuïteitsrisico’s ontstaan. Het alternatief is om het register onderdeel te maken van de normale werkwijze.
Wat moet je structureel op orde hebben?
Een volwassen DORA-aanpak begint bij samenhang. Het Register of Information is niet bedoeld als losse spreadsheet met leveranciers en contracten, maar als een gestructureerd overzicht van de ICT-diensten waarop de financiële organisatie steunt.
Je legt vast welke entiteiten, branches, contracten, ICT-diensten, leveranciers, onderaannemers en bedrijfsfuncties met elkaar samenhangen. Daardoor wordt zichtbaar welke ICT-diensten kritieke of belangrijke functies ondersteunen, welke partijen daarbij betrokken zijn en waar afhankelijkheden of concentratierisico’s ontstaan.
Concreet betekent dit:
- Je legt vast welke organisatieonderdelen en branches binnen de scope vallen en welke functies of activiteiten zij uitvoeren. Voor deze functies bepaal je onder meer de kritikaliteit, RTO, RPO en de impact van discontinuïteit. Een BIA is hiervoor een logische en sterke bron.
- Je legt alle contractuele afspraken over ICT-diensten vast, inclusief contracttype, looptijd, kosten, opzegtermijnen, toepasselijk recht en eventuele relatie met bovenliggende of intra-groep contracten.
- Je legt per contract vast welke ICT-diensten daarin zijn opgenomen, welke leverancier deze levert en welke entiteiten, branches en functies daarvan afhankelijk zijn.
- Je registreert welke eigen entiteiten contracten ondertekenen, welke externe ICT-dienstverleners contractpartij zijn en welke groepsentiteiten eventueel intern ICT-diensten doorleveren.
- Je legt vast welke interne contractuele afspraken bestaan binnen de groep en aan welke externe leverancierscontracten deze zijn gekoppeld. Zo wordt zichtbaar wanneer een entiteit afhankelijk is van een interne IT-dienstverlener die op haar beurt afhankelijk is van externe leveranciers.
- Je registreert niet alleen de directe leverancier, maar ook de ICT service supply chain: de relevante onderaannemers en hun positie in de keten. De ITS beschrijft deze keten als een reeks contractuele afspraken die verbonden zijn met de ICT-dienst, startend bij de directe ICT third-party provider en doorlopend naar subcontractors.
- Je koppelt ICT-diensten aan de bedrijfsfuncties die zij ondersteunen, zodat duidelijk wordt of een dienst een kritieke of belangrijke functie raakt.
- Je beoordeelt ICT-diensten die kritieke of belangrijke functies ondersteunen op onder meer substitueerbaarheid, exitplan, herintegratiemogelijkheid, impact bij discontinuïteit, alternatieve leveranciers en laatste auditdatum.
- Je zorgt dat wijzigingen in contracten, dienstverlening, leveranciers, onderaannemers, datalocaties of functie-afhankelijkheden leiden tot een herbeoordeling van de relevante ICT-dienst en het register.
Daarom is het DORA-register niet alleen een rapportageverplichting. Het is de basis voor professioneel third-party ICT risk management. Je ziet welke diensten belangrijk zijn, welke functies afhankelijk zijn, welke leveranciers en subcontractors betrokken zijn en waar kwetsbaarheden ontstaan.
Zo wordt third-party risk management geen losstaand complianceproces, maar een continu verbeterproces: van contract en leverancier naar afhankelijkheid, risico, beoordeling, opvolging en aantoonbare beheersing.
Compliance volgt uit goed beheersen
Het DORA Register of Information is belangrijk. Natuurlijk moet het volledig, actueel en aanleverbaar zijn. Maar de waarde zit niet in het bestand dat je naar de toezichthouder stuurt. De waarde zit in het inzicht dat je onderweg opbouwt.
Een organisatie die haar leveranciers echt beheerst, kan op ieder moment zien:
- waar de grootste afhankelijkheden zitten,
- welke leveranciers extra aandacht vragen,
- welke contracten onvoldoende bescherming bieden,
- welke diensten kritisch zijn voor continuïteit,
- waar concentratierisico ontstaat,
- welke maatregelen nodig zijn om de weerbaarheid te vergroten.
Daarmee verandert het gesprek. Het gaat niet meer over „hebben we het register gevuld?”, maar over „kunnen we onderbouwen dat onze leveranciersrisico’s beheerst zijn?” Dat is precies de beweging die DORA stimuleert.
De rol van technologie
Met Excel kun je een eerste inventarisatie maken. Maar zodra leveranciers, contracten, ICT-diensten, entiteiten, processen, onderaannemers, risico’s, maatregelen en bewijs met elkaar samenhangen, wordt Excel kwetsbaar. Je mist dan al snel versiebeheer, eigenaarschap, workflow, audittrail, koppelingen tussen objecten, signalen bij verlopen contracten of ontbrekende beoordelingen, inzicht in openstaande acties en betrouwbare rapportages.
Een platform voor third party risk management moet daarom meer doen dan gegevens vastleggen. Het moet de werkwijze ondersteunen: beoordelen, opvolgen, toetsen, verbeteren en aantonen. De beste aanpak is om het Register of Information niet als apart rapportageproject te behandelen, maar als resultaat van je dagelijkse leveranciersmanagement.
Conclusie: begin niet bij DORA, begin bij afhankelijkheid
DORA dwingt organisaties om beter naar ICT-leveranciers te kijken. Maar de reden om third party risk management goed in te richten, ligt dieper. Je doet dit niet omdat de toezichthouder een register kan opvragen. Je doet dit omdat je organisatie afhankelijk is van derden. Omdat een verstoring bij een leverancier jouw dienstverlening kan raken. Omdat een zwakke schakel in de keten jouw reputatie, continuïteit en klantvertrouwen kan beschadigen.
Het DORA Register of Information is daarbij geen einddoel. Het is een hulpmiddel om grip te krijgen op afhankelijkheden die er al zijn. Wie het register ziet als verplicht nummer, krijgt er vooral werk bij. Wie het gebruikt als stuurinstrument, bouwt aan een organisatie die beter weet waar zij kwetsbaar is, sneller kan bijsturen en sterker staat wanneer er iets misgaat.
FullyInControl Third party Risk Management helpt je om leveranciers, contracten, ICT-diensten, risico’s, maatregelen, assessments, onderaannemers en bewijs in één geïntegreerde omgeving te beheren. Voor de DORA-reporting van 2026 genereer je met één druk op de knop het volledige Register of Information als XBRL-CSV package: actueel, herleidbaar en klaar voor de toezichthouder.
Lees hier meer over de oplossing voor Third-party risk management!