ICT-leveranciersrisico onder DORA: een toezichtgids voor bestuurders

1. Begin met de dienst die het bedrijf moet blijven leveren

Een inkooprapport begint meestal met leveranciers, jaarlijkse uitgaven en verlengingsdata. Een nuttig DORA-overleg begint bij wat de klant nodig heeft: een schadevergoeding ontvangen, een betaling uitvoeren, een beleggingshistorie behouden of toegang krijgen tot een rekening. Bepaal vervolgens welke systemen, externe diensten en mensen daarvoor nodig zijn.

Dit verandert de vraag van “Hebben we onze cloudleverancier beoordeeld?” naar “Wat gebeurt er met deze dienst als het identiteitsplatform, de hostingregio of de ondersteunende leverancier niet beschikbaar is?” De tweede vraag brengt afhankelijkheden aan het licht die een leverancierscorekaart kan missen. Een goedkope authenticatiedienst kan meer activiteit stilleggen dan een groot softwarecontract.

Het juridische uitgangspunt is dat het gebruik van ICT-diensten de verplichtingen van de financiële entiteit niet overdraagt aan haar leverancier. DORA plaatst ICT-derdepartijrisico’s binnen het risicomanagementkader van de entiteit. Zie artikel 28 van Verordening (EU) 2022/2554. De interpretatie en werkmethoden in deze handleiding zijn praktische suggesties; ze vormen geen uitputtende beschrijving van alle vereisten die op elk type entiteit van toepassing zijn.

Vraag voor de bestuursstukken aan de verantwoordelijke leidinggevende om de betrokken dienst, de interne verantwoordelijke, de aanvaardbare onderbrekingsduur, het huidige risico en het benodigde besluit te benoemen. Bewaar technische details voor de bijlagen. Bestuurders hebben genoeg informatie nodig om aannames te toetsen, zonder het werk van het incidentteam over te nemen of iedere contractclausule te onderhandelen.

2. Onderscheid een kritieke functie van een aangewezen kritieke leverancier

Deze twee beoordelingen beantwoorden verschillende vragen. Uw organisatie bepaalt welke functies onder DORA kritiek of belangrijk zijn. De Europese toezichthoudende autoriteiten wijzen kritieke derde aanbieders van ICT-diensten aan voor het Europese toezichtskader. Volgens ESMA vult dit toezicht de eigen verantwoordelijkheid van financiële entiteiten aan; het vervangt die niet. Zie de uitleg van ESMA over DORA-toezicht.

Pas dit onderscheid toe op een kleine gespecialiseerde leverancier. Deze kan uw enige toegang tot een belangrijke financiële dienst mogelijk maken zonder op een lijst van aangewezen providers te staan. Evenzo vervalt de noodzaak tot beoordelen van het daadwerkelijke gebruik niet als u een kleine dienst afneemt bij een grote aangewezen provider. Bewaar deze twee classificaties gescheiden om te voorkomen dat een misleidend veld “kritiek: ja/nee” alle vervolgbesluiten beïnvloedt.

3. Zorg voor een volledig register met begrijpelijke samenhang

Het register is niet beperkt tot de contracten die kritieke of belangrijke functies ondersteunen. Artikel 28(3) omvat alle contractuele afspraken voor ICT-diensten geleverd door ICT-derden, met onderscheid voor afspraken die die functies ondersteunen. De Uitvoeringsverordening (EU) 2024/2956 bevat de standaardmodellen, waaronder aanvullende beoordelingsinformatie en gegevens over de toeleveringsketen voor kritieke of belangrijke functies.

Controleer de volledigheid door het register te vergelijken met inkoopgegevens, terugkerende betalingen, de applicatie-inventaris en de kennis van dienstverantwoordelijken. Verschillen vragen om onderzoek en bewijzen niet automatisch een overtreding: een factuur kan een dienst buiten ICT betreffen, of meerdere facturen kunnen bij één overeenkomst horen. Leg de conclusie vast in plaats van de afwijking stilzwijgend te negeren.

Vraag iemand buiten het registerteam één afhankelijkheid van begin tot eind te volgen. Kan die persoon de contracterende entiteit, de werkelijke gebruiker, de leverancier, de ondersteunde functie, de verantwoordelijke en het geldende contract aanwijzen? Is de externe overeenkomst te onderscheiden van de bijbehorende afspraak binnen de groep? Als die verbanden onduidelijk zijn, lost een technisch correct exportbestand het bestuurlijke probleem niet op.

• Wijs iemand aan die open vragen over classificatie en verantwoordelijkheden moet oplossen.
• Noteer datum en reden voor een wijziging, vooral na overnames of dienstmigraties.
• Stem wijzigingen af zodra een nieuwe dienst wordt goedgekeurd, niet alleen vóór een indieningsdeadline.
• Laat het management zien welke informatie ontbreekt en hoelang dat al zo is, in plaats van alleen het totale aantal leveranciers.

Het bestuur hoeft niet iedere rij van het register goed te keuren. Het moet erop kunnen vertrouwen dat iemand verantwoordelijk is voor de volledigheid, dat onzekerheden zichtbaar zijn en dat belangrijke afhankelijkheden voldoende aandacht krijgen.

4. Verbind het leveranciersbeleid aan concrete beslismomenten

Beleid is nuttig als het een besluit beïnvloedt voordat de organisatie afhankelijk wordt van een leverancier. Voor entiteiten waarop de betreffende beleidsvereisten van toepassing zijn, behandelt de Gedelegeerde Verordening (EU) 2024/1773 de levenscyclus van overeenkomsten die kritieke of belangrijke functies ondersteunen. Het bestuursorgaan moet het beleid ten minste jaarlijks beoordelen en zo nodig bijwerken. Toepasselijkheid en proportionaliteit moeten worden getoetst aan de categorie waaronder de entiteit valt.

De volgende stappen zijn een voorstel voor de werkwijze. Vóór de selectie beschrijft de dienstverantwoordelijke de dienst en de gevolgen van uitval. Vóór ondertekening stellen risicomanagement, beveiliging, juridische zaken en inkoop samen vast welke problemen nog openstaan. Vóór ingebruikname tonen de operationele teams aan dat monitoring, ondersteuning en herstel zijn geregeld. Bij verlenging of een belangrijke wijziging controleert de verantwoordelijke of de oorspronkelijke aannames nog kloppen.

Scheid bij ieder beslismoment het verkregen bewijs, de beoordeling en de geaccepteerde uitzondering. Een assurancerapport van de leverancier is bewijs. De conclusie dat het uw gebruik van de dienst voldoende dekt, is een beoordeling. Doorgaan met een onopgelost tekort is een uitzondering: daarvoor zijn een besluit van een bevoegde persoon, voorwaarden en een einddatum nodig.

Laat niet elk probleem “geaccepteerd door het bedrijf” worden. Identificeer wie bevoegd is om welke blootstelling te accepteren binnen de governance-afspraken van de organisatie. Escaleer afhankelijkheden waarvan de gevolgen deze bevoegdheid overschrijden. De meest waardevolle bijdrage van het bestuur kan het financieren van een ontbrekende herstelcapaciteit zijn of het afwijzen van een gehaaste lancering waarvan de weerbaarheidsaannames nog niet zijn getoetst.

5. Beoordeel concentratie verder dan de uitgaven per leverancier

Concentratie gaat zowel over uitval met een gemeenschappelijke oorzaak als over commerciële afhankelijkheid. Twee contracten met verschillende bedrijven kunnen steunen op hetzelfde hostingplatform, dezelfde netwerkleverancier, identiteitsdienst of gespecialiseerde onderaannemer. Ook twee cloudregio’s kunnen een gemeenschappelijke beheeromgeving hebben. Een uitgavengrafiek geeft geen antwoord op deze technische afhankelijkheden.

Artikel 29 van DORA behandelt de beoordeling van ICT-concentratierisico. Voor een praktisch bestuursgesprek: vraag het management enkele plausibele afhankelijkheidsstoringen te presenteren en te tonen welke bedrijfsdiensten dan samen zouden uitvallen. Maak de aannames zichtbaar: personeelsbeschikbaarheid, toegang tot sleutels, connectiviteit, dataconsistentie en capaciteit bij het voorgestelde alternatief.

Meer leveranciers kunnen ook meer complexiteit, hogere kosten en grotere coördinatierisico’s veroorzaken. Het doel is niet om iedere concentratie te verbieden of alle infrastructuur te verdubbelen. Het gaat om een bewuste keuze voor een concreet risico, met uitvoerbare opties en een duidelijke verantwoordelijke. Leg vast waarom de maatregel proportioneel is en welke gebeurtenis tot heroverweging leidt.

6. Toets de contractdocumentatie aan de dienst die u daadwerkelijk gebruikt

Een label met “DORA addendum ondertekend” is te globaal voor effectief toezicht. Artikel 30 stelt contractuele vereisten vast, met aanvullende bepalingen voor ICT-diensten die kritieke of belangrijke functies ondersteunen. Juridisch adviseurs dienen de toepasselijke vereisten te koppelen aan de feitelijke regeling. De onderstaande vergelijking is een praktisch controlegereedschap, geen vervangende contracttekst.

Lees assurancerapporten met oog voor hun beperkingen. Welke periode dekken ze? Welke dienstconfiguratie is beoordeeld? Welke verantwoordelijkheden worden bij de klant verondersteld? Sluit het rapport een onderdeel uit waarvan uw herstelplan afhankelijk is? Een geldig certificaat kan nuttig zijn en toch een concrete operationele vraag onbeantwoord laten.

Houd een beknopt overzicht van tekortkomingen bij. Verbind ieder probleem aan een gevolg voor de bedrijfsvoering, een compenserende maatregel, een verantwoordelijke en een termijn. Leg belangrijke onopgeloste risico’s en besluiten buiten de gedelegeerde bevoegdheid voor aan het bestuur. Verberg een wezenlijk tekort niet achter een hoog percentage afgevinkte clausules: één ontbrekende capaciteit kan zwaarder wegen dan veel opgeloste kleine punten.

7. Test of het exitplan uitvoerbaar is

Een contractueel recht om te vertrekken en een operationele mogelijkheid om te vertrekken zijn verschillende zaken. DORA’s exitbepalingen voor diensten die kritieke of belangrijke functies ondersteunen zijn te vinden in artikel 28, lid 8. Toets als bestuur de aannames achter het plan: bestemming, gegevens, mensen, tijd, geld en voortzetting van de dienstverlening.

Maak onderscheid tussen een geplande migratie en een acute storing. Een migratie van zes maanden kan zakelijk haalbaar zijn, maar onbruikbaar als onmiddellijke reactie op uitval. Het herstelplan kan de dienstverlening op gang houden, terwijl het exitplan de afhankelijkheid op langere termijn oplost. Vraag het management dat verband toe te lichten, zonder een van beide documenten als universele oplossing te presenteren.

1. Kies een representatieve dienst en bepaal wanneer het exitplan wordt geactiveerd.
2. Exporteer een gecontroleerde steekproef van benodigde gegevens met passende bescherming.
3. Controleer of de bestemming de gegevens kan lezen en reconciliëren, niet alleen bestanden kan opslaan.
4. Controleer toegangsrechten, licenties, specialistische vaardigheden en overeengekomen transitieondersteuning.
5. Meet de tijd en identificeer handmatig werk, ontbrekende afhankelijkheden en niet-getoetste aannames.
6. Werk de kosten, volgorde, verantwoordelijke en datum van de volgende test bij.

Dit is een voorgestelde testvolgorde, geen vereiste voor een ongecontroleerde migratie naar productie. Kies veilige testen passend bij de dienst en documenteer hun beperkingen. Is alleen een kleine steekproef getest, vermeld dit. Is er geen alternatief beschikbaar, rapporteer die beperking open en toon het voorlopige risicobesluit. Een groene status mag nooit betekenen dat er slechts een document bestaat.

8. Gebruik beknopte bestuursstukken met de besluiten als bijlage

Een bruikbaar bestuursrapport kan vijf vragen beantwoorden: wat is veranderd, wat kan tegelijk uitvallen, welke verificaties geven minder zekerheid, welke opties resteren en welk besluit is nodig? Dit is een voorgestelde structuur. De frequentie moet passen bij de risico’s en bestuursafspraken van de organisatie, niet bij een verzonnen universele DORA-kwartaalcyclus.

Neem het (kleine) aantal afhankelijkheden op met de grootste bedrijfsimpact, recente wijzigingen die daar effect op hebben, achterstallige belangrijke acties en het eerstvolgende relevante contract- of migratiebesluit. Leg trends uit. Een stijgend leveranciersaantal kan duiden op betere inventarisatie en niet automatisch op meer risico. Minder openstaande acties kan door daadwerkelijke oplossing komen of door een andere manier van tellen.

• Koppel elk materieel risico aan een ondersteunde bedrijfsdienst en een verantwoordelijke bestuurder.
• Onderscheid geteste herstelcapaciteit van een doelstelling of leveranciersbelofte.
• Toon contractuele uitzonderingen, ontbrekende verificaties en hoelang die al openstaan.
• Bepaal veranderingen in concentratie en aannames die nieuw bewijs vereisen.
• Geef het gevraagde besluit, overwogen alternatieven en het gevolg van uitstel aan.

Gebruik de gids voor het DORA-dashboard voor bestuurders om deze indicatoren te verbinden met breder toezicht op ICT-risico’s. Oefen het nemen van besluiten over een afhankelijkheid met grote gevolgen in de incidentoefening voor het bestuur. Het bestuur dient in alle drie de discussies dezelfde servicenamen, risicohouders en herstelveronderstellingen te herkennen.

9. Bereid het volgende overleg voor rondom één echte afhankelijkheid

Vraag niet meteen ieder team om alle rapporten opnieuw te ontwerpen. Kies één belangrijke dienst en vraag om een samenhangend geheel: de functiebeoordeling, de registervermelding, het contract, het assurancerapport, de hersteltest en het exitplan. Laat de verantwoordelijken dit samen doornemen. Tegenstrijdige identificaties, verouderde aannames en acties zonder verantwoordelijke komen dan snel aan het licht.

Maak van de bevindingen een kort verbeterplan. Verduidelijk eerst de verantwoordelijkheden en vul de inventaris aan. Pak vervolgens urgente besluiten op rond verlenging, migratie of blootstelling aan risico’s. Verbeter ten slotte het reguliere toezicht, zodat dezelfde tekorten niet terugkomen. Geef elke actie een toetsbaar resultaat, niet alleen de opdracht “de governance verbeteren”.

Bestuurders hebben ook een gedeeld begrip van hun rol nodig. De gids voor DORA-opleidingsvereisten voor bestuur legt uit hoe leren samenhangt met bestuurlijke verantwoordelijkheden. De opleiding van BlueTeam Academy «DORA-cybersecuritytraining voor bestuurders en directieleden» biedt een programma rond bestuurlijke besluiten voor leidinggevenden van financiële entiteiten die onder DORA vallen. Het is geen beoordeling van de naleving door de organisatie. Verbind de opleiding met bewijs, besluiten en vervolgacties voor uw eigen diensten.