GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
Digitale Resilienz ist in den letzten Jahren zu einem festen Begriff in der Finanzwelt geworden. Unternehmen sprechen darüber in Strategiepapieren, Beratungsfirmen verwenden ihn in Hochglanzpräsentationen, und auch Regulierungsbehörden betonen immer wieder seine Bedeutung. Doch während Resilienz lange Zeit vor allem als gutes Ziel galt – als eine Art Leitlinie, an der man sich orientieren konnte – hat sich die Situation mit dem Digital Operational Resilience Act, kurz DORA, grundlegend verändert. Aus der Theorie ist eine gesetzliche Pflicht geworden, und die EU hat dafür fünf zentrale Säulen definiert, die jedes betroffene Unternehmen umsetzen muss. Diese Säulen sind nicht nur Überschriften in einem Gesetzestext, sondern bilden ein verbindliches Gerüst, das alle relevanten Aspekte abdeckt, um den Betrieb auch unter digitalen Extrembedingungen aufrechtzuerhalten. Wer sie versteht, erkennt schnell: Es geht nicht nur um Technik, sondern um ein Zusammenspiel aus Prozessen, Organisation und Kultur.
DORA ist keine weitere „IT-Compliance-Checkliste“, sondern ein Rahmenwerk, das das Zusammenspiel von Risikomanagement, operativem Betrieb, Lieferkette, Testkultur und sektorweitem Lernen in den Mittelpunkt stellt. Der Kernunterschied zu älteren Regelwerken: DORA verlangt Wirksamkeit. Es genügt nicht, Policies zu schreiben oder Tools zu beschaffen. Entscheidend ist, ob ein Institut seine kritischen Dienstleistungen auch dann liefern kann, wenn Teile der IT gestört, angegriffen oder extern beeinträchtigt werden. Messbar wird das an Reaktionszeiten, Wiederanlauf, Qualität der Kommunikation, Stabilität der Lieferkette und geübten Notfallabläufen. Die fünf Säulen bilden dafür die Struktur – die Umsetzung wird am Ergebnis gemessen.
Die erste Säule ist das IKT-Risikomanagement. Darunter versteht DORA die Gesamtheit aller Maßnahmen, mit denen ein Unternehmen Risiken aus der Nutzung von Informations- und Kommunikationstechnologien identifiziert, bewertet, steuert und überwacht. Diese Pflicht ist nicht neu, wird aber durch DORA konkreter und verbindlicher. Es reicht nicht mehr, eine allgemeine Risikoanalyse pro Jahr durchzuführen. Gefordert sind laufende Bewertungen, abgestimmt auf die tatsächliche Bedrohungslage und die individuelle Risikosituation. Das IKT-Risikomanagement muss außerdem klar dokumentiert, regelmäßig vom Management überprüft und an veränderte Umstände angepasst werden. Damit macht DORA deutlich, dass Risikomanagement keine lästige Pflichtübung ist, sondern ein lebendiger, kontinuierlicher Prozess, der in den Alltag integriert werden muss.
Worauf es praktisch ankommt:
Typische Fehlgriffe: Risikoanalysen nur auf Papier, Inventare ohne Owner, Ausnahmegenehmigungen ohne Enddatum, Kennzahlen ohne Zielwerte oder Verantwortliche. DORA verlangt nachvollziehbare Entscheidungen – nicht nur hübsche Matrizen.
Die zweite Säule betrifft das Incident Reporting, also die Meldung von schweren IKT-Vorfällen an die zuständigen Behörden. Auch hier gibt es zwar bereits nationale Vorgaben, doch DORA vereinheitlicht sie und verschärft zugleich die Anforderungen. Künftig gibt es klare Kriterien, was als meldepflichtiger Vorfall gilt, feste Fristen und standardisierte Meldeformate. Ziel ist es, dass Vorfälle EU-weit vergleichbar sind und Behörden schneller reagieren können. Für Unternehmen bedeutet das, dass sie interne Prozesse so aufsetzen müssen, dass Vorfälle nicht nur erkannt, sondern auch bewertet und fristgerecht gemeldet werden können. Dabei ist Zeit oft der kritischste Faktor – wer hier unvorbereitet ist, verliert wertvolle Stunden und riskiert gleichzeitig regulatorische Sanktionen.
Was ein belastbares Vorfallmanagement auszeichnet:
Tipp: Vorfallakten standardisieren. Jede Akte enthält Zeitleiste, Entscheidungen, Meldeweg, Root-Cause, Maßnahmen, Wirksamkeitsnachweis. Diese Evidenz spart Nerven – im Audit und in der Nachbereitung.
Die dritte Säule ist das Digital Operational Resilience Testing. Hier geht es um die Überprüfung der eigenen Resilienz durch gezielte Tests. Das Spektrum reicht von Schwachstellenanalysen und internen Notfallübungen bis hin zu komplexen, realitätsnahen Simulationen, bei denen externe Experten im Rahmen sogenannter Threat-Led Penetration Tests (TLPT) versuchen, in Systeme einzudringen. DORA macht diese Tests verbindlich und schreibt vor, dass ihre Häufigkeit und Tiefe am Risikoprofil des Unternehmens ausgerichtet werden müssen.
Die Handlungsfelder an einem Ausfallszenario verbinden. Spielen Sie eine Unterbrechung bei einem kritischen Dienstleister durch. Prüfen Sie gemeinsam Risikoentscheidung, Reaktion, Testnachweis und Informationswege, damit die einzelnen Themen im Betrieb zusammenpassen.
Operational Resilience ist mehr als Notfallplanung. Die Managementperspektive behandelt digitale Abhängigkeiten, die Vorbereitung auf Störungen und die organisatorische Fähigkeit, kritische Leistungen auch unter Belastung zu steuern.
Von Dr. Markus Groß
Ein sinnvolles Test-Portfolio enthält:
Wichtig ist Follow-up-Disziplin: Findings brauchen Besitzer, Fristen, Prioritäten und einen Wirksamkeits-Check. Tests ohne Abstellmaßnahmen sind Kosmetik.
Die vierte Säule widmet sich dem IKT-Drittparteienrisiko. Angesichts der wachsenden Abhängigkeit von Cloud-Anbietern, Rechenzentren, Software-as-a-Service-Diensten und spezialisierten IT-Dienstleistern ist dieser Bereich besonders kritisch. DORA verlangt, dass Unternehmen ihre Drittanbieter systematisch bewerten, vertraglich absichern und kontinuierlich überwachen. Dazu gehören klare Anforderungen an Sicherheit, Resilienz, Meldepflichten und Exit-Strategien für den Fall, dass ein Anbieter ausfällt oder nicht mehr den Anforderungen entspricht. Besonders bedeutsam ist, dass bestimmte kritische Drittanbieter künftig direkt von europäischen Behörden beaufsichtigt werden. Das entlastet zwar die einzelnen Unternehmen teilweise, ändert aber nichts daran, dass sie für ihre Lieferketten verantwortlich bleiben.
Bausteine eines wirksamen Drittparteien-Managements:
Praxisrealität: Fragebögen reichen nicht. Stichprobenprüfungen, technische Nachweise und (wo möglich) Audits sind nötig, um Vertrauen zu verifizieren.
Die fünfte und letzte Säule ist der Informationsaustausch. Dieser Punkt ist weniger technisch, dafür aber strategisch hoch relevant. DORA fördert, dass Unternehmen innerhalb des Finanzsektors Bedrohungsinformationen, Angriffsmuster und Erfahrungen aus Sicherheitsvorfällen austauschen – freiwillig, aber in strukturierten Formaten. Die Idee dahinter: Wenn Unternehmen voneinander lernen, steigt die kollektive Abwehrfähigkeit des gesamten Sektors. In der Praxis ist dieser Austausch oft eine Herausforderung, weil er Vertrauen und klare Regeln erfordert. Doch richtig umgesetzt, kann er verhindern, dass sich Angriffe unbemerkt von einem Ziel zum nächsten ausbreiten.
Erfolgsfaktoren:
Wer die fünf Säulen isoliert betrachtet, verpasst den Mehrwert. Ein meldepflichtiger Vorfall, der nicht sauber klassifiziert ist, findet nicht den Weg in die Lessons Learned der Risikoorganisation. Ein TLPT-Finding ohne Lieferantenbezug übersieht eine Root Cause im SaaS-Stack. Ein guter Informationsaustausch verpufft, wenn Detection-Use-Cases nicht angepasst werden. Integration heißt: gemeinsame Datenbasis, abgestimmte Metriken, ein einheitliches Reporting und klar definierte Übergabepunkte zwischen Risiko, Betrieb, Compliance, Einkauf, Recht und BCM.
DORA betont die Verantwortung des Top-Managements. Das ist keine Floskel: Ohne regelmäßige Reviews, klare Zielvorgaben und sichtbare Priorisierung durch die Leitung verharren Initiativen in Silos. Bewährt hat sich:
Ein schlanker Satz an Kennzahlen genügt – solange er Entscheidungen ermöglicht:
Zu jeder Zahl gehört eine Erzählung: Warum bewegt sie sich? Welche Maßnahmen wirken? Welche Entscheidung ist fällig?
Viele Institute betreiben wesentliche Teile in der Cloud. DORA ändert daran nichts – verlangt aber Klarheit:
Daten sind der Kern operativer Resilienz:
Gute Technik rettet die Lage – gute Kommunikation schützt Vertrauen:
Phase 1 – Standortbestimmung (4–8 Wochen): Inventar prüfen, Lücken je Säule bewerten, Quick-Wins identifizieren (MFA-Lücken, kritische Patches, Backup-Immutability, Logging-Gaps).
Phase 2 – Governance & Fundamente (8–12 Wochen): Lenkungskreis, KRIs/KPIs, Incident-Playbooks, Lieferanten-Tiering, erste Tabletop-Übungen.
Phase 3 – Ausbau & Integration (3–6 Monate): Resilienztest-Portfolio aufsetzen, Restore-/Failover-Tests, Vertragsnachbesserungen bei kritischen Lieferanten, GRC-/IR-Tooling integrieren.
Phase 4 – Verstetigung (laufend): Quartalsweise Reviews, TLPT-Planung (falls erforderlich), kontinuierliche Verbesserung, Evidenzpflege.
Ein europaweit tätiger Versicherer betrieb Kundenportale in Multi-Cloud-Architektur. Ausgangslage: hohe Tool-Vielfalt, uneinheitliche Kennzahlen, wiederkehrende Patching-Verzüge. Maßnahmen: zentrales KRI-Set, CMDB-Service-Mapping, Cloud-Guardrails, Lieferantentiering mit Nachweisen, Restore-Tests mit Zeitvorgaben, Vorstand-Tabletops. Ergebnis nach neun Monaten: Patch-SLA von 58 % auf 93 %, Restore-Zeit von 9 h auf 2 h, erste meldepflichtige Störung ohne Kundendatenabfluss in < 48 h stabilisiert – dokumentiert, nachvollziehbar, auditfest.
Resilienz entsteht, wenn Menschen wissen, warum sie etwas tun, und spüren, dass es wirkt:
Wer die fünf DORA-Säulen betrachtet, erkennt schnell, dass DORA weit mehr ist als ein weiteres IT-Sicherheitsgesetz. Es verbindet Prävention, Reaktionsfähigkeit, kontinuierliche Verbesserung, Lieferkettensteuerung und kollektive Verteidigung in einem Rahmenwerk, das von allen Marktteilnehmern getragen werden muss. Dabei gibt es bewusst keine Einheitslösungen – jedes Unternehmen muss seinen eigenen Weg finden, die Vorgaben umzusetzen, orientiert am eigenen Risikoprofil. Das macht die Aufgabe komplex, eröffnet aber auch die Möglichkeit, Resilienzmaßnahmen maßgeschneidert und effizient zu gestalten.
In der Praxis wird es entscheidend sein, die Säulen nicht isoliert zu behandeln. Ein Vorfall, der nicht erkannt oder gemeldet wird, kann nicht in die Verbesserung der Tests einfließen. Schwachstellen in der Lieferkette können den besten Notfallplan zunichtemachen. Fehlender Informationsaustausch kann dazu führen, dass andere Unternehmen dieselben Fehler wiederholen. DORA zwingt zu einer integrierten Sichtweise – und genau darin liegt der eigentliche Mehrwert.
Mit der Umsetzung dieser fünf Säulen stellen Unternehmen sicher, dass sie nicht nur die gesetzlichen Vorgaben erfüllen, sondern ihre digitale Widerstandsfähigkeit tatsächlich steigern: weniger Ausfallzeiten, schnellere Reaktionen im Ernstfall, robustere Lieferketten und ein höheres Maß an Vertrauen von Kunden, Partnern und Aufsichtsbehörden. Wer DORA nur als bürokratische Last betrachtet, verpasst die Chance, daraus eine strategische Stärke zu entwickeln. Denn am Ende ist Resilienz nicht nur eine Frage der Compliance – sie ist eine Frage der Zukunftsfähigkeit.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Deine Bewertung hilft bei der Einordnung der Inhalte.
Interessant für dein Netzwerk? Teile den Beitrag direkt.
When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.
We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.
Comments 80
Für mich wäre eine kurze regelmäßige Überprüfung praktikabler als eine seltene große Überarbeitung. Änderungen im normalen Betrieb könnten dabei als Anlass dienen. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Damit kann ich mehr anfangen. Die Grenze zwischen einem hilfreichen Nachweis und zusätzlichem Papier bleibt für mich der entscheidende Punkt. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Könnte diese Lösung nicht gerade bei kleinen Teams zu viel Aufwand verursachen? Ich würde die Mindestanforderung deutlicher abgrenzen. Meine Ausgangsfrage bleibt: Reicht ein Prüfbericht des Anbieters, wenn die eigene Nutzung ganz anders aussieht?
Ein weiterer Punkt: Was bleibt Aufgabe der Organisation, obwohl Mitarbeitende geschult werden? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Das ist ein wichtiger Punkt. Brauchbare Arbeitsmittel und klare Prozesse gehören für mich weiterhin dazu. Schulung sollte nicht dafür herhalten, ungünstige Rahmenbedingungen zu kompensieren.
Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Was müsste bei gemeinsame Priorisierung von Risiken und Maßnahmen für einen neuen Verantwortlichen nachvollziehbar dokumentiert sein?
Ein neuer Verantwortlicher sollte Zweck, Grenzen und offene Punkte der Entscheidung nachvollziehen können. Ein kurzer Entscheidungsvermerk mit den zugrunde liegenden Nachweisen wäre dafür aus meiner Sicht hilfreicher als eine umfangreiche Ablage. Mit Blick auf gemeinsame Priorisierung von Risiken und Maßnahmen würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Ein weiterer Punkt: Wie geht man mit Zielkonflikten zwischen Kontrolle und schneller Umsetzung um? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Für mich liegt der Schwerpunkt hier: Die Abwägung müsste sichtbar entschieden werden. Wenn beide Seiten nur ihre eigene Kennzahl optimieren, bleibt der Konflikt im Gesamtprozess bestehen. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Dazu eine Rückfrage: Wo liegt die Grenze zwischen einem sinnvollen Test und einer zusätzlichen Betriebsgefährdung? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Das ist ein wichtiger Punkt. Ich würde Ziel, Umfang und Abbruchbedingungen gemeinsam mit den zuständigen Funktionen klären. Ein anspruchsvoller Test braucht für mich eine entsprechend belastbare Vorbereitung.
Beim Prinzip bin ich dabei. Bei der Umsetzung könnte aber gerade die Übergabe zwischen zwei Zuständigen schwierig werden. Meine Ausgangsfrage bleibt: Wo liegt die Grenze zwischen einem sinnvollen Test und einer zusätzlichen Betriebsgefährdung?
Ich würde lieber einen vorhandenen Ablauf sinnvoll ergänzen als einen zweiten daneben aufbauen. Voraussetzung ist, dass der gemeinsame Ablauf die unterschiedliche Bedeutung der Aufgaben sichtbar lässt. Das bezieht sich für mich auf den hier beschriebenen Ansatz. Mein Maßstab wäre die nachvollziehbare Wirkung.
Wo würdet ihr bei Nachweise für die Wirksamkeit von Kontrollen anfangen, wenn unter Zeitdruck eine Ausnahme erforderlich wird?
Ich würde zunächst die Ausnahme befristen und mit einem benannten Verantwortlichen sowie einer späteren Überprüfung verbinden. Das schafft eine begrenzte, überprüfbare Arbeitsgrundlage für die weitere Umsetzung. Bei Nachweise für die Wirksamkeit von Kontrollen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Ich sehe den größten Nutzen in Governance mit Steuerungswirkung. Das sollte sich mit wenigen verständlichen Signalen und konkreten Beispielen prüfen lassen.
Ein weiterer Punkt: Wie erreicht man Menschen, ohne mit immer mehr Pflichtinformationen Ermüdung auszulösen? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Mein Vorschlag wäre: Ich würde konkrete Alltagssituationen auswählen und verständliche Handlungsmöglichkeiten anbieten. Mehr Information ist für mich nicht automatisch bessere Unterstützung.
Welche kleine Stichprobe würde bei Entscheidungsrechte bei Ausnahmen zuerst zeigen, ob die Umsetzung im Alltag funktioniert?
Eine kleine, begründete Auswahl konkreter Fälle wäre für mich ein guter Einstieg. Neben einem normalen Ablauf würde ich einen schwierigen Fall prüfen und die Abweichungen kurz dokumentieren. Für Entscheidungsrechte bei Ausnahmen würde ich den ersten Prüfschritt bewusst klein halten.
Dazu eine Rückfrage: Wie viel Kontext gehört zu einem Nachweis, damit Rückfragen nicht unvermeidlich werden?
Ich würde es so einordnen: Ich würde Zweck, Zuordnung und zeitliche Gültigkeit mitgeben. Zu viele unstrukturierte Anlagen können die Prüfung eher erschweren.
Beim Prinzip bin ich dabei. Bei der Umsetzung könnte aber gerade die Übergabe zwischen zwei Zuständigen schwierig werden. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Bei fehlenden Informationen würde ich die Unsicherheit sichtbar machen und eine vorläufige Entscheidung mit klarer Wiedervorlage treffen. Einfach so zu tun, als wäre alles bekannt, wäre die schlechtere Grundlage. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Danke für die Präzisierung. Für mich wäre die Wirkung im Betrieb die interessantere Rückmeldung als die reine Vollständigkeit der Unterlagen. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig. Ich würde dazu einen klaren Prüfanlass festhalten.
Ich würde das nicht allein anhand einer Beschreibung beurteilen. Was wäre ein überzeugender praktischer Nachweis? Meine Ausgangsfrage bleibt: Wie viel Kontext gehört zu einem Nachweis, damit Rückfragen nicht unvermeidlich werden?
Was passiert, wenn ein Vorfall erkannt wird, aber niemand sicher ist, wer entscheiden darf? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Für mich liegt der Schwerpunkt hier: Ich würde Entscheidungspunkte und Vertretungen vorher festlegen. Ein technisch gut erkanntes Problem kann sonst trotzdem im organisatorischen Übergang hängen bleiben.
Das ist mir als Maßstab noch etwas zu weich. Welches Ergebnis müsste sich nach der Änderung nachweisbar verbessern? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.