DORA-gereedheid voor financiële entiteiten en hun ICT-leveranciers

DORA, de verordening betreffende digitale operationele weerbaarheid voor de financiële sector, is sinds 17 januari 2025 van toepassing. Voor financiële entiteiten betekent gereedheid nu het onderhouden van een werkmodel voor digitale operationele weerbaarheid, niet de voorbereiding op een toekomstige deadline. Voor technologieleveranciers betekent het inzicht in hun verantwoordelijkheden richting klanten en in de vraag of een afzonderlijk regime van rechtstreeks toezicht van toepassing is.

De vraag voor het management is praktisch: kan de organisatie uitleggen welke financiële diensten van welke ICT-systemen afhankelijk zijn, hoe een verstoring wordt afgehandeld en welk bewijs de aannames over herstel onderbouwt? Beleid is belangrijk, maar kan die vraag niet alleen beantwoorden. Het management heeft een samenhangend beeld nodig van verantwoordelijkheden, afhankelijkheden, contracten, tests, incidenten en onopgeloste risico's.

Bepaal uw rol voordat u de checklist opstelt

Begin met een gedocumenteerd toepasselijkheidsbesluit voor elke relevante juridische entiteit. Artikel 2 van DORA noemt de categorieën die eronder vallen en de uitzonderingen. Een onderneming die zichzelf fintech, start-up of mkb-bedrijf noemt, valt daardoor niet automatisch binnen of buiten de reikwijdte.

Voorbeelden van financiële entiteiten die eronder vallen zijn kredietinstellingen, betalingsinstellingen, beleggingsondernemingen en verzekeringsondernemingen, met inachtneming van de gedetailleerde reikwijdteregels van de verordening. Leg de toepasselijke categorie vast, eventuele uitsluitingen of vrijstellingen, de relevante bevoegde autoriteit en de onderbouwing van uw conclusie.

Maak voor leveranciers onderscheid tussen drie posities:

Een leverancier die een kritieke of belangrijke financiële functie ondersteunt, is om die reden alleen nog geen aangewezen kritieke derde aanbieder van ICT-diensten. Financiële entiteiten beoordelen het belang van hun functies en afhankelijkheden; de aanwijzing van kritieke aanbieders vindt plaats via het toezichtskader op grond van artikel 31.

De vestigingsplaats beslist de vraag voor leveranciers niet. Een cloud- of softwareaanbieder uit de Verenigde Staten kan te maken krijgen met DORA-gerelateerde eisen van klanten wanneer hij financiële entiteiten in de EU bedient. Die commerciële relatie maakt hem niet automatisch onderworpen aan elke verplichting die voor een financiële entiteit geldt.

Ook evenredigheid vraagt om een onderbouwde beoordeling. Artikel 4 houdt rekening met factoren als omvang, algemeen risicoprofiel en de aard, schaal en complexiteit van de diensten. Artikel 16 voorziet in een vereenvoudigd kader voor ICT-risicobeheer voor bepaalde categorieën. Dat zijn geen uitwisselbare begrippen, en een gewone mkb-status is geen universele kortere weg. Bewaar de analyse van de geschiktheid bij het reikwijdtebesluit.

Maak de verantwoordelijkheid van het management zichtbaar

Op grond van artikel 5 van DORA draagt het leidinggevend orgaan de eindverantwoordelijkheid voor het beheer van het ICT-risico van de financiële entiteit. Het delegeren van de uitvoering aan een CISO, een technologieteam of een externe aanbieder draagt die verantwoordelijkheid niet over.

Het management moet vastleggen wie besluiten voorstelt, wie ze goedkeurt en wie controleert of de uitvoering werkt. Het werkmodel moet bedrijfscontinuïteit, incidentrespons en herstel, afspraken met derden, budget en de kennis omvatten die nodig is voor zinvol toezicht.

Een praktische aanbeveling is het management een rapportagepakket te geven dat op besluiten is gericht, in plaats van een dashboard met voortgangspercentages. Neem daarin op:

• Kritieke of belangrijke functies met niet-geteste aannames over herstel.
• Ernstige incidenten, gevolgen voor klanten en openstaande corrigerende acties.
• Afhankelijkheden van leveranciers met onvolledige contracten of zwakke exitopties.
• Belangrijke lacunes in maatregelen, verantwoordelijke eigenaren en hersteldata.
• Besluiten die financiering, een leverancierswissel of een expliciete risicorespons vereisen.

Elke lacune moet onderscheid maken tussen de wettelijke eis, de huidige operationele zwakte en de voorgestelde oplossing. Een ontbrekende goedkeuringsregistratie is iets anders dan een back-up die niet kan worden teruggezet. Beide kunnen actie vereisen, maar vragen om verschillende eigenaren en prioriteiten.

Goedkeuring door het management van een herstelplan is geen vrijbrief om toepasselijke verplichtingen voor onbepaalde tijd uit te stellen. Is een lacune wezenlijk, overweeg dan naast de structurele oplossing ook directe waarborgen, escalatie en eventuele gevolgen voor het toezicht.

Bouw het programma op rond financiële functies

Een inventaris van bedrijfsmiddelen is noodzakelijk, maar weerbaarheidsplanning moet beginnen bij de dienst die moet doorlopen. Bepaal de financiële functie, de bedrijfseigenaar, de gevolgen van een verstoring en de systemen en aanbieders die de functie ondersteunen.

Breng voor een betaaldienst identiteit, cloudinfrastructuur, transactieverwerking, monitoring en escalatie naar leveranciers in kaart. Neem ook minder zichtbare afhankelijkheden mee, zoals DNS, connectiviteit, bevoorrechte toegang, versleutelingssleutels en supporttools. Een alternatieve productieomgeving kan onbruikbaar zijn als die afhangt van dezelfde uitgevallen identiteitsdienst.

Het resulterende overzicht moet elke functie verbinden met:

• Ondersteunende applicaties, infrastructuur, informatiemiddelen en externe diensten.
• Relevante contracten en service-eigenaren.
• Hersteldoelen en de bedrijfsimpactanalyse die ze onderbouwt.
• Regelingen voor detectie, respons, herstel en communicatie.
• Tests, bevindingen en onopgeloste afhankelijkheidsrisico's.

Valideer het overzicht met zowel operationele als bedrijfsteams. Inkoopgegevens laten zien wat is aangeschaft; ze tonen niet noodzakelijk hoe een dienst vandaag werkt.

Gebruik dit model om ICT-risicobeheer, het beheer en de melding van incidenten, weerbaarheidstests en ICT-risico's van derden te organiseren. DORA bevat ook bepalingen over het vrijwillig delen van informatie over cyberdreigingen. Neemt u daaraan deel, leg dan lidmaatschap, vertrouwelijkheid, toegestaan gebruik en omgangsregels vast, in plaats van delen te behandelen als een onbeperkte uitwisseling van incidentgegevens.

Maak van ICT-risicobeheer gefinancierd werk

De bepalingen van DORA over ICT-risicobeheer omvatten identificatie, bescherming en preventie, detectie, respons en herstel, leren en communicatie. Het kader moet die activiteiten met elkaar verbinden in plaats van ze als losse beleidsverzamelingen te laten bestaan.

Begin de gap-analyse bij de in kaart gebrachte functies. Vraag of toegangsmaatregelen hun systemen beschermen, of kwetsbaarheden worden aangepakt, of wijzigingen worden beheerst, of verdachte activiteiten worden gedetecteerd en of herstelregelingen rekening houden met realistische storingen. Denk naast kwaadwillende aanvallen ook aan technische fouten en operationele vergissingen.

Maak voor elke wezenlijke zwakte een herstelregistratie met een eigenaar, de bedrijfsimpact, de vereiste actie, afrondingscriteria en bewijs van afsluiting. Afhankelijkheden doen ertoe: het verbeteren van herstelprocedures kan wijzigingen in de toegang tot back-ups, toezeggingen van leveranciers en training van medewerkers vereisen voordat een geslaagde test mogelijk is.

Hersteldoelen moeten voortkomen uit bedrijfsbehoeften en impactanalyse, niet uit het standaardserviceniveau dat een leverancier toevallig biedt. Kan de technische capaciteit het doel niet halen, dan moet het management beslissen of de architectuur wordt verbeterd, de dienstafspraak wordt gewijzigd of het werkmodel wordt heroverwogen. Een doel in een continuïteitsplan is geen bewijs dat herstel mogelijk is.

Bereid incidentbesluiten voor vóór de verstoring

DORA verplicht financiële entiteiten om ICT-gerelateerde incidenten te beheren en ernstige incidenten te melden bij de relevante bevoegde autoriteit. De artikelen 17 tot en met 23 vormen het kader; de toepasselijke technische reguleringsnormen en technische uitvoeringsnormen bevatten de gedetailleerde classificatiecriteria, drempels, de inhoud van meldingen en de procedures.

Vertrouw voor het gedetailleerde meldschema niet op een generieke incidentchecklist. Houd een actuele meldmatrix bij met de toepasselijke normen, de instructies van de autoriteit, het meldkanaal, de meldfasen en de berekening van termijnen. Wijs iemand aan die verantwoordelijk is voor het actueel houden ervan.

Het responsproces moet verschillende besluiten onder druk uitvoerbaar maken:

• Wie legt de tijdstippen van detectie, beoordeling en classificatie vast?
• Wie verkrijgt informatie over de impact van operations en leveranciers?
• Wie beslist of aan de criteria voor een ernstig incident is voldaan?
• Wie keurt meldingen goed en dient ze in, ook buiten kantooruren?
• Wie verzorgt de communicatie met klanten en andere toepasselijke meldingen?

Leg de onderbouwing van de classificatie ook vast wanneer een incident niet als ernstig wordt gemeld. Een onvolledig eerste beeld moet tot herbeoordeling leiden naarmate er meer informatie beschikbaar komt, niet tot de blijvende aanname dat de gebeurtenis gering is.

Toezeggingen van leveranciers over meldingen moeten de financiële entiteit voldoende tijd laten om haar eigen verplichtingen te beoordelen en na te komen. Meldtaken kunnen waar toegestaan worden uitbesteed, maar de verantwoordelijkheid blijft bij de financiële entiteit.

Wanneer een ernstig ICT-gerelateerd incident gevolgen heeft voor de financiële belangen van cliënten, moeten financiële entiteiten op grond van DORA die cliënten onverwijld informeren over het incident en over de maatregelen die zijn genomen om de nadelige gevolgen te beperken. Beoordeel afzonderlijk de verplichtingen bij inbreuken in verband met persoonsgegevens en andere toepasselijke regels. Eén verstoring kan tot meerdere meldingsbesluiten leiden, met verschillende ontvangers en juridische toetsen.

Test de aannames waarop het management vertrouwt

Een programma voor het testen van digitale operationele weerbaarheid moet evenredig en risicogebaseerd zijn. Kwetsbaarheidsbeoordelingen, scenario-oefeningen, beveiligingstests en hersteltests beantwoorden verschillende vragen; geen ervan mag als universele vervanging van de andere worden beschouwd.

Een tabletopoefening kan vaststellen of beslissers de escalatie begrijpen. Zij kan niet bewijzen dat transactiegegevens nauwkeurig kunnen worden hersteld. Een penetratietest kan misbruikbare zwakheden blootleggen zonder te bewijzen dat een alternatieve leverancier een dienst kan overnemen.

Leg voor elke test de functie, het scenario, de reikwijdte, de succescriteria, waar vereist de regelingen voor onafhankelijkheid en het verwachte bewijs vast. Bewaar de resultaten, bevindingen, herstelbesluiten en uitkomsten van hertests. Toets de toepasselijke eisen aan dekking en frequentie aan DORA en de relevante normen, inclusief eventuele vrijstellingen of bepalingen over het vereenvoudigde kader.

Dreigingsgestuurde penetratietests (TLPT) zijn op grond van artikel 26 een afzonderlijke toezichtseis voor geselecteerde financiële entiteiten. Het is geen algemene verplichting voor elke financiële onderneming of ICT-leverancier.

Het management moet niet alleen beoordelen of tests hebben plaatsgevonden, maar vooral welke aannames niet bleken te kloppen. Blijkt uit een oefening dat herstel afhangt van één beheerder die niet beschikbaar is, dan is de uitkomst een operationeel risico dat actie vereist, geen afgeronde testmijlpaal.

Behandel risico's van derden als een vraagstuk van dienstcontinuïteit

Op grond van DORA blijft een financiële entiteit verantwoordelijk voor haar verplichtingen wanneer zij ICT-leveranciers inschakelt. De artikelen 28 tot en met 30 verbinden de beoordeling van risico's van derden, contractuele afspraken, monitoring en exitplanning.

Onderhoud het register en het operationele beeld

Financiële entiteiten moeten een informatieregister bijhouden over contractuele regelingen voor ICT-diensten, op de vereiste individuele, gesubconsolideerde en geconsolideerde niveaus. Gebruik voor de structuur ervan de toepasselijke technische uitvoeringsnormen. Een inkoopspreadsheet of een lijst met goedgekeurde leveranciers is niet automatisch voldoende.

Stem het register af op contracten, service-eigenaarschap en afhankelijkheidsoverzichten. Houd de vereiste onderscheidingen aan voor diensten die kritieke of belangrijke functies ondersteunen. Een nieuwe onderaannemer, dienstlocatie of uitgebreide reikwijdte kan het risicobeeld veranderen, ook als de naam van de leverancier gelijk blijft.

Toets contracten aan de werkelijke dienst

Beoordeel de toepasselijke contractuele eisen, waaronder dienstomschrijvingen, locaties, gegevensbescherming, toegang tot en herstel van gegevens, ondersteuning bij incidenten, samenwerking, beëindigingsrechten en serviceniveaus. Regelingen die kritieke of belangrijke functies ondersteunen, vereisen aanvullende bepalingen, waaronder relevante afspraken over rapportage, continuïteit, toegang, inspectie, audit en exit.

Juridische zaken, inkoop, technologie en bedrijfseigenaren moeten deze gezamenlijk beoordelen. Een contractueel auditrecht kan in de praktijk moeilijk uit te oefenen zijn; een toegezegde herstelregeling dekt mogelijk niet de volledige dienstketen van de klant. Breng die beperkingen in kaart voordat de regeling wordt geaccepteerd.

Onderzoek concentratie en exitvermogen

Concentratierisico beperkt zich niet tot het afnemen van meerdere diensten bij één onderneming. Verschillende leveranciers kunnen afhankelijk zijn van hetzelfde cloudplatform, dezelfde regio, hetzelfde netwerk of dezelfde onderaannemer. Beoordeel vervangbaarheid, de complexiteit van migratie en de gevolgen van een gemeenschappelijke storing.

Een exitplan moet ingaan op gegevensformaten, extractie, toegang, migratieafhankelijkheden, ondersteuning bij de overgang, verwijdering en continuïteit tijdens de overstap. Behandel het testen en beoordelen van exits voor kritieke of belangrijke functies als inhoudelijk werk, niet als schrijfoefening.

Leveranciers kunnen een consistent zekerheidspakket voorbereiden met de reikwijdte van de dienst, de verantwoordelijkheidsgrenzen, contactpersonen voor incidenten, bewijs over continuïteit, informatie over onderaanneming en contractuele standpunten. Klantspecifieke eisen moeten nog steeds worden beoordeeld; een certificaat vervangt die niet.

Begrijp waar DORA en NIS2 elkaar raken

DORA is een EU-verordening met rechtstreekse werking. NIS2 is een richtlijn die via nationaal recht wordt geïmplementeerd, waarbij de toepasselijkheid afhangt van sector, omvang, dienst en opnameregels. De termijn voor omzetting in nationaal recht verliep op 17 oktober 2024; organisaties moeten de toepasselijke nationale implementatie onderzoeken in plaats van uit te gaan van één identiek regime.

Artikel 1, lid 2, van DORA legt samen met artikel 4 van NIS2 de sectorspecifieke verhouding vast voor financiële entiteiten die op de relevante terreinen onder DORA vallen. Lees dit niet als een opdracht om gelijkwaardige maatregelen voor risicobeheer en incidentmelding te dupliceren. Ga er evenmin van uit dat het verplichtingen wegneemt voor elke onderneming in een financiële groep of in haar toeleveringsketen.

Een managed service provider die een bank bedient, kan een eigen NIS2-beoordeling nodig hebben en tegelijk aan DORA-gerelateerde contractuele toezeggingen moeten voldoen. Een verplichtingenmatrix per entiteit moet de rechtsgrond, de reikwijdte, de autoriteit, de meldroute en het vereiste bewijs vastleggen.

Gedeelde maatregelen kunnen DORA, ISO 27001, privacyverplichtingen en zekerheid richting klanten ondersteunen wanneer reikwijdte en bewijs overeenkomen. Hergebruik een toegangsreview of hersteltest als die werkelijk meerdere eisen ondersteunt, en behoud daarbij de details die specifiek zijn voor de financiële sector. Een ISO 27001-certificaat toont geen naleving van DORA aan.

Ook de handhaving verschilt. De toezichtsbevoegdheden en sancties voor financiële entiteiten hangen af van de bepalingen van DORA en de toepasselijke nationale maatregelen; voor aangewezen kritieke aanbieders geldt een afzonderlijk toezichtsregime. Baseer het risicobudget niet op een vermeende universele DORA-boete. Beoordeel de relevante juridische blootstelling en de operationele gevolgen van onvoldoende weerbaarheid.

Uitgewerkt voorbeeld: review van de afhankelijkheden van een betaaldienst

Neem als illustratie een betalingsinstelling die een cloudplatform, een identiteitsprovider en een uitbestede monitoringdienst gebruikt. Stel dat de instelling onder DORA valt en dat de uitvoering van betalingen als kritieke of belangrijke functie is geclassificeerd.

De eerste review brengt drie zwakheden aan het licht: de productie- en herstelomgeving delen dezelfde identiteitsafhankelijkheid; het escalatieproces bij incidenten van de monitoringleverancier is onduidelijk; en het exitplan voor de cloud noemt een alternatieve aanbieder zonder aan te tonen dat gegevens kunnen worden geëxtraheerd en gemigreerd.

Het management geeft opdracht voor drie samenhangende werkpakketten:

De bedrijfseigenaar controleert of de hersteldoelen voor betalingen haalbaar blijven. Compliance verifieert dat de meldprocedures en registervermeldingen de regelingen correct weergeven. Het management keurt de benodigde financiering goed en beoordeelt de resterende beperkingen.

Dit voorbeeld toont op zichzelf geen naleving aan. Het laat zien hoe één functie besluiten aan het licht kan brengen die verborgen zouden blijven in afzonderlijke checklists voor beleid, leveranciers en tests.

Zorg voor een reviewritme dat op bewijs is gebaseerd

DORA kent geen universeel certificeringsproces dat doorlopende verplichtingen vervangt. Onafhankelijke zekerheid kan het management informeren, maar gereedheid moet worden aangetoond met werkende maatregelen, registraties en, waar vereist, contact met de toezichthouder.

Een praktische volgende stap is één kritieke of belangrijke functie te kiezen en het reikwijdtebesluit, het afhankelijkheidsoverzicht, de risicobeoordeling, de contracten, de incidentprocedures, de testresultaten en de openstaande acties ervan bijeen te brengen. Beoordeel of die registraties een samenhangend verhaal vertellen.

Secani ondersteunt deze werkwijze door systemen en diensten te modelleren, afhankelijkheden te verbinden en eisen, bewijs, eigenaren, taken en beoordelingsbesluiten in hun context te houden. Upload bestaand materiaal bij de relevante objecten, zet lacunes om in toegewezen werk en behoud expliciete menselijke goedkeuring voor door AI ondersteunde suggesties en conclusies.

Breid vanuit die eerste functie uit zodra eigenaarschap en bewijsroutes duidelijk zijn. Het management moet kunnen zien wat is aangetoond, wat nog onzeker is en welk besluit als volgende nodig is.