1. Innledning

Et stort finanskonsern som opererer på tvers av Den europeiske union, opererer sjelden som én juridisk enhet. Det opererer som et morselskap og en vifte av datterselskaper, typisk ett regulert selskap per medlemsstat, hvert med sin egen lisens, hvert underlagt sin egen nasjonale tilsynsmyndighet, hvert formet av de lokale reglene oppå de felles europeiske. Grunnen er dels historisk, dels regulatorisk og dels kommersiell: lisenser er nasjonale, tilsynsmyndigheter er nasjonale, og en lokal enhet med et lokalt navn og en lokal balanse er lettere å autorisere, å føre tilsyn med og å selge gjennom. Det konsernet derimot sentraliserer, nesten alltid, er informasjonsteknologien. Det er sløsing å bygge den samme kjernebankplattformen, det samme polisebehandlingssystemet, det samme datasenteret, det samme sikkerhetsoperasjonssenteret elleve ganger, så konsernet bygger dem én gang, i morselskapet eller i et dedikert konsern-IT-selskap, og leverer dem til hvert datterselskap som en fellestjeneste. Forretningen er lokal; rørleggingen er sentral.

Digital Operational Resilience Act skjærer tvers gjennom denne ordningen på en måte som er lett å overse inntil den implementeres. DORA, Regulation (EU) 2022/2554, har gjeldt siden 17. januar 2025, og dens grunnenhet er den enkelte regulerte enheten, ikke konsernet (DORA, Arts 1–2). Hvert datterselskap må selv opprettholde et rammeverk for IKT-risikostyring, klassifisere og rapportere sine egne alvorlige hendelser, teste sin egen motstandsdyktighet, føre sitt eget register over IKT-tredjeparter og styre dem under sitt eget styre (DORA, Arts 5–30). Regelverket bryr seg ikke om at datterselskapet ikke bygde plattformen det kjører på og ikke kan endre den; plikten er datterselskapets uansett. Og når konsernet vender seg til enheten som faktisk bygde plattformen, morselskapet, finner det at DORA allerede har navngitt forholdet: et konsernselskap som leverer IKT til de regulerte enhetene i sitt eget konsern er en konsernintern IKT-tjenesteleverandør, og DORA behandler det, for nesten alle formål, som en tredjepart (DORA, Art 3(20)).

To problemer følger, og de er temaet for denne artikkelen. Det første er et misforhold mellom hvor plikten ligger og hvor kontrollen ligger. DORA legger plikten på datterselskapet og lar kontrollen bli igjen hos holdingselskapet, og holdingselskapet er, hvis det ikke selv er en regulert finansiell enhet, utenfor regelverkets direkte rekkevidde, berørt bare gjennom kontraktene og tilsynet datterselskapene er forpliktet til å pålegge det. Vi kaller dette etterlevelse–kontroll-asymmetrien, og avsnitt 3.1 anatomiserer den. Det andre er at sentraliseringen av IKT-en konsentrerer risikoen. En felles kjerne er et enkeltpunkt hvis svikt ikke er ett datterselskaps problem, men hvert datterselskaps problem samtidig, en korrelert fellesmodushendelse snarere enn en uavhengig, diversifiserbar, og fordi hvert berørt datterselskap må rapportere til sin egen tilsynsmyndighet, blir én teknisk svikt til en vifte av samtidige regulatoriske innmeldinger på tvers av unionen. Avsnitt 3.2 redegjør for dette og avsnitt 4 modellerer det.

Bidraget er en diagnose og et design, ikke en juridisk kommentar. Vi fremstiller de to strukturelle problemene klart, gir en liten kvantitativ modell av konsentrasjonsproblemet slik at et konsern kan se hvordan dets grad av sentralisering veksler per-enhet-pålitelighet mot konsernomfattende korrelert risiko (avsnitt 4), og arbeider oss gjennom hva DORAs hovedforpliktelser, registeret og kontraktene (avsnitt 5), hendelsesrapportering (avsnitt 6), testing (avsnitt 7) og styring (avsnitt 8), krever av et sentralisert konsern spesielt. Avsnitt 9 foreslår en måloperasjonsmodell som tilfredsstiller regelverket samtidig som den beholder effektiviteten som fikk konsernet til å sentralisere i utgangspunktet. Avsnitt 10 til 12 besvarer innvendinger, angir grenser og konkluderer. Spørsmålet gjennomgående er: hvordan etterlever et konsern, enhet for enhet, et regelverk som antar at hver enhet kontrollerer sin egen IKT, når det i virkeligheten er én felles kjerne som kontrollerer dem alle?

2. Hva DORA krever, og av hvem

2.1 De fem pilarene

DORA organiserer den operasjonelle motstandsdyktigheten til en finansiell enhet i fem områder, og det er verdt å nevne dem én gang fordi konsernproblemet berører alle fem. Det første er IKT-risikostyring (Chapter II, Arts 5–16): et styrings- og kontrollrammeverk, eid av ledelsesorganet, som dekker identifisering, beskyttelse, deteksjon, respons og gjenoppretting, med et lettere forenklet rammeverk tilgjengelig for visse mindre enheter (Art 16). Det andre er håndtering og rapportering av IKT-relaterte hendelser (Chapter III, Arts 17–23): en prosess for å oppdage og håndtere hendelser, en harmonisert klassifisering av deres alvorlighetsgrad (Art 18), og en plikt til å rapportere alvorlige hendelser til vedkommende myndighet etter en fast tidsplan med innledende, mellomliggende og endelige rapporter (Art 19). Det tredje er testing av digital operasjonell motstandsdyktighet (Chapter IV, Arts 24–27): et program med regelmessig testing for hver enhet, og avansert trusselbasert penetrasjonstesting (TLPT) minst hvert tredje år for dem myndighetene peker ut som betydelige (Arts 26–27). Det fjerde er styring av IKT-tredjepartsrisiko (Chapter V, Arts 28–44), som er der konsernstrukturen biter hardest, og som vi behandler utførlig nedenfor. Det femte er informasjonsdeling om cybertrusler (Chapter VI, Art 45), som er frivillig og ikke behøver å oppholde oss her.

2.2 Enhetsprinsippet

Trekket ved DORA som styrer alt i denne artikkelen er at dens forpliktelser festes til den enkelte autoriserte enheten. Et bankkonsern er ikke autorisert; dets bankdatterselskaper er det. DORAs virkeområdebestemmelse lister opp hvilke slags finansielle enheter den binder, og hver er en enhet som innehar en lisens (Art 2). Konsekvensen er at etterlevelse vurderes, og håndheves, én enhet om gangen, av den enhetens egen vedkommende myndighet. Det finnes ingen konsernlisens som kan etterleve på vegne av datterselskapene, og ingen enkelt europeisk tilsynsmyndighet som konsernet som helhet svarer overfor for sin motstandsdyktighet. Informasjonsregisteret er det ene stedet konserndimensjonen er eksplisitt: en enhet må føre det ikke bare på sitt eget nivå, men, der den er del av et konsern, også på delkonsolidert og konsolidert nivå (Art 28(3)), slik at en konsoliderende enhet setter sammen et konsernomfattende bilde. Men plikten til å etterleve, å styre, å rapportere og å teste forblir det enkelte datterselskapets, og kan ikke oppfylles ved å peke oppover mot morselskapet.

2.3 Konsernintern IKT er tredjeparts IKT

Det andre trekket som styrer denne artikkelen er DORAs behandling av IKT levert fra innsiden av konsernet. Det ville være naturlig å anta at tjenester et datterselskap mottar fra sitt eget morselskap er interne, og utenfor tredjepartsregimet DORA retter mot eksterne leverandører. DORA stenger den antakelsen ute. Den definerer en konsernintern IKT-tjenesteleverandør som et foretak som er del av konsernet og leverer IKT-tjenester overveiende til enheter i samme konsern (Art 3(20)), og den bringer en slik leverandør inn under tredjepartsreglene: det mottakende datterselskapet må registrere ordningen i sitt register (Art 28(3)), styre den under en skriftlig kontrakt som bærer de obligatoriske bestemmelsene (Art 30), vurdere konsentrasjonen den skaper (Art 29), og ha avviklingsordninger for den der den understøtter en kritisk eller viktig funksjon (Art 28(8)). Den konserninterne karakteren ved forholdet er noe som skal registreres, ikke en grunn til unntak. Kort sagt, når morselskapet leverer plattformen, leser DORA morselskapet som en tredjepartsleverandør og datterselskapet som dets kunde, med alle forpliktelsene som en kunde av en ekstern sky- eller programvareleverandør ville bære. Et konsern som behandler forholdet som en rent intern sak, styrt av en tjenestekatalog og en konsernintern viderefakturering snarere enn en DORA-samsvarende kontrakt, er ikke i samsvar.

3. Det sentraliserte holdingmønsteret

Figur 1 tegner mønsteret denne artikkelen handler om. Et holding- eller konsern-IT-selskap drifter den kritiske IKT-kjernen og leverer den til flere regulerte datterselskaper, hvert i sin egen medlemsstat og hvert underlagt tilsyn av sin egen nasjonale vedkommende myndighet. Tjenestens piler går nedover fra kjernen; pilene for tilsyn og hendelsesrapportering går fra hvert datterselskap til dets egen myndighet. De to problemene fra innledningen er synlige i bildet: det som binder konsernet sammen, kjernen, leveres av en enhet som regulatorene når bare indirekte, og en svikt på toppen av diagrammet forplanter seg til hver gren samtidig, mens rapporteringen fragmenteres på tvers av hver myndighet i bunnen.

3.1 Etterlevelse–kontroll-asymmetrien

I en lærebokenhet drifter selskapet som bærer DORA-plikten også systemene, slik at plikten og spakene for å oppfylle den er i de samme hendene. Det sentraliserte konsernet trekker dem fra hverandre. Datterselskapet bærer plikten, fordi det er den autoriserte enheten, men det drifter ikke kjernen, kan ikke lappe den, kan ikke velge dens arkitektur, kan ikke sette dens gjenopprettingsmål og kan ikke, på egen hånd, teste den. Holdingselskapet drifter kjernen og holder alle disse spakene, men det bærer ingen direkte DORA-plikt hvis det ikke selv er en autorisert finansiell enhet, noe et rent IT- eller holdingselskap vanligvis ikke er. Regelverket forutser nettopp dette og ruter rundt det: det når holdingselskapet gjennom datterselskapet, ved å kreve at datterselskapet pålegger, ved kontrakt, de rettighetene til tilgang, revisjon, samarbeid, hendelsesvarsling, testing og avvikling som lar datterselskapet oppfylle en plikt over systemer det ikke eier (Art 30). Datterselskapets etterlevelse avhenger derfor av dets kontraktsmessige makt over sitt eget morselskap, noe som er en uvanlig og ubehagelig ting å måtte utøve.

Asymmetrien har en skarp praktisk kant. Et datterselskaps styre blir av DORA fortalt at det til syvende og sist er ansvarlig for enhetens IKT-risiko og ikke kan delegere det ansvaret (Art 5(2)); likevel går styrets reelle innflytelse over kjernen som bærer mesteparten av den risikoen gjennom en konsernfunksjon som rapporterer til morselskapet, ikke til det. Hvis styret simpelthen stoler på senteret, har det i substans delegert det det ikke kan delegere i jus. Hvis det forsøker å utøve genuint tilsyn, trenger det informasjon, forsikring og rettigheter som et uformelt konserninternt forhold ikke gir. Designsvaret, utviklet i avsnitt 9, er å gi forholdet den formaliteten det ville hatt med en ekstern leverandør nettopp slik at datterselskapets styre kan se inn i og utfordre kjernen, og å bygge konsernrammeverket slik at hvert styres tilsyn er et reelt innspill snarere enn en høflighet.

3.2 Konsentrasjonsrisiko

Det andre problemet er at den felles kjernen er en konsentrasjon. DORA navngir konsentrasjonsrisiko direkte og krever at hver enhet vurderer den før inngåelse av kontrakt og holder den under oppsyn, og inkluderer eksplisitt risikoen fra konserninterne ordninger og fra leverandører som er vanskelige å erstatte (Art 29). I et sentralisert konsern er konsentrasjonen nær total: én kjerne, ett sikkerhetsoperasjonssenter, ett sett med gjenopprettingsordninger, som betjener hver regulert enhet i konsernet. Effektivitetsargumentet for dette er nettopp dets fare. Den samme enkeltplattformen som er billigere å bygge og lettere å sikre én gang, er også et enkeltpunkt hvis svikt deles av alle som er avhengige av den. Der et føderert konsern av datterselskaper som hvert drifter sin egen IKT ville lide svikt én om gangen, uavhengig, lider et sentralisert konsern dem sammen, fordi sviktene har en felles årsak.

Dette er skillet mellom uavhengig svikt og fellesmodussvikt som sikkerhets- og systemrisikolitteraturen lenge har insistert på (Perrow, 1999; Leveson, 2011; ESRB, 2022). Uavhengige svikt diversifiserer: sjansen for at mange faller samtidig er produktet av små sannsynligheter, og forsvinnende liten. Fellesmodussvikt diversifiserer ikke: når den felles årsaken svikter, svikter alt nedstrøms for den samtidig, og konsernets motstandsdyktighet begrenses av motstandsdyktigheten til dets svakeste delte komponent, ikke forbedret av antallet enheter som sprer lasten. Å konsentrere IKT-en sprer ikke risikoen på tvers av datterselskapene; den kobler datterselskapene til én enkelt risiko. Neste avsnitt gjør poenget presist.

4. En minimal modell av korrelert konsernrisiko

Modellen er en skisse, ment å gjøre mekanismen eksplisitt og å la et konsern resonnere om sin egen grad av sentralisering, ikke et kalibrert risikoanslag. Den skiller sviktet et datterselskap lider på egen hånd fra sviktet hele konsernet lider sammen, og viser hvordan sentralisering flytter risiko fra den første typen til den andre.

4.1 Per-enhet-ramming

Betrakt et konsern av $n$ regulerte datterselskaper. En andel $c$ av dem, som vi vil behandle som sannsynligheten for at et gitt datterselskap er avhengig av holdingselskapets felles kjerne for en kritisk eller viktig funksjon, er koblet til kjernen; kall $c$ sentraliseringsforholdet. I en gitt periode lider den felles kjernen en kritisk forstyrrelse med sannsynlighet $p_0$. Dette er en fellesmodushendelse: når den inntreffer, rammes hvert koblet datterselskap i samme øyeblikk, av samme grunn. Uavhengig av kjernen svikter hvert datterselskaps egen lokale IKT i perioden med sannsynlighet $q$. Et koblet datterselskap rammes derfor når enten kjernen eller dets egen lokale IKT svikter,

som er tallet et enkelt datterselskaps styre ser når det ser på sin egen hendelsesopptegnelse. Sentraliseringen som kobler datterselskapet til en velkjørt kjerne har en tendens til å senke $q$, fordi en profesjonell felles plattform vanligvis drives bedre enn en liten lokal, slik at $u$ kan falle etter hvert som konsernet sentraliserer. Sett én enhet om gangen forbedrer sentralisering motstandsdyktigheten, og dette er den ærlige halvdelen av effektivitetsargumentet.

4.2 Fra uavhengig til korrelert

Konsernet erfarer ikke sin risiko én enhet om gangen. Det som betyr noe for konsernet, og for regulatorene, er sjansen for at flere datterselskaper rammes samtidig, fordi det er hendelsen som er systemisk, grensekryssende og samtidig rapporteringspliktig. Uten en felles kjerne er den eneste måten to datterselskaper faller sammen på at to av dem tilfeldigvis svikter lokalt i samme periode, et sammentreff av uavhengige hendelser hvis sannsynlighet er av orden $q^{2}$, det vil si andreordens liten. Med en felles kjerne tar en enkelt kjerneforstyrrelse ned hvert koblet datterselskap samtidig, slik at sannsynligheten for en samtidig flerenhetshendelse er av størrelsesorden som kjernens egen sviktsannsynlighet,

der klammen er sannsynligheten for at minst to av de $n$ datterselskapene er koblet, slik at en kjernesvikt rammer minst to samtidig. Poenget er ikke den eksakte formen, men ordenen: sentralisering konverterer sannsynligheten for en konsernomfattende hendelse fra andreordens i en liten lokal sannsynlighet til førsteordens i kjernens sannsynlighet. En kjerne som svikter bare sjelden er fremdeles, som en kilde til samtidig flerenhetssvikt, langt farligere enn summen av datterselskapenes uavhengige risikoer, fordi dens svikt deles snarere enn spres. Figur 2 tegner denne sannsynligheten mot sentraliseringsforholdet for de to arkitekturene: et føderert konsern, med hvert datterselskap på sin egen IKT, holder den flat nær null, mens den for et sentralisert konsern stiger bort fra den grunnlinjen etter hvert som mer av konsernet kobles til den felles kjernen.

4.3 Den regulatoriske belastningsmultiplikatoren

Det finnes en andre konsekvens av fellesmodushendelsen som er spesifikk for DORA og for konsernstrukturen, og den gjelder ikke motstandsdyktighet, men rapportering. Fordi hvert datterselskap er en egen regulert enhet som svarer overfor sin egen vedkommende myndighet (avsnitt 2.2), genererer en enkelt kjernesvikt ikke én hendelsesrapport; den genererer én fra hvert datterselskap den rammer, hver til en forskjellig myndighet, hver på den myndighetens klokke, muligens på den myndighetens språk. Det forventede antallet samtidige alvorlig-hendelse-rapporter utløst av én kjerneforstyrrelse er simpelthen det forventede antallet koblede datterselskaper,

slik at et konsern av et dusin datterselskaper fullt koblet til en felles kjerne gjør en enkelt teknisk hendelse om til et dusin parallelle regulatoriske innmeldinger i et dusin jurisdiksjoner, innenfor DORAs frist for innledende rapport, alle som beskriver samme rotårsak. Denne regulatoriske belastningsmultiplikatoren er usynlig i ett enkelt datterselskaps planlegging og blir synlig bare på konsernnivå, som er nettopp det nivået DORA ikke gjør noen enkelt enhet ansvarlig for. Det er det sterkeste praktiske argumentet for koordineringen på konsernnivå som avsnitt 9 bygger.

5. Registeret, konsentrasjonen og kontraktene

DORAs tredjepartskapittel gir det sentraliserte konsernet tre instrumenter det må bruke, og hvert av dem, anvendt ærlig, bringer problemene ovenfor til overflaten snarere enn å skjule dem.

Informasjonsregisteret (Art 28(3)) er en fortegnelse over hver kontraktsmessige ordning for IKT-tjenester, ført etter en standardmal fastsatt av gjennomføringsmessige tekniske standarder (ITS 2024/2956) og som skiller ordningene som understøtter kritiske eller viktige funksjoner fra dem som ikke gjør det. For et sentralisert konsern er registeret der den konserninterne avhengigheten blir ubestridelig: hvert datterselskaps register fører holdingselskapet som en leverandør av dets kritiske tjenester, og det konsoliderte registeret konsernet må sette sammen (Art 28(3)) viser, på en enkelt side, at én leverandør står bak de kritiske funksjonene til hele konsernet. Et konsern som fyller ut registeret ordentlig har dokumentert sin egen konsentrasjon; et konsern som fristes til å utelate den konserninterne ordningen, på den teori at den er intern, både bryter registerplikten og blindes for nettopp den risikoen registeret finnes for å vise. Tabell 1 angir de tre nivåene registeret føres på og hva hvert er til for.

Konsentrasjonsrisikovurderingen (Art 29) stiller så spørsmålet registeret reiser: hva skjer hvis denne leverandøren svikter eller må erstattes? For en ekstern leverandør er svaret en substitusjonsanalyse; for den konserninterne kjernen er det vanskeligere, fordi kjernen vanligvis ikke er substituerbar i det hele tatt på noen rimelig horisont, ettersom den er bygget én gang for hele konsernet. DORA forbyr ikke konsentrasjon, men den krever at enheten ser den og veier den, og et sentralisert konserns ærlige svar, at kjernen er et enkeltpunkt for svikt for konsernet og i praksis uerstattelig på kort sikt, er selv funnet som bør drive motstandsdyktighetsinvesteringen og avviklingsplanleggingen regelverket også krever (Art 28(8)).

De kontraktsmessige ordningene (Art 30) er mekanismen datterselskapet erverver makt over en kjerne det ikke eier gjennom. DORA foreskriver et gulv av bestemmelser for hver ordning og en lengre liste for ordninger som understøtter kritiske eller viktige funksjoner: fulle beskrivelser av tjenestenivå, lokasjoner for tjeneste og data, rettigheter til tilgang, inspeksjon og revisjon, plikter til å bistå ved hendelser, samarbeid med myndighetene, rettigheter til å overvåke, vilkår for underleveranse (nå detaljert av RTS 2025/532) og dokumenterte avviklingsstrategier (Arts 28(8), 30(2)–(3)). Den konserninterne settingen slakker ikke på noe av dette. Designinstruksen, utviklet nedenfor, er å skrive den konserninterne kontrakten som om motparten var en ekstern leverandør på armlengdes avstand, fordi det er den eneste måten datterselskapets styre, på papiret, får rettighetene asymmetrien ellers nekter det.

6. Én hendelse, mange regulatorer

Hendelsesrapporteringsregimet er der den regulatoriske belastningsmultiplikatoren fra avsnitt 4 blir et operasjonelt problem. DORA krever at en enhet klassifiserer en IKT-relatert hendelse mot harmoniserte kriterier, og, hvis den er alvorlig, varsler sin vedkommende myndighet med en innledende rapport på en kort frist, deretter en mellomliggende rapport etter hvert som bildet festner seg, så en endelig rapport med rotårsak (Arts 18–19). Klassifiseringskriteriene, terskelverdiene og malene er harmonisert på tvers av unionen ved nivå 2-regler, noe som er en hjelp; men rapportene går fortsatt til hver enhets egen myndighet, og klokken starter for hver enhet når den enheten blir klar over det.

For et sentralisert konsern er en enkelt kjernesvikt, samtidig, en alvorlig hendelse for hvert datterselskap den rammer. Hvert datterselskap må klassifisere den, hvert må avgjøre om den krysser alvorlighetsterskelen, og hvert må melde inn, til sin egen myndighet, innen fristen. Hvis datterselskapene klassifiserer uavhengig og utformer uavhengig, produserer konsernet en spredning av rapporter som beskriver samme hendelse inkonsistent, ankommer til forskjellige tider, og utsetter konsernet for det åpenbare tilsynsspørsmålet om hvorfor dets enheter er uenige om hva som skjedde med deres delte system. Feilmodusen er ikke underrapportering, men usammenhengende overrapportering. Botemiddelet er ikke å sentralisere rapporteringen, noe DORA ikke tillater, siden plikten er hver enhets, men å sentralisere fakta: én hendelsestaksonomi, én rotårsaksfastsettelse og én klokke drevet fra konsernets sikkerhetsoperasjonssenter, som nærer en konsistent kjerne av fakta inn i hvert datterselskaps egen innmelding, som hvert datterselskaps egen ansvarlige funksjon deretter eier, signerer og sender inn til sin egen myndighet. Konsernet leverer sannheten; hver enhet leverer innmeldingen. Avsnitt 9 gjør dette konkret.

7. Å teste en felles kjerne

DORAs testregime har to nivåer, og konsernstrukturen kompliserer begge. Det grunnleggende nivået krever at hver enhet kjører et program med motstandsdyktighetstester, proporsjonalt med sin størrelse og risiko (Art 24–25). Det avanserte nivået krever trusselbasert penetrasjonstesting, omtrent hvert tredje år, for de enhetene myndighetene identifiserer som betydelige nok til å berettige det (Arts 26–27). I et sentralisert konsern er objektet verdt å teste i stor grad den felles kjernen, fordi det er der de kritiske systemene og konsentrasjonen er; men plikten til å teste ligger på datterselskapene, som ikke drifter kjernen.

Å teste den samme felles kjernen separat for hvert datterselskap ville være sløsing og, verre, risikabelt, siden gjentatt direkte red-teaming av en produksjonsplattform som betjener hele konsernet mangedobler sjansen for at en test selv forårsaker en hendelse. DORA forutser delte leverandører og tillater, på vilkår, at testing samles eller gjennomføres i fellesskap der flere enheter er avhengige av samme IKT-leverandør eller tilhører samme konsern og deler systemer, slik at én riktig styrt test av den felles kjernen kan tilfredsstille de deltakende enhetene (Arts 26–27 og de tekniske standardene for TLPT). Samling oppløser ikke den individuelle plikten: hvert deltakende datterselskap må fortsatt være part i ordningen, må fortsatt sikre at testen dekker dets egne kritiske funksjoner, og må fortsatt handle på funnene. Men den lar konsernet teste det som faktisk betyr noe, kjernen, én gang og godt, snarere enn mange ganger og dårlig. Designimplikasjonen er at konsernet bør planlegge testing fra kjernen og utover, inkludere hvert datterselskaps kritiske funksjoner i den felles testen, og ha de kontraktsmessige rettighetene (Art 30) som lar et datterselskap kreve at dets leverandør, her dets eget morselskap, deltar.

8. Ansvarlighet som ikke kan delegeres oppover

Tråden som løper gjennom hvert avsnitt er DORAs insistering på at ledelsesorganet i hver enhet bærer det endelige ansvaret for den enhetens IKT-risiko, og at dette ansvaret ikke kan kontraktsfestes eller delegeres bort (Art 5). I et sentralisert konsern er dette bestemmelsen som er mest i spenn med driftsvirkeligheten, fordi virkeligheten er at datterselskapene har delegert IKT-en, i substans, til konsernet. DORA forbyr ikke konsernet å drifte IKT-en sentralt; det den forbyr er at datterselskapsstyret behandler den ordningen som en grunn til å slutte å være ansvarlig. Styret må beholde tilstrekkelig forståelse av kjernen det er avhengig av, tilstrekkelig informasjon om hvordan den drives og hvordan den svikter, og tilstrekkelig kontraktsmessig makt og styringsmakt til å utfordre og, i ytterste fall, å handle, slik at dets lovbestemte ansvar er reelt snarere enn nominelt.

Dette strider mot et naturlig og vanligvis velment sentraliseringsinstinkt, som er å spare datterselskapsstyrene for de tekniske detaljene og la ekspertene i senteret håndtere det. DORA krever det motsatte: at hvert datterselskapsstyre utrustes og forpliktes til å styre en risiko det har satt ut til sitt eget morselskap. De praktiske konsekvensene er en rapporteringslinje fra konsernets IKT-funksjon inn i hvert datterselskapsstyre, ikke bare inn i morselskapet; IKT-risikokompetanse på styrenivå ved hvert datterselskap, ikke bare i senteret; og et konsernrammeverk utformet slik at hvert styres tilsyn er et genuint kontrollpunkt. Et konsern som bygger den felles kjernen, men lar datterselskapsstyrene være uinformerte, har skapt etterlevelse–kontroll-asymmetrien i dens farligste form, der menneskene som er ansvarlige i jus er de minst i stand til faktisk å utøve ansvaret.

9. En måloperasjonsmodell for konsernet

Designet som svarer på de to problemene er ikke å desentralisere IKT-en, noe som ville kaste bort effektiviteten og, ifølge modellen i avsnitt 4, kanskje ikke engang forbedre konsernets motstandsdyktighet når den felles kjernen først er velkjørt. Det er å beholde den sentrale kjernen og pakke den inn i strukturen DORA krever, slik at plikten og kontrollen gjenforenes ved styring og kontrakt snarere enn ved eierskap. Fem grep følger av analysen.

Driv ett konsern-IKT-risikorammeverk, synlig for hvert styre. Bygg rammeverket for IKT-risikostyring én gang, på konsernet, til standarden DORA og dens RTS krever (Art 6; RTS 2024/1774), men koble dets rapportering inn i hvert datterselskaps ledelsesorgan og ikke bare inn i morselskapets, slik at hvert styre styrer den delte risikoen med reell informasjon. Rammeverket er sentralt; ansvarligheten forblir distribuert, som regelverket krever.

Kontraktfest med morselskapet som om det var en leverandør. Gi hver konserninterne leveranse av en kritisk eller viktig funksjon en skriftlig kontrakt som bærer de fulle bestemmelsene i Article 30, rettigheter til tilgang og revisjon, plikter til hendelsesbistand og samarbeid, vilkår for underleveranse og en dokumentert avviklingsstrategi, nøyaktig slik et datterselskap ville pålegge en ekstern skyleverandør. Formaliteten er ikke byråkratisk overhead; den er instrumentet som konverterer datterselskapets papiransvar til reell makt over kjernen.

Før et konsolidert register og les det som et risikokart. Vedlikehold registeret på enhets-, delkonsolidert og konsolidert nivå (Art 28(3)) og behandle det konsoliderte bildet ikke som en innmeldingsplikt, men som konsernets kart over sin egen konsentrasjon, innspillet til konsentrasjonsrisikovurderingen (Art 29) og til motstandsdyktighetsinvesteringen som følger av den.

Sentraliser fakta om en hendelse, distribuer innmeldingen. Driv én hendelsestaksonomi, én rotårsaksprosess og én klokke fra konsernets sikkerhetsoperasjonssenter, og mat en enkelt, konsistent redegjørelse for enhver kjernehendelse inn i hvert berørt datterselskaps egen rapportering, som det datterselskapet eier og melder inn til sin egen myndighet (Arts 18–19). Konsernet leverer én sannhet; hver enhet oppfyller sin egen plikt.

Test kjernen én gang, for alle som er avhengige av den. Planlegg motstandsdyktighets- og trusselbasert testing fra den felles kjernen og utover, med DORAs bestemmelser om samlet og konserntesting (Arts 26–27) slik at det som bærer konsentrasjonen testes ordentlig og sjelden snarere enn gjentatte ganger og tynt, med hvert datterselskaps kritiske funksjoner inkludert og hvert datterselskap som handler på funnene.

Ingen av disse opphever sentraliseringen; hvert gjenforener en plikt DORA la på datterselskapet med en kontroll konsernet la i holdingselskapet. Sammen lar de et konsern beholde plattformen det bygget én gang og likevel gi hver regulert enhet, og hver nasjonal tilsynsmyndighet, det styrte, kontraktfestede, dokumenterte og testede forholdet regelverket krever.

10. Innvendinger og svar

Morselskapet er ikke en regulert enhet, så DORA gjelder ikke for det. Direkte, nei; gjennom sine datterselskaper, fullstendig. DORA når holdingselskapet som en konsernintern IKT-tjenesteleverandør ved å forplikte hvert datterselskap til å styre det, inngå kontrakt med det og føre tilsyn med det (Arts 3(20), 30). Et konsern som leser morselskapets mangel på lisens som frihet fra DORA har forvekslet forpliktelsens rute med dens fravær, og vil finne forpliktelsen ventende i hvert datterselskaps register, kontrakt og revisjon.

Sentralisering av IKT forbedrer motstandsdyktigheten, så konsentrasjon er en egenskap, ikke en risiko. Begge er sanne, som er poenget i avsnitt 4. En velkjørt felles kjerne senker hvert datterselskaps egen, uavhengige sviktsannsynlighet; den hever samtidig sannsynligheten for en enkelt korrelert hendelse som rammer hele konsernet samtidig. DORAs konsentrasjonsbestemmelser (Art 29) finnes nettopp fordi den andre effekten er reell og er usynlig fra innsiden av enhver enkelt enhet. Designoppgaven er å fange den første fordelen samtidig som man ser, priser og demper den andre, ikke å benekte at avveiningen finnes.

Å skrive en full Article 30-kontrakt mellom et morselskap og dets eget datterselskap er juridisk teater. Det ville det vært, hvis kontraktens eneste formål var å tilfredsstille en sjekkliste. Dens virkelige formål er å gi datterselskapets styre, som i jus er ansvarlig for en kjerne det ikke eier, håndhevbare rettigheter til informasjon, revisjon, bistand og avvikling over den kjernen. Uten dem er styrets lovbestemte ansvar (Art 5) nominelt. Formaliteten er mekanismen som gjør ansvaret utøvbart, og den konserninterne settingen, der motparten er en søsterenhet med samme endelige eier, er nettopp der uformelle ordninger har en tendens til å la de rettighetene stå uskrevne.

Samlet testing fritar konsernet fra den individuelle testplikten. Det gjør den ikke. Samling (Arts 26–27) er en måte å teste den felles kjernen effektivt og trygt på, ikke en måte å oppfylle en enhets plikt på ved å peke på en annens test. Hvert deltakende datterselskap forblir individuelt forpliktet til å sikre at dets egne kritiske funksjoner er innenfor omfanget og til å handle på funnene; samlingen gjelder hvordan testen kjøres, ikke hvem sin plikt den er.

11. Begrensninger

Dette er praktikerrettet analyse, og dens grenser bør angis klart. Det er ikke juridisk rådgivning; den styrende teksten er Regulation og dens nivå 2-rettsakter, lest sammen med veiledningen fra European Supervisory Authorities og hver relevant nasjonal vedkommende myndighet, og et konserns egne jurister må kartlegge den generelle strukturen her mot sine spesifikke enheter, lisenser og medlemsstater. Artikkelreferansene er til DORA slik den sto tidlig i 2025, med de delegerte og gjennomførende rettsaktene som da var vedtatt; detaljene i de tekniske standardene, og tilsynspraksisen under dem, vil fortsette å utvikle seg. Modellen i avsnitt 4 er en skisse hvis størrelser er definert klart nok til å måles, men hvis funksjonelle former og illustrative verdier er valgt for å gjøre mekanismen synlig, ikke estimert fra et konserns data; et konsern bør fylle inn $c$, $p_0$ og $q$ fra sin egen arkitektur og hendelseshistorikk før det trekker noen konklusjon fra kurvene. Artikkelen behandler også det vanlige og rene tilfellet med én sentral kjerne og en klar mor–datter-deling; virkelige konsern har flere kjerner, delvis sentralisering, mellomliggende holdingselskaper, delte eksterne leverandører bak den konserninterne, og funksjoner som er kritiske i én medlemsstat og ikke i en annen, hvert av dem kompliserer bildet uten å endre dets to grunnleggende problemer.

12. Konklusjon

Et pan-europeisk finanskonsern som drifter sin kritiske IKT fra senteret og sin regulerte virksomhet fra ytterkantene har bygget den mest fornuftige strukturen for effektivitet og den mest kronglete for DORA. Regelverket binder hvert datterselskap individuelt, antar at hvert kontrollerer sin egen IKT, og finner i stedet at én felles kjerne, levert av et morselskap regelverket når bare i annen hånd, kontrollerer dem alle. To problemer følger: plikten til å etterleve ligger der kontrollen ikke gjør det, og sentraliseringen av IKT-en konsentrerer konsernets risiko i et enkelt korrelert punkt hvis svikt rammer hvert datterselskap samtidig og rapporteres til hver tilsynsmyndighet separat. Vi har redegjort for begge, modellert det andre for å vise at sentralisering veksler en lavere per-enhet-sviktsannsynlighet mot en høyere konsernomfattende korrelert, og lest resultatet mot DORAs bestemmelser om register, konsentrasjon, kontrakt, hendelser, testing og styring.

Svaret er ikke å oppgi den sentrale kjernen, men å styre den slik DORA krever: ett konsernrammeverk synlig for hvert styre, konserninterne kontrakter skrevet som om til en ekstern leverandør, et konsolidert register lest som et konsentrasjonskart, ett sett med hendelsesfakta distribuert til mange innmeldinger, og den felles kjernen testet én gang for alle som er avhengige av den. Hvert grep gjenforener en plikt regelverket la på datterselskapet med en kontroll konsernet la i holdingselskapet, slik at det konsernet bygget én gang kan driftes i samsvar av hver enhet som er avhengig av det. Den dypere lærdommen er den DORA ble skrevet for å lære bort: at operasjonell motstandsdyktighet ikke er en egenskap ved en plattform, men ved ordningene rundt den, og at i et konsern er det disse ordningene, ikke eierskapskartet, som avgjør om et enkeltpunkt for effektivitet også er et enkeltpunkt for svikt.

Vedlegg A. Modellen i sin helhet

Modellen i avsnitt 4 bruker fire størrelser, som alle et konsern kan estimere fra sin egen arkitektur og hendelseshistorikk. Sentraliseringsforholdet $c$ er andelen av konsernets regulerte datterselskaper hvis kritiske eller viktige funksjoner er avhengige av den felles kjernen; et konsern kan lese det fra det konsoliderte registeret (Art 28(3)) ved å telle, av sine datterselskaper, hvor mange som fører den konserninterne kjernen bak en kritisk funksjon. Kjernesviktsannsynligheten $p_0$ er sannsynligheten for at den felles kjernen lider en forstyrrelse alvorlig nok til å ramme et avhengig datterselskaps kritiske funksjon i en valgt periode; den estimeres fra kjernens egen hendelsesopptegnelse, ikke fra noe enkelt datterselskaps. Den lokale sviktsannsynligheten $q$ er den tilsvarende sannsynligheten for et datterselskaps egen, ikke-delte IKT. Antallet $n$ er antallet regulerte datterselskaper.

Den uavhengige grunnlinjen er sammenligningen som gjør konsentrasjonen synlig. Hvis det ikke fantes noen felles kjerne, med hvert datterselskap som svikter uavhengig med sannsynlighet $q$, ville sannsynligheten for at minst to datterselskaper ble rammet i samme periode være $1-(1-q)^{n}-nq(1-q)^{n-1}$, som for liten $q$ er omtrent $\binom{n}{2}q^{2}$, en andreordens størrelse. Med den felles kjernen er det ledende leddet i samme sannsynlighet $p_0$ ganger sjansen for at minst to datterselskaper er koblet, en førsteordens størrelse i $p_0$. Forholdet mellom de to er faktoren sentralisering hever konsernets eksponering for samtidige flerenhetshendelser med, og den er stor når som helst $p_0$ ikke er mye mindre enn $q^{2}$, noe den nesten aldri er. Dette er det formelle innholdet i påstanden om at konsentrasjon kobler datterselskapene til én enkelt risiko snarere enn å spre risikoen på tvers av dem.

To fallgruver fortjener omtale. Den første er å estimere $p_0$ fra et enkelt datterselskaps erfaring med kjernen, noe som underrapporterer den, fordi et gitt datterselskap ser bare de kjernehendelsene som tilfeldigvis rammet det; $p_0$ må leses fra kjernens egen opptegnelse på tvers av alle avhengige. Den andre er å behandle $c$ som fast når det er en beslutning: konsernet velger, funksjon for funksjon, hvor mye som skal kobles til kjernen, og modellens verdi ligger i å vise kostnaden, i korrelert konsernomfattende risiko, av hvert trinn i det valget, slik at valget treffes med avveiningen i Figur 2 for øye snarere enn på effektivitetsgrunnlag alene.

Vedlegg B. En sjekkliste for konserninterne kontraktsbestemmelser

Sjekklisten nedenfor samler bestemmelsene i Article 30 som et datterselskap bør sikre seg i sin kontrakt for den konserninterne leveransen av en kritisk eller viktig funksjon. Den er ingen erstatning for Regulation eller for juridisk rådgivning; den er en arbeidsliste for designsamtalen mellom et konserns sentrale IT-funksjon og dets datterselskapsstyrer. Hver bestemmelse er en datterselskapet trenger for å oppfylle, over en kjerne det ikke eier, en plikt DORA legger på det; den konserninterne settingen er der hver oftest etterlates underforstått og i stedet bør skrives ned.

Referanser

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