Dokumentierte Resilienz rettet kein kritisches System

92 Prozent der Unternehmen glauben, im Ernstfall ihre Recovery-Ziele erreichen zu können. Wenn es aber so weit kommt, gelingt das weniger als 40 Prozent. Der aktuelle Optro BCM Report zeigt außerdem: 76 Prozent der Unternehmen haben in den vergangenen zwei Jahren einen durch Drittanbieter verursachten Ausfall erlebt. Bei 31 Prozent waren betroffene Prozesse nicht vollständig dokumentiert oder gemappt, 27 Prozent berichteten von nicht erkannten Drittanbieter-Abhängigkeiten. Nur 31 Prozent führen gemeinsame Resilienztests mit kritischen Drittanbietern durch.

von Haibei Wang, Chief Product & Technology Officer, Optro

Für Finanzorganisationen ist das eine unbequeme Erkenntnis. Es fehlt meist nicht an BCM-Plänen, Recovery-Zielen oder Governance-Strukturen, sondern am vollständigen Verständnis der eigenen Laufzeitarchitektur. Pläne und Dokumentationen allein schaffen keine Resilienz – entscheidend ist, dass Prozesse, Abhängigkeiten und Wieder­herstellungs­maßnahmen im Ernstfall tatsächlich funktionieren.

Die blinden Flecken der Laufzeitarchitektur

Die klassische BCM-Dokumentation reicht häufig dort nicht aus, wo operative Resilienz entscheidet: bei den technischen Abhängigkeiten zwischen Geschäftsprozess, Applikation, Plattform, Provider und Betriebsmodell.

Ein Zahlungsverkehrsprozess hängt nicht nur von der Kernbankenanwendung ab, sondern auch von Komponenten wie Identitätsmanagement, API-Gateways, Message Brokern, Datenbanken oder Netzwerkdiensten.“

Fällt eine dieser Komponenten aus, kann ein formal unkritischer Service zum Single Point of Failure für einen kritischen Prozess werden. Viele BCM-Pläne dokumentieren zwar kritische Prozesse, Anwendungen und Recovery Time Objectives (RTO). Wichtig ist jedoch, welche technischen Kontroll-, Daten- und Identitätspfade tatsächlich verfügbar sein müssen, damit ein Prozess nach einem Ausfall wieder anlaufen kann.

Dependency Mapping: Der Graph ist wichtiger als das Dokument

Die dokumentierte Architektur beschreibt, wie ein System entworfen wurde. Die Laufzeitarchitektur zeigt dagegen, wie es unter realen Bedingungen kommuniziert, Daten verarbeitet und Abhängigkeiten tatsächlich nutzt. In vielen Instituten entwickeln sich beide Ebenen auseinander. Microservices werden ergänzt, APIs angepasst, Datenflüsse verlagert oder Cloud-Regionen erweitert. Die Configuration Management Database kann dadurch formal korrekt und operativ dennoch unvollständig sein.

Ein belastbares Dependency Mapping muss deshalb Geschäftsprozesse, Anwendungen, Infrastruktur, Datenflüsse und externe Dienste miteinander verknüpfen. Erst wenn nachvollziehbar ist, über welche Anwendungen, Plattformen, Provider und Datenpfade ein Geschäftsprozess tatsächlich läuft, lassen sich Kaskadeneffekte realistisch bewerten.

SLA ist kein Recovery-Nachweis

Besonders deutlich wird dies bei der Third-Party Resilience. Ein SLA beschreibt Verfügbarkeit, Reaktionszeiten oder Vertragsstrafen. Es belegt jedoch nicht, dass ein Anbieter gemeinsam mit der Bank einen Prozess innerhalb des geforderten RTO wiederherstellen kann. Dafür sind technische Runbooks, getestete Kommunikationswege, Transparenz über Subdienstleister sowie gemeinsame Übungen erforderlich.

Wer Hyperscaler, Managed-Service-Provider oder SaaS-Plattformen nutzt, muss außerdem Konzentrationsrisiken auf der Control Plane berücksichtigen.“

Eine Multi-Region-Architektur bietet nur begrenzten Schutz, wenn Identitätsmanagement, DNS oder zentrale Deployment-Pipelines weiterhin dieselbe Abhängigkeit aufweisen.
Resilienztests müssen deshalb näher an der technischen Realität stattfinden. Tabletop Exercises machen Rollen und Eskalationswege sichtbar. Ob ein kritischer Prozess tatsächlich wiederhergestellt werden kann, zeigen jedoch erst Game Days und technische Failover-Tests.

Simuliert werden sollten typische Ausfallszenarien wie der Ausfall einer Cloud-Region, eines Identity Providers, fehlerhafte DNS-Einträge oder unterbrochene Netzwerkverbindungen.
Ebenso wichtig sind Tests der Messaging- und Datenbankebenen sowie kompletter Prozessketten. Auch Chaos Engineering kann helfen, Architekturannahmen zu überprüfen und Schwachstellen in Runbooks aufzudecken, vorausgesetzt, Fehlerhypothesen, Blast Radius, SLOs und Stop-Kriterien sind klar definiert.

Recovery-Ziele müssen gemessen werden, nicht behauptet

RTO und RPO sind in vielen Organisationen zunächst Zielwerte aus der Business Impact Analysis. Aussagekräftig werden sie erst, wenn sie unter realen Bedingungen gemessen werden. Das RTO endet erst, wenn ein Geschäftsprozess mit allen erforderlichen Daten, Schnittstellen und Berechtigungen wieder vollständig nutzbar ist.
Auch das RPO ist mehr als eine Backup-Kennzahl.

Entscheidend ist, ob Daten vollständig, konsistent und in der richtigen Reihenfolge wiederhergestellt werden können.“

Nachweisen lässt sich das nur durch Restore-Tests, Integritätsprüfungen und die Messung tatsächlicher Replikations­verzögerungen.
Zur technischen Evidenz gehören daher nicht nur Backup-Logs, sondern auch Monitoring- und Incident-Daten, Messwerte zur Wiederherstellungsdauer, Hinweise auf SLO-Verletzungen sowie Informationen über Datenverluste, Queue-Rückstände, manuelle Workarounds und die tatsächliche Wiederanlaufzeit kompletter Prozessketten.

Klare Steuerung benötigt

Operative Resilienz setzt eine klare Steuerung voraus. Rollen, Eskalationspfade, technische Verantwortlichkeiten und Entscheidungsbefugnisse müssen vor einem Krisenfall feststehen. Während Runbooks technische Arbeitsschritte beschreiben, koordinieren Playbooks Abläufe über Teams und Provider hinweg. Automatische Alarmierung sollte deshalb nicht nur Infrastrukturzustände melden, sondern auch Auswirkungen auf Services und Geschäftsprozesse sichtbar machen.

Das Ziel ist ein operationalisiertes Resilienzmodell mit aktuellen Abhängigkeitsgraphen, durchgängiger Observability, Dashboards für kritische Geschäftsservices, regelmäßigen Recovery-Drills, gemeinsamen Tests mit Drittanbietern und einer Governance, die technische Evidenz höher bewertet als die Vollständigkeit von Dokumentationen.“

Für Finanzunternehmen liegt die nächste Reifestufe nicht in zusätzlicher Dokumentation, sondern in der Fähigkeit, Störungen technisch vorherzusehen, Kaskadeneffekte zu begrenzen und Recovery unter realistischen Bedingungen nachzuweisen. Compliance bleibt notwendig, genügt allein aber nicht.

Wer seine Abhängigkeiten nicht kennt, kann sie nicht steuern. Wer sie nicht testet, kann seine Recovery-Ziele nicht belegen. Wer sie erst im Incident erkennt, verfügt nicht über operative Resilienz, sondern lediglich über gut dokumentierte Annahmen.

Haibei „Happy“ Wang, Optro