Kritisch oder wichtig? Risiko-Level von Core Banking bis CRM, Data Lake und CDP

Teil 7 von 7 unserer DORA-Serie: Die Frage „kritisch oder wichtig?“ ist keine technische Etikette, sondern eine Steuerungsentscheidung für Auslagerung, Vertrag und Resilienz. Sie knüpft an den Exit-Plan nach DORA und die Analyse der Cloud-Abhängigkeit europäischer Banken an. Dieser Beitrag zeigt, weshalb Core Banking und Zahlungsverkehr meist anders zu bewerten sind als CRM, Data Lake, CDP oder Marketing-Automation.

Autor: acceleraid Redaktion

Die Einstufung entscheidet über die Tiefe der Pflichten

DORA definiert eine „kritische oder wichtige Funktion“ als eine Funktion, deren Ausfall die finanzielle Leistungsfähigkeit, Solidität oder Fortführung der Geschäftstätigkeit erheblich beeinträchtigen würde. Dasselbe gilt, wenn eine unterbrochene, fehlerhafte oder unterbliebene Ausführung die fortlaufende Einhaltung von Zulassungsbedingungen und sonstigen Pflichten erheblich beeinträchtigt. Der Maßstab fragt damit nicht zuerst nach dem Namen eines Systems, sondern nach den Folgen seines Ausfalls. (DORA, Art. 3 Nr. 22 sowie Art. 28 und 30)

Diese Unterscheidung ist der Schalter für die strengeren Anforderungen. Bei IKT-Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen kommen insbesondere zusätzliche Vertragsinhalte, Ausstiegsstrategien, die strukturierte Erfassung im Informationsregister und Resilienztests in den Blick. Deshalb ist „wichtig“ nicht die mildere, folgenlose Alternative zu „kritisch“. Beide Begriffe bilden unter DORA eine gemeinsame regulatorische Schwelle.

Für die Governance folgt daraus eine einfache Regel: Nicht eine zentrale IT-Liste klassifiziert Anwendungen pauschal. Die Fachverantwortung beschreibt die Funktion und ihre Ausfallwirkung; Risiko, Compliance, Datenschutz, Einkauf und IT bewerten diese nachvollziehbar zusammen. Das Ergebnis muss für Verträge, Register und Exit-Plan dieselbe Sprache sprechen.

Von der Systembezeichnung zur Geschäftsfolge

Die EBA-Auslagerungsleitlinien konkretisieren die Prüfung. Eine Funktion ist nach deren Kriterien kritisch oder wichtig, wenn ein Ausfall die Zulassungsbedingungen, die finanzielle Performance oder die Solidität und Fortführung wesentlich beeinträchtigen würde. Das gilt ebenso für ausgelagerte operative Aufgaben interner Kontrollfunktionen und für erlaubnispflichtige Tätigkeiten. Die Leitlinien benennen außerdem Kern-Geschäftsfelder, Datenschutz, Substituierbarkeit, Alternativen und Zeitkritikalität als relevante Prüf- und Dokumentationspunkte. (EBA/GL/2019/02, Rn. 29–31 und 55)

Für Banken sind Einlagengeschäft, Kreditvergabe und Zahlungsverkehr fachliche Ankerkategorien. Core-Banking- und Zahlungssysteme fallen daher typischerweise in die kritische Kategorie: Ein längerer Ausfall kann Leistungserbringung, regulatorische Pflichterfüllung und Kundenvertrauen zugleich treffen. Die finale Zuordnung bleibt dennoch eine institutsbezogene Bewertung der konkreten Funktion und ihrer Abhängigkeiten.

Die praktische Frage lautet daher nicht: „Ist das eine Cloud- oder SaaS-Anwendung?“ Sondern: „Welche fachliche Fähigkeit fällt aus, wenn dieser Dienst nicht verfügbar ist?“ Ein Data Lake kann beispielsweise bloß Analysen verzögern. Er kann aber auch Daten für Risikosteuerung, Meldewesen oder Kundenentscheidungen bündeln. Dieselbe Technologiebezeichnung führt dann zu unterschiedlichen Risikobildern.

Kundensysteme: regelmäßig relevant, nie automatisch gleich

CRM, Data Lake, CDP und Marketing-Automation sind keine pauschal unkritischen Systeme. Sie verarbeiten häufig personenbezogene Daten, prägen Kundenkommunikation und können in mehreren Journeys zugleich eingebunden sein. Gerade deshalb ist eine Einzelfallprüfung erforderlich: Ausfallwirkung, Reputations- und Verlustrisiko, Übertragbarkeit, Wiedereingliederung sowie der Schutz personenbezogener Daten sind gemeinsam zu betrachten.

Für diese kundennahen Workloads ist „wichtig“ häufig der sachgerechte Ausgangspunkt der Prüfung: Nicht weil Marketing automatisch regulierungsfern wäre, sondern weil die Bank die Kombination aus Kundendaten, Kommunikationsfähigkeit, Betriebsunterbrechung und Wechselmöglichkeit bewerten muss. Ein CRM kann etwa für eine überschaubare Vertriebskampagne ersetzbar sein. Ist es zugleich das führende System für Beratungskontakte, Beschwerden oder erforderliche Kundenkommunikation, erhöht das die Ausfallwirkung. Eine CDP kann isolierte Zielgruppenlisten liefern; sie kann aber auch Identitäten, Einwilligungen und Echtzeitaktivierung für zentrale Journeys verbinden. Entscheidend ist die tatsächlich erbrachte Funktion, nicht das Produktetikett.

Auch ein Data Lake lässt sich nicht allein nach seiner technischen Rolle klassifizieren. Wer ihn für historische Auswertungen nutzt, bewertet andere Folgen als ein Institut, das auf ihm aktuelle Risikodaten oder entscheidungsrelevante Kundeninformationen bereitstellt. Marketing-Automation ist entsprechend nicht nur ein Versandkanal: In der Bewertung zählen auch Frequenzregeln, die Abhängigkeit von Einwilligungen, Fehlerfolgen und die Frage, ob alternative Kommunikationswege rechtzeitig funktionieren.

Die Einzelfallprüfung braucht deshalb belastbare Antworten auf fünf Fragen:

• Welche wesentliche Geschäfts-, Kontroll- oder erlaubnispflichtige Tätigkeit wird durch den Dienst unterstützt?

• Was passiert während eines Ausfalls mit Kund:innen, Zahlungs- oder Entscheidungsprozessen, Meldungen und Fristen?

• Welche personenbezogenen Daten liegen dort, und welche Datenschutzfolgen hätte ein Ausfall, Fehlzugriff oder fehlerhafter Betrieb?

• Ist ein alternativer Anbieter oder ein interner Betrieb realistisch verfügbar – mit Daten, Schnittstellen, Know-how und Zeit?

• Können Teams die Funktion wiederherstellen oder geordnet übergeben, ohne neue operative Risiken zu erzeugen?

Die Fragen verbinden Fachlichkeit und Technik. Sie verhindern auch den verbreiteten Denkfehler, dass ein extern betriebenes System automatisch schwer substituierbar sein müsse. Substituierbarkeit ist zu belegen, nicht zu unterstellen.

Substituierbarkeit ist kein Bauchgefühl

Die EBA verlangt für das Auslagerungsregister eine Einschätzung der Substituierbarkeit als „easy, difficult or impossible“, die Benennung alternativer Anbieter, Angaben zur Zeitkritikalität und zum Jahresbudget. Damit wird aus dem abstrakten Wechselrisiko eine prüfbare Dokumentation.

Die DORA-ITS verankern diese Logik im Informationsregister. B_06.01 dient der Identifikation von Funktionen; B_07.01 erfasst die Bewertungen einschließlich Substituierbarkeit und letztem Audit. Die gleiche Registerlogik unterscheidet IaaS, PaaS und SaaS sowie Infrastruktur/Hosting und On-Premise-Software. Eine CDP als SaaS zu erfassen, ersetzt somit nicht die Bewertung der darauf laufenden Kundenfunktion. (DORA-ITS, VO (EU) 2024/2956)

Was nach der Einstufung konkret anders wird

Ist eine ausgelagerte IKT-Leistung als Unterstützung einer kritischen oder wichtigen Funktion eingestuft, reicht ein allgemeiner SaaS-Vertrag nicht aus. Er braucht vollständige Servicelevel-Beschreibungen mit qualitativen und quantitativen Leistungszielen, Notfallpläne, laufende Überwachung, Teilnahme an TLPT sowie eine Ausstiegsstrategie mit verbindlichem Übergangszeitraum. Leistungs- und Datenverarbeitungsorte müssen transparent sein und geplante Änderungen vorab mitgeteilt werden.

Das Exit-Thema ist dabei kein Anhang für den Krisenordner. DORA verlangt umfassende, dokumentierte, ausreichend getestete und regelmäßig überprüfte Ausstiegspläne. Der vorherige Serienteil zum Exit-Plan erläutert die Testlogik im Detail. Die EZB nennt mindestens einen vertieften Desktop-Review durch fachkundige Mitarbeitende, Walkthroughs, periodische Tests kritischer Migrationsschritte und eine unabhängige Machbarkeitsprüfung als gute Praxis. (EZB-Cloud-Leitfaden)

Mit der Einstufung wird auch die Lieferkette relevant. Für kritische oder wichtige Funktionen verlangt die einschlägige Delegierte Verordnung eine Zulässigkeitsentscheidung vor Vertragsschluss, Prüfungsrechte bis in die Subunternehmerkette und wiederkehrende Bewertungen, einschließlich geopolitischer Risiken. (Delegierte VO (EU) 2025/532) Wer eine CDP oder Marketing-Automation als wichtig bewertet, muss folglich nicht nur Funktion und Datenfluss verstehen, sondern auch Vertrag, Datenstandorte, Unterauftragnehmer und Übergabeweg zusammenführen.

Ein kurzer Blick auf Schweiz und Vereinigtes Königreich

Die Einordnung ist kein rein europäisches Spezialthema. In der Schweiz definiert FINMA-Rundschreiben 2023/1 kritische Funktionen institutsbezogen und verlangt für jede kritische Funktion eine Unterbrechungstoleranz. Business-Impact-Analysen sollen Wiederanlaufzeit und Wiederanlaufpunkt bestimmen und über SLAs abgesichert werden. (FINMA-RS 2023/1)

Im britischen CTP-Regime muss ein designierter kritischer Drittanbieter je Service ein maximal tolerierbares Unterbrechungsausmaß festlegen und den betroffenen Finanzunternehmen mitteilen. Die Perspektive ist dort auf Anbieterpflichten gerichtet, verfolgt aber dieselbe operative Frage: Welche Leistung darf wie lange ausfallen? (Bank of England, PS16/24)

Fazit: „wichtig“ sauber begründen, „kritisch“ belastbar absichern

Core Banking und Zahlungsverkehr sind typischerweise kritisch, weil sie direkt an zentrale Bankfunktionen und Zulassungsanforderungen anschließen. Kundensysteme wie CRM, Data Lake, CDP und Marketing-Automation sind dagegen keine Kategorie mit vorgegebenem Ergebnis. Sie gehören in eine dokumentierte Einzelfallprüfung und werden je nach Ausfallwirkung, Datenbezug und Substituierbarkeit häufig als wichtige Funktionen zu behandeln sein.

Der richtige Arbeitsmodus ist deshalb wiederholbar: Funktion abgrenzen, Ausfallwirkung bewerten, Daten- und Abhängigkeitsbild prüfen, Substituierbarkeit belegen, Einstufung im Register dokumentieren und die daraus folgenden Vertrags- und Exit-Maßnahmen steuern. So wird DORA nicht zu einer Liste von Systemnamen, sondern zu einer belastbaren Entscheidung darüber, welche Bankfähigkeit im Störfall geschützt werden muss.

Die DORA-Serie im Überblick

• Teil 1: DORA für Banken: Was die EU-Verordnung regelt und wie sie funktioniert

• Teil 2: Der Exit-Plan nach DORA: Was er enthalten muss und warum er getestet werden muss

• Teil 3: Cloud-Abhängigkeit europäischer Banken: Wie man von AWS, Microsoft und Google notfalls loskommt

• Teil 4: Exit-Option für Customer-Engagement-Workloads: CDP, Personalisierung und Kampagnen DORA-konform absichern

• Teil 5: Das DORA-Informationsregister: Warum es in Wahrheit ein Datenqualitätsproblem ist

• Teil 6: KI-Anbieter als neues Konzentrationsrisiko: Was DORA für Modell-Abhängigkeiten bedeutet

• Teil 7: Kritisch oder wichtig? Risiko-Level von Core Banking bis CRM, Data Lake und CDP (dieser Beitrag)

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.