Ein DORA-Risikomanagementrahmen muss zeigen, wie ein Finanzunternehmen seine Leistungen trotz IKT-Störungen schützen und wiederherstellen kann. Eine Sammlung von Richtlinien genügt dafür nicht. Zwischen Geschäftsprozess, technischer Abhängigkeit, Risiko, Kontrolle und Leitungsentscheidung muss ein nachvollziehbarer Zusammenhang bestehen.
Die Artikel 5 bis 15 der Verordnung (EU) 2022/2554 bilden den allgemeinen Rahmen. Artikel 16 regelt einen besonderen vereinfachten Rahmen für ausdrücklich genannte Unternehmen. Dieser Beitrag führt durch einen ausgefüllten Arbeitsfall: Ein fiktives, dem allgemeinen Rahmen unterliegendes Zahlungsinstitut überprüft die Widerstandsfähigkeit seiner Zahlungsfreigabe. Die Zahlen im Beispiel sind interne Planungsannahmen und keine allgemeinen gesetzlichen Grenzwerte.
Den anwendbaren Rahmen vor der Kontrollplanung bestimmen
Zuerst wird die eigene Einordnung nach Artikel 2 mit den einschlägigen Ausnahmen dokumentiert. Eine Tätigkeit im Finanzumfeld allein beantwortet die Anwendbarkeit nicht. Danach folgt die Prüfung, ob Artikel 16 tatsächlich einschlägig ist. Die Vorschrift nennt unter anderem kleine und nicht verflochtene Wertpapierfirmen sowie bestimmte nach dem jeweiligen sektoralen Recht freigestellte Zahlungs- und E-Geld-Institute.
Eine geringe Beschäftigtenzahl eröffnet Artikel 16 nicht automatisch. Die dort genannten Kategorien und Bedingungen müssen erfüllt sein. Davon zu unterscheiden sind einzelne Erleichterungen für Kleinstunternehmen innerhalb des allgemeinen Rahmens. Beispielsweise verlangt Artikel 6 Absatz 5 grundsätzlich eine mindestens jährliche Überprüfung, bei Kleinstunternehmen eine periodische Überprüfung. Diese Unterschiede dürfen nicht zu einem vermeintlichen allgemeinen „DORA-Light für kleine Firmen“ vermischt werden.
Im Arbeitsfall hält die Rechtsfunktion fest, weshalb das Zahlungsinstitut dem allgemeinen Rahmen unterliegt. Die zuständigen Rollen verwenden diese Einordnung für ihre Kontrollliste. Verhältnismäßigkeit nach Artikel 4 beeinflusst die Ausgestaltung anhand Größe, Gesamtrisikoprofil und Art, Umfang sowie Komplexität der Leistungen. Sie bedeutet nicht, dass ausdrücklich geltende Pflichten nach Belieben weggelassen werden können.
Eine konkrete Leitungsentscheidung vorbereiten
Artikel 5 weist dem Leitungsorgan die Definition, Genehmigung, Überwachung und Verantwortung für die Umsetzung des IKT-Risikomanagements zu. Operative Aufgaben können verteilt werden. Die Verantwortung verschwindet jedoch nicht dadurch, dass ein Dienstleister die Infrastruktur betreibt oder eine Fachabteilung die Dokumentation erstellt.
Das Leitungsorgan des Beispielinstituts erhält eine Entscheidungsvorlage mit drei Fragen: Welche Zahlungsfunktionen sind betroffen? Welche Unterbrechungen und Datenverluste kann das Institut nach seiner Auswirkungsanalyse tolerieren? Welche Maßnahmen und Mittel sind erforderlich, um diese Ziele belastbar zu erreichen? Die Vorlage verbindet dabei Risikotoleranz, Wiederanlaufplanung und Budget, statt nur eine fertige Richtlinie zur Unterschrift vorzulegen.
Im Beispiel wird entschieden: Die Zahlungsfreigabe benötigt einen überprüften Ersatzbetrieb. Eine alleinige Zusage des Cloudanbieters reicht als Nachweis nicht aus. Ein Projektteam bekommt Ressourcen, um Wiederherstellung und fachliche Abstimmung zu erproben. Die Kontrollfunktion berichtet offen über die verbleibende Abhängigkeit. Mitglieder des Leitungsorgans müssen ihre Kenntnisse zu IKT-Risiken aktuell halten; der konkrete Schulungsbedarf wird aus den Entscheidungen abgeleitet, die sie tatsächlich beurteilen müssen.
Geschäftsleistung und technische Abhängigkeiten verbinden
Artikel 8 verlangt die Identifikation und Dokumentation IKT-gestützter Funktionen, Rollen, Informationswerte, IKT-Assets und Abhängigkeiten. Ein reines Geräteverzeichnis ist dafür zu eng. Ein Server kann technisch verfügbar sein, während die Zahlungsfreigabe wegen eines ausgefallenen Identitätsdienstes stillsteht.
| Element der Zahlungsfreigabe | Konkrete Abhängigkeit im Beispiel | Verantwortlicher Nachweis |
|---|---|---|
| Anmeldung der Freigabeberechtigten | Identitätsdienst und starke Authentisierung | IT dokumentiert regulären und kontrollierten Notfallzugang |
| Prüfung des Zahlungsauftrags | Aktueller Auftragsbestand und Berechtigungsregeln | Fachbereich bestätigt Datenvollständigkeit und Freigabelogik |
| Übermittlung der Freigabe | Schnittstelle zum Abwicklungssystem | Betrieb weist Erreichbarkeit und Fehlerbehandlung nach |
| Nachvollziehbarkeit | Zeitlich zuordenbare Protokolle | Sicherheitsfunktion prüft Erfassung, Schutz und Auswertung |
| Wiederherstellung | Sicherung, Schlüssel und einsatzfähige Zielumgebung | Notfallteam führt technischen und fachlichen Wiederanlauf durch |
| Externe Unterstützung | Cloud- und Supportverträge einschließlich Unterabhängigkeiten | Dienstleisterverantwortliche halten Kontakte, Leistungen und Grenzen fest |
Das Inventar erhält Beziehungen zwischen diesen Elementen. Bei einer wesentlichen Änderung wird nicht nur ein neuer Produktname eingetragen. Das Team prüft, ob sich ein gemeinsamer Ausfallpunkt, eine Wiederherstellungsannahme oder die Kritikalität einer Funktion verändert. Die Abhängigkeiten fließen zugleich in das Drittparteirisikomanagement und den Ausstiegsplan ein.
Risiken als überprüfbare Szenarien formulieren
„Cyberangriff“ ist als Risikobeschreibung zu allgemein. Im Beispiel lautet ein Szenario: Ein kompromittiertes Administratorkonto verändert Berechtigungen und deaktiviert die zentrale Protokollierung. Dadurch könnten unzulässige Zahlungsfreigaben entstehen und die spätere Rekonstruktion erschwert werden. Ein zweites Szenario betrifft den Ausfall des Identitätsdienstes ohne kurzfristig nutzbaren Ersatzweg.
Für jedes Szenario werden Eintrittswege, Auswirkungen und vorhandene Kontrollen beschrieben. Die Fachseite bewertet, welche Zahlungen betroffen wären und welche Folgen Verzögerungen oder falsche Freigaben hätten. Die IT beurteilt technische Wiederherstellbarkeit. Die Kontrollfunktion hinterfragt Annahmen, beispielsweise ob der Notfallzugang vom ausgefallenen Dienst selbst abhängt.
Das Ergebnis ist im Beispiel kein einzelner grüner Gesamtwert. Für den Administrationsfall wird die Trennung privilegierter Rollen als vorhandene Maßnahme bestätigt, eine unzureichende Alarmierung aber als offene Lücke erfasst. Für den Identitätsausfall ist der dokumentierte Ersatzweg noch nicht erprobt. Das Institut behandelt diesen Punkt bis zum erfolgreichen Nachweis als verbleibendes Risiko.
Schutz und Erkennung mit konkreten Kontrollen umsetzen
Artikel 9 behandelt Schutz und Prävention, Artikel 10 die Erkennung. Die Delegierte Verordnung (EU) 2024/1774 konkretisiert Werkzeuge, Methoden, Prozesse und Richtlinien. Die Zuordnung erfolgt deshalb nicht nur zur Überschrift eines DORA-Artikels, sondern zu den tatsächlich einschlägigen Anforderungen und ihrem vorgesehenen Nachweis.
Für privilegierte Zugriffe entscheidet das Beispielinstitut, dass persönliche Administrationskonten, begrenzte Berechtigungen und starke Authentisierung eingesetzt werden. Eine Änderung an sicherheitsrelevanten Parametern benötigt eine dokumentierte Freigabe. Ein Notfall darf einen beschleunigten Ablauf haben, muss aber weiterhin nachvollziehbar sein und nachbearbeitet werden. Gemeinsame Kennwörter ohne individuelle Zuordnung würden diese Kontrolle unterlaufen.
Die Erkennung prüft mehr als den Eingang von Protokolldaten. Das Team löst in einer geeigneten kontrollierten Umgebung ein definiertes Ereignis aus und verfolgt, ob es einen Alarm erzeugt, die zuständige Person erreicht und eine Reaktion auslöst. Ein Bericht „Logging aktiviert“ beweist diese Kette nicht. Bei personenbezogenen Protokollen werden Zweck, Zugriff und Aufbewahrung zugleich datenschutzrechtlich begrenzt.
Für gespeicherte Daten und Übertragungen verbindet das Institut Datenklassifikation, Risiko und Schlüsselverantwortung. Der Beitrag zur Verschlüsselung personenbezogener Daten hilft, den Schutz an den einzelnen Stationen zu konkretisieren. Eine pauschale Liste kryptografischer Begriffe ersetzt nicht die Prüfung des tatsächlichen Zugangswegs.
Wiederanlaufziele fachlich begründen und erproben
Die Business-Impact-Analyse nach Artikel 11 untersucht schwere Betriebsunterbrechungen mit qualitativen und quantitativen Kriterien. Sie berücksichtigt Funktionen, unterstützende Prozesse, Dienstleister und ihre gegenseitigen Abhängigkeiten. Daraus müssen geeignete Wiederanlauf- und Wiederherstellungsentscheidungen entstehen.
Im Beispiel setzt das Institut für einen internen Übungsfall ein Wiederanlaufziel von zwei Stunden und einen maximal tolerierten Rückstand von fünfzehn Minuten an. Diese Werte sind fiktive Entscheidungen, die nur nach einer passenden Auswirkungsanalyse tragfähig wären. Sie werden nicht als DORA-Vorgabe für alle Zahlungsinstitute ausgegeben.
Die erste Übung stellt das System nach neunzig Minuten technisch wieder her. Die fachliche Abstimmung offener Zahlungsaufträge dauert jedoch weitere zwei Stunden. Das Ziel wurde damit verfehlt, obwohl die Infrastruktur rechtzeitig verfügbar war. Der Befund lautet: „Technischer Wiederanlauf erfolgreich, nutzbarer Zahlungsbetrieb außerhalb des freigegebenen Ziels.“ Das Team erhält einen konkreten Auftrag zur Verbesserung der Abstimmung und plant die erneute Überprüfung.
Artikel 11 Absatz 6 sieht im allgemeinen Rahmen mindestens jährliche Tests der dort genannten Kontinuitäts- und Wiederherstellungspläne sowie zusätzliche Prüfungen bei wesentlichen Änderungen der IKT-Systeme für kritische oder wichtige Funktionen vor. Artikel 12 behandelt Sicherungs- und Wiederherstellungsverfahren. Der Leitfaden zur Backup-Wiederherstellung vertieft die praktische Trennung von Kopie, Wiederherstellbarkeit und funktionierendem Betrieb.
Kommunikation und Vorfallbehandlung in die Übung aufnehmen
Ein wiederhergestelltes System beantwortet noch nicht, wer Kunden über ausstehende Zahlungen informiert oder eine aufsichtsrechtliche Meldung prüft. Artikel 14 verlangt Kommunikationsvorkehrungen; die konkrete Vorfallbehandlung und Meldung folgt zusätzlich den dafür geltenden DORA-Regeln. Die Übung sollte deshalb auch das Erkennen, Klassifizieren und Eskalieren des Ereignisses enthalten.
Das Beispielteam hält einen gemeinsamen Faktenstand fest: Beginn der Störung, betroffene Funktion, Umfang, bestätigte Datenfolgen und bisherige Maßnahmen. Rechtliche Entscheidungen werden daraus gesondert abgeleitet. Für die Abstimmung von DORA und DSGVO ist das wesentlich, weil ein Betriebsereignis und eine Verletzung personenbezogener Daten unterschiedliche Prüfungen auslösen können.
Ebenso wird keine pauschale zusätzliche NIS2-Meldung für jedes DORA-Unternehmen angenommen. Die sektorale Sonderregelung und die konkrete Rolle müssen berücksichtigt werden. Der Beitrag zu parallelen Vorfallmeldungen führt diese Zuständigkeits- und Fristentscheidungen zusammen.
Änderungen anhand desselben Funktionsmodells prüfen
Vor einer Migration des Identitätsdienstes verwendet das Institut die bestehende Abhängigkeitskarte erneut. Es prüft, ob alte Notfallkonten weiter funktionieren, ob die neue Schnittstelle dieselben Berechtigungsregeln übernimmt und ob ein Rückfall auf den bisherigen Dienst tatsächlich möglich ist. Die Freigabe verlangt außerdem einen benannten Abbruchpunkt und eine verantwortliche Person für die Rückentscheidung. Im Beispiel wird die Migration verschoben, weil der bisherige Dienst bereits vor Abschluss der fachlichen Prüfung abgeschaltet werden sollte. Damit hätte ein dokumentierter Rückfallplan praktisch nicht ausgeführt werden können. Der Befund verändert die Umstellungsreihenfolge, nicht nur den Text der Richtlinie.
Den Rahmen anhand von Befunden weiterentwickeln
Artikel 6 verlangt einen dokumentierten und überprüften Rahmen, Artikel 13 das Lernen aus Ereignissen und Prüfungen. Im Beispiel erhält jeder wesentliche Befund einen Verantwortlichen, eine Maßnahme, einen Termin und einen Nachweis für die Schließung. Die Aussage „mit dem Dienstleister besprochen“ schließt die fehlende Wiederherstellbarkeit nicht ab.
Die Kontrollfunktion bewertet die Umsetzung mit ausreichender Unabhängigkeit. Interne Prüfungen richten sich nach den einschlägigen Vorgaben und einem risikoorientierten Prüfplan. Eine Zertifizierung oder ein vorhandenes Informationssicherheitsmanagement kann Nachweise liefern, ersetzt aber keinen Abgleich mit den konkreten DORA-Anforderungen. Veraltete Normtabellen sollten nicht ungeprüft als aktuelle Zuordnung übernommen werden.
Der nächste Leitungsbericht enthält deshalb vier Aussagen: Welche Ziele wurden erreicht? Welche Lücken bleiben? Welche Risiken ändern sich durch neue Dienstleister oder Technik? Welche Entscheidung wird jetzt benötigt? Im Zahlungsbeispiel ist die offene fachliche Wiederanlaufzeit deutlich sichtbar. Erst die erneute erfolgreiche Übung erlaubt es, den Befund zu schließen und die dokumentierte Widerstandsfähigkeit entsprechend anzupassen.
Wer dafür ein Werkzeug auswählt, sollte eine durchgängige Beispielakte vorführen lassen: von der Funktion über die Abhängigkeit und das Risiko bis zum Nachweis der Maßnahme. Die Kriterien für DORA-Compliance-Software können eine Beschaffungsprüfung strukturieren. Ob die Dokumentation zunächst in einem bestehenden System oder einem neuen Werkzeug geführt wird, ist eine Betriebsentscheidung; ihre Vollständigkeit, Aktualität und Prüfbarkeit müssen in beiden Fällen tatsächlich erreicht werden.