IKT-Risikomanagement nach DORA: Die erste Säule als Führungsaufgabe

Problem in der Praxis

In vielen Finanzunternehmen war IKT-Risikomanagement de facto an die IT oder an die zweite Verteidigungslinie delegiert. Das Leitungsorgan genehmigte Budgets und nahm Berichte zur Kenntnis, traf aber selten dokumentierte Risikoentscheidungen. Genau dieses Muster trifft DORA.

Das zweite typische Problem ist Fragmentierung. Schutzmaßnahmen, Monitoring, Incident Response und Wiederanlaufplanung existieren, aber als getrennte Inseln mit eigenen Verantwortlichen und ohne durchgängige Logik. DORA betrachtet diese Phasen als einen Kreislauf: Schutz und Prävention, Erkennung, Reaktion und Wiederherstellung sowie das anschließende Lernen und Weiterentwickeln. Fehlt die Verbindung, entstehen Lücken zwischen Erkennung und Reaktion oder zwischen einem Vorfall und der daraus folgenden Verbesserung.

Drittens fehlt oft die Brücke zwischen Norm und Aufsicht. Ein ISMS-Auditbericht beantwortet nicht automatisch die Frage einer Aufsichtsbehörde, wer welche IKT-Risikoentscheidung wann getroffen hat und wie das Leitungsorgan eingebunden war.

CISO-Einordnung

DORA ist regulatorische Pflicht, kein Zertifizierungsschema. Sie beschreibt das Was und Wozu, nicht das vollständige Wie. Das Wie liefert ein ISMS. Der CISO sollte die erste Säule daher nicht als neues Parallelsystem aufbauen, sondern als aufsichtliche Anforderungsschicht auf vorhandene Steuerung legen.

Hilfreich ist eine Einordnung entlang von drei Ebenen:

• Governance-Ebene: Das Leitungsorgan trägt die Letztverantwortung für den Rahmen, genehmigt ihn, überwacht die Umsetzung und muss ausreichende Kenntnis über IKT-Risiken vorhalten. Diese Verantwortung ist nicht vollständig delegierbar.
• Rahmen-Ebene: Der IKT-Risikomanagementrahmen ist dokumentiert, regelmäßig zu überprüfen und deckt Strategien, Leitlinien, Verfahren und Werkzeuge ab.
• Lebenszyklus-Ebene: Schutz und Prävention, Erkennung, Reaktion und Wiederherstellung inklusive Backup- und Wiederanlauflogik, ergänzt um Lernen, Weiterentwicklung und Kommunikation.

Dieser Lebenszyklus lässt sich gut auf etablierte Bezugsrahmen abbilden. Das NIST Cybersecurity Framework strukturiert Sicherheit entlang von Funktionen wie Govern, Identify, Protect, Detect, Respond und Recover; DORAs Phasenlogik korrespondiert dazu inhaltlich, ohne rechtlich daran gebunden zu sein. ISO/IEC 27001 liefert die Managementsystem-Mechanik für Governance, Risikobehandlung und Wirksamkeitsnachweis. Beide sind Strukturhilfe, ersetzen aber die Verordnung nicht.

Umsetzungsperspektive

Aus CISO-Sicht bewährt sich eine Umsetzung in vier Schritten statt eines Großprojekts:

1. Governance verankern. Das Leitungsorgan erhält eine klare, wiederkehrende Rolle: Genehmigung des Rahmens, regelmäßige Risikoberichte, dokumentierte Entscheidungen und nachweisbare Befassung mit IKT-Risiken. Diese Befassung sollte protokolliert sein, nicht informell.
2. Rahmen konsolidieren. Vorhandene ISMS-Artefakte werden auf DORA gemappt statt neu geschrieben. Asset- und Zugriffsmanagement, Risikobehandlung, Business Continuity und Lieferantensteuerung sind in der Regel schon vorhanden und müssen vor allem konsistent und auffindbar gemacht werden.
3. Lebenszyklus schließen. Schutz, Erkennung, Reaktion und Wiederherstellung werden als ein Prozess mit definierten Übergängen betrieben. Besonderes Augenmerk gilt den Schnittstellen: Was löst aus der Erkennung eine Reaktion aus, und wie fließt ein Vorfall in Wiederanlauf und Verbesserung zurück.
4. Nachweisfähigkeit herstellen. Entscheidungen, Tests, Reviews und Verbesserungen erzeugen Spuren, auf die sich die Aufsicht stützen kann. Nachweis sollte Nebenprodukt des Betriebs sein, nicht eine Sonderaktion vor der Prüfung.

Für kleinere Einheiten sieht DORA einen vereinfachten IKT-Risikomanagementrahmen vor (vgl. Art. 16 DORA). Der Umfang skaliert mit Größe, Risikoprofil und Komplexität. Der CISO sollte frühzeitig klären, ob das Unternehmen unter den vereinfachten Rahmen fällt, um Aufwand angemessen zu dimensionieren.

Typische Fehler

1. Das Leitungsorgan wird formal benannt, aber nicht real eingebunden; es fehlen dokumentierte Entscheidungen und nachweisbare Befassung.
2. DORA wird als neues Parallelsystem neben dem ISMS aufgebaut, statt vorhandene Steuerung zu nutzen und aufsichtlich zu schärfen.
3. Schutz, Erkennung, Reaktion und Wiederherstellung bleiben getrennte Silos ohne durchgängige Übergänge.
4. Der Rahmen wird einmal geschrieben, aber nicht regelmäßig überprüft und fortgeschrieben.
5. Proportionalität wird ignoriert: Entweder überzieht ein kleines Unternehmen, oder ein großes beruft sich fälschlich auf Vereinfachung.

Risiken und Trade-offs

Der zentrale Trade-off liegt zwischen Tiefe und Betreibbarkeit. Ein zu schwerer Rahmen erzeugt Dokumentation, die im Alltag niemand pflegt und die im Prüfungsfall veraltet ist. Ein zu schlanker Rahmen liefert nicht die Nachweisbarkeit, die DORA und die Aufsicht erwarten.

Ein zweites Spannungsfeld ist die Abgrenzung von Verantwortung. Das Leitungsorgan kann und soll operative Aufgaben delegieren, trägt aber die Letztverantwortung. Wird diese Grenze unscharf gezogen, entsteht entweder Mikromanagement oder eine Verantwortungslücke.

Drittens besteht das Risiko, DORA rein als Compliance-Übung zu behandeln. Dann werden Artefakte erzeugt, ohne dass sich die tatsächliche operationale Resilienz verbessert. Der eigentliche Zweck, die digitale Widerstandsfähigkeit im Finanzsektor, geht verloren.

Entscheidungspunkte

• Fällt das Unternehmen unter den vollen oder den vereinfachten IKT-Risikomanagementrahmen?
• In welcher Taktung und in welchem Format befasst sich das Leitungsorgan nachweisbar mit IKT-Risiken?
• Welcher vorhandene Bezugsrahmen (ISO/IEC 27001, NIST CSF) dient als Strukturgeber, und wie wird das Mapping zu DORA gepflegt?
• Wie werden die vier Lebenszyklusphasen verbunden, und wer verantwortet die Übergänge?
• Wie entstehen Nachweise automatisch aus dem Betrieb statt manuell vor einer Prüfung?

Praktische Empfehlungen

1. Bauen Sie DORA auf das bestehende ISMS auf und ergänzen Sie gezielt die aufsichtlichen Spezifika statt ein zweites System zu führen.
2. Geben Sie dem Leitungsorgan eine feste, protokollierte Rolle im IKT-Risikomanagement mit klarer Berichts- und Entscheidungstaktung.
3. Betreiben Sie Schutz, Erkennung, Reaktion und Wiederherstellung als einen Kreislauf mit definierten Schnittstellen und Eskalationswegen.
4. Nutzen Sie NIST CSF und ISO/IEC 27001 als Struktur- und Mappinghilfe, behandeln Sie aber die Verordnung als verbindliche Quelle.
5. Verankern Sie Lernen aus Vorfällen und Tests fest im Rahmen, damit Resilienz messbar besser wird und nicht nur dokumentiert ist.
6. Prüfen Sie konkrete Detailpflichten, etwa Klassifizierungs- und Meldevorgaben für Vorfälle, stets an den einschlägigen technischen Standards (RTS/ITS), da diese im Level-2-Recht konkretisiert werden.

Relevante Normreferenzen

• Verordnung (EU) 2022/2554 (DORA), insbesondere die erste Säule zum IKT-Risikomanagement (Kapitel II): Verantwortung des Leitungsorgans, IKT-Risikomanagementrahmen sowie der Lebenszyklus aus Schutz, Erkennung, Reaktion und Wiederherstellung; vereinfachter Rahmen für bestimmte kleinere Einheiten. Verbindlich ist der EUR-Lex-Volltext.
• DORA wird durch Level-2-Recht (RTS/ITS der ESAs) konkretisiert; verbindliche Detailpflichten sind dort gegenzuprüfen.
• ISO/IEC 27001: Referenz für die Managementsystem-Mechanik (Governance, Risikobehandlung, Wirksamkeitsnachweis) als Wie zur DORA-Pflicht.
• NIST Cybersecurity Framework: Referenz für die funktionale Strukturierung (u. a. Schutz, Erkennung, Reaktion, Wiederherstellung) als Outcome-Bezugsrahmen, nicht normativ.