Wissensraum · Deep Dive 3 von 27
Warum Architektur entscheidender ist als Risikotabellen
Was dieser Deep Dive Ihnen zeigt
Warum Architektur bei ICT-Risikomanagement entscheidender ist als Risikotabellen.
DORA rückt das Management von ICT-Risiken in den Mittelpunkt der operativen Steuerung. In der Praxis wird ICT Risk Management jedoch häufig reduziert auf Risikotabellen, periodische Risiko-Workshops oder abstrakte Risikomatrizen.
DORA verlangt deutlich mehr: ein integriertes Risikosystem, das technische Realitäten abbildet, organisatorische Abhängigkeiten sichtbar macht und Governance, Verantwortlichkeiten und Entscheidungswege verknüpft.
Arbeitet mit abstrakten Risikokategorien
Häufig top-down organisiert
Zu generisch für technische und digitale Risiken
Keine systematische Verbindung zu Architektur, Datenflüssen oder Kontrollen
Einordnung
Diese Modelle eignen sich zur Gesamtsteuerung, greifen jedoch für ICT-Risiken im Sinne von DORA zu kurz.
Deutlich näher an technischen Risiken
Strukturierte Betrachtung von Bedrohungen und Kontrollen
Häufig stark technisch umgesetzt
Organisatorische Verantwortung bleibt unklar
Governance-Strukturen werden nicht konsequent mitmodelliert
Risiken werden entlang von Geschäftsprozessen betrachtet
Bessere Anschlussfähigkeit an Organisation und Abläufe
Technische Abhängigkeiten gehen verloren, wenn die Systemarchitektur nicht klar ist
DORA verbindet alle diese Perspektiven ausdrücklich: technische Risiken, organisatorische Risiken, interne und externe Abhängigkeiten, Datenflüsse, Governance und Verantwortlichkeiten sowie kritische Geschäftsprozesse.
Kernlogik Risiken entstehen dort, wo Architektur, Prozesse und Zuständigkeiten aufeinandertreffen.
Technische Tests bleiben wichtig, zeigen aber lediglich einzelne Schwachstellen zu einem bestimmten Zeitpunkt unter definierten Testbedingungen. Sie zeigen nicht: strukturelle Abhängigkeiten, organisatorische Verantwortungsbrüche, systemische Risiken zwischen Komponenten oder die Reaktions- und Entscheidungsfähigkeit bei Vorfällen. Genau diese Aspekte stehen im Zentrum von DORA.
Ausgangssituation
Ein mittelgroßer Finanzdienstleister bereitet sich auf DORA vor. Das ICT Risk Register ist vollständig, sauber dokumentiert und auditfähig. Ein Incident im Kundencenter führt dennoch zu erheblichen Ausfallzeiten. Auslöser: ein blockierter File-Processing-Service.
Was sich im Nachgang zeigt
Der Service war kritisch, aber nicht als solcher klassifiziert
Mehrere abhängige Systeme waren unbekannt
Ein Ausfall stoppte die gesamte Output-Pipeline ohne Alarmierung
Dem Incident Manager fehlten aktuelle Datenflussdokumente
Warum das passieren konnte
Risikoanalyse basierte auf abstrakten Kategorien („Verfügbarkeit hoch“)
Architektur war nur auf konzeptioneller Ebene dokumentiert
Abhängigkeiten zwischen Systemen waren nicht sichtbar
Keine Verzahnung zwischen Risk Management, IT und Operations
Ergebnis
Das Risk Register war korrekt – das Risikosystem jedoch unzureichend.
Zentrale Erkenntnisse
ICT Risk Management ist unter DORA eine Architekturentscheidung – nicht nur ein Audit-Thema
Lieferkettenschärfe, Drittanbieterkaskaden und Exit-Fähigkeit sind nicht optional
Qualitative Risikoeinschätzung bleibt – wird aber durch kontinuierliche Metriken flankiert
Datenfluss- und Abhängigkeitsanalysen integrieren: Kritische Services inklusive aller technischen und organisatorischen Abhängigkeiten.
Rollen und Verantwortlichkeiten klar zuordnen: Eindeutige ICT-Risk-Owner pro kritischem Service.
Messbare Kontrollen etablieren: Monitoring, Health Checks, Failover-Mechanismen.
Eine Risikoarchitektur ergänzen: Strukturelles Modell aus Prozessen, Systemen, Datenflüssen und Zuständigkeiten – ergänzend zum Risk Register.
Praxis-Impuls
Stellen Sie Ihrem Risk-Team die Frage: Können wir für jeden kritischen Geschäftsprozess benennen, welche Systeme und Abhängigkeiten daran hängen? Wenn die Antwort „nein“ oder „nur teilweise“ lautet, haben Sie keine Risikoarchitektur – sondern eine Risikodokumentation.