1. Introduktion

En stor finansiel koncern, der opererer på tværs af Den Europæiske Union, opererer sjældent som én juridisk enhed. Den opererer som et moderselskab og en vifte af datterselskaber, typisk ét reguleret selskab pr. medlemsstat, hvert med sin egen licens, hvert underlagt sin egen nationale tilsynsmyndighed, hvert formet af de lokale regler oven på de fælles europæiske. Grunden er dels historisk, dels regulatorisk og dels kommerciel: licenser er nationale, tilsynsmyndigheder er nationale, og en lokal enhed med et lokalt navn og en lokal balance er lettere at autorisere, at føre tilsyn med og at sælge igennem. Det, koncernen derimod næsten altid centraliserer, er informationsteknologien. Det er spild at bygge den samme kernebankplatform, det samme policy-administrationssystem, det samme datacenter, det samme security operations centre elleve gange, så koncernen bygger dem én gang, i moderselskabet eller i et dedikeret koncern-IT-selskab, og leverer dem til hvert datterselskab som en fælles tjeneste. Forretningen er lokal; rørføringen er central.

Digital Operational Resilience Act skærer tværs igennem denne ordning på en måde, der er let at overse, indtil den implementeres. DORA, Regulation (EU) 2022/2554, har været gældende siden 17. januar 2025, og dens grundlæggende enhed er den enkelte regulerede enhed, ikke koncernen (DORA, Arts 1–2). Hvert datterselskab skal selv opretholde en ramme for IKT-risikostyring, klassificere og indberette sine egne større hændelser, teste sin egen modstandsdygtighed, føre sit eget register over IKT-tredjeparter og føre tilsyn med dem under sin egen bestyrelse (DORA, Arts 5–30). Forordningen tager sig ikke af, at datterselskabet ikke byggede den platform, det kører på, og ikke kan ændre den; pligten er datterselskabets uanset. Og når koncernen vender sig mod den enhed, der byggede platformen, moderselskabet, opdager den, at DORA allerede har navngivet relationen: et koncernselskab, der leverer IKT til de regulerede enheder i sin egen koncern, er en koncernintern IKT-tjenesteyder, og DORA behandler det, til næsten ethvert formål, som en tredjepart (DORA, Art 3(20)).

To problemer følger heraf, og de er emnet for dette papir. Det første er et misforhold mellem, hvor pligten ligger, og hvor kontrollen ligger. DORA lægger pligten på datterselskabet og efterlader kontrollen hos holdingselskabet, og holdingselskabet er, hvis det ikke selv er en reguleret finansiel enhed, uden for forordningens direkte rækkevidde, berørt kun gennem de kontrakter og det tilsyn, dets datterselskaber er forpligtet til at pålægge det. Vi kalder dette compliance-kontrol-asymmetrien, og afsnit 3.1 anatomiserer den. Det andet er, at centralisering af IKT’en koncentrerer risikoen. En fælles kerne er et enkelt punkt, hvis svigt ikke er ét datterselskabs problem, men hvert datterselskabs problem på én gang, en korreleret fælles-mode-hændelse snarere end en uafhængig, spredbar, og fordi hvert ramt datterselskab skal indberette til sin egen tilsynsmyndighed, bliver ét teknisk svigt til en vifte af samtidige regulatoriske indgivelser på tværs af Unionen. Afsnit 3.2 opstiller dette, og afsnit 4 modellerer det.

Bidraget er en diagnose og et design, ikke en juridisk kommentar. Vi fremlægger de to strukturelle problemer tydeligt, giver en lille kvantitativ model af koncentrationsproblemet, så en koncern kan se, hvordan dens grad af centralisering afvejer pålidelighed pr. enhed mod koncernomfattende korreleret risiko (afsnit 4), og gennemgår, hvad DORA’s vigtigste forpligtelser — registeret og kontrakterne (afsnit 5), hændelsesindberetning (afsnit 6), test (afsnit 7) og governance (afsnit 8) — kræver af en centraliseret koncern i særdeleshed. Afsnit 9 foreslår en måldriftsmodel, der opfylder forordningen, samtidig med at den bevarer den effektivitet, der fik koncernen til at centralisere i første omgang. Afsnit 10 til 12 besvarer indvendinger, angiver begrænsninger og konkluderer. Spørgsmålet gennem det hele er: hvordan overholder en koncern, enhed for enhed, en forordning, der antager, at hver enhed kontrollerer sin egen IKT, når i virkeligheden én fælles kerne kontrollerer dem alle?

2. Hvad DORA kræver, og af hvem

2.1 De fem søjler

DORA organiserer en finansiel enheds operationelle modstandsdygtighed i fem områder, og det er værd at nævne dem én gang, fordi koncernproblemet berører alle fem. Det første er IKT-risikostyring (Chapter II, Arts 5–16): en governance- og kontrolramme, ejet af ledelsesorganet, der dækker identifikation, beskyttelse, detektion, respons og genopretning, med en lettere, forenklet ramme tilgængelig for visse mindre enheder (Art 16). Det andet er håndtering og indberetning af IKT-relaterede hændelser (Chapter III, Arts 17–23): en proces til at detektere og håndtere hændelser, en harmoniseret klassificering af deres alvor (Art 18) og en forpligtelse til at indberette større hændelser til den kompetente myndighed efter en fast tidsplan med indledende, mellemliggende og endelige rapporter (Art 19). Det tredje er test af digital operationel modstandsdygtighed (Chapter IV, Arts 24–27): et program for regelmæssig test for hver enhed og avanceret trusselsbaseret penetrationstest (TLPT) mindst hvert tredje år for dem, myndighederne udpeger som betydelige (Arts 26–27). Det fjerde er styring af IKT-tredjepartsrisiko (Chapter V, Arts 28–44), som er dér, koncernstrukturen bider hårdest, og som vi behandler udførligt nedenfor. Det femte er informationsdeling om cybertrusler (Chapter VI, Art 45), som er frivillig og ikke behøver at opholde os her.

2.2 Enhedsprincippet

Det træk ved DORA, der styrer alt i dette papir, er, at dens forpligtelser knytter sig til den enkelte autoriserede enhed. En bankkoncern er ikke autoriseret; dens bankdatterselskaber er. DORA’s anvendelsesbestemmelse opregner de typer finansielle enheder, den binder, og hver er en enhed, der har en licens (Art 2). Konsekvensen er, at compliance vurderes, og håndhæves, én enhed ad gangen, af den enheds egen kompetente myndighed. Der er ingen koncernlicens til at overholde reglerne på datterselskabernes vegne og ingen enkelt europæisk tilsynsmyndighed, som koncernen som helhed svarer over for for sin modstandsdygtighed. Informationsregisteret er det ene sted, hvor koncerndimensionen er eksplicit: en enhed skal føre det ikke kun på sit eget niveau, men, hvor den er en del af en koncern, også på delkonsolideret og konsolideret niveau (Art 28(3)), så en konsoliderende enhed samler et koncernomfattende overblik. Men pligten til at overholde reglerne, at føre tilsyn, at indberette og at teste forbliver det enkelte datterselskabs og kan ikke opfyldes ved at pege opad mod moderselskabet.

2.3 Koncernintern IKT er tredjeparts-IKT

Det andet træk, der styrer dette papir, er DORA’s behandling af IKT leveret inden fra koncernen. Det ville være naturligt at antage, at tjenester, et datterselskab modtager fra sit eget moderselskab, er interne og uden for det tredjepartsregime, DORA retter mod eksterne leverandører. DORA lukker den antagelse af. Den definerer en koncernintern IKT-tjenesteyder som en virksomhed, der er en del af koncernen og leverer IKT-tjenester overvejende til enheder i samme koncern (Art 3(20)), og den bringer en sådan tjenesteyder ind under tredjepartsreglerne: det modtagende datterselskab skal registrere ordningen i sit register (Art 28(3)), føre tilsyn med den under en skriftlig kontrakt med de obligatoriske bestemmelser (Art 30), vurdere den koncentration, den skaber (Art 29), og have exitordninger for den, hvor den understøtter en kritisk eller vigtig funktion (Art 28(8)). Den koncerninterne karakter af relationen er noget, der skal registreres, ikke en grund til fritagelse. Kort sagt: når moderselskabet leverer platformen, læser DORA moderselskabet som en tredjepartstjenesteyder og datterselskabet som dets kunde, med alle de forpligtelser, en kunde hos en ekstern cloud- eller softwareleverandør ville bære. En koncern, der behandler relationen som et rent internt anliggende, styret af et servicekatalog og en koncernintern viderefakturering snarere end en DORA-kompatibel kontrakt, er ikke compliant.

3. Det centraliserede holding-mønster

Figur 1 tegner det mønster, dette papir handler om. Et holding- eller koncern-IT-selskab driver den kritiske IKT-kerne og leverer den til flere regulerede datterselskaber, hvert i sin egen medlemsstat og hvert under tilsyn af sin egen nationale kompetente myndighed. Tjenestepilene løber nedad fra kernen; pilene for tilsyn og hændelsesindberetning løber fra hvert datterselskab til dets egen myndighed. De to problemer fra indledningen er synlige i billedet: det, der binder koncernen sammen, kernen, leveres af en enhed, som regulatorerne kun når indirekte, og et svigt i toppen af diagrammet forplanter sig til hver gren på én gang, mens indberetningen fragmenteres på tværs af hver myndighed i bunden.

3.1 Compliance-kontrol-asymmetrien

I en lærebogsenhed driver det firma, der bærer DORA-pligten, også systemerne, så pligten og de håndtag, der skal opfylde den, er i de samme hænder. Den centraliserede koncern trækker dem fra hinanden. Datterselskabet bærer pligten, fordi det er den autoriserede enhed, men det driver ikke kernen, kan ikke patche den, kan ikke vælge dens arkitektur, kan ikke fastsætte dens genopretningsmål og kan ikke, på egen hånd, teste den. Holdingselskabet driver kernen og besidder alle disse håndtag, men det bærer ingen direkte DORA-pligt, hvis det ikke selv er en autoriseret finansiel enhed, hvilket et rent IT- eller holdingselskab som regel ikke er. Forordningen forudser netop dette og går uden om det: den når holdingselskabet gennem datterselskabet ved at kræve, at datterselskabet, ved kontrakt, pålægger de rettigheder til adgang, revision, samarbejde, hændelsesunderretning, test og exit, der lader datterselskabet opfylde en pligt over systemer, det ikke ejer (Art 30). Datterselskabets compliance afhænger derfor af dets kontraktlige magt over sit eget moderselskab, hvilket er en usædvanlig og ubehagelig ting at skulle udøve.

Asymmetrien har en skarp praktisk kant. Et datterselskabs bestyrelse får af DORA at vide, at den i sidste ende er ansvarlig for enhedens IKT-risiko og ikke kan delegere det ansvar (Art 5(2)); og dog løber bestyrelsens reelle indflydelse på den kerne, der bærer det meste af den risiko, gennem en koncernfunktion, der rapporterer til moderselskabet, ikke til den. Hvis bestyrelsen blot stoler på centret, har den i substansen delegeret det, den ikke må delegere i retten. Hvis den forsøger at udøve ægte tilsyn, har den brug for information, assurance og rettigheder, som en afslappet koncernintern relation ikke giver. Designsvaret, udviklet i afsnit 9, er at give relationen den formalitet, den ville have med en ekstern leverandør, netop for at datterselskabets bestyrelse kan se ind i og udfordre kernen, og at bygge koncernrammen, så hver bestyrelses tilsyn er et reelt input snarere end en høflighed.

3.2 Koncentrationsrisiko

Det andet problem er, at den fælles kerne er en koncentration. DORA navngiver koncentrationsrisiko direkte og kræver, at hver enhed vurderer den før indgåelse af kontrakt og holder den under løbende revision, eksplicit inklusive risikoen fra koncerninterne ordninger og fra tjenesteydere, der er svære at erstatte (Art 29). I en centraliseret koncern er koncentrationen næsten total: én kerne, ét security operations centre, ét sæt genopretningsordninger, der betjener hver reguleret enhed i koncernen. Effektivitetsargumentet for dette er præcis dets fare. Den samme enkelte platform, der er billigere at bygge og lettere at sikre én gang, er også et enkelt punkt, hvis svigt deles af alle, der afhænger af den. Hvor en fødereret koncern af datterselskaber, der hver driver sin egen IKT, ville lide svigt ét ad gangen, uafhængigt, lider en centraliseret koncern dem sammen, fordi svigtene har en fælles årsag.

Dette er sondringen mellem uafhængigt og fælles-mode-svigt, som sikkerheds- og systemisk-risiko-litteraturen længe har insisteret på (Perrow, 1999; Leveson, 2011; ESRB, 2022). Uafhængige svigt spredes: chancen for, at mange falder på én gang, er produktet af små sandsynligheder og forsvindende lille. Fælles-mode-svigt spredes ikke: når den fælles årsag svigter, svigter alt nedstrøms for den sammen, og koncernens modstandsdygtighed er begrænset af modstandsdygtigheden af dens svageste fælles komponent, ikke forbedret af antallet af enheder, der fordeler belastningen. At koncentrere IKT’en spreder ikke risikoen på tværs af datterselskaberne; den kobler datterselskaberne til en enkelt risiko. Næste afsnit gør pointen præcis.

4. En minimal model af korreleret koncernrisiko

Modellen er en skitse, der skal gøre mekanismen eksplicit og lade en koncern ræsonnere om sin egen grad af centralisering, ikke et kalibreret risikoestimat. Den adskiller det svigt, et datterselskab lider på egen hånd, fra det svigt, hele koncernen lider sammen, og viser, hvordan centralisering flytter risiko fra den første slags til den anden.

4.1 Svækkelse pr. enhed

Betragt en koncern af $n$ regulerede datterselskaber. En andel $c$ af dem, som vi vil behandle som sandsynligheden for, at et givet datterselskab afhænger af holdingselskabets fælles kerne for en kritisk eller vigtig funktion, er koblet til kernen; kald $c$ for centraliseringsforholdet. I en given periode lider den fælles kerne en kritisk forstyrrelse med sandsynlighed $p_0$. Dette er en fælles-mode-hændelse: når den indtræffer, svækkes hvert koblet datterselskab i samme øjeblik, af samme grund. Uafhængigt af kernen svigter hvert datterselskabs egen lokale IKT i perioden med sandsynlighed $q$. Et koblet datterselskab svækkes derfor, når enten kernen eller dets egen lokale IKT svigter,

hvilket er det tal, en enkelt datterselskabsbestyrelse ser, når den ser på sin egen hændelsesoptegnelse. Den centralisering, der kobler datterselskabet til en velkørt kerne, har tendens til at sænke $q$, fordi en professionel fælles platform som regel drives bedre end en lille lokal, så $u$ kan falde, efterhånden som koncernen centraliserer. Set én enhed ad gangen forbedrer centralisering modstandsdygtigheden, og dette er den ærlige halvdel af effektivitetsargumentet.

4.2 Fra uafhængig til korreleret

Koncernen oplever ikke sin risiko én enhed ad gangen. Det, der betyder noget for koncernen, og for regulatorerne, er chancen for, at flere datterselskaber svækkes på samme tid, fordi det er den hændelse, der er systemisk, grænseoverskridende og samtidigt indberetningspligtig. Uden en fælles kerne er den eneste måde, hvorpå to datterselskaber falder sammen, hvis to af dem tilfældigvis svigter lokalt i samme periode, et sammentræf af uafhængige hændelser, hvis sandsynlighed er af størrelsesordenen $q^{2}$, altså andenordens lille. Med en fælles kerne tager en enkelt kerneforstyrrelse hvert koblet datterselskab ned på én gang, så sandsynligheden for en samtidig hændelse med flere enheder er af størrelsesordenen af kernens egen svigtsandsynlighed,

hvor parentesen er sandsynligheden for, at mindst to af de $n$ datterselskaber er koblet, så et kernesvigt svækker mindst to på én gang. Pointen er ikke den præcise form, men størrelsesordenen: centralisering konverterer sandsynligheden for en koncernomfattende hændelse fra andenorden i en lille lokal sandsynlighed til førsteorden i kernens sandsynlighed. En kerne, der kun svigter sjældent, er stadig, som kilde til samtidigt svigt med flere enheder, langt farligere end summen af datterselskabernes uafhængige risici, fordi dens svigt deles snarere end spredes. Figur 2 tegner denne sandsynlighed mod centraliseringsforholdet for de to arkitekturer: en fødereret koncern, med hvert datterselskab på sin egen IKT, holder den flad tæt på nul, mens den for en centraliseret koncern stiger væk fra den grundlinje, efterhånden som mere af koncernen kobles til den fælles kerne.

4.3 Den regulatoriske belastningsmultiplikator

Der er en anden konsekvens af fælles-mode-hændelsen, der er specifik for DORA og for koncernstrukturen, og den vedrører ikke modstandsdygtighed, men indberetning. Fordi hvert datterselskab er en separat reguleret enhed, der svarer over for sin egen kompetente myndighed (afsnit 2.2), genererer et enkelt kernesvigt ikke én hændelsesrapport; det genererer én fra hvert datterselskab, det svækker, hver til en forskellig myndighed, hver på den myndigheds ur, muligvis på den myndigheds sprog. Det forventede antal samtidige rapporter om større hændelser udløst af én kerneforstyrrelse er blot det forventede antal koblede datterselskaber,

så en koncern af et dusin datterselskaber fuldt koblet til en fælles kerne forvandler en enkelt teknisk hændelse til et dusin parallelle regulatoriske indgivelser i et dusin jurisdiktioner, inden for DORA’s frist for den indledende rapport, alle beskrivende den samme grundårsag. Denne regulatoriske belastningsmultiplikator er usynlig i ethvert enkelt datterselskabs planlægning og bliver kun synlig på koncernniveau, hvilket er præcis det niveau, DORA ikke gør en enkelt enhed ansvarlig for. Det er det stærkeste praktiske argument for den koordinering på koncernniveau, som afsnit 9 bygger.

5. Registeret, koncentrationen og kontrakterne

DORA’s tredjepartskapitel giver den centraliserede koncern tre instrumenter, den skal bruge, og hvert af dem, anvendt ærligt, bringer problemerne ovenfor frem snarere end at skjule dem.

Informationsregisteret (Art 28(3)) er en fortegnelse over enhver kontraktlig ordning om IKT-tjenester, ført efter en standardskabelon fastsat af gennemførelsesmæssige tekniske standarder (ITS 2024/2956) og med skelnen mellem de ordninger, der understøtter kritiske eller vigtige funktioner, og dem, der ikke gør. For en centraliseret koncern er registeret dér, hvor den koncerninterne afhængighed bliver unægtelig: hvert datterselskabs register opfører holdingselskabet som leverandør af sine kritiske tjenester, og det konsoliderede register, koncernen skal samle (Art 28(3)), viser, på en enkelt side, at én leverandør sidder bag hele koncernens kritiske funktioner. En koncern, der udfylder registeret ordentligt, har dokumenteret sin egen koncentration; en koncern, der fristes til at udelade den koncerninterne ordning, ud fra teorien om, at den er intern, både overtræder registerforpligtelsen og blinder sig selv for netop den risiko, registeret findes for at vise. Tabel 1 opstiller de tre niveauer, registeret føres på, og hvad hvert er til.

Koncentrationsrisikovurderingen (Art 29) stiller derefter det spørgsmål, registeret rejser: hvad sker der, hvis denne leverandør svigter eller skal erstattes? For en ekstern leverandør er svaret en substitutionsanalyse; for den koncerninterne kerne er det sværere, fordi kernen som regel slet ikke kan substitueres inden for nogen rimelig horisont, idet den er bygget én gang for hele koncernen. DORA forbyder ikke koncentration, men den kræver, at enheden ser den og vejer den, og en centraliseret koncerns ærlige svar — at kernen er et enkelt svigtpunkt for koncernen og reelt uerstattelig på kort sigt — er i sig selv det fund, der bør drive den investering i modstandsdygtighed og den exitplanlægning, forordningen også kræver (Art 28(8)).

De kontraktlige ordninger (Art 30) er den mekanisme, hvorved datterselskabet erhverver magt over en kerne, det ikke ejer. DORA foreskriver et minimum af bestemmelser for enhver ordning og en længere liste for ordninger, der understøtter kritiske eller vigtige funktioner: fulde beskrivelser af serviceniveauer, placeringer af tjeneste og data, rettigheder til adgang, inspektion og revision, forpligtelser til at bistå ved hændelser, samarbejde med myndighederne, rettigheder til at overvåge, betingelser for underleverance (nu detaljeret af RTS 2025/532) og dokumenterede exitstrategier (Arts 28(8), 30(2)–(3)). Den koncerninterne kontekst slækker intet af dette. Designinstruksen, udviklet nedenfor, er at skrive den koncerninterne kontrakt, som om modparten var en ekstern leverandør på armslængde, fordi det er den eneste måde, datterselskabets bestyrelse får, på papiret, de rettigheder, asymmetrien ellers nægter den.

6. Én hændelse, mange regulatorer

Hændelsesindberetningsregimet er dér, hvor den regulatoriske belastningsmultiplikator fra afsnit 4 bliver et operationelt problem. DORA kræver, at en enhed klassificerer en IKT-relateret hændelse op imod harmoniserede kriterier, og, hvis den er større, underretter sin kompetente myndighed med en indledende rapport på en kort frist, derefter en mellemliggende rapport, efterhånden som billedet fæstner sig, derefter en endelig rapport med grundårsag (Arts 18–19). Klassificeringskriterierne, tærsklerne og skabelonerne er harmoniserede på tværs af Unionen ved niveau 2-regler, hvilket er en hjælp; men rapporterne går stadig til hver enheds egen myndighed, og uret starter for hver enhed, når den enhed bliver opmærksom.

For en centraliseret koncern er et enkelt kernesvigt samtidig en større hændelse for hvert datterselskab, det svækker. Hvert datterselskab skal klassificere det, hvert skal afgøre, om det krydser tærsklen for en større hændelse, og hvert skal indgive, til sin egen myndighed, inden for fristen. Hvis datterselskaberne klassificerer uafhængigt og udarbejder uafhængigt, producerer koncernen en spredning af rapporter, der beskriver den samme hændelse inkonsekvent, ankommer på forskellige tidspunkter og udsætter koncernen for det oplagte tilsynsspørgsmål om, hvorfor dens enheder er uenige om, hvad der skete med deres fælles system. Fejltilstanden er ikke underindberetning, men usammenhængende overindberetning. Afhjælpningen er ikke at centralisere indberetningen, hvilket DORA ikke tillader, da forpligtelsen er hver enheds, men at centralisere fakta: én hændelsestaksonomi, én grundårsagsbestemmelse og ét ur ført fra koncernens security operations centre, der føder en konsistent kerne af fakta ind i hvert datterselskabs egen indgivelse, som hvert datterselskabs egen ansvarlige funktion så ejer, underskriver og indsender til sin egen myndighed. Koncernen leverer sandheden; hver enhed leverer indgivelsen. Afsnit 9 gør dette konkret.

7. At teste en fælles kerne

DORA’s testregime har to niveauer, og koncernstrukturen komplicerer begge. Grundniveauet kræver, at hver enhed kører et program af modstandsdygtighedstest, proportionalt med sin størrelse og risiko (Art 24–25). Det avancerede niveau kræver trusselsbaseret penetrationstest, nogenlunde hvert tredje år, for de enheder, myndighederne identificerer som betydelige nok til at berettige det (Arts 26–27). I en centraliseret koncern er det objekt, der er værd at teste, i vid udstrækning den fælles kerne, fordi det er dér, de kritiske systemer og koncentrationen er; men forpligtelsen til at teste påhviler datterselskaberne, som ikke driver kernen.

At teste den samme fælles kerne separat for hvert datterselskab ville være spild og, værre, risikabelt, da gentaget live red-teaming af en produktionsplatform, der betjener hele koncernen, mangedobler chancen for, at en test selv forårsager en hændelse. DORA forudser fælles leverandører og tillader, under betingelser, at test samles eller udføres fælles, hvor flere enheder afhænger af den samme IKT-leverandør eller tilhører samme koncern og deler systemer, så én ordentligt styret test af den fælles kerne kan opfylde de deltagende enheder (Arts 26–27 og de tekniske standarder for TLPT). Sammenlægning opløser ikke den individuelle forpligtelse: hvert deltagende datterselskab skal stadig være part i ordningen, skal stadig sikre, at testen dækker dets egne kritiske funktioner, og skal stadig handle på fundene. Men den lader koncernen teste det, der faktisk betyder noget, kernen, én gang og godt, snarere end mange gange og dårligt. Designimplikationen er, at koncernen bør planlægge test fra kernen og udad, afgrænse hvert datterselskabs kritiske funktioner ind i den fælles test og besidde de kontraktlige rettigheder (Art 30), der lader et datterselskab kræve, at dets leverandør, her dets eget moderselskab, deltager.

8. Ansvarlighed, der ikke kan delegeres opad

Tråden, der løber gennem hvert afsnit, er DORA’s insisteren på, at hver enheds ledelsesorgan bærer det endelige ansvar for den enheds IKT-risiko, og at dette ansvar ikke kan kontraheres eller delegeres væk (Art 5). I en centraliseret koncern er dette den bestemmelse, der er mest i spænding med den operationelle virkelighed, fordi virkeligheden er, at datterselskaberne i substansen har delegeret IKT’en til koncernen. DORA forbyder ikke koncernen at drive IKT’en centralt; det, den forbyder, er, at datterselskabsbestyrelsen behandler den ordning som en grund til at holde op med at være ansvarlig. Bestyrelsen skal bevare tilstrækkelig forståelse af den kerne, den afhænger af, tilstrækkelig information om, hvordan den drives, og hvordan den svigter, og tilstrækkelig kontraktlig og governance-mæssig magt til at udfordre og, i yderste fald, at handle, så dens lovbestemte ansvar er reelt snarere end nominelt.

Dette strider mod en naturlig og som regel velment centraliseringstilbøjelighed, nemlig at skåne datterselskabsbestyrelserne for de tekniske detaljer og lade eksperterne i centret håndtere det. DORA kræver det modsatte: at hver datterselskabsbestyrelse er udrustet og forpligtet til at føre tilsyn med en risiko, den har outsourcet til sit eget moderselskab. De praktiske konsekvenser er en rapporteringslinje fra koncern-IKT-funktionen ind i hver datterselskabsbestyrelse, ikke kun ind i moderselskabets; IKT-risikokyndighed på bestyrelsesniveau i hvert datterselskab, ikke kun i centret; og en koncernramme designet, så hver bestyrelses tilsyn er et ægte kontrolpunkt. En koncern, der bygger den fælles kerne, men efterlader datterselskabsbestyrelserne uinformerede, har skabt compliance-kontrol-asymmetrien i dens farligste form, hvor de mennesker, der er ansvarlige i retten, i virkeligheden er de mindst i stand til at udøve ansvaret.

9. En måldriftsmodel for koncernen

Det design, der svarer på de to problemer, er ikke at decentralisere IKT’en, hvilket ville smide effektiviteten væk og, efter modellen i afsnit 4, måske ikke engang forbedre koncernens modstandsdygtighed, når først den fælles kerne drives godt. Det er at bevare den centrale kerne og pakke den ind i den struktur, DORA kræver, så pligten og kontrollen genforbindes af governance og kontrakt snarere end af ejerskab. Fem træk følger af analysen.

Kør én koncern-IKT-risikoramme, synlig for hver bestyrelse. Byg rammen for IKT-risikostyring én gang, på koncernniveau, til den standard DORA og dens RTS kræver (Art 6; RTS 2024/1774), men kobl dens rapportering ind i hvert datterselskabs ledelsesorgan og ikke kun ind i moderselskabets, så hver bestyrelse fører tilsyn med den fælles risiko med reel information. Rammen er central; ansvarligheden forbliver fordelt, som forordningen kræver.

Kontrahér med moderselskabet, som om det var en leverandør. Giv enhver koncernintern levering af en kritisk eller vigtig funktion en skriftlig kontrakt, der bærer de fulde Article 30-bestemmelser, rettigheder til adgang og revision, pligter til hændelsesbistand og samarbejde, betingelser for underleverance og en dokumenteret exitstrategi, præcis som et datterselskab ville pålægge en ekstern cloud-leverandør. Formaliteten er ikke bureaukratisk overhead; den er det instrument, der konverterer datterselskabets papiransvar til reel magt over kernen.

Før et konsolideret register, og læs det som et risikokort. Vedligehold registeret på enheds-, delkonsolideret og konsolideret niveau (Art 28(3)), og behandl det konsoliderede overblik ikke som en indberetningspligt, men som koncernens kort over sin egen koncentration, inputtet til koncentrationsrisikovurderingen (Art 29) og til den investering i modstandsdygtighed, der følger af den.

Centralisér fakta om en hændelse, fordel indgivelsen. Kør én hændelsestaksonomi, én grundårsagsproces og ét ur fra koncernens security operations centre, og fød en enkelt, konsistent redegørelse for enhver kernehændelse ind i hvert ramt datterselskabs egen indberetning, som det datterselskab ejer og indgiver til sin egen myndighed (Arts 18–19). Koncernen leverer én sandhed; hver enhed opfylder sin egen forpligtelse.

Test kernen én gang, for alle, der afhænger af den. Planlæg modstandsdygtigheds- og trusselsbaseret test fra den fælles kerne og udad, ved at bruge DORA’s bestemmelser om samlet og koncernvis test (Arts 26–27), så det, der bærer koncentrationen, testes ordentligt og sjældent snarere end gentagne gange og tyndt, med hvert datterselskabs kritiske funktioner afgrænset ind og hvert datterselskab handlende på fundene.

Ingen af disse ophæver centralisering; hver genforbinder en pligt, DORA lagde på datterselskabet, til en kontrol, koncernen lagde i holdingselskabet. Tilsammen lader de en koncern beholde den platform, den byggede én gang, og alligevel give hver reguleret enhed, og hver national tilsynsmyndighed, den styrede, kontraherede, dokumenterede og testede relation, forordningen kræver.

10. Indvendinger og svar

Moderselskabet er ikke en reguleret enhed, så DORA gælder ikke for det. Direkte, nej; gennem dets datterselskaber, fuldstændigt. DORA når holdingselskabet som en koncernintern IKT-tjenesteyder ved at forpligte hvert datterselskab til at føre tilsyn med, kontrahere med og overvåge det (Arts 3(20), 30). En koncern, der læser moderselskabets mangel på en licens som frihed fra DORA, har forvekslet forpligtelsens rute med dens fravær og vil finde forpligtelsen ventende i hvert datterselskabs register, kontrakt og revision.

Centralisering af IKT forbedrer modstandsdygtigheden, så koncentration er en egenskab, ikke en risiko. Begge er sande, hvilket er pointen i afsnit 4. En velkørt fælles kerne sænker hvert datterselskabs egen, uafhængige svigtsandsynlighed; den hæver samtidig sandsynligheden for en enkelt korreleret hændelse, der svækker hele koncernen på én gang. DORA’s koncentrationsbestemmelser (Art 29) findes netop, fordi den anden effekt er reel og er usynlig indefra enhver enkelt enhed. Designopgaven er at indfange den første fordel, mens man ser, prissætter og afbøder den anden, ikke at benægte, at afvejningen eksisterer.

At skrive en fuld Article 30-kontrakt mellem et moderselskab og dets eget datterselskab er legalistisk teater. Det ville det være, hvis kontraktens eneste formål var at opfylde en tjekliste. Dens reelle formål er at give datterselskabets bestyrelse, der i retten er ansvarlig for en kerne, den ikke ejer, håndhævelige rettigheder til information, revision, bistand og exit over den kerne. Uden dem er bestyrelsens lovbestemte ansvar (Art 5) nominelt. Formaliteten er den mekanisme, der gør ansvaret udøveligt, og den koncerninterne kontekst, hvor modparten er en søsterenhed med samme endelige ejer, er netop dér, hvor uformelle ordninger har tendens til at efterlade de rettigheder uskrevne.

Samlet test lader koncernen slippe fri af den individuelle testforpligtelse. Det gør den ikke. Sammenlægning (Arts 26–27) er en måde at teste den fælles kerne effektivt og sikkert på, ikke en måde at opfylde en enheds forpligtelse ved at pege på en andens test. Hvert deltagende datterselskab forbliver individuelt forpligtet til at sikre, at dets egne kritiske funktioner er i scope, og til at handle på fundene; sammenlægningen vedrører, hvordan testen køres, ikke hvis pligt det er.

11. Begrænsninger

Dette er analyse henvendt til praktikere, og dens grænser bør angives tydeligt. Det er ikke juridisk rådgivning; den styrende tekst er forordningen og dens niveau 2-retsakter, læst med vejledningen fra de europæiske tilsynsmyndigheder og hver relevant national kompetent myndighed, og en koncerns egen juridiske rådgiver skal kortlægge den generelle struktur her til dens specifikke enheder, licenser og medlemsstater. Artikelhenvisningerne er til DORA, som den stod i begyndelsen af 2025, med de delegerede og gennemførelsesmæssige retsakter, der da var vedtaget; detaljen i de tekniske standarder, og tilsynspraksis under dem, vil fortsætte med at udvikle sig. Modellen i afsnit 4 er en skitse, hvis størrelser er defineret tydeligt nok til at måle, men hvis funktionelle former og illustrative værdier er valgt for at gøre mekanismen synlig, ikke estimeret ud fra en koncerns data; en koncern bør udfylde $c$, $p_0$ og $q$ ud fra sin egen arkitektur og hændelseshistorik, før den drager nogen konklusion af kurverne. Papiret behandler også det almindelige og rene tilfælde af en enkelt central kerne og en klar opdeling mellem moder- og datterselskab; virkelige koncerner har flere kerner, delvis centralisering, mellemliggende holdingselskaber, fælles eksterne leverandører bag den koncerninterne og funktioner, der er kritiske i én medlemsstat og ikke i en anden, hvoraf hver især komplicerer billedet uden at ændre dets to grundlæggende problemer.

12. Konklusion

En paneuropæisk finansiel koncern, der driver sin kritiske IKT fra centret og sin regulerede forretning fra kanterne, har bygget den mest fornuftige struktur for effektivitet og den mest akavede for DORA. Forordningen binder hvert datterselskab individuelt, antager, at hvert kontrollerer sin egen IKT, og finder i stedet, at én fælles kerne, leveret af et moderselskab, forordningen kun når i anden hånd, kontrollerer dem alle. To problemer følger: pligten til at overholde reglerne ligger dér, hvor kontrollen ikke gør, og centralisering af IKT’en koncentrerer koncernens risiko i et enkelt korreleret punkt, hvis svigt svækker hvert datterselskab på én gang og indberettes til hver tilsynsmyndighed separat. Vi har opstillet begge, modelleret det andet for at vise, at centralisering bytter en lavere svigtsandsynlighed pr. enhed for en højere koncernomfattende korreleret, og læst resultatet op imod DORA’s bestemmelser om register, koncentration, kontrakt, hændelser, test og governance.

Svaret er ikke at opgive den centrale kerne, men at føre tilsyn med den, som DORA kræver: én koncernramme synlig for hver bestyrelse, koncerninterne kontrakter skrevet som over for en ekstern leverandør, et konsolideret register læst som et koncentrationskort, ét sæt hændelsesfakta fordelt ind i mange indgivelser, og den fælles kerne testet én gang for alle, der afhænger af den. Hvert træk genforbinder en pligt, forordningen lagde på datterselskabet, til en kontrol, koncernen lagde i holdingselskabet, så det, koncernen byggede én gang, kan drives compliant af hver enhed, der afhænger af den. Den dybere lektion er den, DORA blev skrevet for at lære: at operationel modstandsdygtighed ikke er en egenskab ved en platform, men ved ordningerne omkring den, og at i en koncern er det de ordninger, ikke organisationsdiagrammet, der afgør, om et enkelt effektivitetspunkt også er et enkelt svigtpunkt.

Bilag A. Modellen i sin helhed

Modellen i afsnit 4 bruger fire størrelser, som en koncern alle kan estimere ud fra sin egen arkitektur og hændelseshistorik. Centraliseringsforholdet $c$ er den andel af koncernens regulerede datterselskaber, hvis kritiske eller vigtige funktioner afhænger af den fælles kerne; en koncern kan aflæse det fra det konsoliderede register (Art 28(3)) ved at tælle, af sine datterselskaber, hvor mange der opfører den koncerninterne kerne bag en kritisk funktion. Kernesvigtsandsynligheden $p_0$ er sandsynligheden for, at den fælles kerne lider en forstyrrelse, der er alvorlig nok til at svække et afhængigt datterselskabs kritiske funktion i en valgt periode; den estimeres ud fra kernens egen hændelsesoptegnelse, ikke ud fra noget enkelt datterselskabs. Den lokale svigtsandsynlighed $q$ er den tilsvarende sandsynlighed for et datterselskabs egen, ikke-fælles IKT. Antallet $n$ er antallet af regulerede datterselskaber.

Den uafhængige baseline er den sammenligning, der gør koncentrationen synlig. Hvis der ikke var nogen fælles kerne, idet hvert datterselskab svigter uafhængigt med sandsynlighed $q$, ville sandsynligheden for, at mindst to datterselskaber blev svækket i samme periode, være $1-(1-q)^{n}-nq(1-q)^{n-1}$, hvilket for små $q$ er omtrent $\binom{n}{2}q^{2}$, en andenordens størrelse. Med den fælles kerne er den ledende term i den samme sandsynlighed $p_0$ gange chancen for, at mindst to datterselskaber er koblet, en førsteordens størrelse i $p_0$. Forholdet mellem de to er den faktor, hvormed centralisering hæver koncernens eksponering mod samtidige hændelser med flere enheder, og den er stor, når som helst $p_0$ ikke er meget mindre end $q^{2}$, hvilket den næsten aldrig er. Dette er det formelle indhold af påstanden om, at koncentration kobler datterselskaberne til en enkelt risiko snarere end at sprede risikoen på tværs af dem.

To faldgruber fortjener en bemærkning. Den første er at estimere $p_0$ ud fra et enkelt datterselskabs erfaring med kernen, hvilket undervurderer det, fordi et givet datterselskab kun ser de kernehændelser, der tilfældigvis svækkede det; $p_0$ skal aflæses fra kernens egen optegnelse på tværs af alle afhængige. Den anden er at behandle $c$ som fast, når det er en beslutning: koncernen vælger, funktion for funktion, hvor meget der skal kobles til kernen, og modellens værdi ligger i at vise omkostningen, i korreleret koncernomfattende risiko, ved hvert trin i det valg, så valget træffes med afvejningen i figur 2 for øje snarere end på effektivitetsgrundlag alene.

Bilag B. En tjekliste over koncerninterne kontraktbestemmelser

Tjeklisten nedenfor samler de Article 30-bestemmelser, et datterselskab bør sikre sig i sin kontrakt om den koncerninterne levering af en kritisk eller vigtig funktion. Den er ikke en erstatning for forordningen eller for juridisk rådgivning; den er en arbejdsliste til designsamtalen mellem en koncerns centrale IT-funktion og dens datterselskabsbestyrelser. Hver bestemmelse er en, datterselskabet har brug for for at kunne opfylde, over en kerne det ikke ejer, en pligt DORA lægger på det; den koncerninterne kontekst er dér, hvor hver oftest efterlades implicit og i stedet bør skrives ned.

Referencer

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