IT-, KI- und GRC-Beratung
T-NEX berät Banken und Versicherungen bei Softwarevorhaben und GRC-Prozessen. Mit Fachkonzept, technischer Planung und vereinbartem Umsetzungsumfang.
Service entdeckenBei jedem Fremdbezug muss ein Institut bestimmen, welche Leistung es tatsächlich bezieht und welchem Regelwerk sie unterliegt. Die Einordnung als Auslagerung nach MaRisk und die Einordnung als IKT-Dienstleistung nach DORA folgen unterschiedlichen Kriterien. Davon hängen Risikoanalyse, Vertragsanforderungen, Register und Exit-Vorkehrungen ab.
Für Auslagerungsmanagement, Einkauf, Informationssicherheit, Rechtsabteilung und Fachbereiche deutscher Kreditinstitute.
Die MaRisk-Fassung vom 30. Juni 2026 nimmt in der Erläuterung zu AT 9 Tz. 1 IKT-Dienstleistungen nach Art. 3 Nr. 21 DORA aus dem Anwendungsbereich des AT 9 aus, soweit sie dem IKT-Drittparteienrisikomanagement nach Art. 28 bis 30 DORA unterliegen. Die Ausnahme betrifft damit eine definierte Leistungskategorie. Sie ist keine pauschale Freistellung jedes IT-Vertrags von sämtlichen Organisationspflichten.
Zuerst ist außerdem der Institutsstatus zu prüfen. Die aktuelle MaRisk richtet sich grundsätzlich an national beaufsichtigte Institute; bedeutende Institute unter direkter EZB-Aufsicht sind nach AT 2.1 ausgenommen. DORA hat einen eigenen Anwendungsbereich. Für deutsche Banken im jeweiligen Anwendungsbereich bleiben daneben gesetzliche Vorgaben, insbesondere § 25b KWG bei Auslagerungen, gesondert zu berücksichtigen. Eine Ausnahme im Rundschreiben hebt die gesetzlichen Anforderungen nicht für sich genommen auf.
Für AT 9 ist zu untersuchen, ob ein anderes Unternehmen Aktivitäten oder Prozesse übernimmt, die ansonsten das Institut selbst erbringen würde. Erst anschließend bewertet die Risikoanalyse, ob die Auslagerung wesentlich ist. Ein Vertragsname wie Unterstützung oder Beratung entscheidet diese Frage nicht.
DORA erfasst fortlaufend erbrachte digitale Dienste und Datendienste im Sinne seiner IKT-Definition. Auch ein Bezug, der bislang als sonstiger Fremdbezug behandelt wurde, kann darunter fallen. Danach ist zu bewerten, ob die IKT-Leistung eine kritische oder wichtige Funktion unterstützt. Ein gemischter Vertrag kann mehrere Leistungen enthalten, die jeweils eine eigene Einordnung benötigen.
| Prüffrage | MaRisk AT 9 | DORA Art. 28–30 |
|---|---|---|
| Worauf wird abgestellt? | Übernahme institutstypischer Aktivitäten oder Prozesse im AT-9-Anwendungsbereich | Vertragliche Nutzung von IKT-Dienstleistungen durch ein erfasstes Finanzunternehmen |
| Risikoeinstufung | Wesentliche oder nicht wesentliche Auslagerung | Unterstützung einer kritischen oder wichtigen Funktion |
| Vertragslogik | Besondere Anforderungen an wesentliche Auslagerungen | Mindestinhalte für IKT-Verträge plus zusätzliche Inhalte für kritische/wichtige Funktionen |
| Typischer Fehler | Wesentlichkeit allein anhand des Vertragswerts bestimmen | Nur bereits als wesentlich eingestufte Auslagerungen untersuchen |
Die Analyse sollte den unterstützten Geschäftsprozess, mögliche Unterbrechungen, betroffene Daten, rechtliche Risiken und die tatsächlichen Handlungsoptionen des Instituts verbinden. Eine teure, leicht ersetzbare Leistung kann anders zu bewerten sein als ein günstiger Dienst ohne kurzfristige Alternative. Maßgeblich ist die Auswirkung auf das Institut.
Für IKT-Dienste verlangt DORA insbesondere eine Vorprüfung, Due Diligence und die Betrachtung von Konzentrationsrisiken. Dazu gehört nicht nur der direkte Vertragspartner. Mehrere Anwendungen können auf denselben Cloud-Anbieter oder denselben Unterauftragnehmer angewiesen sein. Für Dienste mit kritischen oder wichtigen Funktionen konkretisiert die Delegierte Verordnung 2025/532 den Umgang mit Unterauftragsvergabe.
Eine nachvollziehbare Entscheidung hält fest, welche Informationen vorlagen, welche Annahmen unsicher bleiben und wer ein Restrisiko akzeptiert hat. Ausfallannahmen müssen zur Business-Impact-Analyse und zur Notfallplanung passen. Die Bewertung ist bei relevanten Änderungen der Leistung oder Lieferkette erneut aufzugreifen.
DORA Art. 30 unterscheidet allgemeine Mindestinhalte von zusätzlichen Anforderungen für IKT-Dienste, die kritische oder wichtige Funktionen unterstützen. Zu prüfen sind unter anderem Leistungsumfang, Daten- und Leistungsorte, Unterstützung bei Vorfällen, Behördenkooperation, Kündigung sowie bei kritischen oder wichtigen Funktionen präzise Serviceziele, Prüfungsrechte und Übergangsvorkehrungen.
Das DORA-Informationsregister nach Art. 28 Abs. 3 erfasst grundsätzlich die vertraglichen Vereinbarungen über IKT-Dienste und beschränkt sich nicht auf kritische Funktionen. Das Auslagerungsregister nach § 25b KWG hat einen anderen gesetzlichen Anknüpfungspunkt und enthält im einschlägigen Anwendungsbereich wesentliche und nicht wesentliche Auslagerungen. Die Anforderungen sind getrennt zu beurteilen; technisch müssen daraus keine voneinander isolierten Datenbestände entstehen.
Eine gemeinsame Vertragsreferenz kann Leistung, Anbieter, nutzende Einheit, unterstützte Funktion, Bewertung, Laufzeit und Lieferkette verbinden. Daraus lassen sich unterschiedliche Registeransichten ableiten. Welche Felder und Lieferketteneinträge für eine konkrete Einreichung verlangt werden, bestimmt der jeweils geltende amtliche Template- und Meldeumfang.
Für IKT-Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen fordert DORA Art. 28 Abs. 8 dokumentierte und ausreichend getestete Ausstiegspläne. Die Strategie muss einen Ausstieg ermöglichen, ohne Geschäftsaktivitäten unvertretbar zu beeinträchtigen oder die Erfüllung regulatorischer Anforderungen zu gefährden. Die Vertragsregelungen nach Art. 30 Abs. 3 müssen einen angemessenen Übergang unterstützen.
Ein Exit-Plan benennt die Auslöser, etwa anhaltenden Ausfall, schwerwiegende Leistungsprobleme oder unerwartete Kündigung. Dazu kommen die Zielalternative, erforderliche Daten, Rechte an Konfigurationen, Ressourcen, Kostenannahmen, Zeitplan und Entscheidungsträger. Die Wiederherstellung beim bisherigen Anbieter ist ein anderer Anwendungsfall als der Wechsel auf eine unabhängige Lösung.
Bei wesentlichen Nicht-IKT-Auslagerungen sind die einschlägigen MaRisk-Vorgaben zu Handlungsoptionen und Ausstiegsstrategien zu berücksichtigen. Etwaige gruppenbezogene Erleichterungen aus AT 9 dürfen nicht ungeprüft auf DORA-Verträge übertragen werden. Die Zugehörigkeit zu einer Gruppe beseitigt eine Abhängigkeit technisch nicht.
Das folgende fiktive Beispiel betrifft einen Reporting-Dienst, der eine kritische oder wichtige Funktion unterstützt. Es beschreibt mögliche Prüfschritte, keine vorgeschriebene einheitliche Testmethode. Umfang und Tiefe müssen zur Kritikalität, Austauschbarkeit und möglichen Unterbrechungsdauer passen. Ein Planspiel allein belegt noch keine funktionierende Datenmigration.
Der Test sollte messbare Abnahmekriterien enthalten. Dazu zählen fachlich vollständige Daten, funktionierende Berechtigungen und ein Bericht, der aus dem exportierten Bestand auf der Zielumgebung erzeugt werden kann. Wenn einzelne Schritte nur simuliert wurden, wird diese Grenze dokumentiert. Offene Lücken erhalten einen Verantwortlichen und einen Termin für Nachbesserung und erneuten Nachweis.
| Testschritt | Prüfung | Nachweis |
|---|---|---|
| Auslöser und Entscheidung | Wer darf den Wechsel auslösen und bis wann? | Protokoll der Eskalationsübung |
| Datenexport | Sind Daten, Historie und benötigte Konfigurationen vollständig? | Abgleich von Datensatzanzahl, Summen und Versionen |
| Zielbetrieb | Kann die alternative Umgebung einen vereinbarten Bericht erstellen? | Reproduzierbares Ergebnis und fachliche Abnahme |
| Übergang und Abschluss | Funktionieren Zugänge, Umschaltung und geregelter Entzug alter Rechte? | Ablaufprotokoll, Restpunkteliste und Abschlussentscheidung |
Verträge bleiben während ihrer Laufzeit in Bewegung. Ein neuer Datenstandort, ein zusätzlicher Unterauftragnehmer, veränderte Servicezeiten oder ein schwacher Exit-Test können eine Neubewertung erforderlich machen. Die zuständigen Funktionen brauchen deshalb klare Meldewege und eine Verbindung zwischen Vertragsänderung, Risikobewertung, Register und Maßnahmen.
Berichte an die Geschäftsleitung sollten die für Entscheidungen relevanten Abhängigkeiten zeigen: schwer ersetzbare Leistungen, wiederholte Leistungsstörungen, Konzentrationen und überfällige Abhilfen. Ein Zertifikat des Anbieters beantwortet nicht automatisch jede Frage zum konkret bezogenen Dienst. Auch die europäische Einstufung eines Anbieters als kritische IKT-Drittpartei ersetzt die eigene Risikosteuerung nicht.
Ein konkreter Einstieg ist die Verbindung von Vertragsbestand, Leistungsinventar, Bewertungen und offenen Maßnahmen. T-NEX kann mit Ihrem Institut Verantwortlichkeiten und Freigaben strukturieren sowie die benötigten Datenwege und Berichte umsetzen. Ob bestehende Komponenten passen oder eine Erweiterung notwendig ist, wird am vorgesehenen Arbeitsfall geprüft.
Für eine Registeraufbereitung oder einen Exit-Workflow werden Datenumfang, technische Übergaben und Abnahmekriterien ausdrücklich vereinbart. Daraus folgt keine pauschale Zusage eines bereits verfügbaren DORA-Meldeexports oder einer regulatorischen Freigabe. Der Anbieter muss außerdem selbst die Informationen liefern, die Ihr Institut für seinen Dienstleisterprüfprozess benötigt.
Nein. Die Begriffe stammen aus unterschiedlichen Regelwerken und Bewertungslogiken. Eine vorhandene MaRisk-Bewertung ist ein Input, ersetzt aber die DORA-Einordnung der Funktion und ihrer IKT-Unterstützung nicht.
Nein. Art. 28 Abs. 3 DORA erfasst grundsätzlich die vertraglichen Vereinbarungen über die Nutzung von IKT-Diensten. Für die Unterstützung kritischer oder wichtiger Funktionen gelten zusätzliche Angaben und Anforderungen.
DORA schreibt keinen universellen vollständigen Produktivwechsel für jeden Test vor. Der Test muss angemessen belegen, dass der Plan umsetzbar ist. Technische Teiltests, Migrationsübungen und organisatorische Übungen sind anhand des konkreten Risikos zu kombinieren.
Nein. Die Verantwortung für die ordnungsgemäße Organisation und Risikosteuerung bleibt beim Institut. Mögliche Erleichterungen müssen aus dem jeweils anwendbaren Regelwerk hergeleitet werden.
T-NEX berät Banken und Versicherungen bei Softwarevorhaben und GRC-Prozessen. Mit Fachkonzept, technischer Planung und vereinbartem Umsetzungsumfang.
Service entdecken
Vom Upload eines Regelwerks bis zum Prüfbericht: T-NEX Compliance verbindet Anforderungen, Bewertung, Maßnahmen und laufende Fortschrittskontrolle.
Mehr erfahren
Freigaben und wiederkehrende Arbeitsschritte in einer Anwendung verbinden. T-NEX entwickelt Prozesslösungen auf vorhandenen Plattformbausteinen.
Service entdeckenGesellschaften, internationale Teamstandorte, Datenzugriffe und Betriebsverantwortung: konkrete Themen für die Anbieterprüfung einer Zusammenarbeit mit T-NEX.
Mehr erfahren