DORA: IKT-Risiken, Anbieter und Nachweise

Definition: DORA schafft digitale ope­ra­tio­na­le Resi­li­enz für den Finanzsektor

DORA führt gemeinsame digitale Resilienzprinzipien für den Finanzsektor ein. Ziel ist es, dass Banken, Zahlungsinstitute, Investmentgesellschaften, Versicherungen und andere Finanzinstitute ihre Dienste trotz eines ICT-Ausfalls, eines Cyberangriffs, eines Lieferantenfehlers oder eines Betriebsvorfalls aufrechterhalten können. Dabei geht es nicht nur um die Compliance-Dokumentation, sondern darum, nachweisen zu können, dass kritische Dienste Verantwortliche, Kontrollen, Tests und Betriebsnachweise haben.

DORA-Maßnahmen organisieren

Anwendungsbereich anhand von Unternehmenstyp, Ausnahmen und Verhältnismäßigkeit bestimmen. Ein Maßnahmenplan setzt bestehende Pflichten nicht aus: Vorfallmeldung, Zugriffsschutz, Backups und Überwachung müssen funktionieren. Dringende Lücken zeitnah behandeln; Prüfungen nach 30/60/90 Tagen bewerten den Fortschritt.

• Kritische oder wichtige Funktionen nach DORA-Kriterien und Störungsauswirkungen einstufen, nicht allein nach der umgangssprachlichen Bedeutung von „kritisch“.
• ICT-System: Anwendung, Infrastruktur, Cloud, Netzwerk, Backup oder Anbieterdienst zur Unterstützung einer kritischen Funktion.
• Dokumentierte Maßnahmen: Testergebnisse, Prüfberichte, Protokolle, Entscheidungen der Verantwortlichen und bestätigte Änderungen.
• Maßnahmenplan: Verantwortliche, Termine, Abhängigkeiten und Übergangsschutz; die Genehmigung allein beseitigt keine Nichtkonformität.
• Prüfung nach 30 Tagen: Funktionsübersicht, Informationsregister, Nachweislücken und Backup-Testergebnisse bewerten.
• Prüfung nach 60 Tagen: Vorfallklassifizierung und Meldungen, Testplan, Verträge und Managementberichte prüfen.
• Prüfung nach 90 Tagen: Anbieterüberwachung, Monitoring, Wiederherstellung, Rechte und Nachweisvollständigkeit bewerten.
• Nach 90 Tagen: fester Betriebsrhythmus, benannte Kontrollverantwortliche, aktualisierte Risiken und eine Aufgabenliste zur laufenden Verbesserung der Resilienz.

Rechtslage: DORA ist bereits anzuwenden

DORA, oder Digital Operational Resilience Act, ist die Verordnung (EU) 2022/2554. Nach dem Gesetzestext gilt sie seit dem 17. Januar 2025. Im Jahr 2026 ist DORA daher kein Vorbereitungsprojekt mehr, sondern das geltende Regelwerk für die digitale operationale Resilienz. In der Praxis verbindet es Compliance, Cybersicherheit, Geschäftskontinuität, die Steuerung von ICT-Anbietern und den IT-Betrieb.

Was DORA für eine Or­ga­ni­sa­ti­on verändert

DORA ist mehr als ein Compliance-Projekt. Entscheidend ist, ob Finanzdienstleistungen trotz Ausfall, Cybervorfall, Fehler eines Anbieters oder Störung der ICT-Infrastruktur weiterlaufen können. Dokumentation ist nur dann wertvoll, wenn sie mit realen Systemen, durchgeführten Tests, Managemententscheidungen und klaren Serviceverantwortlichkeiten verknüpft ist. Die größte Herausforderung von DORA besteht darin, die Sprache von Risiko, Compliance und IT zu kombinieren.

Zentrale DORA-Bereiche

In der Praxis muss das DORA-Projekt als Karte der Beziehungen zwischen dem Geschäftsdienst, dem ICT-System, dem Anbieter, dem Risiko, der Kontrolle und dem zugehörigen Nachweis geführt werden. Ohne diese Zuordnung entstehen schnell Richtlinien, die sich im Betrieb nicht umsetzen oder pflegen lassen.

• ICT-Risikomanagement: Vermögenswerte, Prozesse, Verantwortliche, geschäftliche Auswirkungen, Risikotoleranz und Managemententscheidungen.
• Umgang mit Vorfällen: Klassifizierung, Eskalation, Kommunikation, Registrierung, Berichterstattung und Schlussfolgerungen nach dem Vorfall.
• Resilienztests: Backup, Wiederherstellung, Fehlerszenarien, Schwachstellen, Geschäftskontinuität und Übungen.
• ICT-Drittparteienrisiko: Verträge, Subunternehmer, Kritikalität, Ausstiegspläne, SLAs, Berichte und Überprüfungen.
• Freiwilliger Austausch von Bedrohungsinformationen: vereinbarte Regeln, Vertraulichkeit und Datenschutz; Artikel 45 verlangt keine Teilnahme an jeder solchen Vereinbarung.

Für wen gilt DORA?

DORA gilt unmittelbar für die erfassten Finanzunternehmen. Andere ICT-Anbieter können vertragliche und operative Anforderungen ihrer Kunden aus dem Finanzsektor erfüllen müssen; der direkte DORA-Aufsichtsrahmen gilt hingegen für von den Europäischen Aufsichtsbehörden als kritisch benannte IKT-Drittdienstleister. Der Umfang ist deshalb getrennt für das regulierte Unternehmen, seine Dienste und die Anbieter kritischer oder wichtiger Funktionen zu bestimmen.

Verantwortung von Leitungsorgan und Serviceverantwortlichen

Serviceverantwortliche bearbeiten zugewiesene Aufgaben und eskalieren Risiken. Das Leitungsorgan bleibt für den IKT-Risikomanagementrahmen verantwortlich; Outsourcing und Risikoakzeptanz heben regulatorische Pflichten nicht auf.

• Welche Funktionen sind kritisch oder wichtig und welche ICT-Systeme unterstützen sie.
• Welche Art von Ausfallzeiten, Datenverlusten oder Serviceverschlechterungen sind aus geschäftlicher Sicht inakzeptabel?
• Welcher ICT-Lieferant hat ein Konzentrationsrisiko, eine Abhängigkeit von Subunternehmern oder keinen Ausstiegsplan?
• Wie wir Vorfälle klassifizieren und wer über Eskalation, Kommunikation und den Abschlussbericht entscheidet.
• Welche Nachweise erhält das Management nach einem Test, einem Vorfall, einer Anbieterprüfung oder einer Ausnahmegenehmigung?

So übertragen Sie DORA auf Systeme und Verantwortlichkeiten

Was am häufigsten fehlt, ist nicht die Richtlinie selbst, sondern die Verbindung zwischen Geschäftsdienst, System, Anbieter, Risiko und Wirksamkeitsnachweis. Ohne diese Verknüpfung bleibt unklar, wer einen Test durchführt, wer das Risiko akzeptiert und welche Unterlagen bei einer Prüfung vorzulegen sind.

• Identifizieren Sie für jeden kritischen Dienst ICT-Systeme, Daten, Integrationen, fachlich Verantwortliche und technische Verantwortliche.
• Geben Sie für jeden Lieferanten die Kritikalität, das SLA, den Verarbeitungsort, die Subunternehmer, den Ausstiegsplan und die Bereitstellung von Berichten an.
• Weisen Sie jeder Kontrolle einen Nachweis zu: Testergebnis, Protokoll, Entscheidung, Überwachungsbericht oder Ausnahmegenehmigung.
• Legen Sie für Vorfälle eine Klassifizierung, Eskalationsschwellen, Kontaktpersonen, Meldefristen und eine Vorlage für die Nachbereitung des Vorfalls fest.
• Erstellen Sie für die Geschäftsführung eine kurze Karte der Risiken, Kosten, Toleranzen und genehmigungspflichtigen Entscheidungen.

DORA, NIS2 und technische Cybersicherheit

DORA regelt die digitale Resilienz im Finanzsektor, während NIS2 die Cybersicherheit wesentlicher und wichtiger Einrichtungen breiter erfasst. Für Finanzunternehmen im Anwendungsbereich von DORA ist jedoch die Lex-specialis-Regel in Artikel 4 NIS2 zu beachten: Stellt ein sektorspezifischer Unionsrechtsakt gleichwertige Anforderungen an ICT-Risikomanagement und Vorfallmeldungen, gelten die entsprechenden NIS2-Vorschriften nicht. Der konkrete Umfang ist stets für das einzelne Unternehmen zu prüfen; Dokumente ersetzen keine wirksamen Kontrollen und Nachweise.

Inhalte des Nachweispakets

Das Nachweispaket regelmäßig pflegen. Es umfasst aktuelle Dokumente, Berichte, Testergebnisse und Entscheidungen mit Zeitraum und Verantwortlichen. Fehlende Nachweise und offene Maßnahmen müssen erkennbar bleiben.

• Informationsregister zu vertraglichen Vereinbarungen über IKT-Dienste, verknüpft mit Diensten, Anbietern, Funktionen und Verantwortlichen; der Umfang ist nicht auf Anbieter kritischer Funktionen begrenzt.
• Vorfallprotokoll mit Klassifizierung, Entscheidungen, Kommunikation, Reaktionszeiten und Korrekturmaßnahmen.
• Ergebnisse von Backup-, Wiederherstellungs-, Schwachstellen-, Kontinuitäts- und Notfallszenariotests.
• Überprüfung von Lieferanten, Verträgen, SLAs, Subunternehmern, Ausstiegsplänen und Konzentrationsrisiken.
• Überwachungsberichte, Zugriffsüberprüfungen, Ausnahmegenehmigungen und Entscheidungen der Risikoverantwortlichen.

ISO-27001-Zertifikat des Partners und DORA-Konformität

Das eigene ISMS-Zertifikat von Virtline beschreibt den zertifizierten Managementsystemumfang. Es unterstützt die Bewertung der Arbeitsweise des Partners, bescheinigt aber keine DORA-Konformität des Kunden. Prüfergebnisse benötigen tatsächliche Kontrollen und aktuelle Nachweise.

Die häufigsten Fehler bei der Implementierung von DORA

Fehler entstehen meist, wenn Compliance und IT getrennt arbeiten. Eine Organisation hat dann zwar eine Richtlinie, aber keinen Wiederherstellungstest; ein Anbieterregister, aber keine klare Zuordnung zu kritischen Funktionen; oder ein Vorfallverfahren, dessen Eskalationsweg nie geübt wurde.

Risiken, die direkt benannt werden müssen

Belastbare DORA-Nachweise verschleiern keine schwierigen Abhängigkeiten. Sie zeigen, wo in der Organisation ein Konzentrationsrisiko besteht, wo der Lieferant von entscheidender Bedeutung ist, wo die Sicherung die Wiederherstellung des Dienstes nicht bestätigt und wo eine Managemententscheidung erforderlich ist.

• Eine Finanzdienstleistung hängt von mehreren Systemen ab, aber nur einige davon haben einen technischen Verantwortlichen.
• Der ICT-Anbieter unterstützt einen kritischen Prozess und der Vertrag sieht kein Exit-Szenario oder Resilienzberichte vor.
• Vorfälle werden im Helpdesk ohne Einstufung nach den regulatorischen Kriterien und ohne Meldeentscheidung geschlossen.
• Der Sicherungstest bestätigt, dass die Datei wiederhergestellt wurde, er bestätigt jedoch nicht, dass die gesamte Geschäftsfunktion wiederhergestellt wurde.
• Die Überwachung generiert Warnungen, verfügt jedoch über keinen Eskalationspfad, keine Prioritäten oder messbare Reaktionszeiten.

Wie Virtline DORA unterstützt

Wir verbinden Audit, Umsetzung und laufenden Betrieb der ICT-Umgebung. Wir überführen Empfehlungen aus der Tabelle in Konfigurationen, Verfahren, Tests, Monitoring, Nachweise und konkrete Betriebsaufgaben.

Was die Organisation nach dem Projekt erhält

Ziel sind Ergebnisse, die auch nach dem Workshop gepflegt werden können. Deshalb benennt das Projekt konkrete Verantwortlichkeiten, Prüfintervalle und erforderliche Nachweise, statt nur Empfehlungen zu liefern.

• Karte der ICT-Dienste, kritischen Funktionen, Anbieter und Entscheidungsträger.
• Lückenregister mit Prioritäten, Abhängigkeiten, Verantwortlichen und verbindlichen Fristen.
• Vorfall-, Test- und Anbieterverfahren, die mit realen Systemen verknüpft sind.
• Vorlagen für Management- und Betriebsberichte, die den Status von Risiken und Aktivitäten anzeigen.
• Nachweispaket für das DORA-Audit: Register, Testergebnisse, Überprüfungen, Entscheidungen und Abnahmenachweise.

DORA-Prioritäten für 2026

Sammeln Sie die Ergebnisse von Tests, Überprüfungen und der Bearbeitung von Vorfällen, um Prüfern, Kunden oder der zuständigen Aufsichtsbehörde zu zeigen, wie Ihre Verfahren in der Praxis funktionieren. Halten Sie fest, welche Dienste kritisch sind, welche ICT-Systeme sie unterstützen, wer über Risiken entscheidet, wie die Wiederherstellung getestet wird und wie Anbieter überwacht werden.

• Pflegen Sie eine aktuelle Karte kritischer Funktionen, ICT-Systeme, Anbieter, Verantwortlicher und technischer Abhängigkeiten.
• Verknüpfen Sie Vorfallaufzeichnungen mit Klassifizierungen, Reaktionszeiten, Eskalationsentscheidungen und Schlussfolgerungen nach dem Ereignis.
• Testen Sie die digitale operationale Resilienz: Backup, Wiederherstellung, Fehlerszenarien, Kommunikation und Maßnahmen auf Lieferantenseite.
• Bewerten Sie regelmäßig ICT-Verträge, SLAs, Subunternehmer, Ausstiegsplan, Verarbeitungsort und Konzentrationsrisiko.
• Bereiten Sie einen kurzen Bericht für den Vorstand vor: Risikostatus, fehlende Nachweise, Budget, Entscheidungsträger und verbindliche Fristen.

Schnelle Auswahl des Umfangs: Audit, Implementierung oder Wartung

Nicht jede Organisation braucht den gleichen Start. Ein Unternehmen mit vorgefertigter Dokumentation benötigt möglicherweise eine Prüfung der Nachweise und Tests der Konfiguration. Eine Organisation ohne Verzeichnis der ICT-Dienste sollte mit einer Abhängigkeitszuordnung beginnen. Nach einem Vorfall sollte die Organisation zunächst Klassifizierung, Kommunikation und Korrekturmaßnahmen organisieren. DORA ist ein digitales Resilienzprogramm, das Compliance, Cybersicherheit und IT-Wartung kombiniert.

Kontakt

Am besten bevor ein Prüfer, Kunde oder eine zuständige Aufsichtsbehörde nach Nachweisen fragt. Ein kurzer Workshop trennt kritische Maßnahmen von reiner Dokumentationsarbeit und führt zu einem realistischen Compliance-Kontrollplan.

• Es gibt keine aktuelle Karte der ICT-Dienste, Anbieter und kritischen Prozesse.
• Eine Sicherung ist vorhanden, es finden jedoch keine regelmäßigen Tests zur Wiederherstellung der Dienste statt.
• Vorfälle werden ad hoc behandelt, ohne Klassifizierung oder Protokollierung von Entscheidungen.
• ICT-Anbieterverträge spiegeln die Kritikalität der Dienste nicht wider.
• Der Vorstand benötigt kurze Informationen zu Risiko, Budget und Prioritäten.

Quellen zu den beschriebenen Anforderungen und Fristen