1. Inledning

En stor finansiell koncern som verkar över hela Europeiska unionen verkar sällan som en enda juridisk person. Den verkar som ett moderbolag och en solfjäder av dotterbolag, vanligen ett reglerat bolag per medlemsstat, vart och ett med sin egen auktorisation, vart och ett som svarar inför sin egen nationella tillsynsmyndighet, vart och ett format av de lokala reglerna ovanpå de gemensamma europeiska. Skälet är delvis historiskt, delvis regulatoriskt och delvis kommersiellt: auktorisationer är nationella, tillsynsmyndigheter är nationella, och en lokal enhet med ett lokalt namn och en lokal balansräkning är lättare att auktorisera, att utöva tillsyn över och att sälja genom. Det koncernen däremot nästan alltid centraliserar är informationstekniken. Det är slöseri att bygga samma centrala banksystem, samma system för försäkringsadministration, samma datacenter, samma säkerhetscenter elva gånger om, så koncernen bygger dem en gång, i moderbolaget eller i ett särskilt koncern-IT-bolag, och levererar dem till varje dotterbolag som en delad tjänst. Verksamheten är lokal; rörmokeriet är centralt.

Förordningen om digital operativ motståndskraft skär tvärs igenom detta upplägg på ett sätt som är lätt att förbise tills den ska införas. DORA, Regulation (EU) 2022/2554, har tillämpats sedan den 17 januari 2025, och dess grundenhet är den enskilda reglerade enheten, inte koncernen (DORA, Arts 1–2). Varje dotterbolag måste självt upprätthålla ett ramverk för IKT-riskhantering, klassificera och rapportera sina egna allvarliga incidenter, testa sin egen motståndskraft, föra sitt eget register över IKT-tredjeparter och styra dem under sin egen styrelse (DORA, Arts 5–30). Förordningen bryr sig inte om att dotterbolaget inte byggde den plattform det driver på och inte kan ändra den; plikten är dotterbolagets likväl. Och när koncernen vänder sig till den enhet som faktiskt byggde plattformen, moderbolaget, finner den att DORA redan har namngett relationen: ett koncernbolag som levererar IKT till de reglerade enheterna i sin egen koncern är en IKT-tjänsteleverantör inom koncernen, och DORA behandlar den, för nästan varje syfte, som en tredje part (DORA, Art 3(20)).

Två problem följer, och de är ämnet för denna artikel. Det första är ett glapp mellan var plikten sitter och var kontrollen sitter. DORA lägger plikten på dotterbolaget och lämnar kontrollen hos holdingbolaget, och holdingbolaget är, om det inte självt är en reglerad finansiell enhet, utanför förordningens direkta räckvidd, berört endast genom de avtal och den tillsyn dess dotterbolag är skyldiga att ålägga det. Vi kallar detta efterlevnads–kontrollasymmetrin, och avsnitt 3.1 anatomiserar den. Det andra är att centraliseringen av IKT:n koncentrerar risken. En gemensam kärna är en enda punkt vars fel inte är ett dotterbolags problem utan varje dotterbolags problem på en gång, en korrelerad händelse med gemensam orsak snarare än en oberoende, diversifierbar, och eftersom varje drabbat dotterbolag måste rapportera till sin egen tillsynsmyndighet blir ett enda tekniskt fel en solfjäder av samtidiga regulatoriska anmälningar över hela unionen. Avsnitt 3.2 redogör för detta och avsnitt 4 modellerar det.

Bidraget är en diagnos och en utformning, inte en juridisk kommentar. Vi anger de två strukturella problemen rättframt, ger en liten kvantitativ modell av koncentrationsproblemet så att en koncern kan se hur dess grad av centralisering byter tillförlitlighet per enhet mot koncernövergripande korrelerad risk (avsnitt 4), och arbetar igenom vad DORA:s huvudsakliga skyldigheter, registret och avtalen (avsnitt 5), incidentrapporteringen (avsnitt 6), testningen (avsnitt 7) och styrningen (avsnitt 8), kräver av en centraliserad koncern i synnerhet. Avsnitt 9 föreslår en målverksamhetsmodell som uppfyller förordningen samtidigt som den behåller den effektivitet som fick koncernen att centralisera i första hand. Avsnitten 10 till 12 bemöter invändningar, anger begränsningar och avslutar. Frågan genomgående är: hur efterlever en koncern, enhet för enhet, en förordning som förutsätter att varje enhet kontrollerar sin egen IKT, när i själva verket en enda gemensam kärna kontrollerar dem alla?

2. Vad DORA kräver, och av vem

2.1 De fem pelarna

DORA ordnar en finansiell enhets operativa motståndskraft i fem områden, och det är värt att ange dem en gång eftersom koncernproblemet berör alla fem. Det första är IKT-riskhantering (Chapter II, Arts 5–16): ett styrnings- och kontrollramverk, ägt av ledningsorganet, som omfattar identifiering, skydd, upptäckt, respons och återställning, med ett lättare förenklat ramverk tillgängligt för vissa mindre enheter (Art 16). Det andra är hantering och rapportering av IKT-relaterade incidenter (Chapter III, Arts 17–23): en process för att upptäcka och hantera incidenter, en harmoniserad klassificering av deras allvarlighetsgrad (Art 18), och en skyldighet att rapportera allvarliga incidenter till den behöriga myndigheten enligt en fast tidtabell av inledande, mellanliggande och slutliga rapporter (Art 19). Det tredje är testning av digital operativ motståndskraft (Chapter IV, Arts 24–27): ett program för regelbunden testning för varje enhet, och avancerade hotbildsstyrda penetrationstester (TLPT) minst vart tredje år för dem myndigheterna pekar ut som betydande (Arts 26–27). Det fjärde är hanteringen av IKT-tredjepartsrisk (Chapter V, Arts 28–44), vilket är där koncernstrukturen biter hårdast, och vilket vi behandlar utförligt nedan. Det femte är informationsdelning om cyberhot (Chapter VI, Art 45), vilket är frivilligt och inte behöver uppehålla oss här.

2.2 Enhetsprincipen

Det drag hos DORA som styr allt i denna artikel är att dess skyldigheter fäster vid den enskilda auktoriserade enheten. En bankkoncern är inte auktoriserad; dess bankdotterbolag är det. DORA:s tillämpningsbestämmelse räknar upp de slags finansiella enheter den binder, och var och en är en enhet som innehar en auktorisation (Art 2). Följden är att efterlevnad bedöms, och verkställs, en enhet i taget, av den enhetens egen behöriga myndighet. Det finns ingen koncernauktorisation som efterlever för dotterbolagens räkning, och ingen enda europeisk tillsynsmyndighet inför vilken koncernen som helhet svarar för sin motståndskraft. Informationsregistret är den enda plats där koncerndimensionen är uttrycklig: en enhet måste föra det inte bara på sin egen nivå utan, där den ingår i en koncern, även på delkonsoliderad och konsoliderad nivå (Art 28(3)), så att en konsoliderande enhet sätter samman en koncernövergripande bild. Men plikten att efterleva, att styra, att rapportera och att testa förblir det enskilda dotterbolagets, och kan inte fullgöras genom att peka uppåt mot moderbolaget.

2.3 IKT inom koncernen är tredjeparts-IKT

Det andra drag som styr denna artikel är DORA:s behandling av IKT som levereras inifrån koncernen. Det vore naturligt att anta att de tjänster ett dotterbolag tar emot från sitt eget moderbolag är interna, och utanför den tredjepartsregim som DORA riktar mot externa leverantörer. DORA stänger det antagandet ute. Den definierar en IKT-tjänsteleverantör inom koncernen som ett företag som ingår i koncernen och tillhandahåller IKT-tjänster övervägande till enheter i samma koncern (Art 3(20)), och den för in en sådan leverantör under tredjepartsreglerna: det mottagande dotterbolaget måste registrera arrangemanget i sitt register (Art 28(3)), styra det genom ett skriftligt avtal som bär de obligatoriska bestämmelserna (Art 30), bedöma den koncentration det skapar (Art 29), och ha avvecklingsarrangemang för det där det stöder en kritisk eller viktig funktion (Art 28(8)). Att relationen är koncernintern är något som ska registreras, inte ett skäl för undantag. Kort sagt, när moderbolaget levererar plattformen läser DORA moderbolaget som en tredjepartsleverantör och dotterbolaget som dess kund, med alla de skyldigheter som en kund hos en extern moln- eller programvaruleverantör skulle bära. En koncern som behandlar relationen som en rent intern angelägenhet, styrd av en tjänstekatalog och en koncernintern vidarefakturering snarare än ett DORA-förenligt avtal, efterlever inte.

3. Mönstret med centraliserat holdingbolag

Figur 1 ritar det mönster denna artikel handlar om. Ett holding- eller koncern-IT-bolag driver den kritiska IKT-kärnan och levererar den till flera reglerade dotterbolag, vart och ett i sin egen medlemsstat och vart och ett under tillsyn av sin egen nationella behöriga myndighet. Tjänstepilarna löper nedåt från kärnan; pilarna för tillsyn och incidentrapportering löper från varje dotterbolag till dess egen myndighet. Inledningens två problem är synliga i bilden: det som binder samman koncernen, kärnan, levereras av en enhet som tillsynsmyndigheterna når endast indirekt, och ett fel högst upp i diagrammet fortplantar sig till varje gren på en gång medan rapporteringen splittras över varje myndighet längst ned.

3.1 Efterlevnads–kontrollasymmetrin

I en läroboksenhet driver det företag som bär DORA-plikten också systemen, så plikten och de spakar som fullgör den ligger i samma händer. Den centraliserade koncernen drar isär dem. Dotterbolaget bär plikten, eftersom det är den auktoriserade enheten, men det driver inte kärnan, kan inte patcha den, kan inte välja dess arkitektur, kan inte sätta dess återställningsmål och kan inte, på egen hand, testa den. Holdingbolaget driver kärnan och håller alla dessa spakar, men det bär ingen direkt DORA-plikt om det inte självt är en auktoriserad finansiell enhet, vilket ett rent IT- eller holdingbolag vanligen inte är. Förordningen förutser precis detta och leder runt det: den når holdingbolaget genom dotterbolaget, genom att kräva att dotterbolaget genom avtal ålägger de rättigheter till åtkomst, revision, samarbete, incidentunderrättelse, testning och utträde som låter dotterbolaget fullgöra en plikt över system det inte äger (Art 30). Dotterbolagets efterlevnad beror därför på dess avtalsmässiga makt över sitt eget moderbolag, vilket är en ovanlig och obekväm sak att behöva utöva.

Asymmetrin har en skarp praktisk egg. Ett dotterbolags styrelse får av DORA veta att den är ytterst ansvarig för enhetens IKT-risk och inte kan delegera det ansvaret (Art 5(2)); ändå löper styrelsens verkliga inflytande över den kärna som bär merparten av den risken genom en koncernfunktion som rapporterar till moderbolaget, inte till den. Om styrelsen helt enkelt litar på centrum har den i sak delegerat det den inte får delegera i lag. Om den försöker utöva genuin tillsyn behöver den information, säkerhet och rättigheter som en informell koncernintern relation inte ger. Utformningssvaret, utvecklat i avsnitt 9, är att ge relationen den formalitet den skulle ha med en extern leverantör just för att dotterbolagets styrelse ska kunna se in i och utmana kärnan, och att bygga koncernramverket så att varje styrelses tillsyn är en verklig insats snarare än en artighet.

3.2 Koncentrationsrisk

Det andra problemet är att den gemensamma kärnan är en koncentration. DORA namnger koncentrationsrisk direkt och kräver att varje enhet bedömer den före avtalsslut och håller den under översyn, uttryckligen inklusive risken från koncerninterna arrangemang och från leverantörer som är svåra att ersätta (Art 29). I en centraliserad koncern är koncentrationen nära total: en kärna, ett säkerhetscenter, en uppsättning återställningsarrangemang, som betjänar varje reglerad enhet i koncernen. Effektivitetsargumentet för detta är just dess fara. Samma enda plattform som är billigare att bygga och lättare att säkra en gång är också en enda punkt vars fel delas av alla som är beroende av den. Där en federerad koncern av dotterbolag som vart och ett driver sin egen IKT skulle drabbas av fel ett i taget, oberoende, drabbas en centraliserad koncern av dem tillsammans, eftersom felen har en gemensam orsak.

Detta är skillnaden mellan oberoende fel och fel med gemensam orsak som säkerhets- och systemrisklitteraturen länge insisterat på (Perrow, 1999; Leveson, 2011; ESRB, 2022). Oberoende fel diversifierar: chansen att många inträffar på en gång är produkten av små sannolikheter, och försvinnande liten. Fel med gemensam orsak diversifierar inte: när den gemensamma orsaken fallerar fallerar allt nedströms om den tillsammans, och koncernens motståndskraft begränsas av motståndskraften hos dess svagaste delade komponent, inte förbättrad av antalet enheter som sprider belastningen. Att koncentrera IKT:n sprider inte risken över dotterbolagen; den kopplar dotterbolagen till en enda risk. Nästa avsnitt gör poängen exakt.

4. En minimal modell av korrelerad koncernrisk

Modellen är en skiss, avsedd att göra mekanismen tydlig och att låta en koncern resonera om sin egen grad av centralisering, inte en kalibrerad riskskattning. Den skiljer det fel ett dotterbolag drabbas av på egen hand från det fel hela koncernen drabbas av tillsammans, och visar hur centralisering flyttar risk från det första slaget till det andra.

4.1 Störning per enhet

Betrakta en koncern med $n$ reglerade dotterbolag. En andel $c$ av dem, vilken vi behandlar som sannolikheten att ett givet dotterbolag är beroende av holdingbolagets gemensamma kärna för en kritisk eller viktig funktion, är kopplade till kärnan; kalla $c$ centraliseringskvoten. Under en given period drabbas den gemensamma kärnan av en kritisk störning med sannolikhet $p_0$. Detta är en händelse med gemensam orsak: när den inträffar störs varje kopplat dotterbolag i samma ögonblick, av samma skäl. Oberoende av kärnan fallerar varje dotterbolags egen lokala IKT under perioden med sannolikhet $q$. Ett kopplat dotterbolag störs därför när antingen kärnan eller dess egen lokala IKT fallerar,

vilket är den siffra ett enskilt dotterbolags styrelse ser när den tittar på sin egen incidenthistorik. Den centralisering som kopplar dotterbolaget till en välskött kärna tenderar att sänka $q$, eftersom en professionell delad plattform vanligen sköts bättre än en liten lokal, så $u$ kan falla när koncernen centraliserar. Betraktad en enhet i taget förbättrar centralisering motståndskraften, och detta är den ärliga halvan av effektivitetsargumentet.

4.2 Från oberoende till korrelerad

Koncernen erfar inte sin risk en enhet i taget. Det som betyder något för koncernen, och för tillsynsmyndigheterna, är chansen att flera dotterbolag störs samtidigt, eftersom det är den händelse som är systemisk, gränsöverskridande och samtidigt rapporteringspliktig. Utan en gemensam kärna är det enda sättet som två dotterbolag faller tillsammans att två av dem råkar fallera lokalt under samma period, ett sammanträffande av oberoende händelser vars sannolikhet är av storleksordningen $q^{2}$, det vill säga liten av andra ordningen. Med en gemensam kärna slår en enda kärnstörning ut varje kopplat dotterbolag på en gång, så sannolikheten för en samtidig händelse som berör flera enheter är av storleksordningen av kärnans egen felsannolikhet,

där hakparentesen är sannolikheten att minst två av de $n$ dotterbolagen är kopplade, så att ett kärnfel stör minst två på en gång. Poängen är inte den exakta formen utan storleksordningen: centralisering omvandlar sannolikheten för en koncernövergripande händelse från andra ordningen i en liten lokal sannolikhet till första ordningen i kärnans sannolikhet. En kärna som fallerar endast sällan är ändå, som källa till samtidigt fel som berör flera enheter, långt farligare än summan av dotterbolagens oberoende risker, eftersom dess fel är delade snarare än spridda. Figur 2 ritar denna sannolikhet mot centraliseringskvoten för de två arkitekturerna: en federerad koncern, med varje dotterbolag på sin egen IKT, håller den platt nära noll, medan en centraliserad koncerns stiger bort från den baslinjen när en större del av koncernen kopplas till den gemensamma kärnan.

4.3 Multiplikatorn för regulatorisk belastning

Det finns en andra konsekvens av händelsen med gemensam orsak som är specifik för DORA och för koncernstrukturen, och den rör inte motståndskraft utan rapportering. Eftersom varje dotterbolag är en separat reglerad enhet som svarar inför sin egen behöriga myndighet (avsnitt 2.2) genererar ett enda kärnfel inte en incidentrapport; det genererar en från varje dotterbolag det stör, var och en till en annan myndighet, var och en på den myndighetens klocka, möjligen på den myndighetens språk. Det förväntade antalet samtidiga rapporter om allvarliga incidenter som utlöses av en kärnstörning är just det förväntade antalet kopplade dotterbolag,

så en koncern med ett dussin dotterbolag fullt kopplade till en gemensam kärna förvandlar en enda teknisk händelse till ett dussin parallella regulatoriska anmälningar i ett dussin jurisdiktioner, inom DORA:s tidsfrist för inledande rapport, alla beskrivande samma grundorsak. Denna multiplikator av regulatorisk belastning är osynlig i ett enskilt dotterbolags planering och blir synlig endast på koncernnivå, vilket är just den nivå DORA inte gör någon enskild enhet ansvarig för. Det är det starkaste praktiska argumentet för den koncernnivåsamordning som avsnitt 9 bygger.

5. Registret, koncentrationen och avtalen

DORA:s tredjepartskapitel ger den centraliserade koncernen tre instrument den måste använda, och vart och ett av dem, ärligt tillämpat, blottlägger problemen ovan snarare än döljer dem.

Informationsregistret (Art 28(3)) är en förteckning över varje avtalsarrangemang för IKT-tjänster, fört enligt en standardmall fastställd av tekniska standarder för genomförande (ITS 2024/2956) och som skiljer de arrangemang som stöder kritiska eller viktiga funktioner från dem som inte gör det. För en centraliserad koncern är registret där det koncerninterna beroendet blir obestridligt: varje dotterbolags register anger holdingbolaget som leverantör av sina kritiska tjänster, och det konsoliderade register koncernen måste sätta samman (Art 28(3)) visar, på en enda sida, att en leverantör står bakom hela koncernens kritiska funktioner. En koncern som fyller i registret ordentligt har dokumenterat sin egen koncentration; en koncern som frestas att utelämna det koncerninterna arrangemanget, med motiveringen att det är internt, både bryter mot registerskyldigheten och förblindar sig för just den risk registret finns till för att visa. Tabell 1 anger de tre nivåer på vilka registret förs och vad var och en är till för.

Koncentrationsriskbedömningen (Art 29) ställer sedan den fråga registret väcker: vad händer om denna leverantör fallerar eller måste ersättas? För en extern leverantör är svaret en substitutionsanalys; för den koncerninterna kärnan är det svårare, eftersom kärnan vanligen inte alls är utbytbar inom någon rimlig horisont, då den byggdes en gång för hela koncernen. DORA förbjuder inte koncentration, men den kräver att enheten ser den och väger den, och en centraliserad koncerns ärliga svar, att kärnan är en gemensam felkälla för koncernen och i praktiken oersättlig på kort sikt, är i sig det fynd som bör driva den investering i motståndskraft och den utträdesplanering förordningen också kräver (Art 28(8)).

Avtalsarrangemangen (Art 30) är den mekanism genom vilken dotterbolaget skaffar sig makt över en kärna det inte äger. DORA föreskriver ett golv av bestämmelser för varje arrangemang och en längre lista för arrangemang som stöder kritiska eller viktiga funktioner: fullständiga beskrivningar av servicenivåer, platser för tjänst och data, rättigheter till åtkomst, inspektion och revision, skyldigheter att bistå vid incidenter, samarbete med myndigheterna, rätt att övervaka, villkor för underentreprenad (nu detaljerade av RTS 2025/532) och dokumenterade utträdesstrategier (Arts 28(8), 30(2)–(3)). Den koncerninterna miljön mildrar inget av detta. Utformningsanvisningen, utvecklad nedan, är att skriva det koncerninterna avtalet som om motparten vore en extern leverantör på armlängds avstånd, eftersom det är det enda sättet som dotterbolagets styrelse, på papper, får de rättigheter asymmetrin annars förvägrar den.

6. En incident, många tillsynsmyndigheter

Regimen för incidentrapportering är där multiplikatorn av regulatorisk belastning från avsnitt 4 blir ett operativt problem. DORA kräver att en enhet klassificerar en IKT-relaterad incident mot harmoniserade kriterier, och, om den är allvarlig, underrättar sin behöriga myndighet med en inledande rapport inom en kort tidsfrist, sedan en mellanliggande rapport allteftersom bilden klarnar, sedan en slutlig rapport med grundorsak (Arts 18–19). Klassificeringskriterierna, tröskelvärdena och mallarna är harmoniserade över unionen genom nivå 2-regler, vilket är en hjälp; men rapporterna går fortfarande till varje enhets egen myndighet, och klockan börjar för varje enhet när den enheten blir varse.

För en centraliserad koncern är ett enda kärnfel, samtidigt, en allvarlig incident för varje dotterbolag det stör. Varje dotterbolag måste klassificera den, var och en måste avgöra om den passerar tröskeln för allvarlig, och var och en måste inlämna, till sin egen myndighet, inom tidsfristen. Om dotterbolagen klassificerar oberoende och författar oberoende frambringar koncernen en spridning av rapporter som beskriver samma händelse inkonsekvent, anländer vid olika tidpunkter, och utsätter koncernen för tillsynsmyndighetens uppenbara fråga om varför dess enheter är oense om vad som hände med deras delade system. Felläget är inte underrapportering utan osammanhängande överrapportering. Botemedlet är inte att centralisera rapporteringen, vilket DORA inte tillåter, eftersom skyldigheten är varje enhets, utan att centralisera fakta: en incidenttaxonomi, en fastställelse av grundorsak och en klocka som drivs från koncernens säkerhetscenter, som matar en konsekvent kärna av fakta in i varje dotterbolags egen anmälan, vilken varje dotterbolags egen ansvariga funktion sedan äger, undertecknar och lämnar in till sin egen myndighet. Koncernen levererar sanningen; varje enhet levererar anmälan. Avsnitt 9 gör detta konkret.

7. Att testa en gemensam kärna

DORA:s testregim har två nivåer, och koncernstrukturen komplicerar bägge. Den grundläggande nivån kräver att varje enhet driver ett program av motståndskraftstester, proportionerligt mot dess storlek och risk (Art 24–25). Den avancerade nivån kräver hotbildsstyrda penetrationstester, ungefär vart tredje år, för de enheter myndigheterna identifierar som tillräckligt betydande för att motivera det (Arts 26–27). I en centraliserad koncern är det objekt som är värt att testa till stor del den gemensamma kärnan, eftersom det är där de kritiska systemen och koncentrationen finns; men skyldigheten att testa vilar på dotterbolagen, som inte driver kärnan.

Att testa samma gemensamma kärna separat för varje dotterbolag vore slöseri och, värre, riskabelt, eftersom upprepad skarp red teaming av en produktionsplattform som betjänar hela koncernen mångdubblar chansen att ett test självt orsakar en incident. DORA förutser delade leverantörer och tillåter, under vissa villkor, att testning samlas eller genomförs gemensamt där flera enheter förlitar sig på samma IKT-leverantör eller tillhör samma koncern och delar system, så att ett korrekt styrt test av den gemensamma kärnan kan uppfylla de deltagande enheterna (Arts 26–27 och de tekniska standarderna för TLPT). Att samla testningen upplöser inte den individuella skyldigheten: varje deltagande dotterbolag måste fortfarande vara part i arrangemanget, måste fortfarande säkerställa att testet täcker dess egna kritiska funktioner, och måste fortfarande agera på fynden. Men det låter koncernen testa det som faktiskt betyder något, kärnan, en gång och väl, snarare än många gånger och dåligt. Utformningsimplikationen är att koncernen bör planera testning från kärnan och utåt, inkludera varje dotterbolags kritiska funktioner i det delade testet, och inneha de avtalsmässiga rättigheter (Art 30) som låter ett dotterbolag kräva att dess leverantör, här dess eget moderbolag, deltar.

8. Ansvar som inte kan delegeras uppåt

Den tråd som löper genom varje avsnitt är DORA:s insisterande att varje enhets ledningsorgan bär det yttersta ansvaret för den enhetens IKT-risk, och att detta ansvar inte kan avtalas eller delegeras bort (Art 5). I en centraliserad koncern är detta den bestämmelse som är mest i spänning med den operativa verkligheten, eftersom verkligheten är att dotterbolagen i sak har delegerat IKT:n till koncernen. DORA förbjuder inte koncernen att driva IKT:n centralt; vad den förbjuder är att dotterbolagets styrelse behandlar det arrangemanget som ett skäl att upphöra att vara ansvarig. Styrelsen måste behålla tillräcklig förståelse av den kärna den är beroende av, tillräcklig information om hur den sköts och hur den fallerar, och tillräcklig avtalsmässig och styrningsmässig makt för att utmana och, i yttersta fall, att agera, så att dess lagstadgade ansvar är verkligt snarare än nominellt.

Detta går emot en naturlig och vanligen välmenande centraliserande instinkt, nämligen att bespara dotterbolagsstyrelserna de tekniska detaljerna och låta experterna i centrum hantera det. DORA kräver motsatsen: att varje dotterbolagsstyrelse är utrustad och skyldig att styra en risk den har lagt ut på sitt eget moderbolag. De praktiska följderna är en rapporteringslinje från koncernens IKT-funktion in i varje dotterbolagsstyrelse, inte bara in i moderbolagets; IKT-riskkompetens på styrelsenivå vid varje dotterbolag, inte bara i centrum; och ett koncernramverk utformat så att varje styrelses tillsyn är en genuin kontrollpunkt. En koncern som bygger den gemensamma kärnan men lämnar dotterbolagsstyrelserna oinformerade har skapat efterlevnads–kontrollasymmetrin i dess farligaste form, där de människor som är ansvariga i lag är de som i praktiken är minst i stånd att utöva ansvaret.

9. En målverksamhetsmodell för koncernen

Den utformning som besvarar de två problemen är inte att decentralisera IKT:n, vilket skulle kasta bort effektiviteten och, enligt modellen i avsnitt 4, kanske inte ens förbättra koncernens motståndskraft när den gemensamma kärnan väl sköts väl. Den är att behålla den centrala kärnan och omge den med den struktur DORA kräver, så att plikten och kontrollen återkopplas genom styrning och avtal snarare än genom ägande. Fem drag följer av analysen.

Driv ett enda IKT-riskramverk för koncernen, synligt för varje styrelse. Bygg ramverket för IKT-riskhantering en gång, på koncernnivå, enligt den standard DORA och dess RTS kräver (Art 6; RTS 2024/1774), men koppla dess rapportering in i varje dotterbolags ledningsorgan och inte bara in i moderbolagets, så att varje styrelse styr den delade risken med verklig information. Ramverket är centralt; ansvaret förblir fördelat, som förordningen kräver.

Avtala med moderbolaget som om det vore en extern leverantör. Ge varje koncernintern leverans av en kritisk eller viktig funktion ett skriftligt avtal som bär de fullständiga bestämmelserna i Article 30, rättigheter till åtkomst och revision, skyldigheter till incidentbistånd och samarbete, villkor för underentreprenad och en dokumenterad utträdesstrategi, precis som ett dotterbolag skulle ålägga en extern molnleverantör. Formaliteten är inte byråkratisk omkostnad; den är det instrument som omvandlar dotterbolagets pappersansvar till verklig makt över kärnan.

För ett konsoliderat register och läs det som en riskkarta. Upprätthåll registret på enhets-, delkonsoliderad och konsoliderad nivå (Art 28(3)) och behandla den konsoliderade bilden inte som en inlämningssyssla utan som koncernens karta över sin egen koncentration, insatsvaran till koncentrationsriskbedömningen (Art 29) och till den investering i motståndskraft som följer av den.

Centralisera fakta om en incident, fördela rapporteringen. Driv en incidenttaxonomi, en grundorsaksprocess och en klocka från koncernens säkerhetscenter, och mata en enda, konsekvent redogörelse för varje kärnincident in i varje drabbat dotterbolags egen rapportering, vilken det dotterbolaget äger och lämnar in till sin egen myndighet (Arts 18–19). Koncernen levererar en sanning; varje enhet uppfyller sin egen skyldighet.

Testa kärnan en gång, för alla som är beroende av den. Planera motståndskrafts- och hotbildsstyrd testning från den gemensamma kärnan och utåt, med hjälp av DORA:s bestämmelser om samlad testning och koncerntestning (Arts 26–27) så att det som bär koncentrationen testas ordentligt och sällan snarare än upprepat och tunt, med varje dotterbolags kritiska funktioner inkluderade och varje dotterbolag agerande på fynden.

Inget av dessa upphäver centraliseringen; vart och ett återkopplar en plikt DORA lade på dotterbolaget till en kontroll koncernen lade i holdingbolaget. Tillsammans låter de en koncern behålla den plattform den byggde en gång och ändå ge varje reglerad enhet, och varje nationell tillsynsmyndighet, den styrda, avtalade, dokumenterade och testade relation förordningen kräver.

10. Invändningar och svar

Moderbolaget är inte en reglerad enhet, så DORA gäller inte för det. Direkt, nej; genom dess dotterbolag, helt och hållet. DORA når holdingbolaget som en IKT-tjänsteleverantör inom koncernen genom att ålägga varje dotterbolag att styra, avtala med och utöva tillsyn över det (Arts 3(20), 30). En koncern som läser moderbolagets avsaknad av auktorisation som frihet från DORA har förväxlat skyldighetens väg med dess frånvaro, och kommer att finna skyldigheten väntande i varje dotterbolags register, avtal och revision.

Att centralisera IKT förbättrar motståndskraften, så koncentration är en egenskap, inte en risk. Bägge är sanna, vilket är poängen med avsnitt 4. En välskött gemensam kärna sänker varje dotterbolags egen, oberoende felsannolikhet; den höjer samtidigt sannolikheten för en enda korrelerad händelse som stör hela koncernen på en gång. DORA:s koncentrationsbestämmelser (Art 29) finns just därför att den andra effekten är verklig och är osynlig inifrån någon enskild enhet. Utformningsuppgiften är att fånga den första fördelen samtidigt som man ser, prissätter och mildrar den andra, inte att förneka att avvägningen finns.

Att skriva ett fullständigt Article 30-avtal mellan ett moderbolag och dess eget dotterbolag är legalistisk teater. Det vore det, om avtalets enda syfte vore att uppfylla en checklista. Dess verkliga syfte är att ge dotterbolagets styrelse, som är ansvarig i lag för en kärna den inte äger, verkställbara rättigheter till information, revision, bistånd och utträde över den kärnan. Utan dem är styrelsens lagstadgade ansvar (Art 5) nominellt. Formaliteten är den mekanism som gör ansvaret utövbart, och den koncerninterna miljön, där motparten är en systerenhet med samma yttersta ägare, är precis där informella arrangemang tenderar att lämna dessa rättigheter oskrivna.

Samlad testning släpper koncernen från kroken för individuell testning. Det gör den inte. Att samla testningen (Arts 26–27) är ett sätt att testa den gemensamma kärnan effektivt och säkert, inte ett sätt att fullgöra en enhets skyldighet genom att peka på någon annans test. Varje deltagande dotterbolag förblir individuellt skyldigt att säkerställa att dess egna kritiska funktioner är inom omfattningen och att agera på fynden; poolen rör hur testet drivs, inte vems plikten är.

11. Begränsningar

Detta är en analys riktad till praktiker, och dess begränsningar bör anges rättframt. Den är inte juridisk rådgivning; den styrande texten är förordningen och dess nivå 2-akter, lästa med vägledning från de europeiska tillsynsmyndigheterna och varje relevant nationell behörig myndighet, och en koncerns egen juridiska rådgivare måste avbilda den allmänna strukturen här på dess specifika enheter, auktorisationer och medlemsstater. Artikelhänvisningarna avser DORA så som den stod i början av 2025, med de delegerade akter och genomförandeakter som då antagits; detaljerna i de tekniska standarderna, och tillsynspraxis under dem, kommer att fortsätta utvecklas. Modellen i avsnitt 4 är en skiss vars storheter är definierade tillräckligt tydligt för att mätas men vars funktionsformer och illustrativa värden är valda för att göra mekanismen synlig, inte skattade ur en koncerns data; en koncern bör fylla $c$, $p_0$ och $q$ från sin egen arkitektur och incidenthistorik innan den drar någon slutsats av kurvorna. Artikeln behandlar också det vanliga och rena fallet med en enda central kärna och en tydlig uppdelning i moder- och dotterbolag; verkliga koncerner har flera kärnor, partiell centralisering, mellanliggande holdingbolag, delade externa leverantörer bakom den koncerninterna, och funktioner som är kritiska i en medlemsstat och inte i en annan, vilka var och en komplicerar bilden utan att ändra dess två grundläggande problem.

12. Slutsats

En alleuropeisk finansiell koncern som driver sin kritiska IKT från centrum och sin reglerade verksamhet från kanterna har byggt den mest förnuftiga strukturen för effektivitet och den mest besvärliga för DORA. Förordningen binder varje dotterbolag individuellt, förutsätter att var och en kontrollerar sin egen IKT, och finner i stället att en enda gemensam kärna, levererad av ett moderbolag som förordningen når endast i andra hand, kontrollerar dem alla. Två problem följer: plikten att efterleva sitter där kontrollen inte gör det, och centraliseringen av IKT:n koncentrerar koncernens risk till en enda korrelerad punkt vars fel stör varje dotterbolag på en gång och rapporteras till varje tillsynsmyndighet separat. Vi har redogjort för bägge, modellerat det andra för att visa att centralisering byter en lägre felsannolikhet per enhet mot en högre koncernövergripande korrelerad, och läst resultatet mot DORA:s bestämmelser om register, koncentration, avtal, incidenter, testning och styrning.

Svaret är inte att överge den centrala kärnan utan att styra den som DORA kräver: ett koncernramverk synligt för varje styrelse, koncerninterna avtal skrivna som om till en extern leverantör, ett konsoliderat register läst som en koncentrationskarta, en uppsättning incidentfakta fördelade till många anmälningar, och den gemensamma kärnan testad en gång för alla som är beroende av den. Vart och ett av dragen återkopplar en plikt förordningen lade på dotterbolaget till en kontroll koncernen lade i holdingbolaget, så att det koncernen byggde en gång kan drivas förenligt av varje enhet som är beroende av det. Den djupare lärdomen är den DORA skrevs för att lära ut: att operativ motståndskraft inte är en egenskap hos en plattform utan hos arrangemangen omkring den, och att i en koncern är det dessa arrangemang, inte ägarschemat, som avgör om en enda effektivitetspunkt också är en enda felpunkt.

Bilaga A. Modellen i sin helhet

Modellen i avsnitt 4 använder fyra storheter, som en koncern alla kan skatta ur sin egen arkitektur och incidenthistorik. Centraliseringskvoten $c$ är den andel av koncernens reglerade dotterbolag vars kritiska eller viktiga funktioner är beroende av den gemensamma kärnan; en koncern kan läsa den ur det konsoliderade registret (Art 28(3)) genom att räkna, av sina dotterbolag, hur många som anger den koncerninterna kärnan bakom en kritisk funktion. Kärnans felsannolikhet $p_0$ är sannolikheten att den gemensamma kärnan drabbas av en störning allvarlig nog att störa ett beroende dotterbolags kritiska funktion under en vald period; den skattas ur kärnans egen incidenthistorik, inte ur något enskilt dotterbolags. Den lokala felsannolikheten $q$ är den motsvarande sannolikheten för ett dotterbolags egen, icke-delade IKT. Antalet $n$ är antalet reglerade dotterbolag.

Den oberoende baslinjen är den jämförelse som gör koncentrationen synlig. Om det inte fanns någon gemensam kärna, där varje dotterbolag fallerar oberoende med sannolikhet $q$, skulle sannolikheten att minst två dotterbolag stördes under samma period vara $1-(1-q)^{n}-nq(1-q)^{n-1}$, vilket för litet $q$ är ungefär $\binom{n}{2}q^{2}$, en storhet av andra ordningen. Med den gemensamma kärnan är den ledande termen i samma sannolikhet $p_0$ gånger chansen att minst två dotterbolag är kopplade, en storhet av första ordningen i $p_0$. Kvoten mellan de två är den faktor med vilken centralisering höjer koncernens exponering mot samtidiga händelser som berör flera enheter, och den är stor närhelst $p_0$ inte är mycket mindre än $q^{2}$, vilket det nästan aldrig är. Detta är det formella innehållet i påståendet att koncentration kopplar dotterbolagen till en enda risk snarare än sprider risken över dem.

Två fallgropar förtjänar att nämnas. Den första är att skatta $p_0$ ur ett enskilt dotterbolags erfarenhet av kärnan, vilket underskattar den, eftersom ett givet dotterbolag ser endast de kärnincidenter som råkade störa det; $p_0$ måste läsas ur kärnans egen historik över alla beroende enheter. Den andra är att behandla $c$ som fast när det är ett beslut: koncernen väljer, funktion för funktion, hur mycket som ska kopplas till kärnan, och modellens värde ligger i att visa kostnaden, i korrelerad koncernövergripande risk, för varje ökning av det valet, så att valet görs med avvägningen i Figur 2 i åtanke snarare än på enbart effektivitetsgrunder.

Bilaga B. En checklista för avtalsvillkor inom koncernen

Checklistan nedan samlar de bestämmelser i Article 30 som ett dotterbolag bör säkra i sitt avtal för den koncerninterna leveransen av en kritisk eller viktig funktion. Den är inte en ersättning för förordningen eller för juridisk rådgivning; den är en arbetslista för utformningssamtalet mellan en koncerns centrala IT-funktion och dess dotterbolagsstyrelser. Varje bestämmelse är en sådan dotterbolaget behöver för att fullgöra, över en kärna det inte äger, en plikt DORA lägger på det; den koncerninterna miljön är där var och en oftast lämnas underförstådd och i stället bör skrivas ned.

Referenser

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