Warum DORA mehr als ein Compliance-Projekt ist
Seit dem 17. Januar 2025 ist der Digital Operational Resilience Act (DORA, Verordnung (EU) 2022/2554) für Banken, Versicherer, Zahlungsdienstleister und ihre IKT-Dienstleister bindend. Die Verordnung erzwingt erstmals europaweit einen ganzheitlichen Resilienz-Ansatz, der weit über klassische IT-Sicherheit hinausgeht: betriebliche Stabilität, Vorfallsmanagement, Testen unter realen Bedingungen und die durchgängige Steuerung von Drittparteien stehen im Fokus.
Eine aktuelle Einschätzung eines PwC-Experten im IT-Finanzmagazin macht deutlich: Wer DORA als reine Dokumentenübung versteht und seine Kontrollkette nur formal nachbessert, riskiert beim ersten Prüfbericht handfeste Feststellungen. Die größten Lücken liegen heute nicht in der Peripherie, sondern in der Zugriffssicherheit – also genau dort, wo Angreifer in den letzten Jahren systematisch erfolgreich waren.
DORA verpflichtet Finanzunternehmen zu nachweisbarer digitaler Betriebsstabilität. Geprüft werden u. a. IKT-Risikomanagement, Vorfallmeldungen, Resilienztests und das Drittparteienregister. Die IAM-Architektur berührt mehrere dieser Bereiche gleichzeitig und wird damit zum zentralen Prüfgegenstand.
Diese Analyse fasst die zentralen Aussagen zusammen, ordnet sie regulatorisch ein und zeigt anhand der vier kritischen Stellschrauben – IAM-Architektur, Re-Zertifizierung, Log-Tiefe und Drittparteiensteuerung –, welche Maßnahmen jetzt realistisch tragen.
IAM-Architektur: Vom Berechtigungsdickicht zum kontrollierten Zugriff
Über Jahre gewachsene Berechtigungsmodelle sind in vielen Häusern Realität: Sammelaccounts, dauerhaft erhöhte Rechte für Admins, Servicekennungen ohne Eigentümer und manuell gepflegte Rollen in mehreren Verzeichnissen. DORA verlangt – unter anderem über Artikel 9 (Schutz und Prävention) – ein Least-Privilege-Modell, lückenlose Identitätsbindung und nachvollziehbare Zugriffsentscheidungen über den gesamten Lebenszyklus.
Identity-Lifecycle automatisieren
Joiner-, Mover- und Leaver-Prozesse end-to-end aus dem führenden HR-System auslösen. Manuelle Pflege ist die häufigste Ursache verwaister Konten.
Privileged Access trennen
Administrative Sitzungen über dedizierte Bastions oder Access-Bridges leiten – kein Direktzugang aus Standardarbeitsplätzen auf produktive Kernsysteme.
Just-in-Time-Berechtigung
Erhöhte Rechte zeitlich befristen und an Tickets oder Change-Records binden. Permanente Admin-Rollen sind in der DORA-Prüfung schwer zu rechtfertigen.
MFA durchgehend
Mehrfaktorauthentifizierung phishing-resistent ausgestalten (FIDO2/Passkeys, Smartcards) – insbesondere für Admins, Remote-Zugriffe und Drittanbieter.
In vielen Häusern existieren historisch gewachsene Sammelaccounts mit hohen Rechten, ohne klaren Eigentümer und ohne aktuelle Re-Zertifizierung. Diese Konten sind das bevorzugte Ziel von Ransomware-Operatoren und ein nahezu sicherer DORA-Befund, sobald die Prüfer Stichproben ziehen.
Re-Zertifizierung: Prozess statt Pflichtübung
Re-Zertifizierungen sind in den meisten Häusern etabliert – aber nicht selten als jährliche Massensignatur durch überlastete Führungskräfte. DORA und die zugehörigen Regulatory Technical Standards verlangen jedoch risikoorientierte, prüfbare Entscheidungen, die nachvollziehbar an die Sensitivität der Anwendung gekoppelt sind.
Ablauf einer belastbaren Re-Zertifizierung
- 1Anwendungen nach Schutzbedarf und Kritikalität klassifizieren (z. B. nach BAIT/MaRisk-Logik).
- 2Frequenz festlegen: hochkritische Systeme quartalsweise, Standardanwendungen halbjährlich, Massendaten mindestens jährlich.
- 3Entscheider eindeutig benennen – fachlicher Eigentümer, nicht der IT-Betrieb.
- 4Kampagne mit Kontext anstoßen: Welche Rolle, welche Aktivität in den letzten 90 Tagen, welche segregations-kritische Kombination?
- 5Entzug oder Anpassung sofort technisch nachvollziehen – kein „akzeptiert" ohne ticketgestützte Konsequenz.
- 6Ergebnisse signiert ablegen und für die Prüfung mindestens für die regulatorisch geforderte Aufbewahrungsfrist vorhalten.
Entscheidend ist die Konsequenzkette: Wer ein Recht entzieht, muss prüfen können, ob die Änderung in Active Directory, Entra ID, Datenbanken und SaaS-Plattformen tatsächlich angekommen ist. Ohne diesen Closing-Loop bleibt die Zertifizierung Papier.
Log-Tiefe: Was Prüfer und Forensiker tatsächlich erwarten
DORA verlangt die Erkennung anomaler Aktivitäten und die forensische Auswertbarkeit von Vorfällen. Reine Anmeldelogs reichen dafür nicht. Geprüft wird, ob die Logkette von der Anmeldung über die Rechteausübung bis zur Datenmanipulation rekonstruierbar ist und ob die Logs manipulationsresistent abgelegt werden.
| Bereich | Häufig vorhanden | DORA-Erwartung |
|---|---|---|
| Authentifizierung | Login-Events (Erfolg/Fehler) | + MFA-Faktor, Geräte- und Kontextdaten, Risiko-Score |
| Privilegierte Sitzungen | Sudo-/RunAs-Events | Vollständige Session-Aufzeichnung, Befehlsprotokolle, Vier-Augen-Freigabe |
| Datenzugriff | Read-Counter aggregiert | Object-Level-Auditing, Massenexporte alarmiert, DLP-Korrelation |
| Aufbewahrung | 30–90 Tage online | Mehrjährige WORM-Archivierung, Hash-Kette, getrennte Speicherklasse |
Eine pragmatische Minimal-Konfiguration für Windows-Server, die in den meisten DORA-Prüfungen unauffällig durchgeht, sieht etwa so aus:
# Privilegierte Aktionen & Logon-Sessions sauber erfassen
auditpol /set /subcategory:"Sensitive Privilege Use" /success:enable /failure:enable
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable
auditpol /set /subcategory:"Authentication Policy Change" /success:enable /failure:enable
# Command-Line in 4688-Events aktivieren
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" \
/v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /fBehandeln Sie das zentrale SIEM/Logging als eigenes kritisches System mit eigenem Notfallplan. Wer im Vorfall keine Logs hat, kann auch nicht melden – und DORA-Vorfallmeldungen sind fristgebunden.
Drittparteiensteuerung: Identität endet nicht an der Unternehmensgrenze
Die Kapitel V der Verordnung – insbesondere die Artikel 28 ff. – machen die Steuerung von IKT-Drittanbietern zu einem eigenständigen Pflichtprogramm. Praktisch heißt das: Jeder externe Dienstleister, der auf Daten oder Systeme zugreift, muss in der IAM-Welt sauber abgebildet sein – mit eigener Identität, klaren Berechtigungsgrenzen und überwachten Sitzungen.
Externe Berater oder Wartungs-Teams arbeiten oft mit Sammel-VPN-Accounts, geteilten Admin-Passwörtern oder unmoderierten RDP-Sprungservern. Im Vorfall ist nicht nachvollziehbar, wer was getan hat – ein Befund, der nicht nur DORA-relevant ist, sondern auch zivilrechtliche Haftungsfragen aufwirft.
Sinnvoll ist eine klare Architektur, die externe Identitäten technisch und organisatorisch isoliert, ohne den operativen Betrieb auszubremsen:
Eigene Identitäten
Externe erhalten personalisierte Konten mit eindeutiger Kennzeichnung, gebunden an einen vertraglich benannten Eigentümer.
Zeitfenster & Tickets
Zugriffe nur innerhalb genehmigter Change-/Wartungsfenster; nach Ablauf automatisches Deaktivieren über den IAM-Workflow.
Session-Brokering
Privilegierte Tätigkeiten ausschließlich über eine Access-Bridge mit Aufzeichnung, statt direktem RDP/SSH ins Netz.
Register & Reporting
Lückenlose Abbildung im DORA-Drittparteienregister inkl. Kritikalitätseinstufung und Konzentrationsanalysen.
Diese Maßnahmen bringen einen Doppelnutzen: Sie erfüllen die DORA-Anforderungen an die Drittparteiensteuerung und schließen gleichzeitig den Angriffspfad, der bei den großen Supply-Chain-Vorfällen der letzten Jahre regelmäßig ausgenutzt wurde.
Was jetzt zu tun ist: Vom Befund zur belastbaren Resilienz
Häuser, die DORA bislang formal abgehakt haben, sollten die Zeit bis zur ersten Tiefenprüfung nutzen, um die Zugriffssicherheit substanziell zu härten. Der pragmatische Pfad besteht aus drei Phasen – jede einzelne liefert prüfbaren Mehrwert und reduziert das reale Risiko unmittelbar.
Roadmap in drei Phasen
- 1Bestandsaufnahme (4–8 Wochen): Identitäten, privilegierte Konten, externe Zugriffe und kritische Datenpfade inventarisieren; Lücken gegen DORA Art. 9 und Art. 28 dokumentieren.
- 2Quick Wins (2–4 Monate): MFA für alle privilegierten Konten erzwingen, Sammelaccounts auflösen, Audit-Policy harmonisieren, Drittanbieter über eine Access-Bridge kanalisieren.
- 3Strukturhärtung (6–12 Monate): Identity-Lifecycle vollautomatisieren, Just-in-Time-Berechtigung etablieren, SIEM-Use-Cases für DORA-Vorfallmeldung an die EU-zuständige Behörde produktiv schalten.
Ein Audit besteht selten an der Detailtiefe einer Richtlinie, sondern an der Frage: Kann das Haus den realen Verlauf eines Vorfalls binnen Stunden rekonstruieren – inklusive aller beteiligten Identitäten und externer Zulieferer? Wer diese Frage glaubhaft mit „ja“ beantwortet, hat den Kern von DORA verstanden.
Wir begleiten Finanzinstitute und ihre Dienstleister bei genau dieser Reise – mit Fokus auf Zugriffssicherheit, Logging und Drittparteiensteuerung. Weiterführende Informationen finden Sie in unserem DORA-Beratungsangebot.