De Wereld Draait DORA deel 1 – Let op bij standaard DORA contracten

Het voelt nog maar een kleine poos geleden dat de financiële sector te maken kreeg met een uitgebreid staaltje compliance-wetgeving, maar gelukkig zijn de meeste financiële instellingen hard op weg om de Digital Operational Resilience Act zich eigen te maken. In mei 2025 publiceerde De Nederlandsche Bank een rapportage waarin zij aangaf dat op dat moment maar liefst 95% van de financiële instellingen hun uitbestedingsbeleid al had geactualiseerd. Alleen had nog maar 34% van deze financiële instellingen hun ICT-contracten met ICT-dienstverleners die kritieke of belangrijke functies ondersteunen in lijn gebracht met de contractuele vereisten uit DORA. Daar is nog werk aan de winkel.

Dat werk wordt veelal verzet middels standaardcontracten waarmee in een klap alle afspraken in lijn zijn gebracht met deze contractuele vereisten. Deze standaard DORA contracten worden erg veel gebruikt in de financiële sector. Maar soms komt zo’n klap harder aan dan nodig. In dit blog ga ik daarom in op de valkuilen voor bij deze veelgebruikte DORA-templates.

De gangbare norm

Alles leuk en aardig, zo’n template, maar waar hebben we het dan eigenlijk over? Vaak kijken we naar (afgeleiden van) een modelovereenkomst uit 2024 opgesteld in opdracht van onder andere het Verbond van Verzekeraars. Hierin komen (bijna) alle vereisten terug uit artikel 30 DORA, waar de contractuele verplichtingen zijn opgenomen. Deze zijn op te splitsen in 2 categorieën:

1. Verplichtingen die terug moeten komen in alle contracten tussen ICT-leveranciers en financiële entiteiten; en
2. Verplichtingen die enkel van toepassing zijn bij diensten die kritieke of belangrijke functies ondersteunen, heel platgeslagen gaat het om erg belangrijke ICT-diensten.

Artikel 30 DORA schrijft grofweg de volgende contractuele vereisten voor:

Overigens komen niet alle contractuele verplichtingen terug in Artikel 30 DORA. Zo zijn onder meer de genoemde beëindigingsrechten terug te vinden in artikel 28 lid 7 DORA en het volgen van trainingen in artikel 13 lid 6 DORA. Tussen de regels door wordt er in de overige artikelen van de wet nog meer invulling gegeven aan deze verplichtingen.

RT-Stress

De hierboven opgesomde vereisten en de overige wetsartikelen zouden een overzichtelijke lijst moeten vormen. Dat zou het moeten zijn, ware het niet dat de ‘technische reguleringsnorm’ (RTS) over het uitbesteden van kritieke of belangrijke functies hier nog overheen komt. In deze norm wordt extra invulling gegeven aan, je raadt het al, de uitbesteding van kritieke functies. Het is echter verwarrend dat de eerste versie van deze RTS was afgewezen door de Europese Commissie en we het een tijd zonder moesten stellen. Inmiddels is er een nieuwe RTS, eentje die minder ver gaat in haar verplichtingen. Er wordt in eerdere DORA modelovereenkomsten nog gerefereerd aan de oude RTS, met vergaande monitoringsverplichtingen. Een belangrijk aandachtspunt bij het gebruik van deze templates is dan ook dat er geen verplichtingen uit de oude RTS in staan.

Uitbreiden en inperken

We hebben nu het frame van alle wettelijke vereisten die de contracten tussen financiële entiteiten en diens ICT-dienstverleners regelen redelijk scherp. Het is de kunst om ons aan dat frame te houden. Partijen kunnen de verplichtingen uit DORA zien als aanleiding om bestaande contracten aan te passen, terwijl dat niet nodig is.

Een goed voorbeeld daarvan is aansprakelijkheid, een thema dat regelmatig terugkomt in contractonderhandelingen. De ICT-dienstverlener wil diens aansprakelijkheid meestal zoveel mogelijk inperken en de afnemer wil die aansprakelijkheid juist uitbreiden. Wanneer er beloftes gemaakt (moeten) worden met betrekking tot beschikbaarheid, authenticiteit en vertrouwelijkheid, kan dat gezien worden als mooi aanknopingspunt om de aansprakelijkheid hiervoor extra uit te breiden dan wel in te dammen. Dergelijke aanknopingspunten kunnen vaak gepareerd worden met een terechte verwijzing naar de hoofdovereenkomst; we hebben het hier over een DORA-addendum, waar alleen DORA-verplichtingen in vereist zijn. Het opnemen van deze bepalingen kan gezien worden als een bevestiging van hetgeen al is overeengekomen in de hoofdovereenkomst. Contractsvrijheid is natuurlijk een groot goed, maar laat het geen aanleiding zijn om de eerdere onderhandelingen onderuit te halen.

Maar één voorbeeld maakt nog geen zomer. Met dat in gedachten: een ander voorbeeld waar partijen vaak over steggelen zijn de dienstenniveaus, of in goed Nederlands: de ‘service levels’. Afspraken die terug te vinden zijn in de gelijknamige ‘Service Level Agreement, maar wat ook met een kort en bondige omschrijving in de overeenkomst zelf opgenomen kan worden. Immers, de zin ‘wij spannen ons zo goed mogelijk in om deze dienst te leveren en blijven kijken hoe we onze dienst kunnen verbeteren’, is ook al een omschrijving van het dienstenniveau. Eentje waar heus wel iets op aan te merken is, maar die toch echt binnen de lijntjes van Artikel 30 lid 2 sub e DORA blijft. Met de kanttekening dat het hier dus wel alleen kan gaan om een dienst die geen kritieke of belangrijke functies ondersteunt. In dat geval zouden de dienstenniveaus uiteraard duidelijke prestatiedoelstellingen moeten bevatten. Het punt wat dit fictieve service level duidelijk wil maken: DORA geeft geen directe aanleiding om uitgebreide nieuwe regels overeen te komen.

Een laatste bepaling die aangestipt kan worden, is er een die op zich niet heel spannend is; het opnemen van een (direct) beëindigingsrecht in het geval van faillissement of surseance van betaling van de ICT-dienstverlener. Vaak wordt dit gepresenteerd in de lijst uit artikel 28 lid 7 DORA, maar de oplettende wettekstlezer zal concluderen dat dit niet in dit wetsartikel opgenomen is en daardoor niet verplicht is als contractueel vereiste.

De kosten

Eerder werd al aangehaald dat de ICT-dienstverlener graag zijn extra kosten wil verhalen op de financiële entiteit. De afspraken waar namelijk eventuele extra kosten bij kunnen komen zijn tenslotte voer voor discussie. De wetgever erkent deze behoefte en probeert dit af te dekken door te zeggen dat er geen extra kosten en alleen vooraf vastgestelde kosten in rekening hiervoor gebracht mogen worden (artikel 30 lid 2 sub f DORA). Bij het volgen van bewustmakingsprogramma’s is dit niet nadrukkelijk overeengekomen. Dat de kosten voor het volgen van deze trainingen in rekening worden gebracht zal dan ook snel een wens of eis van de ICT-dienstverlener zijn. Grappig genoeg moet de organisatie die (digitaal) dergelijke trainingen aanbiedt aan een financiële entiteit zelf óók deze trainingen volgen als daar om gevraagd wordt.

Conclusie

Het gebruiken van een standaardtemplate om alle contractuele verplichtingen die DORA voorschrijft in een keer af te dekken, kan een goede manier zijn om dit te tackelen. Sommige ICT-dienstverleners kiezen ervoor om hun eigen standaardcontracten aan te passen, zodat deze vereisten meteen in de overeenkomst gebakken zitten, of stellen hun eigen addendum op. Allemaal goede oplossingen. Het advies is om scherp te zijn op eventuele toevoegingen die niet verplicht zijn vanuit de DORA. En om dan heel even mijn eigen commerciële bril op te zetten: wie kan daar nou beter bij helpen dan de juristen van ICTRecht?

Heb je hierbij hulp nodig of loop je ergens tegenaan? Neem dan gerust contact met ons op!