DORA ICT-derdepartijenrisico: Een Bestuurlijke Handleiding

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

Een inkooprapport begint meestal met leveranciers, jaarlijkse uitgaven en verlengdata. Een nuttige DORA-bespreking start bij een klantresultaat: een schadeclaim betalen, een transactie uitvoeren, een investeringsrecord bijhouden of klanttoegang tot een account geven. Werk daarna achterwaarts via de systemen, externe diensten en mensen die nodig zijn om dat resultaat te leveren.

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.

Voor een boardstuk vraag je de executive sponsor om de getroffen bedrijfsdienst, de verantwoordelijke interne eigenaar, toelaatbare onderbreking, huidige blootstelling en de benodigde beslissing te benoemen. Beperk technische details tot achtergrondmateriaal. Directeuren dienen voldoende informatie te krijgen om een aanname te betwisten, zonder zelf incidentteam te worden of elk contractueel detail te bespreken.

2. Verwissel geen kritieke functie met een aangewezen kritieke leverancier

Twee beoordelingen beantwoorden verschillende vragen. Uw organisatie bepaalt welke functies binnen het DORA-kader als kritisch of belangrijk worden aangemerkt. De Europese Toezichthoudende Autoriteiten wijzen kritieke ICT-dienstverleners aan voor het Unietoezichtskader. ESMA legt uit dat dit toezicht het eigen verantwoordelijkheid van financiële instellingen aanvult, maar niet vervangt. Zie ESMA's DORA-toezicht uitgelegd.

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. Maak het register volledig, verbonden en uitlegbaar

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. Uitvoeringsverordening (EU) 2024/2956 biedt de standaardtemplates, inclusief aanvullende informatie voor beoordelingen en toeleveringsketen relevant voor kritieke of belangrijke functies.

Een praktische volledigheidstoets start met het vergelijken van het register met inkoopbestanden, terugkerende betalingen, de applicatie-inventaris en de kennis van dienstverantwoordelijken. Verschillen zijn punten van onderzoek, geen automatisch bewijs van een incident: een factuur kan gaan over een niet-ICT-dienst, of meerdere facturen kunnen tot één overeenkomst behoren. Documenteer de conclusie in plaats van het verschil stilzwijgend te negeren.

Vraag iemand buiten het team dat het register onderhoudt om één afhankelijkheid van begin tot eind te volgen. Kunnen ze de contracterende entiteit, feitelijke gebruiker, aanbieder, ondersteunde functie, verantwoordelijke eigenaar en lopend contract aanwijzen? Kunnen ze een externe afspraak onderscheiden van de bijbehorende interne groepsafspraak? Als de schakels niet kunnen worden verklaard, is het exporteren van een technisch geldig bestand geen oplossing voor het managementprobleem.

• Ken een benoemde eigenaar toe aan open classificatie- en eigendomsvragen.
• 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.
• Toon dekkingstekorten en ouderdom aan het management in plaats van alleen een totale leveranciersaantal te rapporteren.

Het bestuur hoeft niet elke spreadsheetrij goed te keuren. Het moet er wel op kunnen vertrouwen dat volledigheid eigenaarschap heeft, onzekerheid zichtbaar is en belangrijke afhankelijkheden gepaste aandacht krijgen.

4. Zet het derde partij beleid om in beslissingspunten

Een beleid wordt nuttig wanneer het een besluit verandert voordat de organisatie afhankelijk wordt. Voor entiteiten die onder de relevante beleidsvereisten vallen, Gedelegeerde Verordening (EU) 2024/1773 behandelt de levenscyclus van regelingen ter ondersteuning van kritieke of belangrijke functies. Het vereist dat het bestuursorgaan het beleid minstens jaarlijks evalueert en indien nodig bijwerkt. Toepassing en proportionaliteit moeten worden getoetst aan de regelgevingscategorie van de entiteit.

De volgende stappen zijn een voorgesteld werkmodel. Voor selectie beschrijft de business owner de dienst en de gevolgen van uitval. Voor ondertekening identificeren risicomanagement, security, juridisch en inkoop gezamenlijk onopgeloste kwesties. Voor livegang toont operations aan dat monitoring, ondersteuning en herstelmaatregelen aanwezig zijn. Bij verlenging of materiële wijziging beoordeelt de eigenaar of de oorspronkelijke aannames nog gelden.

Scheid bij elke fase drie aspecten: het verkregen bewijs, het genomen oordeel en de geaccepteerde uitzondering. Het assurance-rapport van de leverancier is bewijs. De conclusie dat dit jouw gebruik van de dienst voldoende dekt, is een oordeel. Doorgaan ondanks een onopgelost verschil is een uitzondering die een bevoegde beslissing, aanvullende voorwaarden en een einddatum vereist.

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. Daag concentratie uit voorbij het leverancier-uitgavenoverzicht

Concentratie betreft gecorreleerd falen evenals commerciële afhankelijkheid. Twee contracten met verschillende bedrijfsnamen kunnen afhankelijk zijn van hetzelfde onderliggende hostingplatform, connectiviteitsprovider, identiteitsdienst of gespecialiseerde onderaannemer. Twee cloudregio's kunnen hetzelfde beheervlak delen. Dit zijn architecturale vragen waarop een inkoopdiagram geen antwoord geeft.

DORA Artikel 29 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.

Meerdere leveranciers kunnen ook de complexiteit, operationele kosten en coördinatierisico verhogen. Het praktische doel is geen algemeen verbod op concentratie of een eis voor overal dubbele infrastructuur. Het gaat om een geïnformeerde keuze over een specifieke blootstelling, ondersteund door geloofwaardige opties en een duidelijke eigenaar. Leg vast waarom de gekozen maatregel proportioneel is en welk gebeurtenis aanleiding zou geven tot heroverweging.

6. Controleer contractbewijzen tegenover 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 hun grenzen in het vizier. Welke periode bestrijken ze? Welke serviceconfiguratie is beoordeeld? Worden verantwoordelijkheden van de klant verondersteld? Sluit het rapport een component uit waar jouw herstelplan op steunt? Een actueel certificaat kan nuttig zijn maar kan een specifieke operationele vraag onbeantwoord laten.

Houd een beknopt gaplog bij dat elk issue koppelt aan een bedrijfsconsequentie, compenserende maatregel, eigenaar en termijn. Breng het bestuur onopgeloste risico’s en besluiten buiten gedelegeerde bevoegdheid. Voorkom dat één cruciaal tekort wordt verborgen onder een hoog percentage als voltooid gemarkeerde punten: één ontbrekende capaciteit kan belangrijker zijn dan veel gesloten punten met weinig impact.

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(8). In de praktijk zou een bestuur de aannames onder het plan moeten uitdagen: bestemming, gegevens, mensen, tijd, geld en continuïteit van dienst.

Scheid een geplande migratie van een noodsituatie. Een migratietraject van zes maanden kan zakelijk realistisch zijn, maar nutteloos als directe reactie bij een storing. Het herstelplan kan het operationeel houden, het exitplan pakt de langere afhankelijkheid aan. Vraag het management om de relatie toe te lichten in plaats van beide documenten als universele oplossing te presenteren.

1. Kies een representatieve dienst en definieer de exit-trigger.
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. Update the cost, sequence, accountable owner and next test date.

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 een beknopte board pack met beslissingen toegevoegd

Een bruikbaar toezichtpakket past om vijf vragen: wat is veranderd, wat kan tegelijk falen, welke waarborgen zijn verzwakt, welke opties blijven over en welk besluit is nodig? Dit is een voorgestelde rapportagestructuur. De frequentie moet aansluiten bij de risico's en governance van de organisatie, niet bij een willekeurige 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, onopgeloste zekerheidslacunes en hun ouderdom.
• Bepaal veranderingen in concentratie en aannames die nieuw bewijs vereisen.
• Geef het gevraagde besluit, overwogen alternatieven en het gevolg van uitstel aan.

Gebruik de Handleiding DORA-dashboard voor rapportage aan de raad van bestuur om deze maatregelen te koppelen aan breder toezicht op ICT-risico’s. Doe voor een praktische oefening één afhankelijkheid met grote gevolgen in de tabletop-oefening incidentrespons voor 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

Begin niet met het vragen aan elk team om ieder rapport te herontwerpen. Selecteer één belangrijke dienst en vraag om een samenhangende evidentiestroom: functiebeschrijving, register, contract, assurance-review, hersteltest en exitplan. Laat verschillende eigenaars dit samen doorlopen. Tegenstrijdige identificaties, verouderde aannames en onbeheerde acties komen snel boven.

Maak van de bevindingen een kort verbeterplan. Los eerst eigendoms- en inventarisatiegaten op. Behandel daarna beslissingen die tijdsgevoelig zijn vanwege verlenging, migratie of blootstelling. Versterk tenslotte het terugkerende toezichtproces zodat dezelfde gaten niet terugkeren. Geef elke actie een opleverbaar resultaat dat te controleren is, niet slechts de opdracht om ‘governance te verbeteren’.

Bestuurders hebben ook een gedeeld begrip van hun rol nodig. De gids voor DORA-opleidingsvereisten voor bestuur legt uit hoe leren aan governance-verantwoordelijkheden wordt gekoppeld. BlueTeam Academy’s DORA Bestuurs- & Executive Training biedt een besluitgericht programma voor leiderschapsteams bij financiële entiteiten binnen het toepassingsgebied van DORA. Het programma is geen beoordeling van de compliance van de organisatie. Koppel leren aan je eigen dienstspecifieke bewijs, besluiten en opvolging.