DORA IKT-Notfallkonzept erstellen in 7 Schritten

Ein Cyberangriff, der Ausfall eines Rechenzentrums oder die Nichtverfügbarkeit eines Cloud-Providers wird nicht erst dann zum DORA-Thema, wenn der technische Schaden sichtbar ist. Entscheidend ist, ob kritische Geschäftsservices innerhalb akzeptierter Zeit wieder funktionieren und ob Verantwortliche unter Druck handlungsfähig bleiben. Wer ein DORA IKT-Notfallkonzept erstellen will, benötigt deshalb mehr als eine Sammlung technischer Wiederanlaufanweisungen. Er benötigt eine belastbare Verbindung aus Governance, ITSCM, BCM und Krisenmanagement.

DORA verlangt einen steuerbaren Notfallbetrieb

Der Digital Operational Resilience Act verpflichtet betroffene Finanzunternehmen seit dem 17. Januar 2025, ihre digitale operationale Resilienz systematisch zu organisieren. Die Anforderungen betreffen nicht nur präventive Informationssicherheit. Sie reichen von IKT-Risikomanagement über das Management von IKT-Drittdienstleistern bis zu Resilienztests und der Behandlung IKT-bezogener Vorfälle.

Für die Notfallvorsorge ist besonders relevant: Die Organisation muss kritische oder wichtige Funktionen auch bei schwerwiegenden Störungen aufrechterhalten oder geordnet wiederherstellen können. Eine IKT-Business-Continuity-Policy und angemessene Wiederanlauf- und Wiederherstellungsmaßnahmen sind daher kein isoliertes Compliance-Artefakt. Sie müssen im Ernstfall ausführbar, mit den Geschäftsanforderungen abgestimmt und regelmäßig getestet sein.

Ein einzelnes Dokument mit dem Titel IKT-Notfallkonzept genügt nicht. Prüffähig wird das Konzept erst durch klare Zuständigkeiten, nachvollziehbare Abhängigkeiten, realistische Wiederanlaufziele, aktuelle Notfallpläne und belastbare Nachweise aus Übungen. Der Umfang hängt dabei von Geschäftsmodell, Kritikalität der Services, Architektur und Auslagerungsgrad ab. Ein Zahlungsdienstleister mit hoher Cloud-Abhängigkeit setzt andere Schwerpunkte als ein Finanzunternehmen mit weitgehend eigener Infrastruktur.

DORA IKT-Notfallkonzept erstellen: 7 Schritte mit Substanz

1. Kritische Geschäftsservices als Ausgangspunkt bestimmen

Notfallplanung sollte nicht bei Servern, Anwendungen oder einzelnen Verträgen beginnen. Ausgangspunkt sind die Geschäftsservices, deren Ausfall zu nicht akzeptablen Auswirkungen für Kunden, Markt, Regulierung oder das eigene Unternehmen führt. Dazu zählen beispielsweise Zahlungsverkehr, Handelsplattformen, Kundenportale, Meldeprozesse oder die Verarbeitung sensibler Transaktionen.

Eine Business Impact Analysis schafft die erforderliche Entscheidungsgrundlage. Sie ermittelt, welche Folgen ein Ausfall hat, wie lange ein Service maximal unterbrochen sein darf und welche Mindestleistung im Notbetrieb erforderlich ist. Daraus entstehen Wiederanlaufziele wie RTO und RPO. Diese Werte dürfen nicht allein aus der IT heraus festgelegt werden. Die Fachbereiche tragen die Verantwortung dafür, den geschäftlichen Schaden und die tolerierbare Unterbrechungsdauer verbindlich zu bewerten.

2. IKT-Abhängigkeiten Ende zu Ende transparent machen

Ein kritischer Geschäftsservice besteht fast nie nur aus einer Anwendung. Er hängt von Identitätsdiensten, Netzwerken, Datenbanken, Schnittstellen, Betriebsplattformen, Kommunikationsmitteln, Sicherheitskomponenten und häufig von externen Dienstleistern ab. Gerade diese Kette entscheidet darüber, ob ein Wiederanlaufplan in der Praxis funktioniert.

Das IKT-Notfallkonzept muss daher die Abhängigkeiten zwischen Prozessen, Services, Assets und Lieferanten sichtbar machen. Ebenso wichtig sind Konzentrationsrisiken. Zwei vermeintlich getrennte Anwendungen können etwa denselben Cloud-Standort, dieselbe zentrale Identitätsplattform oder dieselbe Betriebsmannschaft nutzen. Fällt diese gemeinsame Komponente aus, helfen formal getrennte Wiederherstellungspläne nur begrenzt.

Nicht jede technische Komponente benötigt eine eigene umfangreiche Notfalldokumentation. Für kritische Abhängigkeiten ist sie jedoch unverzichtbar. Die Dokumentation sollte so strukturiert sein, dass Fachverantwortliche, IT-Betrieb und Krisenstab jeweils erkennen, was sie wissen und entscheiden müssen.

3. Governance, Eskalation und Entscheidungsrechte festlegen

In einer schwerwiegenden IKT-Störung entsteht oft nicht das größte Risiko durch fehlende Technik, sondern durch unklare Führung. Wer erklärt den Notfall? Wer priorisiert die Wiederherstellung konkurrierender Services? Wer entscheidet über einen manuellen Ersatzprozess, eine Kundenkommunikation oder die Einbindung eines Dienstleisters?

Das Konzept braucht deshalb ein definiertes Notfall- und Krisenmanagement. Rollen, Vertretungen, Alarmierungswege und Entscheidungsbefugnisse müssen auch dann funktionieren, wenn einzelne Personen, Standorte oder Kommunikationskanäle ausfallen. Sinnvoll ist eine klare Trennung zwischen technischer Störungsbearbeitung, übergeordneter Notfallkoordination und strategischen Krisenentscheidungen. In kleineren Organisationen können Personen mehrere Rollen wahrnehmen. Die Verantwortlichkeiten dürfen dadurch aber nicht verschwimmen.

Auch die Schnittstelle zum Incident Management ist festzulegen. Nicht jeder Incident ist ein Notfall. Umgekehrt muss der Übergang in den Notfallbetrieb anhand definierter Kriterien schnell und nachvollziehbar möglich sein.

4. Wiederanlauf und Wiederherstellung konkret planen

Jetzt wird aus der Analyse ein operativer Plan. Für jeden priorisierten IKT-Service sollten Wiederanlauf- und Wiederherstellungsverfahren beschreiben, welche Voraussetzungen gelten, welche Schritte in welcher Reihenfolge erfolgen und wie die erfolgreiche Wiederherstellung bestätigt wird. Allgemeine Sätze wie Systeme werden aus dem Backup wiederhergestellt reichen nicht aus.

Benötigt werden unter anderem verfügbare Backup- und Restore-Verfahren, alternative Betriebsoptionen, Zugriffsmöglichkeiten für berechtigte Notfallteams, Abhängigkeiten zu Drittparteien und fachliche Abnahmekriterien. Für zerstörerische Cyberangriffe ist zusätzlich zu klären, wie kompromittierte Systeme von einer vertrauenswürdigen Umgebung getrennt und Daten auf Integrität geprüft werden. Geschwindigkeit ist wichtig, aber ein vorschneller Wiederanlauf kann Schadsoftware erneut in die Produktionsumgebung bringen.

Manuelle Ersatzverfahren verdienen dieselbe Aufmerksamkeit wie technische Maßnahmen. Sie überbrücken eine Störung nur dann wirksam, wenn Kapazitäten, Datenzugriffe, Freigaben und spätere Nachbearbeitung geregelt sind. Ein Excel-Prozess ohne Zugriffsrechte, Vier-Augen-Prinzip und Rückführungskonzept ist kein belastbarer Notbetrieb.

5. Drittdienstleister in die Notfallplanung einbeziehen

DORA lenkt den Blick ausdrücklich auf IKT-Drittparteirisiken. Das bedeutet nicht, dass ein ausgelagerter Service automatisch ein unvertretbares Risiko ist. Es bedeutet, dass die eigene Organisation die Kontroll- und Wiederherstellungsfähigkeit auch bei Abhängigkeit von Dritten bewerten und steuern muss.

Prüfen Sie daher, welche vertraglichen Leistungen im Störungsfall tatsächlich zugesichert sind, welche Eskalationskontakte gelten und wie Wiederanlaufzeiten nachgewiesen werden. Relevant sind auch Exit-Szenarien, Datenportabilität, Subunternehmerketten und die Frage, ob alternative Bezugswege realistisch verfügbar sind. Ein zweiter Provider kann Resilienz erhöhen, verursacht aber zusätzliche Integrations-, Betriebs- und Kontrollkosten. Die richtige Entscheidung ergibt sich aus Kritikalität und Risikobild, nicht aus einem pauschalen Mehrfachanbieter-Prinzip.

6. Melde- und Kommunikationsfähigkeit vorbereiten

Ein wirksames IKT-Notfallkonzept berücksichtigt die Kommunikation nach innen und außen. Im Krisenfall benötigen Vorstand oder Geschäftsführung zeitnahe Lagebilder: Was ist betroffen, welche Services sind eingeschränkt, welche Maßnahmen laufen, welche Entscheidungen stehen an und wann folgt das nächste Update?

Gleichzeitig können regulatorische Meldepflichten bei schwerwiegenden IKT-bezogenen Vorfällen ausgelöst werden. Die Bewertung und Meldung sollten deshalb in das Incident- und Krisenverfahren integriert sein. Vorbereitete Vorlagen helfen, ersetzen aber keine verlässliche Faktenlage. Kommunikationsverantwortliche müssen früh eingebunden werden, ohne dass technische Teams durch unnötige Abstimmungen an der Wiederherstellung gehindert werden.

7. Pläne testen, auswerten und dauerhaft pflegen

Ein ungeübter Notfallplan ist eine Annahme, kein Nachweis. Tests zeigen, ob Kontaktwege erreichbar sind, Wiederherstellungszeiten realistisch bleiben und Teams unter Zeitdruck zusammenarbeiten können. Tabletop-Übungen eignen sich, um Entscheidungen, Eskalationen und Kommunikation zu trainieren. Technische Wiederanlauftests prüfen dagegen, ob Systeme, Daten und Schnittstellen tatsächlich innerhalb der festgelegten Ziele verfügbar sind.

Die Testtiefe sollte risikoorientiert gewählt werden. Nicht jede Anwendung muss monatlich vollständig wiederhergestellt werden. Bei kritischen Services sind jedoch regelmäßige, realitätsnahe Tests erforderlich. Besondere Erkenntnisse liefern Szenarien, in denen mehrere Annahmen zugleich nicht gelten: Ein Provider ist nicht erreichbar, die normale Kommunikation fällt aus oder ein Backup kann nicht sofort verwendet werden.

Jede Übung braucht eine dokumentierte Auswertung mit Maßnahmen, Verantwortlichen und Terminen. Änderungen an Architektur, Lieferanten, Prozessen oder Wiederanlaufzielen müssen in die Notfallplanung zurückfließen. Softwaregestützte BCM- und ITSCM-Prozesse können dabei helfen, Abhängigkeiten, Maßnahmen, Nachweise und Aktualisierungszyklen konsistent zu steuern. Mit [alive-IT] verbindet Controllit diese Pflege mit der operativen Nutzung im Notfall.

Der entscheidende Maßstab ist die Handlungsfähigkeit

Ein DORA-konformes IKT-Notfallkonzept entsteht nicht durch möglichst viele Seiten, sondern durch belastbare Entscheidungen vor dem Ereignis. Kritische Geschäftsservices müssen priorisiert, technische und organisatorische Abhängigkeiten verstanden und Wiederanlaufmaßnahmen realistisch geübt sein. Wer diese Arbeit als dauerhaften Resilienzprozess aufsetzt, schafft nicht nur bessere Nachweise für Aufsicht und Prüfung. Er schützt vor allem die Fähigkeit des Unternehmens, auch unter erheblichem Druck kontrolliert zu handeln.