DORA zorgt vooral voor extra controlewerk, niet voor een andere manier van samenwerken

De Digital Operational Resilience Act, beter bekend als DORA, is voor financiële instellingen zoals verzekeraars al langer een vast onderwerp. De wet is sinds 17 januari 2025 van kracht en moet ervoor zorgen dat financiële instellingen ICT-verstoringen kunnen opvangen, erop kunnen reageren en zich ervan kunnen herstellen. Dat geldt niet alleen voor de eigen systemen, maar ook voor alles wat bij IT-dienstverleners is belegd. Toch leeft de wetgeving dit jaar opnieuw op, nu klanten en toezichthouders scherper kijken naar wie welke verantwoordelijkheid draagt. Voor Garansys betekent dat vooral iets anders dan je misschien zou verwachten. Niet een andere manier van samenwerken met de klant, maar wel een flinke hoeveelheid extra controlewerk. We spraken hierover met Robert, die eerder zelf beheerder was en inmiddels al jaren servicemanager is bij Garansys, verantwoordelijk voor onder meer de beheerdienstverlening aan verzekeraars.

Tekst: Jesper Oskam

Lees ook: Wat betekent DORA-wetgeving voor jouw IT-afdeling

De DORA-wetgeving raakt niet alleen de verzekeraars zelf, maar nadrukkelijk ook hun IT-dienstverleners. Als voorbeeld pakken we een zorgverzekeraar. Die organisatie is daar volgens Robert al vroeg mee gestart. Vanaf begin vorig jaar werd het onderwerp binnen de hele organisatie opgepakt, met dit jaar een verdere uitrol. Concreet betekent dit dat er vanuit het ticketsysteem geautomatiseerd operationele activiteiten worden aangemaakt in het kader van DORA. Sommige een keer per maand, andere een keer per kwartaal, afhankelijk van wat de regelgeving vereist.

“In elk ticket staat omschreven wat het doel is en hoe je de controle moet uitvoeren,” vertelt Robert. “Die wordt toegewezen aan het betreffende beheerteam, dat de controle uitvoert en de resultaten teruglevert.”

Robert ziet hetzelfde vraagstuk bij de andere verzekeraars waarvoor Garansys het beheer uitvoert. Elke organisatie richt het op een eigen manier in. Bij deze zorgverzekeraar is de aanpak het verst uitgewerkt, en daarom lichten we die hier toe.

Voor Garansys komen deze activiteiten boven op het reguliere operationele beheer en doorontwikkelwerkzaamheden. Een afspraak hierover was er vooraf niet, en hoeveel tijd het zou gaan kosten, was ook niet vooraf duidelijk. “Dat was best een stuk extra werk per week,” zegt Robert. Omdat Garansys het beheer tegen een vaste prijs uitvoert, was dat aanleiding voor gesprekken met zijn counterpart bij de klant.

Uit die gesprekken bleek dat een deel van de gevraagde controles al werd afgedekt door de maandelijkse servicemanagementrapportages die Garansys al aanlevert, zoals het behalen van de afgesproken KPI's, het bijhouden van hersteltijden of het signaleren van terugkerende problemen. Voor die onderdelen kon worden afgesproken dat de bestaande rapportage volstaat en het bijbehorende ticket gesloten kan worden. Andere tickets vragen wel degelijk om extra stappen, zoals controles in een omgeving die buiten het afgesproken beheer valt.

Daarnaast komen er geregeld DORA-gerelateerde tickets binnen die volgens Garansys niet bij de IT-dienstverlener thuishoren. Een voorbeeld is een vraag om een kostenindicatie te geven voor een omgeving die bij de klant zelf draait. “We kunnen aangeven wat nodig is qua capaciteit of snelheid, maar wat iets mag kosten, is aan de klant zelf,” aldus Robert. Dit soort tickets worden besproken in het wekelijkse overleg met de contactpersonen bij de klant en vaak teruggelegd of met een nuance opnieuw belegd.

De controles die bij Garansys binnenkomen, zijn terug te voeren op een paar doelen van DORA. Het eerste is grip op ICT-risico’s. Daar horen de controle van firewallregels per resource, de kwetsbaarhedenanalyse en de validatie van de Product Security Baseline bij. Ze moeten aantonen dat de omgeving is ingericht zoals afgesproken en dat zwakke plekken op tijd in beeld komen.

Het tweede doel is aantonen dat systemen een verstoring aankunnen. Daarvoor dienen de beschikbaarheidscontroles per classificatieniveau en de restoretests van servers. Die restoretests zijn volgens Robert inhoudelijk niet nieuw. “Dat moet minstens één keer per jaar of één keer per kwartaal actief getest worden. Eerder deden we dat ook al.”

Deze DORA-controles, in het ticketsysteem ‘operationele activiteiten’ genoemd, vormen in de systemen van Garansys een eigen categorie, los van de bestaande processen voor incidenten, changes en problemen. Ze krijgen standaard een lagere prioriteit dan een incident. Loopt er een DORA-controle en komt er een incident binnen, dan wordt de controle tijdelijk opzijgezet.

DORA vraagt ook om grip op de dienstverleners zelf. Daarom moet de zorgverzekeraar een informatieregister bijhouden van alle ICT-dienstverleners en de afspraken daarmee. Dat register is de verantwoordelijkheid van de klant zelf, maar Garansys wordt regelmatig gevraagd te controleren of de documentatie over de eigen dienstverlening nog actueel is.

Voor gebruikersvragen geldt een vaste volgorde. De medewerkers melden zich eerst bij de eigen helpdesk. Komt die er niet uit, dan belandt de vraag bij Garansys, die hiervoor werkinstructies heeft opgesteld. “In de praktijk komt het nog weleens voor dat nieuwe medewerkers van de klant een vraag doorzetten die de eigen helpdesk had kunnen beantwoorden,” zegt Robert lachend.

Threat Led Penetration Testing is een vorm van weerbaarheidstesten binnen DORA die bewust wordt uitgevoerd door een onafhankelijke partij, nooit door de IT-dienstverlener die het systeem beheert. Robert kent de term dan ook niet uit eigen ervaring, maar herkent het principe direct: “dit soort weerbaarheidstesten laat Garansys bewust aan een onafhankelijke partij over, om diezelfde reden,” vertelt hij. “Ook klanten laten dit doen door een externe partij. Risico’s of kwetsbaarheden die daaruit naar voren komen, landen vervolgens als ticket bij Garansys om samen met de klant op te lossen.”

De zorgverzekeraar heeft inmiddels een apart team dat zich specifiek met DORA bezighoudt. Dat team is het eerste aanspreekpunt voor vragen over de regelgeving en neemt zelf ook contact op wanneer iets niet duidelijk is. Volgens Robert verandert dat weinig aan de samenwerking, omdat de lijnen al kort waren. Bij ticketopvolging wordt naast de beheerder ook de servicemanager standaard meegenomen. Vragen vanuit het DORA-team komen daardoor direct terecht bij iemand die het overzicht heeft.

Wel vraagt de uitvoering van de DORA-controles soms om extra afstemming, vooral via mail of telefonisch met de vaste contactpersoon bij de klant. Denk aan vragen als wat precies de bedoeling is van een controle, of dat wat er al gedaan is voldoende is. “Het is niet zo dat de hele communicatie door DORA anders is gelopen,” benadrukt Robert. “Maar een deel van de tickets vraagt wel om een stukje extra afstemming.”

Wat opvalt in het gesprek met Robert, is dat de impact van de DORA-wetgeving zich niet beperkt tot de IT-dienstverlener. Ook de klant zelf had vooraf niet volledig in beeld hoeveel werk de wetgeving binnen de eigen organisatie zou vragen. Garansys ziet daarnaast regelmatig dat klanten taken bij de IT-dienstverlener neerleggen die eigenlijk bij henzelf horen, zoals de eerder genoemde kostenvraag. Pas bij nadere uitleg blijkt dat dit een verantwoordelijkheid is die de klant zelf moet invullen, al kan Garansys daarbij wel de benodigde informatie aanleveren en meedenken.

Het beeld dat uit dit gesprek naar voren komt, sluit aan bij wat we vaker zien bij nieuwe regelgeving zoals DORA. De impact wordt niet zozeer onderschat op het niveau van techniek, maar vooral op het niveau van governance en eigenaarschap: wie is waarvoor verantwoordelijk, en hoeveel structureel werk brengt dat intern en bij de dienstverlener met zich mee?

Robert geeft andere IT-servicemanagers die met vergelijkbare vraagstukken te maken krijgen een paar concrete aanknopingspunten mee. Maak vooraf duidelijke afspraken over de prioriteit van DORA-controles ten opzichte van het reguliere beheer. En wanneer een klant structureel meer werk verwacht, is het volgens hem verstandig om te bekijken of dat een apart, betaald onderdeel van de dienstverlening moet worden.

Incidentenmanagement blijft voor hem het belangrijkste, mede omdat beveiligingsrisico’s vaak de oorzaak zijn van incidenten. “Het is slim om bij terugkerende problemen zo snel mogelijk de onderliggende oorzaak te achterhalen,” sluit Robert af. “Dat scheelt uiteindelijk weer tijd voor de rest van het beheer.”