BLOG

BLOG

Font size: +
8 minutes reading time (1522 words)

Fahrplan zur Compliance – So startest du dein DORA-Projekt richtig

Fahrplan zur Compliance – So startest du dein DORA-Projekt richtig Fahrplan zur Compliance – So startest du dein DORA-Projekt richtig

Der Digital Operational Resilience Act (DORA) ist mehr als nur ein weiteres EU-Regelwerk. Er ist ein Paradigmenwechsel in der Art und Weise, wie Finanzunternehmen und ihre Dienstleister digitale Resilienz verstehen und umsetzen müssen. Mit dem Stichtag 17. Januar 2025 rückt die Frist für die vollständige Umsetzung näher, und in vielen Organisationen ist die Erkenntnis gereift: Wer jetzt nicht mit einem strukturierten Fahrplan startet, wird später unter Zeitdruck geraten und riskieren, halbherzige Lösungen einzuführen, die weder den regulatorischen Anforderungen noch den eigenen Sicherheitsbedürfnissen gerecht werden. DORA-Compliance ist kein „Ordner mit Policies“, sondern die Fähigkeit, unter massiven digitalen Störungen handlungsfähig zu bleiben – messbar, prüfbar, wiederholbar.

DORA in 60 Sekunden

DORA harmonisiert europaweit die Anforderungen an die digitale Betriebsstabilität (Operational Resilience) im Finanzsektor. Der Kern lässt sich in fünf Säulen einordnen:

  1. IKT-Risikomanagement,
  2. IKT-Vorfälle und Meldungen,
  3. digitale Resilienztests (bis hin zu TLPT),
  4. IKT-Drittparteiensteuerung (inkl. kritischer Anbieter) und
  5. Informationsaustausch.
    Neu ist nicht, dass es diese Themen gibt – neu ist die Verbindlichkeit, die Tiefe, der Management-Fokus und die Erwartung an Nachweis- und Testfähigkeit.

Wer ist betroffen – und wie tief?

Betroffen sind Banken, Wertpapierfirmen, Versicherungen, Zahlungs- und E-Geldinstitute, Anbieter von Krypto-Diensten, Marktinfrastrukturen (z. B. Handelsplätze, CCPs), aber auch IKT-Dienstleister mit kritischer Bedeutung. DORA wirkt entlang der gesamten Wertschöpfungskette: auch ausgelagerte Funktionen, Cloud-Dienste und SaaS-Bausteine fallen ins Blickfeld. Kleinere Häuser sind nicht automatisch ausgenommen; der risikobasierte Ansatz bedeutet: weniger Komplexität, aber keine Abstriche bei den Grundprinzipien.

Die fünf Säulen von DORA – was wirklich gefordert ist

IKT-Risikomanagement. Kontinuierliche Identifikation, Bewertung, Behandlung und Überwachung von Risiken aus Technologie, Prozessen und Menschen – nicht nur jährlich, sondern laufend. Technik, Organisation und Lieferkette gehören untrennbar zusammen.

IKT-Vorfälle & Meldungen. Harmonisierte Klassifikation, enge Fristen, konsistente Inhalte. Was nicht geübt ist, ist im Ernstfall zu langsam.

Digitale Resilienztests. Vom Kontroll-Self-Assessment über Red-Team-Übungen bis Threat-Led Penetration Testing (TLPT) nach EU-Methodik – mit Fokus auf kritische Dienstleistungen.

Drittparteiensteuerung. Risikobasierte Auswahl, Verträge mit Prüf- und Meldepflichten, laufende Überwachung und Exit-Fähigkeit. Kritische Anbieter unterliegen zudem EU-weiter Aufsicht – die Verantwortung des Instituts bleibt.

Informationsaustausch. Strukturen für sicheren, zweckgebundenen Austausch relevanter Bedrohungsinformationen – datenschutz- und wettbewerbskonform.

Vom Gesetz zum Betriebsmodell: Prinzipien für die Umsetzung

DORA verlangt kein Papier-ISMS, sondern Betriebsfähigkeit unter Stress. Fünf Prinzipien helfen, den Gesetzestext in gelebte Praxis zu übersetzen:

  • Ende-zu-Ende-Sicht: Kritische Services statt Silos denken (Business → Prozess → Applikation → Infrastruktur → Lieferanten).
  • Messbarkeit vor Meinung: KRIs/KPIs, die Wirkung zeigen (Patch-SLA, MFA-Abdeckung, MTTD/MTTR, Restore-Erfolg, Lieferanten-Compliance).
  • Tests statt Annahmen: Playbooks und Wiederanlauf nicht nur planen, sondern regelmäßig üben.
  • Management im Takt: Quartalsberichte, Beschlüsse, Priorisierung – Chefsache, nicht IT-Randthema.
  • Evidenzfähig: Entscheidungen, Maßnahmen, Ergebnisse nachvollziehbar dokumentieren.

Bestandsaufnahme: Wo stehen wir heute?

Bevor Maßnahmen geplant werden, braucht es ein ehrliches Bild. Bewährt hat sich eine strukturierte Standortbestimmung entlang der fünf Säulen:

  • IKT-Risiko: Gibt es ein vollständiges Asset-/Service-Inventar? Schutzbedarfe? Eine Bewertungssystematik, die Business-Impact einbezieht?
  • Vorfälle: Klassifikation, Meldekette, 24/7-Erreichbarkeit, forensische Sicherung, Kommunikationsplan?
  • Tests: Von Kontrollen über Tabletop-Übungen bis Red-/Purple-Team – dokumentiert, ausgewertet, verbessert?
  • Drittparteien: Tiering, Due Diligence, vertragliche Mindestanforderungen, Nachweisführung, Exit-Pläne?
  • Informationsaustausch: Quellen, Prozesse, rechtlicher Rahmen, Einbindung in Risiko/Detektion?

Ergebnis ist ein Heatmap-Profil mit Stärken, Lücken, Quick-Wins und „Long Poles“ (Themen mit langer Durchlaufzeit, z. B. IAM-Neuaufbau, Backup-Härtung, Cloud-Kontrollrahmen).

Lückenanalyse & Priorisierung: Wirkung zuerst

Nicht alle Themen sind gleich. DORA ist risikobasiert, also sollten es auch Ihre Prioritäten sein. Typische Top-Hebel:

  • Identitäten & Zugriffe: MFA, Least-Privilege, PAM, regelmäßige Rezertifizierung.
  • Vulnerabilities & Patches: Kritische Schwachstellen mit verbindlichen SLAs, risikobasiert nach Exponierung/Exploit-Lage.
  • Backups & Restore: Unveränderliche Kopien, Off-Site, regelmäßige Wiederherstellungstests.
  • Logging & Monitoring: Vollständigkeit kritischer Systeme, zentrales SIEM/SOAR, Hands-on-Handover in die 24/7-Überwachung.
  • Lieferkette: Tiering, Mindestanforderungen, Nachweise, Auditrechte, Exit-Readiness.
  • Playbooks: Incident-, Ransomware-, Cloud-Ausfall-Szenarien – geübt, nicht nur beschrieben.

Governance & Projektstruktur: Chefsache mit Traktion

DORA berührt Compliance, Risiko, IT, Einkauf, Recht, BCM und Interne Revision. Damit Entscheidungen zügig fallen, braucht es:

  • Lenkungsausschuss auf Management-Ebene (Quartalstakt, Ampel-Report, Beschlüsse).
  • Programm-Team (Security, Risk, IT-Ops, Architektur, Einkauf, Recht, BCM, Datenschutz).
  • Drei Verteidigungslinien klar getrennt (1st Line: Betrieb/Fach, 2nd Line: Risk/IS/Compliance, 3rd Line: Revision).
  • RACI-Matrizen für Schlüsselprozesse (z. B. Vorfallmeldung, Lieferanten-Onboarding, Notfallkommunikation).

Zielbetrieb (Target Operating Model) für IKT-Risiko

Ein reifer Zielbetrieb enthält:

  • Inventar & Service-Mapping: CMDB/Service-Katalog, kritische Abhängigkeiten, Owner-Prinzip.
  • Risikomethodik: Kalibrierte Skalen, die CVSS & Business-Impact verbinden; Szenariodenken.
  • Behandlung & Kontrolle: Kontrollen-Portfolio (präventiv, detektiv, reaktiv) mit Wirksamkeitsnachweisen.
  • KRIs/KPIs & Reporting: Wenige, harte Kennzahlen mit Trend, Plan/Ist, Maßnahmen.
  • Review-Taktung: Monatlich operativ, quartalsweise Management-Review, jährliche unabhängige Prüfung.

Ende-zu-Ende-Prozesse: von Change bis Crisis

DORA „landet“ in alltäglichen Abläufen. Kernprozesse, die risikofest sein müssen:

  • Change/Release/Config: Vier-Augen-Prinzip, Risiko-Check, Rückfallplan, Nachkontrolle, Infra-as-Code.
  • Vuln/Patch: Kontinuierliche Scans, Priorisierung nach Exponierung, SLA-Steuerung, Ausnahmen mit Ablaufdatum.
  • Incident/IR: 24/7-Erreichbarkeit, Erstbewertung, forensische Sicherung, Eskalationsmatrix, regulatorische Meldung.
  • BCM/DR: BIA mit RTO/RPO, getestete Notfallmodi, Wiederanlauf-Proben, Lessons Learned.
  • Supplier Lifecycle: Due Diligence, Vertragsklauseln, Nachweise, Monitoring, Re-Assessment, Exit.

Incident-Management & Meldungen: Üben schlägt Hoffen

Ein gutes Vorfallmanagement erkennt man daran, dass es funktioniert, wenn’s ungemütlich wird:

  • Klassifikation & Trigger (Schweregrade, Meldepflichten, Fristen).
  • Rollen & Playbooks (Incident Lead, Forensik, Recht, Kommunikation, Fach).
  • Kommunikation (Behörden, Kunden, Medien; abgestimmte Botschaften).
  • Forensik & Beweise (Chain of Custody, rechtssicher).
  • Nachbereitung (Root Cause, Maßnahmen, Wirksamkeitsprüfung).

Mindestens vierteljährliche Tabletop-Übungen mit Management-Beteiligung sind Gold wert – sie finden Lücken, die kein Dokument zeigt.

Metriken & Management-Reporting: Weniger ist mehr

Ein Board-tauglicher Satz an Kennzahlen (quartalsweise):

  • Patch-SLA-Einhaltung (kritische CVEs).
  • MFA-Abdeckung (gesamt/priviligiert).
  • PAM-Konten unter Kontrolle (Rezertifizierung).
  • MTTD/MTTR für kritische Vorfälle.
  • Restore-Erfolg und Zeit vs. RTO/RPO.
  • Logging-Abdeckung kritischer Systeme.
  • Lieferanten-Compliance (Nachweise, Findings, Fristen).
  • Audit-Findings (offen, überfällig).

Wichtig: Erzählung zur Zahl – welche Maßnahmen erklären Trends, wo bleibt Wirkung aus, welche Entscheidung ist jetzt nötig?

Test-Portfolio: vom Kontroll-Check bis TLPT

  • Kontroll-Selbstprüfungen (Policy-Konformität, Härtung, Baselines).
  • Technische Tests (Pen-Tests, Config-Audit, Purple-Team, Phishing-Simulationen).
  • Resilienztests (Wiederherstellung, Failover, Degradationsbetrieb).
  • Tabletops & Live-Drills (Kommunikation, Eskalation, Entscheidungswege).
  • TLPT für ausgewählte Häuser (threat-informed, aufsichtsgeführt) – Fokus auf kritische Services.

Tests ohne Follow-Up sind reine Kosmetik – Findings brauchen Eigentümer, Fristen, Wirksamkeitskontrolle.

Drittparteiensteuerung: Lieferkette als Risikofilter

  • Tiering: Kritikalität der Dienstleistung und Sub-Outsourcing verstehen.
  • Mindestanforderungen: Sicherheit, Resilienz, Meldepflicht, Auditrechte, Exit-Klauseln.
  • Nachweise & Monitoring: Zertifikate, Audit-Berichte, Pentest-Summaries; risikoorientierte Vertiefung.
  • Exit-Strategie: Daten-Rückführung, Know-how-Transfer, Plan B (Zeit & Kosten realistisch).
  • Konzentrationsrisiken: Abhängigkeiten von wenigen Hyperscalern sichtbar machen und steuern.

Cloud-Spezifika: geteilte Verantwortung, klare Kontrollen

  • Shared Responsibility vertraglich und technisch verstehen (IAM, Logging, Verschlüsselung, Netzwerk).
  • Kontrollrahmen: Cloud-Härtung, Guardrails, präventive Policies, IaC-Prüfung (Shift-Left).
  • Sichtbarkeit: Unified Logging, CSPM/CWPP, Exposure-Management.
  • Mandanten-Trennung & Schlüsselmanagement als rote Linien.
  • BCM im Cloud-Kontext: Region/Zone, Provider-Ausfälle, Notfallpläne jenseits des „Selbstheilungs“-Mythos.

Daten, CMDB & Service-Mapping: Ohne Karte kein Kompass

  • Aktuelles Inventar (Assets, Services, Abhängigkeiten, Owner).
  • Datenklassifikation (Schutzbedarf C/I/A; DSGVO-Bezug).
  • Service-Ketten (welcher Lieferant, welche Region, welches RTO/RPO gilt wo?).
  • Automatisierte Discovery plus menschlicher Kontext – nur so stimmen die Landkarten.

Kultur & Schulung: Befähigen statt belehren

  • Rollenbasierte Trainings: Management-Pflichten, Entwickler-Security, Admin-Härtung/Forensik, Fachbereiche (Datenhandhabung).
  • Kontinuität statt Pflichtstunde: kurze Impulse, Kampagnen, Gamification mit Augenmaß.
  • Fehlerkultur: Melden ohne Angst, Lernen ohne Schuldzuweisung.

Dokumentation & Evidenz: „Schlank, aber vollständig“

  • Risikoregister mit Bewertung, Behandlung, Rest-Exponierung.
  • Kontroll-Katalog mit Nachweisen.
  • Prozessdokumente & Playbooks (Version, Gültigkeit, Besitzer).
  • Berichte & Beschlüsse (Management-Reviews, Lenkungskreis).
  • Lieferantenakten (Verträge, Nachweise, Findings, Maßnahmen).
  • Vorfallakten (Zeitleiste, Meldungen, Root-Cause, Lessons Learned).

Dokumentation ist kein Selbstzweck, sondern Beleg der Wirksamkeit.

Tooling-Architektur: wenig Inseln, klare Schnittstellen

  • CMDB/Service-Katalog als Single Source of Truth.
  • Vuln-Management (Scanner + Priorisierung).
  • IAM/PAM mit Rezertifizierungs-Funktionen.
  • SIEM/SOAR für Korrelation & Reaktion.
  • Backup/Restore-Plattform mit Immutability.
  • GRC-Suite für Risiken, Kontrollen, Findings, Audits.
  • Supplier-Risk-Module (Assessments, Nachweise, Verträge).

Wichtig ist Integration – Metriken und Workflows müssen fließen.

Zeitplan bis 17. Januar 2025: Realistisch planen

Q3/2024: Standortbestimmung, Governance, Quick-Wins (MFA-Lücken, kritische Patches, Backup-Härtung), Vorfall-Playbooks, Lieferanten-Tiering.
Q4/2024: KRIs/KPIs, erstes Management-Review, Tabletop-Übungen, Vertragsanpassungen für kritische Lieferanten, Logging-Gaps schließen, Restore-Tests.
Q1/2025: Nachweise bündeln, offene Lücken mit Plan/Frist belegt, Reporting-Takt stabil, Folgetests terminiert, Beschlüsse protokolliert.

Nicht alles ist bis Tag X „perfekt“ – aber sichtbare Wirksamkeit, Priorisierung und Plan sind Pflicht.

Fallbeispiel kompakt

Ein Zahlungsdienstleister mit hoher Cloud-Quote hatte Policies, aber wiederkehrende Ausfälle durch Konfig-Fehler. Nach DORA-Programm: Cloud-Guardrails, Change-Kontrollen, quartalsweise Restore-Tests, Lieferanten-Tiering, KRIs im Board. Ergebnis nach neun Monaten: Patch-SLA von 62 % auf 92 %, Restore-Zeit von 10 h auf 2 h, kein meldepflichtiger Vorfall trotz Hyperscaler-Störung – dank geübtem Degradationsbetrieb.

Typische Stolpersteine – und Gegenmittel

  • IT-Alleinansatz: → Lenkungskreis & gemeinsame Roadmap.
  • Listen ohne Wirkung: → KRIs mit Verantwortlichen und Fristen.
  • Lieferanten nur per Fragebogen: → Nachweise verifizieren, stichprobenartig prüfen.
  • Ungeübte Playbooks: → Tabletop & Live-Drills fest verankern.
  • Ausnahmen ohne Ablauf: → Befristen, kompensieren, nachhalten.

Kosten & Nutzen: Der Business-Case

Nutzen entsteht durch Risiko- und Ausfallreduktion, Effizienzen (Automation, klare Prozesse), Vertrauensgewinn (Kunden/Aufsicht) und Skalierbarkeit (neue Produkte sicher launchen). Investieren Sie zuerst in die großen Hebel: Identitäten, Patches, Backups, Logging, Lieferkette.

Schnellstart-Checkliste

  • DORA-Programm mandatieren, Governance setzen.
  • Asset/Service-Inventar & Kritikalitäten vervollständigen.
  • Quick-Wins: MFA-Lücken, kritische Patches, Backup-Immutability, Logging-Gaps.
  • Vorfall-Playbooks und Tabletop im Kalender.
  • Lieferanten-Tiering, Mindestanforderungen, Vertragsanpassungen starten.
  • KRIs/KPIs definieren, Board-Reporting beginnen.
  • Restore-Tests durchführen, Findings schließen.
  • Q-Review mit Beschlüssen – belegt, nicht behauptet.

Häufige Fragen kurz beantwortet

Reicht ISO 27001? Eine starke Basis, aber DORA geht tiefer (Meldungen, TLPT, Lieferkette).
Müssen alle TLPT machen? Nein, nur ausgewählte. Alle brauchen jedoch ein stimmiges Test-Portfolio.
Kleine Institute – weniger Aufwand? Ja, aber keine Abstriche bei Grundprinzipien (Risiko, Vorfälle, Lieferkette).
Welche Belege will die Aufsicht sehen? Konsistente Risiken, Maßnahmen, Tests, Berichte, Beschlüsse – mit Datum, Besitzer, Wirkung.

Fazit: Struktur schlägt Hektik

DORA verlangt nichts Unmögliches – aber es verlangt Systematik, Führung und Evidenz. Wer früh startet, Wirkung misst und regelmäßig testet, steht zum Stichtag nicht nur compliant da, sondern robuster. Der wahre Gewinn liegt jenseits des Gesetzestextes: weniger Ausfälle, schnellere Wiederherstellung, höheres Vertrauen. Genau das ist digitale Resilienz – und genau das macht DORA zur Chance statt Bürde.

3
×
Stay Informed

When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.

Schutzziele 2.0 – Was heute noch alles zählt
Der ISB erklärt – Zwischen Feuerwehr und Architekt

Related Posts

Image
We use cookies

We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.