Warum Risiko, Kontrolle und Vertrag selten aus einem Guss sind

Ein Risikoregister ordnet einer Lieferbeziehung eine Einschätzung zu, ein Kontrollnachweis bestätigt die Absicherung dieser Einschätzung, und ein Vertrag hält fest, wozu sich der Drittanbieter verpflichtet hat. Laut einer Untersuchung des Diligent Institute haben nur 19 Prozent der Organisationen ihre Governance-, Risiko- und Compliance-Funktionen vollständig integriert. In der Praxis liegen die drei Ebenen häufig in getrennten Systemen, gepflegt von unterschiedlichen Funktionen mit eigenem Rhythmus der Aktualisierung. Genau an den Übergabestellen zwischen ihnen entstehen die Lücken, die eine Aufsichtsprüfung oder ein Schadensfall offenlegt.

Was verlangt DORA von der Verbindung zwischen Vertrag und Risiko?

Artikel 28 der Verordnung (EU) 2022/2554 verpflichtet Finanzunternehmen, ein Informationsregister zu allen vertraglichen Vereinbarungen mit IKT-Drittdienstleistern zu führen und dieses lückenlos mit Risikoprüfung und Überwachung zu verknüpfen. Das Register muss auf Einzelbasis sowie gegebenenfalls auf teilkonsolidierter und konsolidierter Ebene geführt werden. Es deckt laut Artikel 28 der DORA-Verordnung den gesamten Lebenszyklus ab: von der vorvertraglichen Sorgfaltsprüfung über laufende Überwachung und Prüfrechte bis zur dokumentierten Exit-Strategie. Nach Artikel 28(3) muss das Register der zuständigen Behörde jährlich sowie zusätzlich auf Anfrage vorgelegt werden, wie die luxemburgische Aufsichtsbehörde CSSF festhält. Die Durchführungsverordnung (EU) 2024/2956 legt dazu die Standardvorlagen fest, nach denen das Register zu strukturieren ist. Die Verordnung stellt zugleich klar, dass die Auslagerung von IKT-Dienstleistungen die regulatorische Verantwortung nicht überträgt: Finanzunternehmen bleiben vollständig verantwortlich. Ein solches Register setzt voraus, dass Risikoregister und Vertragswerk auf dieselbe Lieferantenkennung referenzieren, wie es eine konsequente Third-Party Risk Governance beschreibt.

Was bestätigt die Revisionsstelle wirklich am internen Kontrollsystem?

Die Revisionsstelle prüft nach Art. 728a OR nur, ob ein internes Kontrollsystem existiert, nicht ob es dauerhaft und mängelfrei funktioniert. Nach Art. 728a Abs. 1 Ziff. 3 OR prüft die Revisionsstelle im Rahmen der ordentlichen Revision, ob ein internes Kontrollsystem existiert; Absatz 2 verlangt, dass sie dieses bei Umfang und Durchführung der Prüfung berücksichtigt. Der Schweizer Prüfungsstandard 890, in Kraft seit dem 1. Januar 2008, konkretisiert dies laut dem Rechnungslegungsrecht-Skript des Lehrstuhls Handschin: geprüft wird die Dokumentation von Ausgestaltung und Umsetzung, nicht das laufende Funktionieren des internen Kontrollsystems. Für dessen Aufbau und Betrieb bleibt der Verwaltungsrat verantwortlich, wie ein Fachbeitrag im TREX-Magazin von Michael Annen festhält. Diese Trennung ist der Grund, weshalb ein bestätigtes internes Kontrollsystem im Revisionsbericht keine Aussage darüber trifft, ob eine einzelne vertraglich vereinbarte Kontrolle im Tagesgeschäft tatsächlich greift.

Wie verzahnen die FINMA-Rundschreiben Auslagerung, IKT-Risiko und Kontinuität?

Das FINMA-Rundschreiben 2023/1 verlangt einen angemessenen Informationsaustausch zwischen IKT-Risikomanagement, Business Continuity Management, Auslagerungsmanagement und Notfallplanung, ohne eine bestimmte technische Umsetzung vorzuschreiben. Die FINMA veröffentlichte am 5. Dezember 2017 das revidierte Rundschreiben 2018/3 ‚Outsourcing: Banken und Versicherer‘, das am 1. April 2018 in Kraft trat und die bisherige Regulierung aus dem Jahr 1999 ablöste. Für bestehende Auslagerungsverhältnisse bei Banken und Effektenhändlern galt danach eine Übergangsfrist von fünf Jahren, wie Infoguard am 29. März 2018 berichtete. Am 13. Dezember 2022 veröffentlichte die FINMA das totalrevidierte Rundschreiben 2023/1 ‚Operationelle Risiken und Resilienz: Banken‘, das per 1. Januar 2024 in Kraft trat, wie Lexology am 19. Januar 2023 beschrieb. Das auf den 7. Dezember 2022 datierte Rundschreiben verlangt zudem, operationelle Risiken institutsübergreifend und einheitlich zu kategorisieren sowie in ein Inventar mit Schlüsselkontrollen aufzunehmen.

Wer verantwortet welche Übergabe im Three Lines Model?

Das Three Lines Model ordnet der ersten Linie die Risikosteuerung und Kontrollumsetzung zu, der zweiten Linie die Überwachung dieser Tätigkeiten und der dritten Linie die unabhängige Zusicherung gegenüber dem Verwaltungsrat. Das Institute of Internal Auditors führte das Modell 2013 als Positionspapier ein und aktualisierte es im Juli 2020 zum Three Lines Model, wie die Publikation Diligent am 19. Dezember 2025 beschrieb. Der Begriff ‚Defense‘ wurde dabei bewusst entfernt, um den Fokus über reine Schutzmassnahmen hinaus auf Governance und Wertschöpfung zu erweitern. Für die Übergabe zwischen Risikoregister, Kontrollnachweis und Vertragswerk bedeutet das Modell, dass die erste Linie die vertragliche Verpflichtung im Tagesgeschäft einhält, die zweite Linie deren Abbildung im Risikoregister prüft und die dritte Linie unabhängig bestätigt, ob diese Kette insgesamt hält. Das Modell selbst schreibt keine technische Lösung vor; es beschreibt Zuständigkeit, nicht Werkzeug.

Das Many-to-Many-Problem

Eine einzelne Vertragsklausel, etwa ein Auftragsverarbeitungszusatz, eine Service-Level-Verpflichtung oder eine Haftungsbeschränkung, kann als Kontrolle dienen, die gleichzeitig mehrere Risiken mindert: das Risiko eines Ausfalls eines Anbieters, das Risiko eines Datenschutzverstosses und regulatorische Risiken. Eine einzelne Kontrolle, beispielsweise eine jährliche Sicherheitsüberprüfung eines Anbieters, kann gleichzeitig Verpflichtungen erfüllen, die sich über Dutzende von Verträgen und mehrere Compliance-Frameworks erstrecken. Und ein einzelnes Risiko, etwa die Konzentration auf kritische Anbieter, kann teilweise durch eine Vertragsklausel, teilweise durch eine interne Kontrolle und teilweise durch ein bewusst akzeptiertes Restrisiko abgedeckt sein. Das ist eine Many-to-Many-Beziehung, die in alle Richtungen besteht. Dennoch sind die meisten Register weiterhin um hierarchische Taxonomien herum aufgebaut: Ein Risiko wird einer Kategorie zugeordnet, eine Kontrolle wird einer Framework-Anforderung zugeordnet und ein Vertrag wird einem Anbieter oder einer Geschäftseinheit zugeordnet. Hierarchien eignen sich gut dafür, übersichtliche Berichte zu erstellen; sie sind jedoch schlecht darin, ein solches Netzwerk abzubilden. Jedes GRC-Tool, das versucht hat, Vertragsdaten in ein Risiko- und Kontrollmodell zu integrieren, endet entweder damit, Daten in drei verschiedenen Registern zu duplizieren, oder mit dem Aufbau einer Many-to-Many-Verknüpfungstabelle, der niemand vollständig vertraut, weil niemand das Mandat hat, sie aktuell zu halten.

Welcher erste Schritt schliesst die Lücke zwischen Register und Vertrag?

Der erste Schritt ist, für jede vertragliche Kontrollverpflichtung eine eindeutige Kennung festzulegen, die im Risikoregister, im Kontrollnachweis und im Vertragsdokument identisch verwendet wird. Verantwortlich dafür ist die Funktion, die das Vertragsregister führt, in Abstimmung mit dem Risikomanagement und der Kontrollinstanz. Ohne eine gemeinsame Kennung bleibt jede Aussage zur Konsistenz eine Behauptung, die bei einer Prüfung nicht nachvollzogen werden kann. Wie gross die Tragweite lückenhafter ICT-Risikokontrollen sein kann, zeigt ein Schadensfall im Umfang von 89 Millionen Euro. Gleichen Sie innerhalb des nächsten Prüfungszyklus eine Stichprobe von Verträgen mit hoher Risikoeinstufung gegen Risikoregister und Kontrollnachweis ab. Weichen Kennung oder Aktualisierungsstand voneinander ab, gehört die Korrektur an die Stelle, die das jeweilige Register führt, nicht an eine übergeordnete Koordinationsfunktion.

FAQ

Häufige Fragen

Was ist ein DORA-Informationsregister für IKT-Verträge?

Artikel 28 der Verordnung (EU) 2022/2554 verpflichtet Finanzunternehmen, alle vertraglichen Vereinbarungen mit IKT-Drittdienstleistern lückenlos zu dokumentieren und mit Risikoprüfung und Überwachung zu verknüpfen. Das Register deckt den gesamten Lebenszyklus ab, von der Sorgfaltsprüfung bis zur Exit-Strategie, und ist der zuständigen Behörde jährlich sowie auf Anfrage vorzulegen.

Prüft die Revisionsstelle, ob das interne Kontrollsystem tatsächlich funktioniert?

Nach Art. 728a OR bestätigt die Revisionsstelle im Rahmen der ordentlichen Revision lediglich, dass ein internes Kontrollsystem existiert und dokumentiert ist. Ob es dauerhaft und mängelfrei funktioniert, prüft sie nicht. Für Aufbau und Betrieb bleibt der Verwaltungsrat verantwortlich.

Welche FINMA-Vorgaben gelten für Auslagerung und IKT-Risiko?

Das FINMA-Rundschreiben 2023/1 ‚Operationelle Risiken und Resilienz: Banken‘, seit 1. Januar 2024 in Kraft, verlangt einen angemessenen Informationsaustausch zwischen IKT-Risikomanagement, Business Continuity Management, Auslagerungsmanagement und Notfallplanung. Eine bestimmte technische Umsetzung schreibt es nicht vor.

Was ist das Three Lines Model und wer trägt welche Verantwortung?

Das Three Lines Model, 2020 vom Institute of Internal Auditors aktualisiert, ordnet der ersten Linie die Risikosteuerung und Kontrollumsetzung zu, der zweiten Linie deren Überwachung und der dritten Linie die unabhängige Zusicherung gegenüber dem Verwaltungsrat. Es beschreibt Zuständigkeit, keine technische Lösung.

Wie lässt sich die Lücke zwischen Risikoregister und Vertrag schliessen?

Der erste Schritt ist eine eindeutige Kennung, die für jede vertragliche Kontrollverpflichtung identisch im Risikoregister, im Kontrollnachweis und im Vertragsdokument verwendet wird. Ohne diese gemeinsame Referenz bleibt jede Aussage zur Konsistenz bei einer Prüfung nicht nachvollziehbar.

Quellen

1. Artikel 28 der Verordnung (EU) 2022/2554Springlex
2. Rundschreiben 2023/1 Operationelle Risiken und ResilienzFINMA