1. Inleiding

Een grote financiële groep die in de hele Europese Unie opereert, opereert zelden als één rechtspersoon. Zij opereert als een moederonderneming en een waaier van dochterondernemingen, doorgaans één gereguleerde vennootschap per lidstaat, elk met een eigen vergunning, elk verantwoording afleggend aan haar eigen nationale toezichthouder, elk gevormd door de lokale regels bovenop de gemeenschappelijke Europese. De reden is deels historisch, deels regulatoir en deels commercieel: vergunningen zijn nationaal, toezichthouders zijn nationaal, en een lokale entiteit met een lokale naam en een lokale balans is eenvoudiger te vergunnen, te beaufzichtigen en via te verkopen. Wat de groep bijna altijd wel centraliseert, is de informatietechnologie. Het is verspilling om hetzelfde kernbankplatform, hetzelfde polisadministratiesysteem, hetzelfde datacenter, hetzelfde security operations centre elf keer op te bouwen, dus bouwt de groep ze één keer, in de moederonderneming of in een specifieke groeps-IT-vennootschap, en levert ze aan elke dochteronderneming als gedeelde dienst. De bedrijvigheid is lokaal; het leidingwerk is centraal.

De Digital Operational Resilience Act snijdt door deze constructie heen op een manier die gemakkelijk over het hoofd wordt gezien tot zij wordt geïmplementeerd. DORA, Regulation (EU) 2022/2554, is sinds 17 januari 2025 van toepassing, en haar basiseenheid is de individuele gereguleerde entiteit, niet de groep (DORA, art. 1–2). Elke dochteronderneming moet zelf een kader voor ICT-risicobeheer onderhouden, haar eigen ernstige incidenten classificeren en rapporteren, haar eigen weerbaarheid testen, haar eigen register van ICT-derden bijhouden en ze onder haar eigen bestuur besturen (DORA, art. 5–30). De regeling trekt zich er niets van aan dat de dochteronderneming het platform waarop zij draait niet heeft gebouwd en het niet kan wijzigen; de plicht is hoe dan ook die van de dochteronderneming. En wanneer de groep zich wendt tot de entiteit die het platform wél heeft gebouwd, de moederonderneming, blijkt dat DORA de relatie al heeft benoemd: een groepsvennootschap die ICT levert aan de gereguleerde entiteiten van haar eigen groep is een ICT-dienstverlener binnen de groep, en DORA behandelt haar voor vrijwel elk doel als een derde (DORA, art. 3(20)).

Twee problemen volgen hieruit, en zij vormen het onderwerp van dit paper. Het eerste is een discrepantie tussen waar de plicht ligt en waar de zeggenschap ligt. DORA legt de plicht bij de dochteronderneming en laat de zeggenschap bij de holding, en de holding valt, als zij zelf geen gereguleerde financiële entiteit is, buiten het directe bereik van de regeling, en wordt slechts geraakt via de contracten en het toezicht die haar dochterondernemingen verplicht zijn aan haar op te leggen. Wij noemen dit de asymmetrie tussen naleving en zeggenschap, en paragraaf 3.1 ontleedt haar. Het tweede is dat het centraliseren van de ICT het risico concentreert. Een gedeelde kern is één enkel punt waarvan de storing niet het probleem van één dochteronderneming is maar van elke dochteronderneming tegelijk, een gecorreleerde gebeurtenis met een gemeenschappelijke oorzaak in plaats van een onafhankelijke, diversifieerbare, en omdat elke getroffen dochteronderneming aan haar eigen toezichthouder moet rapporteren, wordt één technische storing een waaier van gelijktijdige regulatoire meldingen door de hele Unie. Paragraaf 3.2 zet dit uiteen en paragraaf 4 modelleert het.

De bijdrage is een diagnose en een ontwerp, geen juridisch commentaar. Wij stellen de twee structurele problemen helder, geven een klein kwantitatief model van het concentratieprobleem zodat een groep kan zien hoe haar mate van centralisatie de betrouwbaarheid per entiteit afweegt tegen het groepsbrede gecorreleerde risico (paragraaf 4), en werken uit wat DORA’s belangrijkste verplichtingen, het register en de contracten (paragraaf 5), incidentrapportage (paragraaf 6), testen (paragraaf 7) en governance (paragraaf 8), in het bijzonder van een gecentraliseerde groep vereisen. Paragraaf 9 stelt een doeloperatiemodel voor dat aan de regeling voldoet en toch de efficiëntie behoudt die de groep in de eerste plaats deed centraliseren. Paragrafen 10 tot en met 12 beantwoorden bezwaren, benoemen beperkingen en sluiten af. De vraag is doorgaans: hoe voldoet een groep, entiteit voor entiteit, aan een regeling die ervan uitgaat dat elke entiteit haar eigen ICT beheerst, wanneer in feite één gedeelde kern ze allemaal beheerst?

2. Wat DORA vereist, en van wie

2.1 De vijf pijlers

DORA ordent de operationele weerbaarheid van een financiële entiteit in vijf gebieden, en het is de moeite waard ze eenmaal te benoemen omdat het groepsprobleem alle vijf raakt. Het eerste is ICT-risicobeheer (hoofdstuk II, art. 5–16): een governance- en beheersingskader, in eigendom van het leidinggevend orgaan, dat identificatie, bescherming, detectie, respons en herstel bestrijkt, met een lichter vereenvoudigd kader beschikbaar voor bepaalde kleinere entiteiten (art. 16). Het tweede is beheer en rapportage van ICT-gerelateerde incidenten (hoofdstuk III, art. 17–23): een proces om incidenten te detecteren en af te handelen, een geharmoniseerde classificatie van hun ernst (art. 18), en een verplichting om ernstige incidenten aan de bevoegde autoriteit te rapporteren volgens een vast tijdschema van initiële, tussentijdse en definitieve rapporten (art. 19). Het derde is het testen van de digitale operationele weerbaarheid (hoofdstuk IV, art. 24–27): een programma van regelmatige tests voor elke entiteit, en geavanceerde dreigingsgestuurde penetratietests (TLPT) ten minste om de drie jaar voor die entiteiten die de autoriteiten aanwijzen als significant (art. 26–27). Het vierde is het beheer van ICT-risico van derden (hoofdstuk V, art. 28–44), waar de groepsstructuur het hardst bijt, en dat wij hieronder uitvoerig behandelen. Het vijfde is informatie-uitwisseling over cyberdreigingen (hoofdstuk VI, art. 45), wat vrijwillig is en ons hier niet hoeft bezig te houden.

2.2 Het entiteitsbeginsel

Het kenmerk van DORA dat alles in dit paper beheerst, is dat haar verplichtingen aanhaken bij de individuele vergunninghoudende entiteit. Een bankengroep is niet vergunninghoudend; haar bankdochters wel. De reikwijdtebepaling van DORA somt de soorten financiële entiteit op die zij bindt, en elk is een entiteit die een vergunning houdt (art. 2). Het gevolg is dat naleving entiteit voor entiteit wordt beoordeeld, en gehandhaafd, door de eigen bevoegde autoriteit van die entiteit. Er is geen groepsvergunning die namens de dochterondernemingen naleeft, en geen enkele Europese toezichthouder aan wie de groep als geheel verantwoording aflegt voor haar weerbaarheid. Het informatieregister is de ene plek waar de groepsdimensie expliciet is: een entiteit moet het niet alleen op haar eigen niveau bijhouden maar, waar zij deel uitmaakt van een groep, ook op gesubconsolideerd en geconsolideerd niveau (art. 28(3)), zodat een consoliderende entiteit een groepsbreed beeld samenstelt. Maar de plicht om na te leven, te besturen, te rapporteren en te testen blijft die van de individuele dochteronderneming, en kan niet worden gekweten door naar boven, naar de moederonderneming, te wijzen.

2.3 Intragroeps-ICT is ICT van derden

Het tweede kenmerk dat dit paper beheerst, is DORA’s behandeling van ICT die van binnen de groep wordt geleverd. Het zou voor de hand liggen aan te nemen dat diensten die een dochteronderneming van haar eigen moederonderneming ontvangt intern zijn, en buiten het derdenregime vallen dat DORA op externe leveranciers richt. DORA sluit die aanname uit. Zij definieert een ICT-dienstverlener binnen de groep als een onderneming die deel uitmaakt van de groep en overwegend ICT-diensten verleent aan entiteiten van dezelfde groep (art. 3(20)), en zij brengt zo’n dienstverlener binnen de derdenregels: de ontvangende dochteronderneming moet de regeling in haar register opnemen (art. 28(3)), haar onder een schriftelijk contract met de verplichte bepalingen besturen (art. 30), de concentratie beoordelen die zij creëert (art. 29), en exitregelingen voor haar aanhouden waar zij een kritieke of belangrijke functie ondersteunt (art. 28(8)). Het intragroepskarakter van de relatie is iets om vast te leggen, geen reden tot vrijstelling. Kortom, wanneer de moederonderneming het platform levert, leest DORA de moederonderneming als een derde-dienstverlener en de dochteronderneming als haar afnemer, met alle verplichtingen die een afnemer van een externe cloud- of softwareleverancier zou dragen. Een groep die de relatie als een zuiver interne aangelegenheid behandelt, bestuurd door een servicecatalogus en een intercompanydoorbelasting in plaats van een DORA-conform contract, is niet compliant.

3. Het patroon van de gecentraliseerde holding

Figuur 1 tekent het patroon waar dit paper over gaat. Een holding of groeps-IT-vennootschap draait de kritieke ICT-kern en levert haar aan meerdere gereguleerde dochterondernemingen, elk in haar eigen lidstaat en elk onder toezicht van haar eigen nationale bevoegde autoriteit. De pijlen van dienstverlening lopen omlaag vanuit de kern; de pijlen van toezicht en incidentrapportage lopen van elke dochteronderneming naar haar eigen autoriteit. De twee problemen uit de inleiding zijn zichtbaar in de afbeelding: datgene wat de groep bijeenbindt, de kern, wordt geleverd door een entiteit die de toezichthouders slechts indirect bereiken, en een storing boven in het diagram plant zich tegelijk voort naar elke tak terwijl de rapportage versplintert over elke autoriteit onderaan.

3.1 De asymmetrie tussen naleving en zeggenschap

In een schoolvoorbeeld van een entiteit draait de onderneming die de DORA-plicht draagt ook de systemen, zodat de plicht en de hefbomen om haar te kwijten in dezelfde handen liggen. De gecentraliseerde groep trekt ze uit elkaar. De dochteronderneming draagt de plicht, omdat zij de vergunninghoudende entiteit is, maar zij draait de kern niet, kan haar niet patchen, kan haar architectuur niet kiezen, kan haar hersteldoelstellingen niet bepalen en kan haar niet zelfstandig testen. De holding draait de kern en houdt al die hefbomen in handen, maar draagt geen directe DORA-plicht als zij zelf geen vergunninghoudende financiële entiteit is, wat een zuivere IT- of holdingvennootschap meestal niet is. De regeling anticipeert precies hierop en omzeilt het: zij bereikt de holding via de dochteronderneming, door de dochteronderneming te verplichten per contract de rechten op toegang, audit, samenwerking, incidentmelding, testen en exit op te leggen die de dochteronderneming in staat stellen een plicht te kwijten over systemen die zij niet bezit (art. 30). De naleving door de dochteronderneming hangt daarom af van haar contractuele macht over haar eigen moederonderneming, wat een ongebruikelijk en ongemakkelijk ding is om te moeten uitoefenen.

De asymmetrie heeft een scherpe praktische kant. Het bestuur van een dochteronderneming krijgt van DORA te horen dat het uiteindelijk verantwoordelijk is voor het ICT-risico van de entiteit en die verantwoordelijkheid niet kan delegeren (art. 5(2)); en toch loopt de werkelijke invloed van het bestuur op de kern die het grootste deel van dat risico draagt via een groepsfunctie die aan de moederonderneming rapporteert, niet aan het bestuur. Als het bestuur simpelweg op het centrum vertrouwt, heeft het in wezen gedelegeerd wat het in rechte niet mag delegeren. Als het probeert echt toezicht uit te oefenen, heeft het informatie, assurance en rechten nodig die een losse intragroepsrelatie niet biedt. Het ontwerpantwoord, uitgewerkt in paragraaf 9, is de relatie de formaliteit te geven die zij met een externe leverancier zou hebben, juist opdat het bestuur van de dochteronderneming de kern kan inzien en aanvechten, en het groepskader zo te bouwen dat het toezicht van elk bestuur een echte input is in plaats van een beleefdheid.

3.2 Concentratierisico

Het tweede probleem is dat de gedeelde kern een concentratie is. DORA benoemt concentratierisico rechtstreeks en vereist dat elke entiteit het beoordeelt voordat zij contracteert en het onder toetsing houdt, met expliciete inbegrip van het risico uit intragroepsregelingen en uit dienstverleners die moeilijk te vervangen zijn (art. 29). In een gecentraliseerde groep is de concentratie bijna totaal: één kern, één security operations centre, één set herstelregelingen, die elke gereguleerde entiteit in de groep bedienen. De efficiëntieredenering hiervoor is precies het gevaar ervan. Hetzelfde enkele platform dat eenmalig goedkoper te bouwen en gemakkelijker te beveiligen is, is ook één enkel punt waarvan de storing wordt gedeeld door allen die ervan afhangen. Waar een gefedereerde groep van dochterondernemingen die elk hun eigen ICT draaien storingen één voor één, onafhankelijk, zou lijden, lijdt een gecentraliseerde groep ze gezamenlijk, omdat de storingen een gemeenschappelijke oorzaak hebben.

Dit is het onderscheid tussen onafhankelijk en gemeenschappelijke-oorzaakfalen dat de literatuur over veiligheid en systeemrisico allang benadrukt (Perrow, 1999; Leveson, 2011; ESRB, 2022). Onafhankelijke storingen diversifiëren: de kans dat er vele tegelijk vallen is het product van kleine kansen, en verdwijnend klein. Gemeenschappelijke-oorzaakstoringen diversifiëren niet: wanneer de gedeelde oorzaak faalt, faalt alles stroomafwaarts ervan samen, en de weerbaarheid van de groep wordt begrensd door de weerbaarheid van haar zwakste gedeelde component, niet verbeterd door het aantal entiteiten dat de last spreidt. Het concentreren van de ICT spreidt het risico niet over de dochterondernemingen; het koppelt de dochterondernemingen aan één enkel risico. De volgende paragraaf maakt het punt precies.

4. Een minimaal model van gecorreleerd groepsrisico

Het model is een schets, bedoeld om het mechanisme expliciet te maken en een groep over haar eigen mate van centralisatie te laten redeneren, geen gekalibreerde risicoschatting. Het scheidt de storing die een dochteronderneming op zichzelf lijdt van de storing die de hele groep gezamenlijk lijdt, en laat zien hoe centralisatie risico van de eerste soort naar de tweede verplaatst.

4.1 Aantasting per entiteit

Beschouw een groep van $n$ gereguleerde dochterondernemingen. Een aandeel $c$ daarvan, dat wij zullen behandelen als de kans dat een willekeurige dochteronderneming voor een kritieke of belangrijke functie afhangt van de gedeelde kern van de holding, is aangesloten op de kern; noem $c$ de centralisatieratio. In een gegeven periode lijdt de gedeelde kern een kritieke verstoring met kans $p_0$. Dit is een gebeurtenis met een gemeenschappelijke oorzaak: wanneer zij zich voordoet, wordt elke aangesloten dochteronderneming op hetzelfde moment, om dezelfde reden, aangetast. Onafhankelijk van de kern faalt de eigen lokale ICT van elke dochteronderneming in de periode met kans $q$. Een aangesloten dochteronderneming wordt daarom aangetast wanneer ofwel de kern ofwel haar eigen lokale ICT faalt,

wat het cijfer is dat het bestuur van één dochteronderneming ziet wanneer het naar zijn eigen incidentregistratie kijkt. De centralisatie die de dochteronderneming op een goed gedraaide kern aansluit neigt ertoe $q$ te verlagen, omdat een professioneel gedeeld platform doorgaans beter wordt gedraaid dan een klein lokaal, zodat $u$ kan dalen naarmate de groep centraliseert. Entiteit voor entiteit bekeken verbetert centralisatie de weerbaarheid, en dit is de eerlijke helft van de efficiëntieredenering.

4.2 Van onafhankelijk naar gecorreleerd

De groep ervaart haar risico niet entiteit voor entiteit. Wat telt voor de groep, en voor de toezichthouders, is de kans dat meerdere dochterondernemingen tegelijkertijd worden aangetast, want dat is de gebeurtenis die systemisch, grensoverschrijdend en gelijktijdig rapporteerbaar is. Zonder een gedeelde kern is de enige manier waarop twee dochterondernemingen samen vallen dat twee ervan toevallig in dezelfde periode lokaal falen, een samenloop van onafhankelijke gebeurtenissen waarvan de kans van de orde $q^{2}$ is, dat wil zeggen tweede-orde klein. Met een gedeelde kern haalt één enkele kernverstoring elke aangesloten dochteronderneming tegelijk onderuit, zodat de kans op een gelijktijdige gebeurtenis met meerdere entiteiten van de orde is van de eigen faalkans van de kern,

waarbij de uitdrukking tussen haken de kans is dat ten minste twee van de $n$ dochterondernemingen zijn aangesloten, zodat een kernstoring er ten minste twee tegelijk aantast. Het punt is niet de precieze vorm maar de orde: centralisatie zet de kans op een groepsbrede gebeurtenis om van tweede-orde in een kleine lokale kans naar eerste-orde in de kans van de kern. Een kern die slechts zelden faalt, is als bron van gelijktijdig falen van meerdere entiteiten nog altijd veel gevaarlijker dan de som van de onafhankelijke risico’s van de dochterondernemingen, omdat haar storingen gedeeld worden in plaats van gespreid. Figuur 2 tekent deze kans tegen de centralisatieratio voor de twee architecturen: een gefedereerde groep, met elke dochteronderneming op haar eigen ICT, houdt haar vlak bij nul, terwijl die van een gecentraliseerde groep van die basislijn af omhoog klimt naarmate meer van de groep op de gedeelde kern wordt aangesloten.

4.3 De vermenigvuldiger van de regulatoire last

Er is een tweede gevolg van de gebeurtenis met gemeenschappelijke oorzaak dat specifiek is voor DORA en voor de groepsstructuur, en het betreft niet de weerbaarheid maar de rapportage. Omdat elke dochteronderneming een afzonderlijke gereguleerde entiteit is die verantwoording aflegt aan haar eigen bevoegde autoriteit (paragraaf 2.2), genereert één enkele kernstoring niet één incidentrapport; zij genereert er één van elke dochteronderneming die zij aantast, elk aan een andere autoriteit, elk op de klok van die autoriteit, mogelijk in de taal van die autoriteit. Het verwachte aantal gelijktijdige meldingen van ernstige incidenten dat door één kernverstoring wordt uitgelokt is simpelweg het verwachte aantal aangesloten dochterondernemingen,

zodat een groep van een dozijn dochterondernemingen die volledig op een gedeelde kern is aangesloten, één enkele technische gebeurtenis verandert in een dozijn parallelle regulatoire meldingen in een dozijn jurisdicties, binnen DORA’s deadline voor het initiële rapport, alle beschrijvend dezelfde grondoorzaak. Deze vermenigvuldiger van de regulatoire last is onzichtbaar in de planning van één dochteronderneming en wordt pas zichtbaar op groepsniveau, wat juist het niveau is dat DORA geen enkele entiteit verantwoordelijk maakt. Het is het sterkste praktische argument voor de coördinatie op groepsniveau die paragraaf 9 opbouwt.

5. Het register, concentratie en contracten

DORA’s hoofdstuk over derden geeft de gecentraliseerde groep drie instrumenten die zij moet gebruiken, en elk ervan, eerlijk toegepast, brengt de bovenstaande problemen aan het licht in plaats van ze te verbergen.

Het informatieregister (art. 28(3)) is een inventaris van elke contractuele regeling voor ICT-diensten, bijgehouden volgens een standaardsjabloon dat is vastgesteld door uitvoeringstechnische normen (ITS 2024/2956) en dat de regelingen die kritieke of belangrijke functies ondersteunen onderscheidt van die welke dat niet doen. Voor een gecentraliseerde groep is het register de plek waar de intragroepsafhankelijkheid onloochenbaar wordt: het register van elke dochteronderneming vermeldt de holding als een verlener van haar kritieke diensten, en het geconsolideerde register dat de groep moet samenstellen (art. 28(3)) laat op één pagina zien dat één dienstverlener achter de kritieke functies van de hele groep zit. Een groep die het register naar behoren invult heeft haar eigen concentratie gedocumenteerd; een groep die in de verleiding komt de intragroepsregeling eruit te laten, in de veronderstelling dat zij intern is, schendt zowel de registerverplichting als verblindt zichzelf voor juist het risico dat het register bestaat om te tonen. Tabel 1 zet de drie niveaus uiteen waarop het register wordt bijgehouden en waarvoor elk dient.

De beoordeling van het concentratierisico (art. 29) stelt vervolgens de vraag die het register oproept: wat gebeurt er als deze dienstverlener faalt of moet worden vervangen? Voor een externe dienstverlener is het antwoord een substitutieanalyse; voor de intragroepskern is het lastiger, omdat de kern meestal op geen enkele redelijke termijn vervangbaar is, aangezien zij eenmalig voor de hele groep is gebouwd. DORA verbiedt concentratie niet, maar zij vereist dat de entiteit haar ziet en afweegt, en het eerlijke antwoord van een gecentraliseerde groep, dat de kern een enkel storingspunt voor de groep is en op korte termijn feitelijk onvervangbaar, is zelf de bevinding die de weerbaarheidsinvestering en de exitplanning zou moeten aandrijven die de regeling eveneens vereist (art. 28(8)).

De contractuele regelingen (art. 30) zijn het mechanisme waarmee de dochteronderneming macht verwerft over een kern die zij niet bezit. DORA schrijft een ondergrens aan bepalingen voor elke regeling voor en een langere lijst voor regelingen die kritieke of belangrijke functies ondersteunen: volledige beschrijvingen van serviceniveaus, locaties van dienst en data, rechten op toegang, inspectie en audit, verplichtingen tot bijstand bij incidenten, samenwerking met de autoriteiten, rechten op monitoring, voorwaarden aan onderaanneming (nu uitgewerkt door RTS 2025/532) en gedocumenteerde exitstrategieën (art. 28(8), 30(2)–(3)). De intragroepscontext versoepelt hier niets van. De ontwerpinstructie, hieronder uitgewerkt, is het intragroepscontract te schrijven alsof de wederpartij een externe leverancier op arm’s length was, omdat dat de enige manier is waarop het bestuur van de dochteronderneming op papier de rechten krijgt die de asymmetrie het anders ontzegt.

6. Eén incident, vele toezichthouders

Het regime voor incidentrapportage is waar de vermenigvuldiger van de regulatoire last uit paragraaf 4 een operationeel probleem wordt. DORA vereist dat een entiteit een ICT-gerelateerd incident classificeert aan de hand van geharmoniseerde criteria, en, indien het ernstig is, haar bevoegde autoriteit informeert met een initieel rapport op een korte deadline, dan een tussentijds rapport naarmate het beeld steviger wordt, dan een definitief rapport met de grondoorzaak (art. 18–19). De classificatiecriteria, de drempels en de sjablonen zijn door de hele Unie geharmoniseerd via niveau 2-regels, wat een hulp is; maar de rapporten gaan nog altijd naar de eigen autoriteit van elke entiteit, en de klok begint voor elke entiteit te lopen wanneer die entiteit zich bewust wordt.

Voor een gecentraliseerde groep is één enkele kernstoring tegelijkertijd een ernstig incident voor elke dochteronderneming die zij aantast. Elke dochteronderneming moet het classificeren, elke moet beslissen of het de ernstdrempel overschrijdt, en elke moet binnen de deadline melden bij haar eigen autoriteit. Als de dochterondernemingen onafhankelijk classificeren en onafhankelijk opstellen, produceert de groep een verstrooiing van rapporten die dezelfde gebeurtenis inconsistent beschrijven, op verschillende tijdstippen arriveren, en de groep blootstellen aan de voor de hand liggende toezichtsvraag waarom haar entiteiten het oneens zijn over wat er met hun gedeelde systeem gebeurde. De faalmodus is niet onderrapportage maar incoherente overrapportage. De remedie is niet de rapportage te centraliseren, wat DORA niet toestaat, aangezien de verplichting die van elke entiteit is, maar de feiten te centraliseren: één incidenttaxonomie, één vaststelling van de grondoorzaak en één klok, gedraaid vanuit het security operations centre van de groep, die een consistente kern van feiten voeden in de eigen melding van elke dochteronderneming, die de eigen verantwoordelijke functie van elke dochteronderneming vervolgens in eigendom heeft, ondertekent en indient bij haar eigen autoriteit. De groep levert de waarheid; elke entiteit levert de melding. Paragraaf 9 maakt dit concreet.

7. Het testen van een gedeelde kern

DORA’s testregime heeft twee niveaus, en de groepsstructuur compliceert beide. Het basisniveau vereist dat elke entiteit een programma van weerbaarheidstests draait, evenredig aan haar omvang en risico (art. 24–25). Het geavanceerde niveau vereist dreigingsgestuurde penetratietests, ongeveer om de drie jaar, voor die entiteiten die de autoriteiten significant genoeg achten om dat te rechtvaardigen (art. 26–27). In een gecentraliseerde groep is het object dat het testen waard is grotendeels de gedeelde kern, want dat is waar de kritieke systemen en de concentratie zitten; maar de plicht om te testen rust op de dochterondernemingen, die de kern niet draaien.

Dezelfde gedeelde kern afzonderlijk testen voor elke dochteronderneming zou verspillend en, erger nog, riskant zijn, aangezien herhaald live red-teamen van een productieplatform dat de hele groep bedient de kans vergroot dat een test zelf een incident veroorzaakt. DORA anticipeert op gedeelde dienstverleners en staat, onder voorwaarden, toe dat tests worden gebundeld of gezamenlijk worden uitgevoerd waar meerdere entiteiten op dezelfde ICT-dienstverlener leunen of tot dezelfde groep behoren en systemen delen, zodat één naar behoren bestuurde test van de gedeelde kern aan de deelnemende entiteiten kan voldoen (art. 26–27 en de technische normen voor TLPT). Bundeling lost de individuele verplichting niet op: elke deelnemende dochteronderneming moet nog steeds partij zijn bij de regeling, moet nog steeds waarborgen dat de test haar eigen kritieke functies bestrijkt, en moet nog steeds naar de bevindingen handelen. Maar zij laat de groep toe het ding te testen dat er werkelijk toe doet, de kern, één keer en goed, in plaats van vele keren en slecht. De ontwerpimplicatie is dat de groep het testen vanuit de kern naar buiten moet plannen, de kritieke functies van elke dochteronderneming in de gedeelde test moet opnemen, en de contractuele rechten (art. 30) moet aanhouden die een dochteronderneming toelaten haar dienstverlener, hier haar eigen moederonderneming, tot deelname te verplichten.

8. Verantwoording die niet naar boven kan worden gedelegeerd

De draad die door elke paragraaf loopt is DORA’s aandrang dat het leidinggevend orgaan van elke entiteit de uiteindelijke verantwoordelijkheid draagt voor het ICT-risico van die entiteit, en dat deze verantwoordelijkheid niet contractueel of door delegatie kan worden weggegeven (art. 5). In een gecentraliseerde groep is dit de bepaling die het meest op gespannen voet staat met de operationele realiteit, want de realiteit is dat de dochterondernemingen de ICT in wezen aan de groep hebben gedelegeerd. DORA verbiedt de groep niet de ICT centraal te draaien; wat zij verbiedt is dat het bestuur van de dochteronderneming die regeling behandelt als een reden om op te houden verantwoordelijk te zijn. Het bestuur moet voldoende begrip behouden van de kern waarvan het afhangt, voldoende informatie over hoe zij wordt gedraaid en hoe zij faalt, en voldoende contractuele en governancemacht om aan te vechten en, in het uiterste geval, te handelen, zodat zijn wettelijke verantwoordelijkheid echt is in plaats van nominaal.

Dit snijdt tegen een natuurlijk en doorgaans welgemeend centraliserend instinct in, namelijk de besturen van de dochterondernemingen de technische details te besparen en de experts in het centrum het te laten afhandelen. DORA vereist het tegendeel: dat elk bestuur van een dochteronderneming toegerust en verplicht is een risico te besturen dat het aan zijn eigen moederonderneming heeft uitbesteed. De praktische gevolgen zijn een rapportagelijn van de groeps-ICT-functie naar elk bestuur van een dochteronderneming, niet alleen naar dat van de moederonderneming; ICT-risicogeletterdheid op bestuursniveau bij elke dochteronderneming, niet alleen in het centrum; en een groepskader dat zo is ontworpen dat het toezicht van elk bestuur een echt beheersingspunt is. Een groep die de gedeelde kern bouwt maar de besturen van de dochterondernemingen ongeïnformeerd laat heeft de asymmetrie tussen naleving en zeggenschap in haar gevaarlijkste vorm gecreëerd, waar de mensen die in rechte verantwoordelijk zijn feitelijk het minst in staat zijn de verantwoordelijkheid uit te oefenen.

9. Een doeloperatiemodel voor de groep

Het ontwerp dat de twee problemen beantwoordt is niet de ICT te decentraliseren, wat de efficiëntie zou weggooien en, volgens het model van paragraaf 4, de groepsweerbaarheid misschien niet eens zou verbeteren zodra de gedeelde kern goed wordt gedraaid. Het is de centrale kern te behouden en haar in te pakken in de structuur die DORA vereist, zodat de plicht en de zeggenschap door governance en contract worden herverbonden in plaats van door eigendom. Vijf zetten volgen uit de analyse.

Draai één groepskader voor ICT-risico, zichtbaar voor elk bestuur. Bouw het kader voor ICT-risicobeheer één keer, op groepsniveau, volgens de norm die DORA en haar RTS vereisen (art. 6; RTS 2024/1774), maar bedraad de rapportage ervan naar het leidinggevend orgaan van elke dochteronderneming en niet alleen naar dat van de moederonderneming, zodat elk bestuur het gedeelde risico bestuurt met echte informatie. Het kader is centraal; de verantwoording blijft verdeeld, zoals de regeling eist.

Contracteer met de moederonderneming alsof zij een leverancier was. Geef elke intragroepslevering van een kritieke of belangrijke functie een schriftelijk contract dat de volledige bepalingen van artikel 30 draagt, rechten op toegang en audit, plichten tot incidentbijstand en samenwerking, voorwaarden aan onderaanneming en een gedocumenteerde exitstrategie, precies zoals een dochteronderneming aan een externe cloudaanbieder zou opleggen. De formaliteit is geen bureaucratische overlast; zij is het instrument dat de papieren verantwoordelijkheid van de dochteronderneming omzet in echte macht over de kern.

Houd een geconsolideerd register bij en lees het als een risicokaart. Onderhoud het register op entiteits-, gesubconsolideerd en geconsolideerd niveau (art. 28(3)) en behandel het geconsolideerde beeld niet als een indieningsklus maar als de kaart die de groep van haar eigen concentratie heeft, de input voor de beoordeling van het concentratierisico (art. 29) en voor de weerbaarheidsinvestering die daaruit volgt.

Centraliseer de feiten van een incident, verdeel de melding. Draai één incidenttaxonomie, één grondoorzaakproces en één klok vanuit het security operations centre van de groep, en voed een enkel, consistent verslag van elk kernincident in de eigen rapportage van elke getroffen dochteronderneming, die die dochteronderneming in eigendom heeft en indient bij haar eigen autoriteit (art. 18–19). De groep levert één waarheid; elke entiteit voldoet aan haar eigen verplichting.

Test de kern één keer, voor allen die ervan afhangen. Plan weerbaarheids- en dreigingsgestuurde tests vanuit de gedeelde kern naar buiten, met gebruik van DORA’s bepalingen voor gebundeld en groepstesten (art. 26–27) zodat het ding dat de concentratie draagt naar behoren en zelden wordt getest in plaats van herhaaldelijk en oppervlakkig, met de kritieke functies van elke dochteronderneming erin opgenomen en elke dochteronderneming handelend naar de bevindingen.

Geen van deze maakt centralisatie ongedaan; elk herverbindt een plicht die DORA bij de dochteronderneming legde aan een zeggenschap die de groep in de holding legde. Samen laten zij een groep het platform behouden dat zij één keer bouwde en toch elke gereguleerde entiteit, en elke nationale toezichthouder, de bestuurde, gecontracteerde, gedocumenteerde en geteste relatie geven die de regeling vereist.

10. Bezwaren en weerleggingen

De moederonderneming is geen gereguleerde entiteit, dus DORA is niet op haar van toepassing. Direct, nee; via haar dochterondernemingen, geheel. DORA bereikt de holding als een ICT-dienstverlener binnen de groep door elke dochteronderneming te verplichten haar te besturen, met haar te contracteren en op haar toe te zien (art. 3(20), 30). Een groep die het ontbreken van een vergunning bij de moederonderneming leest als vrijheid van DORA heeft de route van de verplichting verward met haar afwezigheid, en zal de verplichting aantreffen in het register, het contract en de audit van elke dochteronderneming.

Het centraliseren van ICT verbetert de weerbaarheid, dus concentratie is een voordeel, geen risico. Beide zijn waar, wat juist het punt van paragraaf 4 is. Een goed gedraaide gedeelde kern verlaagt de eigen, onafhankelijke faalkans van elke dochteronderneming; zij verhoogt tegelijk de kans op één enkele gecorreleerde gebeurtenis die de hele groep tegelijk aantast. DORA’s concentratiebepalingen (art. 29) bestaan juist omdat het tweede effect echt is en vanuit één entiteit onzichtbaar is. De ontwerptaak is het eerste voordeel te vatten terwijl men het tweede ziet, beprijst en mitigeert, niet te ontkennen dat de afweging bestaat.

Een volledig contract naar artikel 30 opstellen tussen een moederonderneming en haar eigen dochteronderneming is juridisch theater. Dat zou het zijn, als het enige doel van het contract was aan een checklist te voldoen. Zijn werkelijke doel is het bestuur van de dochteronderneming, dat in rechte verantwoordelijk is voor een kern die het niet bezit, afdwingbare rechten op informatie, audit, bijstand en exit over die kern te geven. Zonder die rechten is de wettelijke verantwoordelijkheid van het bestuur (art. 5) nominaal. De formaliteit is het mechanisme dat de verantwoordelijkheid uitoefenbaar maakt, en de intragroepscontext, waar de wederpartij een zusterentiteit met dezelfde uiteindelijke eigenaar is, is precies waar informele regelingen die rechten ongeschreven plegen te laten.

Gebundeld testen laat de groep van de individuele testplicht af. Dat doet het niet. Bundeling (art. 26–27) is een manier om de gedeelde kern efficiënt en veilig te testen, geen manier om de verplichting van een entiteit te kwijten door naar iemand anders’ test te wijzen. Elke deelnemende dochteronderneming blijft individueel verplicht te waarborgen dat haar eigen kritieke functies in scope zijn en naar de bevindingen te handelen; de bundel betreft hoe de test wordt uitgevoerd, niet wiens plicht het is.

11. Beperkingen

Dit is op de praktijk gerichte analyse, en haar beperkingen horen helder te worden benoemd. Het is geen juridisch advies; de bepalende tekst is de verordening en haar niveau 2-handelingen, gelezen met de leidraad van de Europese toezichthoudende autoriteiten en elke relevante nationale bevoegde autoriteit, en de eigen raadsman van een groep moet de algemene structuur hier in kaart brengen op haar specifieke entiteiten, vergunningen en lidstaten. De artikelverwijzingen gelden voor DORA zoals zij begin 2025 luidde, met de toen aangenomen gedelegeerde en uitvoeringshandelingen; het detail van de technische normen, en de toezichtspraktijk daaronder, zal zich blijven ontwikkelen. Het model van paragraaf 4 is een schets waarvan de grootheden helder genoeg zijn gedefinieerd om te meten maar waarvan de functionele vormen en illustratieve waarden zijn gekozen om het mechanisme zichtbaar te maken, niet geschat uit de data van een groep; een groep zou $c$, $p_0$ en $q$ uit haar eigen architectuur en incidenthistorie moeten vullen voordat zij enige conclusie uit de curven trekt. Het paper behandelt ook het gangbare en schone geval van één centrale kern en een heldere scheiding tussen moeder en dochter; echte groepen hebben meerdere kernen, gedeeltelijke centralisatie, tussenliggende holdings, gedeelde externe dienstverleners achter de intragroepsdienstverlener, en functies die in de ene lidstaat kritiek zijn en in een andere niet, elk waarvan het beeld compliceert zonder de twee basisproblemen te veranderen.

12. Conclusie

Een pan-Europese financiële groep die haar kritieke ICT vanuit het centrum draait en haar gereguleerde bedrijvigheid vanaf de randen, heeft de meest verstandige structuur voor efficiëntie gebouwd en de meest ongemakkelijke voor DORA. De regeling bindt elke dochteronderneming afzonderlijk, gaat ervan uit dat elke haar eigen ICT beheerst, en treft in plaats daarvan aan dat één gedeelde kern, geleverd door een moederonderneming die de regeling slechts uit de tweede hand bereikt, ze allemaal beheerst. Twee problemen volgen: de nalevingsplicht ligt waar de zeggenschap niet ligt, en het centraliseren van de ICT concentreert het risico van de groep tot één enkel gecorreleerd punt waarvan de storing elke dochteronderneming tegelijk aantast en aan elke toezichthouder afzonderlijk wordt gerapporteerd. Wij hebben beide uiteengezet, het tweede gemodelleerd om te laten zien dat centralisatie een lagere faalkans per entiteit inruilt voor een hogere groepsbrede gecorreleerde, en het resultaat gelezen tegen DORA’s bepalingen over het register, concentratie, contracten, incidenten, testen en governance.

Het antwoord is niet de centrale kern op te geven maar haar te besturen zoals DORA vereist: één groepskader zichtbaar voor elk bestuur, intragroepscontracten geschreven alsof het om een externe leverancier gaat, een geconsolideerd register gelezen als een concentratiekaart, één set incidentfeiten verdeeld over vele meldingen, en de gedeelde kern één keer getest voor allen die ervan afhangen. Elke zet herverbindt een plicht die de regeling bij de dochteronderneming legde aan een zeggenschap die de groep in de holding legde, zodat het ding dat de groep één keer bouwde compliant kan worden gedraaid door elke entiteit die ervan afhangt. De diepere les is die welke DORA werd geschreven om te onderwijzen: dat operationele weerbaarheid geen eigenschap is van een platform maar van de regelingen eromheen, en dat in een groep die regelingen, niet het organigram, bepalen of één enkel punt van efficiëntie ook één enkel storingspunt is.

Bijlage A. Het model in zijn geheel

Het model van paragraaf 4 gebruikt vier grootheden, die een groep alle uit haar eigen architectuur en incidenthistorie kan schatten. De centralisatieratio $c$ is het aandeel van de gereguleerde dochterondernemingen van de groep waarvan de kritieke of belangrijke functies van de gedeelde kern afhangen; een groep kan het aflezen uit het geconsolideerde register (art. 28(3)) door van haar dochterondernemingen te tellen hoeveel de intragroepskern achter een kritieke functie vermelden. De kernfaalkans $p_0$ is de kans dat de gedeelde kern een verstoring lijdt die ernstig genoeg is om de kritieke functie van een afhankelijke dochteronderneming in een gekozen periode aan te tasten; zij wordt geschat uit de eigen incidentregistratie van de kern, niet uit die van één dochteronderneming. De lokale faalkans $q$ is de overeenkomstige kans voor de eigen, niet-gedeelde ICT van een dochteronderneming. Het aantal $n$ is het aantal gereguleerde dochterondernemingen.

De onafhankelijke basislijn is de vergelijking die de concentratie zichtbaar maakt. Als er geen gedeelde kern was, en elke dochteronderneming onafhankelijk faalde met kans $q$, zou de kans dat ten minste twee dochterondernemingen in dezelfde periode worden aangetast $1-(1-q)^{n}-nq(1-q)^{n-1}$ zijn, wat voor kleine $q$ ongeveer $\binom{n}{2}q^{2}$ is, een tweede-ordegrootheid. Met de gedeelde kern is de leidende term van dezelfde kans $p_0$ maal de kans dat ten minste twee dochterondernemingen zijn aangesloten, een eerste-ordegrootheid in $p_0$. De verhouding tussen de twee is de factor waarmee centralisatie de blootstelling van de groep aan gelijktijdige gebeurtenissen met meerdere entiteiten verhoogt, en zij is groot wanneer $p_0$ niet veel kleiner is dan $q^{2}$, wat vrijwel nooit het geval is. Dit is de formele inhoud van de bewering dat concentratie de dochterondernemingen aan één enkel risico koppelt in plaats van het risico over hen te spreiden.

Twee valkuilen verdienen vermelding. De eerste is het schatten van $p_0$ uit de ervaring van één dochteronderneming met de kern, wat het onderschat, omdat een gegeven dochteronderneming alleen die kernincidenten ziet die haar toevallig aantastten; $p_0$ moet worden afgelezen uit de eigen registratie van de kern over alle afhankelijken. De tweede is het behandelen van $c$ als vast terwijl het een beslissing is: de groep kiest, functie voor functie, hoeveel op de kern wordt aangesloten, en de waarde van het model ligt in het tonen van de kosten, in gecorreleerd groepsbreed risico, van elk increment van die keuze, zodat de keuze wordt gemaakt met de afweging van Figuur 2 in het vizier in plaats van op efficiëntiegronden alleen.

Bijlage B. Een checklist van intragroeps-contractbepalingen

De onderstaande checklist verzamelt de bepalingen van artikel 30 die een dochteronderneming zou moeten zekerstellen in haar contract voor de intragroepslevering van een kritieke of belangrijke functie. Het is geen vervanging voor de verordening of voor juridisch advies; het is een werklijst voor het ontwerpgesprek tussen de centrale IT-functie van een groep en haar besturen van dochterondernemingen. Elke bepaling is er een die de dochteronderneming nodig heeft om, over een kern die zij niet bezit, een plicht te kwijten die DORA bij haar legt; de intragroepscontext is waar elk het vaakst impliciet wordt gelaten en in plaats daarvan zou moeten worden opgeschreven.

Referenties

European Union (2022). Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (Digital Operational Resilience Act). Official Journal of the European Union, L 333, 1–79. https://eur-lex.europa.eu/eli/reg/2022/2554/oj

European Commission (2024). Commission Delegated Regulation (EU) 2024/1774 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying ICT risk management tools, methods, processes and policies and the simplified ICT risk management framework. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj

European Commission (2024). Commission Delegated Regulation (EU) 2024/1773 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards on the policy on contractual arrangements on the use of ICT services supporting critical or important functions. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj

European Commission (2024). Commission Delegated Regulation (EU) 2024/1502 supplementing Regulation (EU) 2022/2554 with regard to criteria for the designation of ICT third-party service providers as critical for financial entities. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2024/1502/oj

European Commission (2024). Commission Implementing Regulation (EU) 2024/2956 laying down implementing technical standards for the application of Regulation (EU) 2022/2554 with regard to the standard templates for the register of information. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj

European Commission (2025). Commission Delegated Regulation (EU) 2025/532 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying the elements a financial entity must determine and assess when subcontracting ICT services supporting critical or important functions. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2025/532/oj

European Supervisory Authorities (EBA, EIOPA and ESMA) (2024). Final report on draft regulatory technical standards on subcontracting under Article 30(5) of Regulation (EU) 2022/2554 (JC 2024 53). Joint Committee of the European Supervisory Authorities. https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024_53_Final_report_DORA_RTS_on_subcontracting.pdf

Basel Committee on Banking Supervision (2021). Principles for operational resilience. Bank for International Settlements. https://www.bis.org/bcbs/publ/d516.htm

Financial Stability Board (2019). Third-party dependencies in cloud services: Considerations on financial stability implications. https://www.fsb.org/2019/12/third-party-dependencies-in-cloud-services-considerations-on-financial-stability-implications/

Financial Stability Board (2023). Enhancing third-party risk management and oversight: A toolkit for financial institutions and financial authorities. https://www.fsb.org/2023/12/enhancing-third-party-risk-management-and-oversight-a-toolkit/

European Systemic Risk Board (2022). Mitigating systemic cyber risk. European Systemic Risk Board. https://www.esrb.europa.eu/pub/pdf/reports/esrb.SystemicCyberRisk220127~b6655fa027.en.pdf

European Banking Authority (2019). Guidelines on outsourcing arrangements (EBA/GL/2019/02). https://www.eba.europa.eu/regulation-and-policy/internal-governance/guidelines-on-outsourcing-arrangements

European Union Agency for Cybersecurity (ENISA) (2023). ENISA threat landscape 2023. https://www.enisa.europa.eu/publications/enisa-threat-landscape-2023

Perrow, C. (1999). Normal accidents: Living with high-risk technologies (Updated ed.). Princeton University Press. ISBN 978-0-691-00412-9.

Leveson, N. G. (2011). Engineering a safer world: Systems thinking applied to safety. MIT Press. ISBN 978-0-262-01662-9.

Kaufman, G. G., & Scott, K. E. (2003). What is systemic risk, and do bank regulators retard or contribute to it? The Independent Review, 7(3), 371–391. https://www.independent.org/pdf/tir/tir_07_3_scott.pdf