Risikomanagement-Software für Finanzdienstleister: IKT-Risiken gemeinsam steuern

Bei einer ausgelagerten IT-Leistung sind die Informationen verteilt: Der Betrieb kennt die Technik, der Fachbereich die Ausfallfolgen und der Einkauf den Vertrag. Die Risikobewertung muss diese Beiträge zusammenführen, damit die Leitung entscheiden kann.

Hier geht es um IKT- und operative Sicherheitsrisiken. An einer Vertragsänderung prüft ihr, wie Fachbereich, Betrieb, Kontrollfunktion und Leitung zur Entscheidung kommen. Kredit-, Markt- und Liquiditätsrisikomodelle benötigen andere Auswahlkriterien.

Das wichtigste Auswahlkriterium: getrennte Verantwortung, gemeinsamer Sachverhalt

Nehmt einen externen Authentifizierungsdienst. Der Betrieb kennt seine Technik, der Fachbereich die Folgen einer Unterbrechung, Einkauf die Vertragsbedingungen. Die Kontrollfunktion muss die Bewertung hinterfragen können, ohne dafür selbst zum Betreiber zu werden.

Prüft diese Rollen mit getrennten Konten. Ein gemeinsamer Datensatz ist hilfreich; eine Oberfläche, in der jeder jede Entscheidung überschreiben kann, ist es nicht.

Den regulatorischen Rahmen vor dem Produktumfang klären

Der Begriff Finanzdienstleister umfasst unterschiedliche Unternehmen. Für DORA sind Anwendungsbereich und mögliche Ausnahmen nach Artikel 2 sowie der einschlägige Risikomanagementrahmen zu prüfen. Nicht jeder kleine Anbieter benötigt dieselbe Umsetzung wie eine große Bank.

Wenn ihr eine umfassende DORA-Plattform sucht, prüft zusätzlich Register, Geschäftsfortführung, Vorfälle und Resilienztests. Der Guide zur DORA-Register-Datenqualität vertieft einen dieser Bereiche. Dieser Artikel konzentriert sich auf die Qualität eurer IKT-Risikoentscheidungen und deren Übergaben.

Was Kopexa für diese Arbeit liefert

Informationswerte und Assets bilden die betroffenen Daten und technischen Abhängigkeiten ab. Risiken und Maßnahmen geben der Behandlung eine Struktur. Eine BIA am Prozess unterstützt die Bewertung zeitabhängiger Ausfallfolgen; Nachweise an Maßnahmen dokumentieren, was tatsächlich umgesetzt und geprüft wurde.

Ziele und KPIs helfen bei der laufenden Überwachung. Beispielsweise ist „Wiederherstellung erfolgreich innerhalb des festgelegten Ziels“ aussagekräftiger als „Test erledigt“. Messwerte können über die API einfließen. Die fachliche Definition und die Bewertung einer Abweichung bleiben erforderlich; dazu passt der Kennzahlen-Guide.

Der entscheidende Test ist eine Vertragsänderung

Lasst den Authentifizierungsdienst im Pilot sein Ersatzverfahren ändern. Verfolgt, wer diese Änderung bewertet, welche bisherige Annahme betroffen ist und ob eine neue Maßnahme notwendig wird. Eine zuvor akzeptierte Restlücke darf nicht allein deshalb weiter gelten, weil ihr Status unverändert ist.

Prüft den Risikoreview und die spätere Rekonstruktion: Kann eine unbeteiligte Person erklären, auf welcher Grundlage die Entscheidung getroffen wurde? Genau hier trennt sich eine operative Arbeitsgrundlage von einem bloßen Risikobericht.

Schnittstellen statt eines unklaren All-in-one-Versprechens

Haltet fest, welches System für Verträge, technische Inventare und finanzielle Risikomodelle führend bleibt. Definiert gemeinsame Kennungen und Verantwortliche für Änderungen. Ein automatisierter Import ohne geklärte Datenhoheit verlagert die Abstimmung nur in die Fehlerbehandlung.

In Kopexas begleiteter Testphase könnt ihr einen vollständigen IKT-Risikofall mit diesen Beteiligten bearbeiten. Die Abnahme sollte an der erklärbaren Entscheidung hängen, nicht an der Anzahl importierter Datensätze.