1. Einleitung

Eine große Finanzgruppe, die über die Europäische Union hinweg tätig ist, operiert selten als eine einzige juristische Person. Sie operiert als eine Muttergesellschaft und ein Fächer von Tochtergesellschaften, typischerweise ein reguliertes Unternehmen pro Mitgliedstaat, jedes mit seiner eigenen Zulassung, jedes seiner eigenen nationalen Aufsichtsbehörde unterstellt, jedes von den lokalen Regeln zusätzlich zu den gemeinsamen europäischen geprägt. Der Grund ist teils historisch, teils regulatorisch und teils kommerziell: Zulassungen sind national, Aufsichtsbehörden sind national, und ein lokales Unternehmen mit einem lokalen Namen und einer lokalen Bilanz ist leichter zuzulassen, zu beaufsichtigen und über das zu verkaufen. Was die Gruppe fast immer zentralisiert, ist die Informationstechnologie. Es ist verschwenderisch, dieselbe Kernbankplattform, dasselbe Policenverwaltungssystem, dasselbe Rechenzentrum, dasselbe Security Operations Centre elf Mal aufzubauen, und so baut die Gruppe sie einmal, in der Muttergesellschaft oder in einem eigens dafür bestimmten Gruppen-IT-Unternehmen, und liefert sie jeder Tochtergesellschaft als gemeinsamen Dienst. Das Geschäft ist lokal; die Infrastruktur ist zentral.

Der Digital Operational Resilience Act durchschneidet diese Anordnung auf eine Weise, die leicht zu übersehen ist, bis sie umgesetzt wird. DORA, Regulation (EU) 2022/2554, gilt seit dem 17. Januar 2025, und seine Grundeinheit ist das einzelne regulierte Unternehmen, nicht die Gruppe (DORA, Art. 1–2). Jede Tochtergesellschaft muss selbst einen Rahmen für das IKT-Risikomanagement unterhalten, ihre eigenen schwerwiegenden Vorfälle klassifizieren und melden, ihre eigene Resilienz testen, ihr eigenes Register der IKT-Drittparteien führen und sie unter ihrem eigenen Leitungsorgan steuern (DORA, Art. 5–30). Die Verordnung kümmert es nicht, dass die Tochtergesellschaft die Plattform, auf der sie läuft, nicht gebaut hat und nicht ändern kann; die Pflicht ist gleichwohl die der Tochtergesellschaft. Und wenn sich die Gruppe an das Unternehmen wendet, das die Plattform gebaut hat, die Muttergesellschaft, stellt sie fest, dass DORA die Beziehung bereits benannt hat: Ein Gruppenunternehmen, das IKT an die regulierten Unternehmen seiner eigenen Gruppe liefert, ist ein gruppeninterner IKT-Dienstleister, und DORA behandelt es für nahezu jeden Zweck wie eine Drittpartei (DORA, Art. 3(20)).

Zwei Probleme folgen daraus, und sie sind der Gegenstand dieses Aufsatzes. Das erste ist ein Missverhältnis zwischen dem Ort, an dem die Pflicht sitzt, und dem Ort, an dem die Kontrolle sitzt. DORA legt die Pflicht auf die Tochtergesellschaft und belässt die Kontrolle bei der Holding, und die Holding ist, wenn sie nicht selbst ein reguliertes Finanzunternehmen ist, außerhalb der direkten Reichweite der Verordnung, berührt nur über die Verträge und die Aufsicht, die ihre Tochtergesellschaften ihr aufzuerlegen verpflichtet sind. Wir nennen dies die Compliance-Kontroll-Asymmetrie, und Abschnitt 3.1 seziert sie. Das zweite ist, dass die Zentralisierung der IKT das Risiko konzentriert. Ein gemeinsamer Kern ist ein einzelner Punkt, dessen Ausfall nicht das Problem einer Tochtergesellschaft ist, sondern das jeder Tochtergesellschaft auf einmal, ein korreliertes Ereignis gemeinsamer Ursache statt eines unabhängigen, diversifizierbaren, und weil jede betroffene Tochtergesellschaft ihrer eigenen Aufsichtsbehörde Meldung erstatten muss, wird aus einem technischen Ausfall ein Fächer gleichzeitiger regulatorischer Meldungen über die gesamte Union hinweg. Abschnitt 3.2 legt dies dar, und Abschnitt 4 modelliert es.

Der Beitrag ist eine Diagnose und eine Gestaltung, kein juristischer Kommentar. Wir benennen die zwei strukturellen Probleme in aller Klarheit, geben ein kleines quantitatives Modell des Konzentrationsproblems, sodass eine Gruppe sehen kann, wie ihr Grad der Zentralisierung die Zuverlässigkeit je Unternehmen gegen das gruppenweite korrelierte Risiko abwägt (Abschnitt 4), und arbeiten durch, was DORAs Hauptpflichten – das Register und die Verträge (Abschnitt 5), die Meldung von Vorfällen (Abschnitt 6), das Testen (Abschnitt 7) und die Governance (Abschnitt 8) – im Besonderen von einer zentralisierten Gruppe verlangen. Abschnitt 9 schlägt ein Zielbetriebsmodell vor, das die Verordnung erfüllt und zugleich die Effizienz bewahrt, die die Gruppe überhaupt erst zur Zentralisierung bewog. Die Abschnitte 10 bis 12 beantworten Einwände, nennen Grenzen und schließen ab. Die durchgehende Frage lautet: Wie hält eine Gruppe, Unternehmen für Unternehmen, eine Verordnung ein, die annimmt, dass jedes Unternehmen seine eigene IKT kontrolliert, wenn in Wahrheit ein gemeinsamer Kern sie alle kontrolliert?

2. Was DORA verlangt, und von wem

2.1 Die fünf Säulen

DORA gliedert die operationale Resilienz eines Finanzunternehmens in fünf Bereiche, und es lohnt sich, sie einmal zu nennen, weil das Gruppenproblem alle fünf berührt. Der erste ist das IKT-Risikomanagement (Kapitel II, Art. 5–16): ein Governance- und Kontrollrahmen, der dem Leitungsorgan gehört und Identifizierung, Schutz, Erkennung, Reaktion und Wiederherstellung abdeckt, mit einem leichteren vereinfachten Rahmen, der bestimmten kleineren Unternehmen offensteht (Art. 16). Der zweite ist das Management und die Meldung IKT-bezogener Vorfälle (Kapitel III, Art. 17–23): ein Prozess zur Erkennung und Behandlung von Vorfällen, eine harmonisierte Klassifizierung ihrer Schwere (Art. 18) und die Pflicht, schwerwiegende Vorfälle der zuständigen Behörde nach einem festen Zeitplan aus Erst-, Zwischen- und Abschlussmeldung zu melden (Art. 19). Der dritte ist das Testen der digitalen operationalen Resilienz (Kapitel IV, Art. 24–27): ein Programm regelmäßiger Tests für jedes Unternehmen und fortgeschrittene bedrohungsgeleitete Penetrationstests (TLPT) mindestens alle drei Jahre für jene, die die Behörden als bedeutend hervorheben (Art. 26–27). Der vierte ist das Management des IKT-Drittparteienrisikos (Kapitel V, Art. 28–44), wo die Gruppenstruktur am härtesten zu Buche schlägt und das wir weiter unten ausführlich behandeln. Der fünfte ist der Informationsaustausch über Cyberbedrohungen (Kapitel VI, Art. 45), der freiwillig ist und uns hier nicht aufhalten muss.

2.2 Das Unternehmensprinzip

Das Merkmal von DORA, das alles in diesem Aufsatz beherrscht, ist, dass seine Pflichten am einzelnen zugelassenen Unternehmen haften. Eine Bankengruppe ist nicht zugelassen; ihre Bank-Tochtergesellschaften sind es. Der Anwendungsbereich von DORA zählt die Arten von Finanzunternehmen auf, die es bindet, und jedes ist ein Unternehmen, das eine Zulassung hält (Art. 2). Die Folge ist, dass die Einhaltung ein Unternehmen nach dem anderen beurteilt und durchgesetzt wird, von der eigenen zuständigen Behörde dieses Unternehmens. Es gibt keine Gruppenzulassung, die stellvertretend für die Tochtergesellschaften erfüllt, und keine einzige europäische Aufsichtsbehörde, der die Gruppe als Ganzes für ihre Resilienz antwortet. Das Informationsregister ist der eine Ort, an dem die Gruppendimension ausdrücklich wird: Ein Unternehmen muss es nicht nur auf seiner eigenen Ebene führen, sondern, wo es Teil einer Gruppe ist, auch auf teilkonsolidierter und konsolidierter Ebene (Art. 28(3)), sodass ein konsolidierendes Unternehmen eine gruppenweite Sicht zusammenstellt. Aber die Pflicht zur Einhaltung, zur Steuerung, zur Meldung und zum Testen bleibt die der einzelnen Tochtergesellschaft und kann nicht dadurch erfüllt werden, dass man nach oben auf die Muttergesellschaft verweist.

2.3 Gruppeninterne IKT ist Drittparteien-IKT

Das zweite Merkmal, das diesen Aufsatz beherrscht, ist DORAs Behandlung von IKT, die aus der Gruppe heraus geliefert wird. Es wäre naheliegend anzunehmen, dass Dienste, die eine Tochtergesellschaft von ihrer eigenen Muttergesellschaft erhält, intern sind und außerhalb der Drittparteienregelung liegen, auf die DORA bei externen Anbietern zielt. DORA schneidet diese Annahme ab. Es definiert einen gruppeninternen IKT-Dienstleister als ein Unternehmen, das Teil der Gruppe ist und IKT-Dienste überwiegend für Unternehmen derselben Gruppe erbringt (Art. 3(20)), und es bringt einen solchen Anbieter unter die Drittparteienregeln: Die empfangende Tochtergesellschaft muss die Vereinbarung in ihrem Register erfassen (Art. 28(3)), sie unter einem schriftlichen Vertrag steuern, der die verpflichtenden Bestimmungen trägt (Art. 30), die Konzentration bewerten, die sie schafft (Art. 29), und Ausstiegsregelungen für sie vorhalten, wo sie eine kritische oder wichtige Funktion unterstützt (Art. 28(8)). Die gruppeninterne Natur der Beziehung ist etwas, das zu erfassen ist, kein Grund für eine Ausnahme. Kurz gesagt: Wenn die Muttergesellschaft die Plattform liefert, liest DORA die Muttergesellschaft als Drittanbieter und die Tochtergesellschaft als ihren Kunden, mit allen Pflichten, die ein Kunde eines externen Cloud- oder Softwareanbieters tragen würde. Eine Gruppe, die die Beziehung als eine rein interne Angelegenheit behandelt, geregelt durch einen Servicekatalog und eine konzerninterne Verrechnung statt durch einen DORA-konformen Vertrag, ist nicht konform.

3. Das Muster der zentralisierten Holding

Abbildung 1 zeichnet das Muster, um das es in diesem Aufsatz geht. Eine Holding oder ein Gruppen-IT-Unternehmen betreibt den kritischen IKT-Kern und liefert ihn an mehrere regulierte Tochtergesellschaften, jede in ihrem eigenen Mitgliedstaat und jede von ihrer eigenen zuständigen nationalen Behörde beaufsichtigt. Die Pfeile des Dienstes laufen vom Kern abwärts; die Pfeile der Aufsicht und der Vorfallsmeldung laufen von jeder Tochtergesellschaft zu ihrer eigenen Behörde. Die zwei Probleme der Einleitung sind im Bild sichtbar: Das, was die Gruppe zusammenhält, der Kern, wird von einem Unternehmen geliefert, das die Regulierer nur mittelbar erreichen, und ein Ausfall an der Spitze des Diagramms pflanzt sich auf einmal auf jeden Zweig fort, während sich die Meldung über jede Behörde am unteren Ende zersplittert.

3.1 Die Compliance-Kontroll-Asymmetrie

In einem Lehrbuchunternehmen betreibt die Firma, die die DORA-Pflicht trägt, auch die Systeme, sodass die Pflicht und die Hebel, sie zu erfüllen, in denselben Händen liegen. Die zentralisierte Gruppe zieht sie auseinander. Die Tochtergesellschaft trägt die Pflicht, weil sie das zugelassene Unternehmen ist, aber sie betreibt den Kern nicht, kann ihn nicht patchen, kann seine Architektur nicht wählen, kann seine Wiederherstellungsziele nicht setzen und kann ihn nicht allein testen. Die Holding betreibt den Kern und hält all diese Hebel, aber sie trägt keine direkte DORA-Pflicht, wenn sie nicht selbst ein zugelassenes Finanzunternehmen ist, was eine reine IT- oder Holdinggesellschaft gewöhnlich nicht ist. Die Verordnung sieht genau dies voraus und umgeht es: Sie erreicht die Holding über die Tochtergesellschaft, indem sie von der Tochtergesellschaft verlangt, vertraglich die Zugangs-, Prüf-, Kooperations-, Vorfallsmeldungs-, Test- und Ausstiegsrechte aufzuerlegen, die es der Tochtergesellschaft erlauben, eine Pflicht über Systeme zu erfüllen, die ihr nicht gehören (Art. 30). Die Einhaltung der Tochtergesellschaft hängt daher von ihrer vertraglichen Macht über ihre eigene Muttergesellschaft ab, was eine ungewöhnliche und unbequeme Sache ist, ausüben zu müssen.

Die Asymmetrie hat eine scharfe praktische Kante. Dem Leitungsorgan einer Tochtergesellschaft sagt DORA, dass es letztlich für das IKT-Risiko des Unternehmens verantwortlich ist und diese Verantwortung nicht delegieren kann (Art. 5(2)); doch der tatsächliche Einfluss des Leitungsorgans auf den Kern, der den Großteil dieses Risikos trägt, läuft über eine Gruppenfunktion, die an die Muttergesellschaft berichtet, nicht an es. Wenn das Leitungsorgan dem Zentrum einfach vertraut, hat es im Wesentlichen delegiert, was es rechtlich nicht delegieren darf. Wenn es versucht, echte Aufsicht auszuüben, braucht es Informationen, Gewähr und Rechte, die eine beiläufige gruppeninterne Beziehung nicht bietet. Die gestalterische Antwort, in Abschnitt 9 entwickelt, ist, der Beziehung die Formalität zu geben, die sie mit einem externen Anbieter hätte, gerade damit das Leitungsorgan der Tochtergesellschaft in den Kern hineinsehen und ihn hinterfragen kann, und den Gruppenrahmen so zu bauen, dass die Aufsicht jedes Leitungsorgans ein echter Beitrag ist statt einer Höflichkeit.

3.2 Konzentrationsrisiko

Das zweite Problem ist, dass der gemeinsame Kern eine Konzentration ist. DORA benennt das Konzentrationsrisiko unmittelbar und verlangt von jedem Unternehmen, es vor Vertragsschluss zu bewerten und unter Beobachtung zu halten, ausdrücklich einschließlich des Risikos aus gruppeninternen Vereinbarungen und aus Anbietern, die schwer zu ersetzen sind (Art. 29). In einer zentralisierten Gruppe ist die Konzentration nahezu total: ein Kern, ein Security Operations Centre, eine Reihe von Wiederherstellungsregelungen, die jedem regulierten Unternehmen der Gruppe dienen. Das Effizienzargument dafür ist genau seine Gefahr. Dieselbe einzelne Plattform, die einmal billiger zu bauen und leichter zu sichern ist, ist auch ein einzelner Punkt, dessen Ausfall von allen geteilt wird, die von ihm abhängen. Wo eine föderierte Gruppe von Tochtergesellschaften, deren jede ihre eigene IKT betreibt, Ausfälle einen nach dem anderen erleiden würde, unabhängig, erleidet eine zentralisierte Gruppe sie gemeinsam, weil die Ausfälle eine gemeinsame Ursache haben.

Dies ist die Unterscheidung zwischen unabhängigem Ausfall und Ausfall gemeinsamer Ursache, auf der die Sicherheits- und die Systemrisikoliteratur seit Langem bestehen (Perrow, 1999; Leveson, 2011; ESRB, 2022). Unabhängige Ausfälle diversifizieren: Die Chance, dass viele zugleich eintreten, ist das Produkt kleiner Wahrscheinlichkeiten und verschwindend klein. Ausfälle gemeinsamer Ursache diversifizieren nicht: Wenn die gemeinsame Ursache ausfällt, fällt alles, was ihr nachgelagert ist, gemeinsam aus, und die Resilienz der Gruppe ist durch die Resilienz ihrer schwächsten gemeinsamen Komponente begrenzt, nicht durch die Zahl der Unternehmen verbessert, die die Last verteilen. Die IKT zu konzentrieren verteilt das Risiko nicht über die Tochtergesellschaften; es koppelt die Tochtergesellschaften an ein einziges Risiko. Der nächste Abschnitt macht den Punkt präzise.

4. Ein minimales Modell korrelierten Gruppenrisikos

Das Modell ist eine Skizze, gedacht, um den Mechanismus explizit zu machen und einer Gruppe zu erlauben, über ihren eigenen Grad der Zentralisierung nachzudenken, keine kalibrierte Risikoschätzung. Es trennt den Ausfall, den eine Tochtergesellschaft für sich allein erleidet, von dem Ausfall, den die ganze Gruppe gemeinsam erleidet, und zeigt, wie Zentralisierung Risiko von der ersten Art zur zweiten verschiebt.

4.1 Beeinträchtigung je Unternehmen

Betrachten wir eine Gruppe von $n$ regulierten Tochtergesellschaften. Ein Anteil $c$ von ihnen, den wir als die Wahrscheinlichkeit behandeln, dass eine beliebige Tochtergesellschaft für eine kritische oder wichtige Funktion vom gemeinsamen Kern der Holding abhängt, ist mit dem Kern verdrahtet; nennen wir $c$ das Zentralisierungsverhältnis. In einem gegebenen Zeitraum erleidet der gemeinsame Kern mit Wahrscheinlichkeit $p_0$ eine kritische Störung. Dies ist ein Ereignis gemeinsamer Ursache: Wenn es eintritt, wird jede verdrahtete Tochtergesellschaft im selben Augenblick aus demselben Grund beeinträchtigt. Unabhängig vom Kern fällt die eigene lokale IKT jeder Tochtergesellschaft im Zeitraum mit Wahrscheinlichkeit $q$ aus. Eine verdrahtete Tochtergesellschaft ist daher beeinträchtigt, wenn entweder der Kern oder ihre eigene lokale IKT ausfällt,

was die Zahl ist, die das Leitungsorgan einer einzelnen Tochtergesellschaft sieht, wenn es auf seine eigene Vorfallsbilanz blickt. Die Zentralisierung, die die Tochtergesellschaft mit einem gut geführten Kern verdrahtet, neigt dazu, $q$ zu senken, weil eine professionelle gemeinsame Plattform gewöhnlich besser geführt wird als eine kleine lokale, sodass $u$ fallen kann, während die Gruppe zentralisiert. Ein Unternehmen nach dem anderen betrachtet, verbessert Zentralisierung die Resilienz, und dies ist die ehrliche Hälfte des Effizienzarguments.

4.2 Von unabhängig zu korreliert

Die Gruppe erfährt ihr Risiko nicht ein Unternehmen nach dem anderen. Was für die Gruppe und für die Regulierer zählt, ist die Chance, dass mehrere Tochtergesellschaften zur selben Zeit beeinträchtigt sind, denn das ist das Ereignis, das systemisch, grenzüberschreitend und gleichzeitig meldepflichtig ist. Ohne einen gemeinsamen Kern ist der einzige Weg, auf dem zwei Tochtergesellschaften gemeinsam fallen, dass zwei von ihnen zufällig im selben Zeitraum lokal ausfallen, ein Zusammentreffen unabhängiger Ereignisse, dessen Wahrscheinlichkeit von der Ordnung $q^{2}$ ist, also klein zweiter Ordnung. Mit einem gemeinsamen Kern reißt eine einzige Kernstörung jede verdrahtete Tochtergesellschaft auf einmal nieder, sodass die Wahrscheinlichkeit eines gleichzeitigen Ereignisses über mehrere Unternehmen von der Ordnung der eigenen Ausfallwahrscheinlichkeit des Kerns ist,

wobei die Klammer die Wahrscheinlichkeit ist, dass mindestens zwei der $n$ Tochtergesellschaften verdrahtet sind, sodass ein Kernausfall mindestens zwei auf einmal beeinträchtigt. Es kommt nicht auf die genaue Form an, sondern auf die Ordnung: Zentralisierung verwandelt die Wahrscheinlichkeit eines gruppenweiten Ereignisses von zweiter Ordnung in einer kleinen lokalen Wahrscheinlichkeit zu erster Ordnung in der Wahrscheinlichkeit des Kerns. Ein Kern, der nur selten ausfällt, ist als Quelle gleichzeitigen Ausfalls über mehrere Unternehmen immer noch weit gefährlicher als die Summe der unabhängigen Risiken der Tochtergesellschaften, weil seine Ausfälle geteilt statt verteilt werden. Abbildung 2 zeichnet diese Wahrscheinlichkeit gegen das Zentralisierungsverhältnis für die zwei Architekturen: Eine föderierte Gruppe, jede Tochtergesellschaft auf ihrer eigenen IKT, hält sie flach nahe null, während die einer zentralisierten Gruppe von dieser Grundlinie aufsteigt, je mehr der Gruppe mit dem gemeinsamen Kern verdrahtet wird.

4.3 Der Multiplikator der regulatorischen Last

Es gibt eine zweite Folge des Ereignisses gemeinsamer Ursache, die spezifisch für DORA und für die Gruppenstruktur ist, und sie betrifft nicht die Resilienz, sondern die Meldung. Weil jede Tochtergesellschaft ein gesondertes reguliertes Unternehmen ist, das seiner eigenen zuständigen Behörde antwortet (Abschnitt 2.2), erzeugt ein einziger Kernausfall nicht eine Vorfallsmeldung; er erzeugt eine von jeder Tochtergesellschaft, die er beeinträchtigt, jede an eine andere Behörde, jede nach der Uhr dieser Behörde, womöglich in der Sprache dieser Behörde. Die erwartete Zahl gleichzeitiger Meldungen schwerwiegender Vorfälle, die eine Kernstörung auslöst, ist gerade die erwartete Zahl verdrahteter Tochtergesellschaften,

sodass eine Gruppe von einem Dutzend Tochtergesellschaften, die vollständig mit einem gemeinsamen Kern verdrahtet sind, ein einziges technisches Ereignis in ein Dutzend paralleler regulatorischer Meldungen in einem Dutzend Rechtsordnungen verwandelt, innerhalb von DORAs Frist für die Erstmeldung, alle mit derselben Grundursache. Dieser Multiplikator der regulatorischen Last ist in der Planung jeder einzelnen Tochtergesellschaft unsichtbar und wird erst auf der Gruppenebene sichtbar, die genau die Ebene ist, für die DORA kein einzelnes Unternehmen verantwortlich macht. Es ist das stärkste praktische Argument für die Koordination auf Gruppenebene, die Abschnitt 9 aufbaut.

5. Das Register, die Konzentration und die Verträge

DORAs Drittparteienkapitel gibt der zentralisierten Gruppe drei Instrumente, die sie nutzen muss, und jedes von ihnen bringt, ehrlich angewandt, die obigen Probleme ans Licht, statt sie zu verbergen.

Das Informationsregister (Art. 28(3)) ist ein Verzeichnis jeder vertraglichen Vereinbarung über IKT-Dienste, geführt nach einer Standardvorlage, die durch technische Durchführungsstandards festgelegt ist (ITS 2024/2956), und unterscheidet die Vereinbarungen, die kritische oder wichtige Funktionen unterstützen, von jenen, die es nicht tun. Für eine zentralisierte Gruppe ist das Register der Ort, an dem die gruppeninterne Abhängigkeit unleugbar wird: Das Register jeder Tochtergesellschaft führt die Holding als Anbieter ihrer kritischen Dienste auf, und das konsolidierte Register, das die Gruppe zusammenstellen muss (Art. 28(3)), zeigt auf einer einzigen Seite, dass ein Anbieter hinter den kritischen Funktionen der gesamten Gruppe steht. Eine Gruppe, die das Register ordentlich ausfüllt, hat ihre eigene Konzentration dokumentiert; eine Gruppe, die versucht ist, die gruppeninterne Vereinbarung wegzulassen, mit der Begründung, sie sei intern, verletzt sowohl die Registerpflicht als auch verblendet sich gegenüber genau dem Risiko, das zu zeigen das Register existiert. Tabelle 1 legt die drei Ebenen dar, auf denen das Register geführt wird, und wofür jede da ist.

Die Konzentrationsrisikobewertung (Art. 29) stellt dann die Frage, die das Register aufwirft: Was geschieht, wenn dieser Anbieter ausfällt oder ersetzt werden muss? Für einen externen Anbieter ist die Antwort eine Substitutionsanalyse; für den gruppeninternen Kern ist sie schwerer, weil der Kern gewöhnlich auf keinem vernünftigen Zeithorizont überhaupt ersetzbar ist, da er einmal für die ganze Gruppe gebaut wurde. DORA verbietet Konzentration nicht, aber es verlangt vom Unternehmen, sie zu sehen und abzuwägen, und die ehrliche Antwort einer zentralisierten Gruppe, dass der Kern ein einzelner Ausfallpunkt für die Gruppe und kurzfristig faktisch unersetzlich ist, ist selbst der Befund, der die Resilienzinvestition und die Ausstiegsplanung antreiben sollte, die die Verordnung ebenfalls verlangt (Art. 28(8)).

Die vertraglichen Vereinbarungen (Art. 30) sind der Mechanismus, durch den die Tochtergesellschaft Macht über einen Kern erwirbt, der ihr nicht gehört. DORA schreibt für jede Vereinbarung einen Sockel von Bestimmungen vor und eine längere Liste für Vereinbarungen, die kritische oder wichtige Funktionen unterstützen: vollständige Service-Level-Beschreibungen, Orte der Dienstleistung und der Daten, Zugangs-, Einsichts- und Prüfrechte, Pflichten zur Unterstützung bei Vorfällen, Zusammenarbeit mit den Behörden, Überwachungsrechte, Bedingungen für die Vergabe von Unteraufträgen (nun ausgeführt durch RTS 2025/532) und dokumentierte Ausstiegsstrategien (Art. 28(8), 30(2)–(3)). Die gruppeninterne Konstellation lockert nichts davon. Die gestalterische Anweisung, weiter unten entwickelt, ist, den gruppeninternen Vertrag so zu schreiben, als wäre die Gegenpartei ein externer Anbieter auf Armeslänge, weil das der einzige Weg ist, auf dem das Leitungsorgan der Tochtergesellschaft auf dem Papier die Rechte erhält, die die Asymmetrie ihm sonst verweigert.

6. Ein Vorfall, viele Regulierer

Die Regelung zur Meldung von Vorfällen ist der Ort, an dem der Multiplikator der regulatorischen Last aus Abschnitt 4 zu einem operativen Problem wird. DORA verlangt von einem Unternehmen, einen IKT-bezogenen Vorfall anhand harmonisierter Kriterien zu klassifizieren und, wenn er schwerwiegend ist, seine zuständige Behörde mit einer Erstmeldung auf kurze Frist zu benachrichtigen, dann mit einer Zwischenmeldung, während sich das Bild verfestigt, dann mit einer Abschlussmeldung mit Grundursache (Art. 18–19). Die Klassifizierungskriterien, die Schwellenwerte und die Vorlagen sind unionsweit durch Level-2-Regeln harmonisiert, was eine Hilfe ist; aber die Meldungen gehen weiterhin an die eigene Behörde jedes Unternehmens, und die Uhr beginnt für jedes Unternehmen zu laufen, wenn dieses Unternehmen Kenntnis erlangt.

Für eine zentralisierte Gruppe ist ein einziger Kernausfall gleichzeitig ein schwerwiegender Vorfall für jede Tochtergesellschaft, die er beeinträchtigt. Jede Tochtergesellschaft muss ihn klassifizieren, jede muss entscheiden, ob er die Schwelle zum Schwerwiegenden überschreitet, und jede muss bei ihrer eigenen Behörde innerhalb der Frist melden. Wenn die Tochtergesellschaften unabhängig klassifizieren und unabhängig entwerfen, erzeugt die Gruppe eine Streuung von Meldungen, die dasselbe Ereignis widersprüchlich beschreiben, zu verschiedenen Zeiten eintreffen und die Gruppe der naheliegenden aufsichtlichen Frage aussetzen, warum ihre Unternehmen uneins sind, was mit ihrem gemeinsamen System geschah. Der Fehlermodus ist nicht Unterberichterstattung, sondern inkohärente Überberichterstattung. Das Mittel ist nicht, die Meldung zu zentralisieren, was DORA nicht erlaubt, da die Pflicht die jedes Unternehmens ist, sondern die Fakten zu zentralisieren: eine Vorfallstaxonomie, eine Grundursachenbestimmung und eine Uhr, geführt vom Security Operations Centre der Gruppe, die einen konsistenten Kern an Fakten in die eigene Meldung jeder Tochtergesellschaft speisen, die die eigene zuständige Funktion jeder Tochtergesellschaft dann besitzt, unterzeichnet und ihrer eigenen Behörde vorlegt. Die Gruppe liefert die Wahrheit; jedes Unternehmen liefert die Meldung. Abschnitt 9 macht dies konkret.

7. Einen gemeinsamen Kern testen

DORAs Testregelung hat zwei Stufen, und die Gruppenstruktur erschwert beide. Die Grundstufe verlangt von jedem Unternehmen, ein Programm von Resilienztests durchzuführen, verhältnismäßig zu seiner Größe und seinem Risiko (Art. 24–25). Die fortgeschrittene Stufe verlangt bedrohungsgeleitete Penetrationstests, etwa alle drei Jahre, für jene Unternehmen, die die Behörden als bedeutend genug erachten, um sie zu rechtfertigen (Art. 26–27). In einer zentralisierten Gruppe ist der Gegenstand, der zu testen lohnt, weitgehend der gemeinsame Kern, weil dort die kritischen Systeme und die Konzentration sind; aber die Pflicht zu testen sitzt auf den Tochtergesellschaften, die den Kern nicht betreiben.

Denselben gemeinsamen Kern für jede Tochtergesellschaft gesondert zu testen wäre verschwenderisch und, schlimmer, riskant, da wiederholtes Live-Red-Teaming einer Produktionsplattform, die der ganzen Gruppe dient, die Chance vervielfacht, dass ein Test selbst einen Vorfall verursacht. DORA sieht gemeinsame Anbieter voraus und erlaubt unter Bedingungen, dass Tests gebündelt oder gemeinsam durchgeführt werden, wo mehrere Unternehmen sich auf denselben IKT-Anbieter verlassen oder zur selben Gruppe gehören und Systeme teilen, sodass ein ordentlich geregelter Test des gemeinsamen Kerns die teilnehmenden Unternehmen zufriedenstellen kann (Art. 26–27 und die technischen Standards zu TLPT). Die Bündelung löst die individuelle Pflicht nicht auf: Jede teilnehmende Tochtergesellschaft muss weiterhin Partei der Vereinbarung sein, muss weiterhin sicherstellen, dass der Test ihre eigenen kritischen Funktionen abdeckt, und muss weiterhin auf die Befunde hin handeln. Aber sie erlaubt der Gruppe, das zu testen, worauf es tatsächlich ankommt, den Kern, einmal und gut, statt viele Male und dürftig. Die gestalterische Folgerung ist, dass die Gruppe das Testen vom Kern nach außen planen, die kritischen Funktionen jeder Tochtergesellschaft in den gemeinsamen Test einbeziehen und die vertraglichen Rechte (Art. 30) vorhalten sollte, die es einer Tochtergesellschaft erlauben, von ihrem Anbieter, hier ihrer eigenen Muttergesellschaft, die Teilnahme zu verlangen.

8. Verantwortung, die nicht nach oben delegiert werden kann

Der rote Faden, der sich durch jeden Abschnitt zieht, ist DORAs Beharren darauf, dass das Leitungsorgan jedes Unternehmens die letztliche Verantwortung für das IKT-Risiko dieses Unternehmens trägt und dass diese Verantwortung nicht vertraglich übertragen oder wegdelegiert werden kann (Art. 5). In einer zentralisierten Gruppe ist dies die Bestimmung, die am stärksten mit der Betriebswirklichkeit in Spannung steht, denn die Wirklichkeit ist, dass die Tochtergesellschaften die IKT im Wesentlichen an die Gruppe delegiert haben. DORA verbietet der Gruppe nicht, die IKT zentral zu betreiben; was es verbietet, ist, dass das Leitungsorgan der Tochtergesellschaft diese Anordnung als Grund behandelt, nicht mehr verantwortlich zu sein. Das Leitungsorgan muss genug Verständnis des Kerns behalten, von dem es abhängt, genug Informationen darüber, wie er betrieben wird und wie er ausfällt, und genug vertragliche und Governance-Macht, um zu hinterfragen und, im äußersten Fall, zu handeln, dass seine gesetzliche Verantwortung real statt nominell ist.

Dies läuft einem natürlichen und meist gut gemeinten Zentralisierungsinstinkt zuwider, nämlich den Leitungsorganen der Tochtergesellschaften das technische Detail zu ersparen und die Experten im Zentrum es handhaben zu lassen. DORA verlangt das Gegenteil: dass jedes Leitungsorgan einer Tochtergesellschaft ausgestattet und verpflichtet ist, ein Risiko zu steuern, das es an seine eigene Muttergesellschaft ausgelagert hat. Die praktischen Folgen sind ein Berichtsweg von der IKT-Funktion der Gruppe in jedes Leitungsorgan der Tochtergesellschaften, nicht nur in die Muttergesellschaft; IKT-Risikokompetenz auf Leitungsebene in jeder Tochtergesellschaft, nicht nur im Zentrum; und ein Gruppenrahmen, so gestaltet, dass die Aufsicht jedes Leitungsorgans ein echter Kontrollpunkt ist. Eine Gruppe, die den gemeinsamen Kern baut, aber die Leitungsorgane der Tochtergesellschaften uninformiert lässt, hat die Compliance-Kontroll-Asymmetrie in ihrer gefährlichsten Form geschaffen, in der die Menschen, die rechtlich verantwortlich sind, faktisch am wenigsten in der Lage sind, die Verantwortung auszuüben.

9. Ein Zielbetriebsmodell für die Gruppe

Die Gestaltung, die die zwei Probleme beantwortet, ist nicht, die IKT zu dezentralisieren, was die Effizienz wegwerfen und, nach dem Modell aus Abschnitt 4, die Gruppenresilienz womöglich nicht einmal verbessern würde, sobald der gemeinsame Kern gut geführt ist. Sie ist, den zentralen Kern zu behalten und ihn in die Struktur zu hüllen, die DORA verlangt, sodass die Pflicht und die Kontrolle durch Governance und Vertrag statt durch Eigentum wieder verbunden werden. Fünf Züge folgen aus der Analyse.

Betreibe einen gruppenweiten IKT-Risikorahmen, sichtbar für jedes Leitungsorgan. Baue den Rahmen für das IKT-Risikomanagement einmal, auf Gruppenebene, nach dem Standard, den DORA und seine RTS verlangen (Art. 6; RTS 2024/1774), aber verdrahte seine Berichterstattung in das Leitungsorgan jeder Tochtergesellschaft und nicht nur in das der Muttergesellschaft, sodass jedes Leitungsorgan das gemeinsame Risiko mit echten Informationen steuert. Der Rahmen ist zentral; die Verantwortung bleibt verteilt, wie die Verordnung verlangt.

Schließe mit der Muttergesellschaft einen Vertrag, als wäre sie ein Anbieter. Gib jeder gruppeninternen Lieferung einer kritischen oder wichtigen Funktion einen schriftlichen Vertrag, der die vollständigen Bestimmungen des Artikels 30 trägt, Zugangs- und Prüfrechte, Pflichten zur Vorfallsunterstützung und Zusammenarbeit, Bedingungen für die Vergabe von Unteraufträgen und eine dokumentierte Ausstiegsstrategie, genau wie eine Tochtergesellschaft sie einem externen Cloud-Anbieter auferlegen würde. Die Formalität ist kein bürokratischer Mehraufwand; sie ist das Instrument, das die papierne Verantwortung der Tochtergesellschaft in echte Macht über den Kern verwandelt.

Führe ein konsolidiertes Register und lies es als Risikokarte. Unterhalte das Register auf Unternehmens-, teilkonsolidierter und konsolidierter Ebene (Art. 28(3)) und behandle die konsolidierte Sicht nicht als Meldepflicht-Fron, sondern als die Karte der Gruppe von ihrer eigenen Konzentration, den Input für die Konzentrationsrisikobewertung (Art. 29) und für die Resilienzinvestition, die daraus folgt.

Zentralisiere die Fakten eines Vorfalls, verteile die Meldung. Betreibe eine Vorfallstaxonomie, einen Grundursachenprozess und eine Uhr vom Security Operations Centre der Gruppe aus und speise eine einzige, konsistente Darstellung jedes Kernvorfalls in die eigene Meldung jeder betroffenen Tochtergesellschaft, die diese Tochtergesellschaft besitzt und bei ihrer eigenen Behörde einreicht (Art. 18–19). Die Gruppe liefert eine Wahrheit; jedes Unternehmen erfüllt seine eigene Pflicht.

Teste den Kern einmal, für alle, die von ihm abhängen. Plane das Resilienz- und bedrohungsgeleitete Testen vom gemeinsamen Kern nach außen, unter Nutzung von DORAs Bestimmungen für gebündeltes und Gruppen-Testen (Art. 26–27), sodass das, was die Konzentration trägt, ordentlich und selten getestet wird statt wiederholt und dünn, mit den einbezogenen kritischen Funktionen jeder Tochtergesellschaft und jeder Tochtergesellschaft, die auf die Befunde hin handelt.

Keiner davon macht die Zentralisierung rückgängig; jeder verbindet eine Pflicht, die DORA auf die Tochtergesellschaft legte, wieder mit einer Kontrolle, die die Gruppe in der Holding ansiedelte. Zusammen erlauben sie einer Gruppe, die Plattform zu behalten, die sie einmal baute, und dennoch jedem regulierten Unternehmen und jeder nationalen Aufsichtsbehörde die geregelte, vertraglich gefasste, dokumentierte und getestete Beziehung zu geben, die die Verordnung verlangt.

10. Einwände und Erwiderungen

Die Muttergesellschaft ist kein reguliertes Unternehmen, also gilt DORA nicht für sie. Direkt, nein; über ihre Tochtergesellschaften, vollständig. DORA erreicht die Holding als gruppeninternen IKT-Dienstleister, indem es jede Tochtergesellschaft verpflichtet, sie zu steuern, mit ihr Verträge zu schließen und sie zu beaufsichtigen (Art. 3(20), 30). Eine Gruppe, die das Fehlen einer Zulassung der Muttergesellschaft als Freiheit von DORA liest, hat den Weg der Pflicht mit ihrem Fehlen verwechselt und wird die Pflicht im Register, im Vertrag und in der Prüfung jeder Tochtergesellschaft wartend vorfinden.

Die Zentralisierung der IKT verbessert die Resilienz, also ist Konzentration ein Merkmal, kein Risiko. Beides ist wahr, was der Punkt von Abschnitt 4 ist. Ein gut geführter gemeinsamer Kern senkt die eigene, unabhängige Ausfallwahrscheinlichkeit jeder Tochtergesellschaft; er erhöht zugleich die Wahrscheinlichkeit eines einzigen korrelierten Ereignisses, das die ganze Gruppe auf einmal beeinträchtigt. DORAs Konzentrationsbestimmungen (Art. 29) existieren gerade, weil der zweite Effekt real und von innerhalb eines einzelnen Unternehmens unsichtbar ist. Die gestalterische Aufgabe ist, den ersten Nutzen zu erfassen und zugleich den zweiten zu sehen, zu bepreisen und zu mindern, nicht zu leugnen, dass der Zielkonflikt existiert.

Einen vollständigen Vertrag nach Artikel 30 zwischen einer Muttergesellschaft und ihrer eigenen Tochtergesellschaft zu schreiben, ist juristisches Theater. Das wäre es, wenn der einzige Zweck des Vertrags wäre, eine Checkliste zu erfüllen. Sein wahrer Zweck ist, dem Leitungsorgan der Tochtergesellschaft, das rechtlich für einen Kern verantwortlich ist, der ihm nicht gehört, durchsetzbare Rechte auf Information, Prüfung, Unterstützung und Ausstieg über diesen Kern zu geben. Ohne sie ist die gesetzliche Verantwortung des Leitungsorgans (Art. 5) nominell. Die Formalität ist der Mechanismus, der die Verantwortung ausübbar macht, und die gruppeninterne Konstellation, in der die Gegenpartei ein Schwesterunternehmen mit demselben letztlichen Eigentümer ist, ist genau der Ort, an dem informelle Vereinbarungen jene Rechte ungeschrieben zu lassen pflegen.

Gebündeltes Testen nimmt die Gruppe von der individuellen Testpflicht. Tut es nicht. Die Bündelung (Art. 26–27) ist ein Weg, den gemeinsamen Kern effizient und sicher zu testen, kein Weg, die Pflicht eines Unternehmens zu erfüllen, indem man auf den Test eines anderen verweist. Jede teilnehmende Tochtergesellschaft bleibt individuell verpflichtet, sicherzustellen, dass ihre eigenen kritischen Funktionen im Umfang sind, und auf die Befunde hin zu handeln; die Bündelung betrifft, wie der Test durchgeführt wird, nicht, wessen Pflicht er ist.

11. Grenzen

Dies ist eine an Praktiker gerichtete Analyse, und ihre Grenzen sollten in aller Klarheit genannt werden. Sie ist keine Rechtsberatung; der maßgebliche Text ist die Verordnung und ihre Level-2-Rechtsakte, gelesen mit den Leitlinien der Europäischen Aufsichtsbehörden und jeder einschlägigen zuständigen nationalen Behörde, und die eigenen Rechtsberater einer Gruppe müssen die allgemeine Struktur hier auf ihre konkreten Unternehmen, Zulassungen und Mitgliedstaaten abbilden. Die Artikelverweise beziehen sich auf DORA in seinem Stand von Anfang 2025, mit den damals angenommenen delegierten und Durchführungsrechtsakten; das Detail der technischen Standards und die Aufsichtspraxis unter ihnen werden sich weiter entwickeln. Das Modell aus Abschnitt 4 ist eine Skizze, deren Größen klar genug definiert sind, um messbar zu sein, deren funktionale Formen und illustrative Werte aber gewählt sind, um den Mechanismus sichtbar zu machen, nicht aus den Daten einer Gruppe geschätzt; eine Gruppe sollte $c$, $p_0$ und $q$ aus ihrer eigenen Architektur und Vorfallsgeschichte befüllen, bevor sie irgendeinen Schluss aus den Kurven zieht. Der Aufsatz behandelt zudem den häufigen und reinen Fall eines einzigen zentralen Kerns und einer klaren Trennung von Mutter- und Tochtergesellschaft; reale Gruppen haben mehrere Kerne, teilweise Zentralisierung, zwischengeschaltete Holdings, gemeinsame externe Anbieter hinter dem gruppeninternen und Funktionen, die in einem Mitgliedstaat kritisch sind und in einem anderen nicht, von denen jede das Bild verkompliziert, ohne seine zwei grundlegenden Probleme zu ändern.

12. Fazit

Eine paneuropäische Finanzgruppe, die ihre kritische IKT aus dem Zentrum und ihr reguliertes Geschäft von den Rändern betreibt, hat die sinnvollste Struktur für Effizienz und die unbequemste für DORA gebaut. Die Verordnung bindet jede Tochtergesellschaft einzeln, nimmt an, dass jede ihre eigene IKT kontrolliert, und findet stattdessen, dass ein gemeinsamer Kern, geliefert von einer Muttergesellschaft, die die Verordnung nur aus zweiter Hand erreicht, sie alle kontrolliert. Zwei Probleme folgen: Die Pflicht zur Einhaltung sitzt dort, wo die Kontrolle nicht ist, und die Zentralisierung der IKT konzentriert das Risiko der Gruppe in einem einzigen korrelierten Punkt, dessen Ausfall jede Tochtergesellschaft auf einmal beeinträchtigt und jeder Aufsichtsbehörde gesondert gemeldet wird. Wir haben beide dargelegt, das zweite modelliert, um zu zeigen, dass Zentralisierung eine niedrigere Ausfallwahrscheinlichkeit je Unternehmen gegen eine höhere gruppenweite korrelierte eintauscht, und das Ergebnis vor dem Hintergrund von DORAs Bestimmungen zu Register, Konzentration, Vertrag, Vorfall, Test und Governance gelesen.

Die Antwort ist nicht, den zentralen Kern aufzugeben, sondern ihn so zu steuern, wie DORA es verlangt: ein Gruppenrahmen, sichtbar für jedes Leitungsorgan, gruppeninterne Verträge, geschrieben wie an einen externen Anbieter, ein konsolidiertes Register, gelesen als Konzentrationskarte, eine Reihe von Vorfallsfakten, verteilt in viele Meldungen, und der gemeinsame Kern, einmal getestet für alle, die von ihm abhängen. Jeder Zug verbindet eine Pflicht, die die Verordnung auf die Tochtergesellschaft legte, wieder mit einer Kontrolle, die die Gruppe in der Holding ansiedelte, sodass das, was die Gruppe einmal baute, von jedem Unternehmen, das von ihm abhängt, konform betrieben werden kann. Die tiefere Lehre ist die, die DORA zu vermitteln geschrieben wurde: dass operationale Resilienz keine Eigenschaft einer Plattform ist, sondern der Vorkehrungen um sie herum, und dass in einer Gruppe diese Vorkehrungen, nicht das Beteiligungsdiagramm, darüber entscheiden, ob ein einzelner Punkt der Effizienz auch ein einzelner Ausfallpunkt ist.

Anhang A. Das Modell in voller Form

Das Modell aus Abschnitt 4 verwendet vier Größen, die eine Gruppe allesamt aus ihrer eigenen Architektur und Vorfallsgeschichte schätzen kann. Das Zentralisierungsverhältnis $c$ ist der Anteil der regulierten Tochtergesellschaften der Gruppe, deren kritische oder wichtige Funktionen vom gemeinsamen Kern abhängen; eine Gruppe kann es aus dem konsolidierten Register (Art. 28(3)) ablesen, indem sie von ihren Tochtergesellschaften zählt, wie viele den gruppeninternen Kern hinter einer kritischen Funktion aufführen. Die Kern-Ausfallwahrscheinlichkeit $p_0$ ist die Wahrscheinlichkeit, dass der gemeinsame Kern in einem gewählten Zeitraum eine Störung erleidet, die schwer genug ist, um die kritische Funktion einer abhängigen Tochtergesellschaft zu beeinträchtigen; sie wird aus der eigenen Vorfallsbilanz des Kerns geschätzt, nicht aus der irgendeiner einzelnen Tochtergesellschaft. Die lokale Ausfallwahrscheinlichkeit $q$ ist die entsprechende Wahrscheinlichkeit für die eigene, nicht geteilte IKT einer Tochtergesellschaft. Die Anzahl $n$ ist die Zahl der regulierten Tochtergesellschaften.

Die unabhängige Grundlinie ist der Vergleich, der die Konzentration sichtbar macht. Gäbe es keinen gemeinsamen Kern, bei dem jede Tochtergesellschaft unabhängig mit Wahrscheinlichkeit $q$ ausfällt, wäre die Wahrscheinlichkeit, dass mindestens zwei Tochtergesellschaften im selben Zeitraum beeinträchtigt sind, $1-(1-q)^{n}-nq(1-q)^{n-1}$, was für kleines $q$ näherungsweise $\binom{n}{2}q^{2}$ ist, eine Größe zweiter Ordnung. Mit dem gemeinsamen Kern ist der führende Term derselben Wahrscheinlichkeit $p_0$ mal die Chance, dass mindestens zwei Tochtergesellschaften verdrahtet sind, eine Größe erster Ordnung in $p_0$. Das Verhältnis der beiden ist der Faktor, um den die Zentralisierung die Exposition der Gruppe gegenüber gleichzeitigen Ereignissen über mehrere Unternehmen erhöht, und es ist groß, wann immer $p_0$ nicht viel kleiner als $q^{2}$ ist, was es fast nie ist. Dies ist der formale Gehalt der Behauptung, dass Konzentration die Tochtergesellschaften an ein einziges Risiko koppelt, statt das Risiko über sie zu verteilen.

Zwei Fallstricke verdienen Erwähnung. Der erste ist, $p_0$ aus der Erfahrung einer einzelnen Tochtergesellschaft mit dem Kern zu schätzen, was es unterschätzt, weil eine gegebene Tochtergesellschaft nur jene Kernvorfälle sieht, die sie zufällig beeinträchtigten; $p_0$ muss aus der eigenen Bilanz des Kerns über alle Abhängigen hinweg gelesen werden. Der zweite ist, $c$ als fest zu behandeln, obwohl es eine Entscheidung ist: Die Gruppe wählt, Funktion für Funktion, wie viel sie mit dem Kern verdrahtet, und der Wert des Modells liegt darin, die Kosten – an korreliertem gruppenweitem Risiko – jedes Zuwachses dieser Wahl zu zeigen, sodass die Wahl mit dem Zielkonflikt aus Abbildung 2 vor Augen getroffen wird statt allein aus Effizienzgründen.

Anhang B. Eine Checkliste gruppeninterner Vertragsbestimmungen

Die Checkliste unten versammelt die Bestimmungen des Artikels 30, die eine Tochtergesellschaft in ihrem Vertrag für die gruppeninterne Lieferung einer kritischen oder wichtigen Funktion sichern sollte. Sie ist kein Ersatz für die Verordnung oder für Rechtsberatung; sie ist eine Arbeitsliste für das gestalterische Gespräch zwischen der zentralen IT-Funktion einer Gruppe und den Leitungsorganen ihrer Tochtergesellschaften. Jede Bestimmung ist eine, die die Tochtergesellschaft braucht, um über einen Kern, der ihr nicht gehört, eine Pflicht zu erfüllen, die DORA ihr auferlegt; die gruppeninterne Konstellation ist der Ort, an dem jede am häufigsten implizit bleibt und stattdessen niedergeschrieben werden sollte.

Literatur

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