DORA ICT-Drittparteienrisiko & Register of Information

5 Min. LesezeitZuletzt aktualisiert Von Marc Grob

Einleitung

Das Register of Information (RoI) ist das wohl praktischste – und zugleich aufwändigste – Artefakt aus DORA. Art. 28 Abs. 3 der Verordnung (EU) 2022/2554 verpflichtet jede betroffene financial entity, ein umfassendes Verzeichnis aller vertraglichen Vereinbarungen über die Nutzung von ICT-Diensten durch Drittparteien zu führen, zu aktualisieren und jährlich an die zuständige Behörde zu übermitteln. Die Commission Implementing Regulation (EU) 2024/2956 vom 29. November 2024 standardisiert das Format mit 15 Datentabellen.

Dieser Beitrag deckt ab:

  • Die rechtliche Verortung des RoI in Art. 28 DORA und den ergänzenden RTS/ITS.
  • Die 15 Datentabellen der ESA-Vorlage – inhaltlich und prozessual.
  • Die Klassifikation kritischer und wichtiger Funktionen (Art. 3 Abs. 1 Nr. 22 DORA).
  • Den schrittweisen Aufbau eines RoI in 90 Tagen.
  • Häufige Implementierungsfehler und wie man sie vermeidet.

Rechtliche Anker sind die DORA-Hauptverordnung Art. 28-30, die Commission Implementing Regulation (EU) 2024/2956, die ESA-Joint Guidelines on the Register of Information sowie ergänzend RTS Sub-Outsourcing (Commission Delegated Regulation (EU) 2024/1773) und RTS on Critical Functions (Art. 3 Abs. 1 Nr. 22). Für CTPP-Designation gilt zusätzlich Commission Delegated Regulation (EU) 2024/1502.

Warum das RoI das Herzstück von DORA Pillar 4 ist

Das RoI erfüllt mehrere parallele Funktionen, was seinen Aufwand erklärt:

  • Aufsichtsinstrument: Die zuständige Behörde (in DE BaFin/Bundesbank, in LU CSSF, in AT FMA, in IT Banca d'Italia/Consob/IVASS) erhält das RoI jährlich elektronisch und nutzt es für Risikoanalysen, CTPP-Designation und Sektor-Konzentrationsanalysen.
  • Internes Steuerungsinstrument: Das RoI zwingt die Finanzunternehmen zu einer disziplinierten Funktion-zu-Lieferant-Abbildung. Viele Institute entdecken erst beim RoI-Aufbau, dass sie ihre eigenen kritischen Funktionen nie sauber identifiziert hatten.
  • Vertragsgrundlage: Das RoI dokumentiert, welche Verträge welche Funktionen abdecken – Voraussetzung für die Art. 30-DORA-Konformitätsprüfung und die Sub-Outsourcing-Disziplin.
  • Konzentrationsrisiko: Die zuständige Behörde aggregiert RoIs sektorenweit, um Konzentrationsrisiken zu identifizieren (z.B. dass 80% der EU-Vermögensverwalter denselben Cloud-Provider nutzen).
  • CTPP-Designation: Die ESAs nutzen RoI-Daten als Eingangsgrösse für die Designation kritischer Drittdienstleister nach Art. 31 DORA.

Die Komplexität des RoI ist kein Selbstzweck, sondern bildet die multiple Funktion ab. Eine gut geführte RoI-Architektur ist daher gleichzeitig Lieferantenmanagement, Risikomanagement, Vertragsmanagement und Aufsichts-Reporting in einem.

Die 15 Datentabellen der ESA-Vorlage

Commission Implementing Regulation (EU) 2024/2956 strukturiert das RoI in 15 Tabellen, gruppiert in drei thematische Blöcke:

  • Allgemeine Informationen (Tabellen B_01 bis B_03): Identifikation des berichtenden Finanzunternehmens (LEI, Sitz, Tochterstruktur), Übersicht aller Vereinbarungen, Gesamtzahl der ICT-Drittdienstleister.
  • Vertragliche Vereinbarungen (Tabellen B_04 bis B_07): Vertrags-ID, Vertragstyp, Anwendungsfunktionen, Laufzeit, Kündigungsfristen, anwendbares Recht, geltende Gerichtsstände, Vergütung, Verlängerungslogik.
  • ICT-Dienste und Funktionen (Tabellen B_08 bis B_15): ICT-Services-Klassifikation nach Annex III, betroffene Funktionen (kritisch/wichtig vs sonstige), Substituierbarkeit, Sub-Outsourcing-Kette, Standorte der Datenverarbeitung und -speicherung, betroffene EU-Mitgliedstaaten und Drittstaaten, Notfall-Wiederherstellungszeiten, Cyber-Security-Anforderungen.

Insgesamt umfasst eine vollständige Vertragsbeschreibung im RoI rund 90 bis 100 Datenpunkte. Für ein mittelgrosses Institut mit 50-200 ICT-Verträgen ergibt das ein RoI mit 4'500 bis 20'000 Einzeldatenpunkten. Die Pflege erfordert klare Datengovernance, definierte Datenowner und idealerweise ein Tool-gestütztes Repository statt einer reinen Excel-Lösung.

Klassifikation kritischer und wichtiger Funktionen

Art. 3 Abs. 1 Nr. 22 DORA definiert eine kritische oder wichtige Funktion als eine Funktion, deren Ausfall die finanzielle Leistungsfähigkeit, die Tragfähigkeit oder die operative Belastbarkeit erheblich beeinträchtigen würde – oder die Erbringung von Diensten, deren Unterbrechung Auswirkungen auf die Erfüllung von Bewilligungspflichten oder regulatorischen Anforderungen haben würde. Die Klassifikation ist die entscheidende Stellschraube für den DORA-Anwendungsbereich, weil viele Pflichten (Art. 28 Abs. 4, Art. 29, Art. 30 Abs. 3) nur für ICT-Dienste zur Unterstützung kritischer oder wichtiger Funktionen gelten.

Eine bewährte Klassifikationsmethodik:

  1. Funktionsinventar: Sammlung aller Geschäfts- und Unterstützungsfunktionen (typisch 50-150 Funktionen je nach Institutsgrösse).
  2. Impact-Analyse: Bewertung der Auswirkungen eines mehrtägigen Ausfalls auf Kundschaft, Markt, Aufsicht, Reputation und Finanzlage. Quantitative Schwellenwerte (z.B. EUR 1 Mio. Tagesverlust = kritisch).
  3. Regulatorische Sicht: Funktionen, die zur Erfüllung von Bewilligungspflichten dienen, sind automatisch kritisch.
  4. Funktion-zu-Vertrag-Mapping: Welche ICT-Dienste unterstützen welche Funktion? Ein einzelner Vertrag kann mehrere Funktionen unterstützen.
  5. Vererbungslogik: Ist eine Funktion kritisch, sind alle sie unterstützenden ICT-Dienste tendenziell kritisch.

Eine zu enge Klassifikation reduziert den DORA-Aufwand kurzfristig, schafft aber Aufsichtsrisiko (Behörde stellt nachträglich fest, dass weitere Funktionen kritisch waren). Eine zu weite Klassifikation bläht den Implementierungsaufwand auf. Empfehlung: dokumentierte, nachvollziehbare Methodik mit jährlichem Review.

RoI in 90 Tagen aufbauen

Ein bewährter 90-Tage-Plan für ein mittelgrosses Institut:

  1. Tag 1-15 – Methodik und Tooling: Datenstruktur definieren, Tooling-Entscheidung (Excel, GRC-Tool, dediziertes RoI-Tool), Datenowner pro Tabelle benennen, Mapping-Regeln festlegen.
  2. Tag 16-30 – Funktionsinventar und Klassifikation: Workshop-Reihe mit allen Geschäftsbereichen, Erstellung des Funktionsinventars, Klassifikation kritisch/wichtig vs sonstige, Genehmigung durch Risikokomitee.
  3. Tag 31-50 – Vertragsinventarisierung: Sammlung aller ICT-Verträge (typisch verteilt über Einkauf, IT, Compliance, einzelne Geschäftsbereiche), strukturierte Erfassung der 90-100 Datenpunkte pro Vertrag.
  4. Tag 51-70 – Funktion-zu-Vertrag-Mapping: Welche Funktion wird von welchen ICT-Diensten unterstützt? Identifikation von Lücken (Funktion ohne sichtbaren Vertrag) und Redundanzen.
  5. Tag 71-85 – Qualitätssicherung: Datenkonsistenz-Checks, Validierung gegen ESA-Vorlage-Spezifikationen, Stichproben-Audit mit Geschäftsbereichen.
  6. Tag 86-90 – Freigabe und Reporting-Setup: Freigabe durch Geschäftsleitung, Vorbereitung des Aufsichtsreportings, Dokumentation des Pflegezyklus (mindestens jährliches Review).

Realistischer Aufwand: 1.5-3 FTE-Monate für die Aufbauphase, danach 0.3-0.5 FTE für den Pflegebetrieb. Tool-Investitionen liegen je nach Lösung bei CHF 15'000 bis CHF 80'000 pro Jahr.

Sub-Outsourcing und Vertragsanforderungen

Art. 29 DORA und der ergänzende Commission Delegated Regulation (EU) 2024/1773 (RTS on Sub-Outsourcing) verlangen besondere Disziplin in der Sub-Outsourcing-Steuerung. Wesentliche Pflichten:

  • Vorabgenehmigung: Sub-Outsourcing kritischer oder wichtiger Funktionen erfordert die vorherige schriftliche Genehmigung des Finanzunternehmens.
  • Vertragliche Weitergabe: Der ICT-TPP muss die DORA-konformen Vertragsbedingungen vollständig an Sub-Auftragnehmer weitergeben (Flow-Down).
  • Konzentrationsanalyse: Wenn mehrere kritische Funktionen am gleichen Sub-Sub-Lieferanten hängen, ist das im RoI zu dokumentieren und im Risikoregister zu bewerten.
  • Drittstaaten-Spezifika: Sub-Outsourcing in Drittstaaten (insbesondere ohne Datenschutz-Adäquanzbeschluss) verlangt zusätzliche rechtliche Bewertung – inklusive Schrems-II-konformer Transfer-Folgenabschätzung.

Art. 30 DORA mit seinen acht Pflichtklauseln ist der vertragliche Anker. Schweizer Institute, die ICT-Verträge ihrer EU-Tochter prüfen, sehen meist Lücken in mindestens drei Bereichen: Audit-Recht der EU-Aufsicht, Service-Level mit messbaren KPIs, und Exit-Klauseln mit konkreten Migrationsverpflichtungen. Vertragsnachverhandlungen mit grossen Cloud-Providern und SaaS-Vendoren sind oft mühsam, aber meist erfolgreich – die DORA-Standardklauseln der Hyperscaler (AWS, Microsoft, Google, Oracle) haben sich seit Q2 2024 etabliert.

Häufige Implementierungsfehler

Aus realen Implementierungsprojekten 2024-2025 wiederkehrende Stolperfallen:

  • Funktionsinventar als Nachgedanken: Wer ohne klares Funktionsinventar mit der Vertragsinventarisierung beginnt, verliert sich in Datenpunkten ohne Steuerungslogik. Funktion zuerst, dann Verträge.
  • RoI als Excel-Insel: Excel funktioniert für die Initialaufnahme, scheitert aber an Versionierung, Mehrbenutzer-Editierung, Validierung und Audit-Trail. Spätestens beim zweiten Aufsichtsreporting wird ein Tool nötig.
  • Sub-Outsourcing als Black Box: Viele ICT-TPPs liefern unvollständige Sub-Lieferantenlisten. Empfehlung: Vertrag verpflichtet zur quartalsweise aktualisierten Sub-Lieferantenliste mit Standortdaten.
  • Klassifikation einmalig: Funktionen verändern ihren Kritikalitätsgrad – ein neues Produkt, ein abgeschalteter Geschäftsbereich, ein neuer regulatorischer Anker. Jährliches Klassifikations-Review ist Pflicht.
  • Datenowner nicht klar: Wer in der Organisation verantwortet welche der 15 Tabellen? Ohne klare RACI bleibt das RoI eine Compliance-Anstrengung statt einer gelebten Steuerung.
  • Schweizer Mutter ausgeschlossen: Wenn die EU-Tochter ICT-Dienste von der Schweizer Mutter bezieht, ist dieser konzerninterne "Vertrag" im RoI zu erfassen. Wird oft übersehen.

Die meisten Fehler sind nachträglich korrigierbar – aber jeder Korrekturzyklus kostet Aufwand und potenziell Aufsichts-Aufmerksamkeit. Frühzeitige saubere Methodik zahlt sich aus.

Wie SIDD unterstützt

SIDD begleitet Schweizer Institute und ihre EU-Töchter beim RoI-Aufbau und beim laufenden Lieferantenmanagement nach DORA. Wir starten mit einem 2-Wochen-Methodik-Sprint, in dem wir Funktionsinventar, Klassifikation und Datenstruktur definieren. Danach führen wir die Vertragsinventarisierung und das Funktion-zu-Vertrag-Mapping durch und liefern ein qualitätsgesichertes RoI in der ESA-Vorlage.

Für die Vertragsanpassung an Art. 30 DORA liefern wir Klausel-Templates, Verhandlungs-Playbooks und juristische Unterstützung bei der Nachverhandlung mit grossen Anbietern. Auf Wunsch übernehmen wir das laufende Lieferantenmanagement im Mandatsmodell, integriert mit unserem externen CISO-Service.

Für die technische Resilienzbewertung der wichtigsten ICT-TPP liefern wir Penetrationstests und Schwachstellenscans, die Lieferanten-Sicherheit objektiv messen. Vereinbaren Sie ein Erstgespräch über /kontakt oder fordern Sie unter /offerte eine Festpreis-Offerte für den 90-Tage-RoI-Aufbau an.

Sie möchten dieses Thema umsetzen? SIDD bietet die passende Leistung.
Leistung ansehen →

DORA ICT-Drittparteienrisiko & Register of Information

EINBLICK

InfoSec
24. Mai 2026
Marc Grob
Das DORA-Informationsregister aufbauen: rechtliche Grundlage, Datentabellen der ESA-Vorlage, kritische Funktionen und typische Fehler.

Hier können Sie kostenlos unseren Newsletter abonnieren

Vielen Dank! Ihr Beitrag ist eingegangen!
Oops! Something went wrong while submitting the form.