DORA für Banken, Zahlungs- und Versicherungsunternehmen
DORA: Technische IT-Resilienz für Cloud-Systeme
Ihr Rahmenwerk steht auf dem Papier. Wir machen daraus Konfiguration, Wiederherstellungstests und Nachweise, die Ihre Compliance- und Risikofunktionen verwenden können. Für IT-Leitung, CISO und CTO, die aus Artikeln und technischen Standards konkrete Plattformarbeit machen müssen.
- Technische Umsetzung, keine Aufsichtsberatung
- Nachweise: Runbooks, Testprotokolle, Konfigurationsstände
- Plattformneutral: Cloud, Kubernetes, eigene Infrastruktur
01Ausgangslage
Wenn das Rahmenwerk dokumentiert ist, die Plattform es aber nicht belegt
Vier Situationen, in denen Unternehmen uns ansprechen:
-
Dokumentiert, aber nicht nachweisbar
Das Risikomanagement-Rahmenwerk ist dokumentiert, aber niemand kann zeigen, welche Konfiguration in Cloud, Kubernetes oder Rechenzentrum es umsetzt.
-
Backup ohne Restore-Erfahrung
Backup existiert, aber Wiederherstellung ist nie unter realistischen Bedingungen getestet worden.
-
Ausstieg nur auf dem Papier
Kritische Funktionen hängen an Cloud-Diensten, und der Ausstieg ist nur beschrieben, nicht gebaut.
-
Neubau oder Migration
Die Plattform wird gerade neu gebaut oder migriert und soll die Anforderungen von Anfang an erfüllen.
02Abgrenzung
Technische Umsetzung ja, Aufsichtsberatung nein
Wir liefern die technische Umsetzung und die Artefakte, die Ihre Compliance- und Risikofunktionen verwenden. Eine Aussage, dass Sie „DORA-konform“ sind, gehört nicht dazu.
Das übernehmen wir
- Technische Gap-Analyse Ihrer Plattformen und Maßnahmenplan nach Risiko und Aufwand.
- Umsetzung: Konfiguration, Automatisierung, Richtlinien als Code, Backup-Architektur, Logging-Anbindung.
- Wiederherstellungs- und Umschalttests mit Protokoll.
- Übergabe mit Einweisung oder laufender Betrieb über Managed Services.
Das tun wir nicht
- Aufsichtsrechtliche Beratung und Abstimmung mit der Aufsicht.
- Bewertung, ob und wie Ihr Unternehmen unter DORA fällt.
- Zertifizierung oder Konformitätsbestätigung.
- Unabhängige Tests, insbesondere bedrohungsgeleitete Penetrationstests (TLPT), als eigenständige Leistung.
- Reine Richtlinien-, Register- und Dokumentenarbeit ohne technische Umsetzung.
03Rechtsstand 13. November 2026
Seit 17. Januar 2025 gilt DORA, für NIS2 gibt es eine Abgrenzung
DORA ist die Verordnung (EU) 2022/2554. Nach Artikel 64 gilt sie seit dem 17. Januar 2025. Welche Unternehmen betroffen sind, regelt Artikel 2; die Liste reicht von Kreditinstituten und Zahlungsinstituten über Wertpapierfirmen bis zu weiteren Finanzunternehmen und IKT-Drittdienstleistern. Die Einordnung Ihres Unternehmens ist eine rechtliche Frage.
Die Verordnung enthält die Pflichten; die technischen Details stehen in ergänzenden Rechtsakten. Für das IKT-Risikomanagement ist vor allem die Delegierte Verordnung (EU) 2024/1774 maßgeblich (technische Regulierungsstandards zu Werkzeugen, Methoden, Prozessen und Richtlinien, einschließlich des vereinfachten Rahmens). Für das Informationsregister über Verträge mit IKT-Drittdienstleistern gilt die Durchführungsverordnung (EU) 2024/2956 mit Standardvorlagen.
Abgrenzung zu NIS2: Nach § 28 Absatz 6 Nummer 1 BSIG gelten die §§ 30, 31, 32, 35, 36, 38 und 39 BSIG (darunter die Risikomanagementmaßnahmen und Meldepflichten) nicht für Finanzunternehmen nach Artikel 2 Absatz 2 der Verordnung (EU) 2022/2554 und für Unternehmen, für die die DORA-Anforderungen aufgrund von § 1a Absatz 2 und 2a des Kreditwesengesetzes oder § 293 Absatz 5 des Versicherungsaufsichtsgesetzes gelten (Wortlaut nach BGBl. 2025 I Nr. 301, Artikel 1, S. 20 f.; Prüfdatum 13. November 2026). Für diese Unternehmen ist DORA also der maßgebliche Rahmen; ob das auf Sie zutrifft, klärt Ihre Rechtsberatung.
04Vorgehen im Projekt
Von der Funktionsliste zum betriebsfähigen Control
Sechs Arbeitspakete; die Tiefe (nur Analyse, Analyse mit Umsetzung, Umsetzung mit Betrieb) bestimmen Sie.
- 01
Scoping
Paket 1Welche kritischen oder wichtigen Funktionen, Systeme, Standorte und Dienstleister sind betroffen? Die Einstufung der Funktionen liefern Sie.
- 02
Technische Gap-Analyse
Paket 2Die Plattformen werden gegen die technischen Anforderungen geprüft (Tabelle unten): Identitäten und Zugriffe, Protokollierung, Netzsegmentierung, Patch- und Änderungsprozess, Backup und Wiederherstellung, Redundanz, Tests.
- 03
Bewertung und Maßnahmenplan
Paket 3Abweichungen nach Risiko und Aufwand, mit Abhängigkeiten. Risikoakzeptanz bleibt bei Ihrem Leitungsorgan.
- 04
Umsetzung
Paket 4Konfiguration, Automatisierung, Richtlinien als Code, Backup-Architektur, Wiederanlauf-Reihenfolge, Logging-Anbindung.
- 05
Tests und Nachweise
Paket 5Wiederherstellungs- und Umschalttests mit Protokoll, Konfigurationsstände, Runbooks.
- 06
Übergabe oder Betrieb
Paket 6Ihr Team übernimmt nach Einweisung selbst, oder wir betreiben die Controls weiter (siehe Managed Services).
05Zuordnung
Von Artikel zu Nachweis: DORA-Anforderungen als Arbeitspakete
Die Tabelle zeigt, welche Artikel der Verordnung wir in technische Arbeitspakete übersetzen. Sie ist unsere fachliche Zuordnung und keine aufsichtliche Auslegung; verbindlich sind die Verordnung und die ergänzenden technischen Standards. Die Spalte „Bleibt bei Ihnen“ benennt, was Leitungsorgan, Risikofunktion und Compliance verantworten.
| Bereich (Quelle) | Konkretes technisches Control | Nachweis-Artefakt | Bleibt bei Ihnen |
|---|---|---|---|
| Identifikation von Informations- und IKT-Assets (Art. 8; RTS Art. 4, 5) | Technisches Inventar aus IaC-Zustand, Cluster- und Cloud-Konfiguration; Abhängigkeiten zwischen Systemen | Asset- und Abhängigkeitsinventar | Klassifikation, Einstufung kritischer oder wichtiger Funktionen |
| Schutz und Prävention (Art. 9; RTS Art. 6, 7, 11, 13, 14) | Sichere Konfigurationsbasis, nur freigegebene Software, Netzsegmentierung mit der Möglichkeit, Verbindungen zu trennen oder zu segmentieren, Verschlüsselung und Schlüsselverwaltung (siehe Datensicherheit) | Baseline-Dokumente, Prüfberichte, Netzdiagramm | Informationssicherheitsrichtlinie |
| Identitäts- und Zugriffsverwaltung (Art. 9 Abs. 4; RTS Art. 20, 21) | Least-Privilege-Rollen, starke Authentifizierung, privilegierter Zugriff mit Protokollierung (siehe IAM und Zero Trust) | Rollen- und Rechtematrix, Berechtigungsreview | Rollenfreigabe, Personalprozesse |
| Patch- und Änderungsmanagement (Art. 9 Abs. 4 Buchst. e, f; RTS Art. 10, 16, 17) | Automatisierte Updates, Schwachstellenscan, kontrollierte Änderungen über Pipeline und Review | Patch-Runbook, Änderungsprotokoll, Scan-Berichte | Freigabeprozess für Änderungen |
| Erkennung (Art. 10; RTS Art. 12, 23) | Zentrale, manipulationsgeschützte Protokollierung (Zugriffe, Änderungen, Betrieb, Netz), Zeitsynchronisation, Erkennung von Logging-Ausfällen, Anbindung an Ihr SIEM | Log-Architektur, Alarm-Testprotokoll | Erkennungskriterien, Alarmbewertung |
| Reaktion und Wiederherstellung (Art. 11, 12; RTS Art. 24 bis 26) | Backup-Konzept mit getrennter Wiederherstellungsumgebung, Redundanz, dokumentierte Wiederanlaufreihenfolge, Umschalttests | Backup-Konzept, Restore-Testprotokoll, Wiederanlauf-Runbook | Business-Impact-Analyse, Festlegung von Wiederanlaufzielen, Krisenmanagement |
| Vorfallsmanagement (Art. 17 bis 19) | Technische Unterstützung: Alarmierungswege, Log-Bereitstellung, Eindämmungs-Runbooks (Zugänge sperren, Workload isolieren, Snapshot sichern) | Runbooks, Übungsprotokoll | Klassifizierung, Meldungen an die Aufsicht |
| Resilienztests (Art. 24, 25) | Wiederholbare Tests: Schwachstellenscans, Konfigurationsprüfung, Szenario- und Umschalttests; Priorisierung und Verfolgung von Befunden | Testprogramm-Anteil, Testberichte mit Datum | Testprogramm als Ganzes, Unabhängigkeit der Tester, TLPT (Art. 26, 27) |
| IKT-Drittparteienrisiko (Art. 28 bis 30) | Technisches Inventar der Dienstleister und ihrer Zugriffe; Exit-Fähigkeit durch portable Architektur und dokumentierte Datenexporte | Dienstleister-Zugriffsmatrix, Exit-Runbook | Register der Verträge, Due Diligence, Vertragsinhalte |
Die letzte Spalte zeigt auch, wo wir Grenzen ziehen: Nach Artikel 24 Absatz 4 müssen Tests von unabhängigen Parteien durchgeführt werden, und die Artikel 26 und 27 regeln bedrohungsgeleitete Penetrationstests (TLPT) mit Anforderungen an die Tester. Beides sind eigene Disziplinen und nicht Teil dieser Leistung.
06Artikel 12 in der Praxis
Was die Wiederherstellungs-Anforderungen für Ihre Architektur bedeuten
Artikel 12 formuliert technische Anforderungen, die sich direkt in Architektur übersetzen lassen:
- Backup-Richtlinien und Wiederherstellungsverfahren müssen dokumentiert sein; Umfang und Mindesthäufigkeit richten sich nach der Kritikalität der Daten.
- Backup- und Wiederherstellungsverfahren sind regelmäßig zu testen.
- Bei Wiederherstellung auf eigenen Systemen müssen die dafür genutzten IKT-Systeme physisch und logisch vom Quellsystem getrennt sein.
- Finanzunternehmen außer Kleinstunternehmen unterhalten redundante IKT-Kapazitäten, die den Geschäftsbedarf abdecken.
- Nach einer Wiederherstellung sind Prüfungen und Abgleiche zur Wahrung der Datenintegrität durchzuführen.
07Runbook
Der Wiederherstellungstest ist der Beleg für Ihr Wiederanlaufkonzept
Nach Artikel 11 Absatz 6 sind die Pläne für Geschäftsfortführung sowie Reaktion und Wiederherstellung mindestens jährlich zu testen, nach Artikel 24 Absatz 6 (für Unternehmen außer Kleinstunternehmen) alle Systeme, die kritische oder wichtige Funktionen unterstützen, ebenfalls mindestens jährlich. Wie oft Sie darüber hinaus testen, legen Sie nach Risiko fest.
08Testablauf im Detail
Sechs Schritte durch einen Restore-Test
- 01
Szenario festlegen
Schritt 1Zum Beispiel Verlust eines Standorts, Verschlüsselung der Produktivdaten oder Ausfall eines Cloud-Dienstes.
- 02
Zielumgebung vorbereiten
Schritt 2Getrennt vom Quellsystem, mit eigenen Zugangsdaten, damit ein kompromittierter Produktivzugang die Wiederherstellung nicht gefährdet.
- 03
Wiederherstellung nach Runbook
Schritt 3In der dokumentierten Reihenfolge, mit Zeitmessung je Schritt.
- 04
Integrität prüfen
Schritt 4Prüfsummen, Abgleich von Datenbeständen, fachliche Stichproben mit den Systemverantwortlichen.
- 05
Auswerten
Schritt 5Erreichte Zeit gegenüber Ihren Wiederanlaufzielen, Abweichungen, offene Punkte.
- 06
Nachverfolgen
Schritt 6Maßnahmen priorisieren, Runbook anpassen, Termin für Wiederholung.
09Artikel 28 bis 30
Cloud-Anbieter als Drittparteien: Haftung bleibt bei Ihnen, der Ausstieg muss gebaut sein
Artikel 28 Absatz 1 macht das Finanzunternehmen unabhängig von seinen Verträgen voll verantwortlich. Für Dienste, die kritische oder wichtige Funktionen unterstützen, verlangt Absatz 8 Ausstiegsstrategien. Artikel 30 listet, was Verträge mit IKT-Drittdienstleistern mindestens enthalten müssen, darunter:
- Beschreibung der Dienste und ob Unterauftragsvergabe erlaubt ist, Standorte der Leistungserbringung und Datenverarbeitung,
- Bestimmungen zu Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit,
- Zugang, Wiederherstellung und Rückgabe der Daten bei Insolvenz oder Vertragsende,
- Servicelevel-Beschreibungen, Unterstützung bei Vorfällen, Zusammenarbeit mit den Aufsichtsbehörden,
- Kündigungsrechte; bei kritischen oder wichtigen Funktionen zusätzlich unter anderem detaillierte Servicelevel mit quantitativen Zielen, Mitwirkung an TLPT sowie Zugangs-, Prüf- und Auditrechte.
Technisch bedeutet das: Exit-Fähigkeit wird in die Architektur gebaut (Standard-Kubernetes, Infrastructure as Code, dokumentierte Datenexporte, keine unnötige Bindung an proprietäre Dienste). Zu Vertragsverhandlungen, Prüfungsrechten und Registerpflege beraten wir nicht; die technische Seite, etwa wie sich ein Ausstieg realisieren lässt, liefern wir. Hinweise zur Plattformwahl finden Sie unter Cloud Exit und Anbieterwechsel und souveräne Cloud.
Übernehmen wir für Sie Betrieb oder Entwicklung, arbeiten wir als IKT-Drittdienstleister im Sinne von DORA. Die Vertragsinhalte nach Artikel 30 vereinbaren wir mit Ihnen, einschließlich der Regeln für Unterauftragnehmer.
10Rollen
Wer bei DORA was verantwortet
-
Ihr Leitungsorgan
Trägt nach Artikel 5 die Verantwortung für das IKT-Risikomanagement-Rahmenwerk und muss sich mit ausreichenden Kenntnissen auf dem Laufenden halten.
-
Risiko, Compliance, Revision
Führen Klassifikation, Risikobewertung, interne Audits und Aufsichtskommunikation.
-
Ihre Rechtsberatung
Klärt Anwendungsbereich und Vertragsinhalte.
-
Prüfer und Aufsicht
Bewerten unabhängig.
-
SKAFFON
Analysiert, plant und setzt die technischen Controls um, dokumentiert sie und überträgt sie in den Betrieb.
11Plattformen
Umsetzung dort, wo Ihre Systeme laufen
Wir setzen plattformneutral um. Die Wahl folgt Ihren Anforderungen, nicht einem Produkt.
Cloud
- AWS
- Azure
- STACKIT
Orchestrierung
- Kubernetes
Eigener Betrieb
- Eigene Infrastruktur
Mehr zu den Plattformen: STACKIT und Disaster Recovery als Service für Kubernetes.
12Zusammenarbeit
Was wir von Ihrer Seite für den Start brauchen
- Einstufung Ihrer kritischen oder wichtigen Funktionen und Ihr Rahmenwerk, soweit vorhanden.
- Zugriff auf Cloud-Konten, Cluster, Backup- und Identitätssysteme (lesend für die Analyse, schreibend für die Umsetzung nach Freigabe).
- Eine benannte Person als Entscheiderin oder Entscheider für Maßnahmen.
- Verfügbarkeit der Systemverantwortlichen für Tests und Abnahmen.
13Angebot
Fünf Faktoren bestimmen den Aufwand Ihres DORA-Projekts
Nach einem Erstgespräch erstellen wir ein Angebot mit klar abgegrenztem Leistungsumfang.
-
Zahl der Systeme
Wie viele Systeme im Scope liegen.
-
Plattformen und Standorte
Wie viele Plattformen und Standorte beteiligt sind.
-
Reifegrad
Wie weit Dokumentation und Automatisierung schon sind.
-
Tiefe der Umsetzung
Analyse, Analyse mit Umsetzung oder Umsetzung mit Betrieb.
-
Abhängigkeiten
Abhängigkeiten zu Ihren Dienstleistern.
14
Häufige Fragen
Prüfen Sie, ob unser Unternehmen unter DORA fällt?
Nein. Die Einordnung Ihres Unternehmens ist eine rechtliche Frage, die Ihre Rechtsberatung klärt. Wir beginnen mit dem technischen Scope, wenn die Einstufung Ihrer kritischen oder wichtigen Funktionen vorliegt.
Bestätigen Sie, dass wir DORA-konform sind?
Nein. Wir liefern technische Umsetzung und Nachweis-Artefakte, aber keine Zertifizierung und keine Konformitätsbestätigung.
Führen Sie bedrohungsgeleitete Penetrationstests (TLPT) durch?
Nicht als eigenständige Leistung. Nach Artikel 24 Absatz 4 müssen Tests von unabhängigen Parteien durchgeführt werden, und die Artikel 26 und 27 stellen eigene Anforderungen an TLPT und Tester. Wir setzen wiederholbare technische Tests auf: Schwachstellenscans, Konfigurationsprüfung, Szenario- und Umschalttests.
Welche Wiederanlaufziele (RPO und RTO) setzen Sie an?
Keine vorgegebenen. Sie leiten die Ziele aus Ihren Geschäftsprozessen ab; im Restore-Test messen wir, wie weit die tatsächliche Wiederherstellungszeit davon abweicht.
15Verwandte Themen
Angrenzende Seiten zu Sicherheit und Plattformwahl
-
Cybersecurity-Überblick
Technische Sicherheitsmaßnahmen für Cloud, Daten und KI.
-
NIS2-Beratung
Falls Sie auch Einrichtungen betreiben, die nicht unter DORA fallen.
-
Cloud Exit und Anbieterwechsel
Wie sich ein Ausstieg technisch realisieren lässt.
-
Souveräne Cloud
Hinweise zur Plattformwahl.
Technischer Scope
Beschreiben Sie Ihre Plattformen und Ihr Ziel
Wir klären mit Ihnen den technischen Scope Ihres DORA-Vorhabens.