DORA-Durchsetzung wird 2026 ernst: Überstehen Ihre Access-Reviews eine Live-Prüfung?

Kurzfassung. DORA ist seit dem 17. Januar 2025 für Finanzunternehmen in der EU und viele IKT-Dienstleister rechtlich verbindlich, aber 2026 markiert den Wechsel von Orientierungshilfe zu echter Durchsetzung. Aufseher wie die BaFin starten 2026 gezielte DORA- und NIS2-Prüfungen, wobei die BaFin bereits ab Q1 2026 mit DORA-Prüfungen zum IKT-Risiko beginnt. Die Frage lautet nicht mehr "Haben wir eine Berechtigungsrichtlinie?", sondern: "Können wir hier und jetzt beweisen, dass jeder privilegierte Zugriffspfad unter Kontrolle ist?"

Dieser Beitrag erklärt, was DORA beim Berechtigungsmanagement tatsächlich verändert, wie eine "Live-Prüfung" im Jahr 2026 praktisch abläuft und warum Tabellen und reine SSO-Abdeckung die Anforderungen der Aufsicht nicht erfüllen werden.

Von Papier zur Beweisführung: Wie DORA das Prüfspiel verändert

Seit Jahren gleichen Berechtigungsüberprüfungen oft einem Compliance-Theater: Export aus ein paar Kernsystemen, Tabellen verteilen und kurz vor Jahresende alles abnicken.

DORA beendet diesen Ansatz.

Eine Regulierung für kontinuierliches Risiko, nicht jährliche Checklisten

DORA (Verordnung (EU) 2022/2554) zielt auf die digitale operationelle Resilienz - also die Fähigkeit, IKT-Störungen zu verkraften, ohne kritische Dienstleistungen zu unterbrechen. Daraus ergeben sich vier wesentliche Konsequenzen für Ihre Identity- und Access-Landschaft:

• Vereinheitlichtes IKT-Risikomanagement. DORA harmonisiert die IKT-Risikoanforderungen für Banken, Versicherer, Wertpapierfirmen und Zahlungsinstitute und ersetzt ein Flickwerk vorheriger Leitlinien.
• Enormer Anwendungsbereich. Über 22.000 Finanzunternehmen und IKT-Anbieter fallen in der EU unter DORA - die Regulierung reicht sehr tief.
• Direkte Pflichten für Dienstleister. Kritische IKT-Drittdienstleister (Critical ICT Third-Party Providers, CTPP) unterliegen nun einer Aufsicht auf EU-Ebene. Die Zugriffskontrollen Ihrer Dienstleister sind damit ebenfalls prüfungsrelevant.
• Beweise statt Erzählungen. Aufseher verwenden RTS/ITS-Templates und Register und erwarten abrufbare, abfragbare Zugriffsdaten - nicht PDF-Berichtsmappen.

Statische, punktuelle Bestätigungen sind passé. Kontinuierliche, datengetriebene Aufsicht ist der neue Standard.

2026: Übergang zu Prüfungen vor Ort

2024-2025 standen technische Standards, Leitlinien und Gap-Analysen im Fokus. 2026 gilt:

• Institute und Aufseher markieren 2026 als erstes echtes Prüfjahr für DORA, mit geplanten thematischen Prüfungen zu IKT-Risiken und Dienstleistersteuerung.
• BaFin und Bundesbank haben bereits DORA-Auslegungshilfen und Umsetzungshinweise veröffentlicht, die künftige Prüfungen konkretisieren.
• Ab 2026 werden Berichte die IKT-Governance direkt mit Kapital- und Risikoanalysen verknüpfen - digitale Resilienz wird damit endgültig zum Vorstandsthema.

Rechnen Sie damit, dass Prüfer sehr genau hinterfragen, wer worauf zugreifen kann, wie dieser Zugriff vergeben, geprüft und nachweisbar dokumentiert wird - in Echtzeit.

Warum Berechtigungsmanagement in DORAs kritischem Pfad liegt

DORA ist keine "Zugriffskontroll-Verordnung" dem Namen nach. Aber wer den Text - Artikel, RTS, Leitlinien - liest, findet Identity- und Access-Governance an jeder Ecke.

Was DORA beim Zugriff konkret verlangt

Zentrale Punkte mit direkter Wirkung auf Access-Reviews:

• Schutz & Prävention (Artikel 9). Artikel 9 verpflichtet zu laufender Überwachung und Kontrolle der IKT, um Verfälschung, Verlust oder unbefugten Zugriff auf Daten zu verhindern - Sie brauchen also jederzeit einen aktuellen Blick auf Berechtigungen.
• Protokollierung und Audit-Trails. Die DORA-RTS fordern die Protokollierung von logischem und physischem Zugriff im Rahmen des IKT-Risikomanagements - privilegierte Zugriffe eingeschlossen.
• Grundsätze der Zugriffsrechte. Zugriffsrechte müssen dem Need-to-know-Prinzip, dem Prinzip der geringstmöglichen Rechte und funktionaler Trennung (Segregation of Duties, SoD) gemäss Artikel 9 Abs. 4 Buchst. c und den RTS folgen. Ad-hoc-Ausweitung von Privilegien bedeutet Nichteinhaltung
• IKT-Drittdienstleister-Register. Es ist ein vollständiges Register aller IKT-Drittdienstleisterverträge zu führen - inklusive Angaben zu Zugriffen und Sicherheitsmaßnahmen

Wenn Ihre Reviews nur einige Inhouse-Systeme abdecken und SaaS, Datenplattformen und Drittdienstleister-Konsolen ausblenden, verfehlen Sie inzwischen sowohl den Geist als auch den Wortlaut von DORA.

Echtzeit-Prüfungen brauchen Echtzeit-Daten

Aufseher sind klar: Sie erwarten laufende Aufsicht - nicht statische, jährliche Berichte.

• IKT-Vorfälle müssen in standardisierten, strukturierten Formaten klassifiziert und gemeldet werden.
• Risikorahmenwerke benötigen nahezu Echtzeit-Monitoring und Anomalieerkennung, nicht nur jährliche Register.

Im Identity-Kontext gilt: Wenn Sie auf Abruf nicht beantworten können, "Welche privilegierten Identitäten haben über welche Pfade Zugriff und wann wurden sie zuletzt überprüft?", besteht ein aufsichtsrechtliches Risiko.

Inside einer DORA-Prüfung 2026: Wie eine "Live-Access-Audit" aussieht

Stellen Sie sich Oktober 2026 vor. Ihr Institut steht vor einer DORA-Prüfung.

Aufseher fragen nicht nur nach Richtlinien - sie setzen sich mit CISO, IT und Compliance an einen Tisch und verlangen, Berechtigungssteuerung live zu sehen.

Die Fragen, die Sie bekommen werden

Die meisten Institute müssen sich auf Folgendes einstellen:

• Abdeckung:
  • "Zeigen Sie uns Ihr vollständiges Verzeichnis aller Systeme im DORA-Geltungsbereich - inklusive SaaS, Cloud und zentralen IKT-Dienstleistern."
  • "Welche Systeme werden zentral gesteuert? Welche erfordern manuelle Administration?"
• Zugriffsstatus:
  • "Liefern Sie für diese Schlüsselplattform eine Echtzeit-Liste aller privilegierten Konten - inklusive Dienst- und Maschinenidentitäten."
  • "Zeigen Sie, wann diese Rechte zuletzt geprüft wurden, von wem und welche Änderungen erfolgt sind."
• Lebenszyklus-Steuerung:
  • "Zeigen Sie für einen zufällig ausgewählten Eintritt und Austritt den vollständigen Access-Lebenszyklus mit Zeitstempeln und Genehmigungsentscheidungen."
• Drittdienstleister-Risiko:
  • "Zeigen Sie aus Ihrem IKT-Drittdienstleister-Register, wer Admin-Rechte auf den Konsolen dieser Anbieter hat und wie diese Rechte geprüft werden."
• Beweissicherheit:
  • "Wo liegen die Protokolle zu Berechtigungsprüfungen und Bereitstellung? Sind sie unveränderbar? Exportierbar?"

Wenn Ihre Antwort lautet "Geben Sie uns ein paar Tage, um das zusammenzustellen", sind Sie nicht bereit. DORA erwartet live, abfragbare Beweise, nicht ad-hoc zusammengestellte Berichte.

Manuell + SSO vs. kontinuierliche Access-Governance

Die meisten Finanzunternehmen mit 50-2.000 Mitarbeitenden arbeiten heute so:

DORA wird diese Lücke 2026 schonungslos sichtbar machen.

Warum manuelle Reviews und reine SSO-Abdeckung DORA nicht überleben

Lassen Sie uns deutlich werden.

"Wir haben SSO, also sind wir auf der sicheren Seite"

SSO-Werkzeuge wie Okta oder Entra ID lösen die Authentifizierung. Sie liefern kein Identity-Governance:

• Sie automatisieren in der Regel nur Zugriffe für SCIM-fähige oder SSO-integrierte Anwendungen - oft lediglich 20 % Ihres Stacks. Daten von Iden zeigen, dass die meisten mittelgroßen Unternehmen genau diesen kleineren Teil automatisieren und den Rest manuell bereitstellen.
• SSO steuert Gruppen/Rollen, aber DORA verlangt Berechtigungen auf Feingranularitätsebene. Aufseher werden auf Kanäle, Repositories, Projekte und ähnliche Objekte zoomen - dort, wo SCIM und SSO unscharf werden.

SSO beantwortet die Login-Frage, nicht die Governance-Frage.

"Unsere Führungskräfte zeichnen einmal im Jahr Berechtigungen ab"

Jährliche Tabellen-Zertifizierungen scheitern an DORA aus drei Kerngründen:

1. Unvollständig. Langschwanz-SaaS, Fachanwendungen und Admin-Konsolen werden oft nie geprüft.
2. Nicht verifizierbar. CSVs und E-Mails lassen sich leicht bearbeiten, verlieren oder sind nie eindeutig mit dem tatsächlichen Berechtigungsstand verknüpft. Es gibt keine Garantie, dass Reviews mit aktuellen Daten erfolgten.
3. Nicht kontinuierlich. DORA erwartet Echtzeit-Überwachung und schnelle Entziehung von Rechten - keine Jahreszyklen.

Aufseher müssen nur live, systembasierte Beweisdaten verlangen - Tabellen verlieren damit ihre Daseinsberechtigung.

"Wir kümmern uns darum, wenn die DORA-Prüfungen starten"

Das ist eine gefährliche Annahme.

Die meisten Mitgliedstaaten haben DORA umgesetzt, mit maximalen Verwaltungsstrafen häufig bis zu 5 Mio. EUR - oder in Belgien bis zu 10 % des Jahresumsatzes

Der Aufbau kontinuierlicher Access-Governance - insbesondere für SaaS, Cloud und Drittdienstleister - lässt sich nicht in letzter Minute erledigen. Dafür braucht es Struktur, keinen Panikmodus.

Wie "DORA-bereites" Berechtigungsmanagement tatsächlich aussieht

Vergessen Sie Schlagworte. Hier ist ein praktisches Zielbild - passend für DORA und schlanke IT-Teams.

1. Universelle Abdeckung aller in-scope Systeme

Eine einheitliche Sicht auf Identitäten und Zugriffe, die umfasst:

• Kernsysteme für Banking/Handel/Zahlungen
• Interne Fachanwendungen
• Kritische SaaS-Werkzeuge (CRM, elektronische Signatur, Cloud-Speicher, Zusammenarbeit)
• Cloud- und Infrastrukturplattformen (IaaS, Kubernetes, Datenbank-Konsolen, Sicherheitswerkzeuge)

DORA interessiert sich nicht dafür, ob eine Anwendung SCIM oder eine API hat. Sie müssen SSO-"Abdeckungslücken" schließen.

2. Automatisierter Lebenszyklus mit richtliniengesteuertem Zugriff

Manuelle Joiner/Mover/Leaver-Prozesse hängen immer hinterher. DORA-bereite Zugriffssteuerung setzt auf richtliniengesteuerte Automatisierung:

• Basiszugriffe nach Rolle, Abteilung, Standort und Risikoprofil
• Zeitlich begrenzte Privilegien mit automatischer Entziehung
• Ereignisgesteuerte Deprovisionierung bei HR-/Verzeichnis-Triggern
• Einheitliche, automatisierte Behandlung von Externen, Dienstkonten und KI-Agenten

Damit belegen Sie gelebte Least-Privilege-Prinzipien - nicht nur formale Häkchen.

3. Automatisierte, risikobasierte Access-Reviews

Sie brauchen nicht weniger, sondern klügere Reviews:

• Risikobasierter Zuschnitt: Hochrisiko-Systeme werden häufiger geprüft
• Kontexthinweise: wann/wer/wie Zugriff erhalten hat; letzte Nutzung
• Standardaktionen (z. B. automatische Entziehung inaktiver Zugriffe, Begründungspflicht bei Ausnahmen)
• Unveränderbare Dokumentation der Zertifizierungen

Iden-Kunden berichten, dass sie durch automatisierte Beweisführung rund 120 Stunden pro Quartal bei Reviews einsparen - Zeit, die von Fleißarbeit zu echter Risikoarbeit verschoben wird.

4. Unveränderbare Audit-Logs im Sinne von DORA

Ihre Protokolle müssen sowohl dem Sicherheitsbetrieb als auch der Aufsicht dienen. Basisanforderungen:

• Zeitstempel und Auslöser für alle Zugriffsereignisse
• Zuordnung der Logs zu sämtlichen Identitäten (inklusive Agenten, Dienstkonten)
• Kryptographisch geschützte/unveränderbare Speicherung
• Fähigkeit, den Berechtigungsstand zu jedem beliebigen Zeitpunkt historisch nachzuvollziehen

DORA erwartet, dass Sie Vorwürfe "unbefugter Zugriffe" mit Nachweisen entkräften - nicht mit Behauptungen.

5. Drittdienstleister-Risiko mit Zugriffspfaden verknüpfen

Die IKT-Drittdienstleistervorgaben von DORA verlangen mehr als Vertragsklauseln. Sie müssen:

• Vom Drittdienstleister-Register ausgehen und abbilden, wer diese Anbieter administrieren darf
• Least-Privilege und SoD konsequent auf diese kritischen Rechte anwenden
• nachweisen, wann diese Rechte zuletzt durch wen geprüft wurden

Sind Vertrags- und Zugriffsdaten getrennt, zwingt DORA Sie, diese Lücke zu schließen.

Wie Iden DORA-taugliche Governance umsetzt

Dies ist kein Pitch, sondern ein Erfahrungsbericht aus der Praxis. Iden wurde für Organisationen gebaut, die über SSO und manuelle Provisionierung hinausgehen wollen, ohne den Ballast klassischer IGA-Suiten. Das ist heute der DORA-Sweet-Spot: 50-2.000 Mitarbeitende, starke SaaS-Nutzung, schlanke IT-/Security-Teams.

Unser Ansatz:

• Vollständige Abdeckung ohne "SCIM-Steuer". Universelle Konnektoren unterstützen SCIM, APIs und sogar schwer integrierbare oder "geschlossene" SaaS-Anwendungen und decken den Langschwanz ab, in dem sensible Daten liegen.
• Feingranulare Steuerung. Governance bis auf Kanal-, Repository- oder Projektebene - nicht nur "hat App/hat keine App". Genau dort entstehen reale SoD-Konflikte.
• Kontinuierliche Governance und automatisierte Reviews. Agentische (KI-gesteuerte, autonome) Workflows führen Reviews durch, sammeln Beweise und markieren Auffälligkeiten - ohne Ticket-Stau.
• Unveränderbare Audit-Trails. Bankentaugliche Verschlüsselung und Protokolle, die Sie einem Prüfer zeigen können - nicht nur ein SharePoint-Ordner mit der Überschrift "DORA 2026".
• Keine SCIM-Steuer. Vollautomatisierung ohne Zwang zu teuren Enterprise-Tarifen im SaaS-Portfolio - ein Ausgleich zwischen DORA-Anforderungen und Kostendisziplin.

Sie brauchen Iden nicht zwingend, um konform zu sein. Aber jede DORA-taugliche Lösung muss denselben Kern abdecken: Abdeckung, Kontrolle und kontinuierliche Evidenz - über Ihren gesamten Stack hinweg.

Konkrete Schritte vor den Prüfungen 2026

Wenn Sie im Fokus von DORA stehen und noch mit Tabellen arbeiten, könnte Ihre Schrittfolge so aussehen:

1. Ihre tatsächliche Zugriffslage kartieren

• DORA-regulierte Einheiten im Unternehmen definieren
• Anwendungsinventar mit Risikoklassen (kritisch, unterstützend, geringes Risiko) erstellen oder aktualisieren
• SaaS- und IKT-Drittdienstleister-Systeme einbeziehen

2. Identitäten und Hochrisiko-Zugriffe klassifizieren

• Identitäten erfassen: Mitarbeitende, Externe, Drittdienstleister-Operatoren, KI-Agenten, Dienstkonten
• Rollen mit sensiblen Befugnissen markieren (Zahlungsverkehr, Handel, Konfiguration, Sicherheit)
• Festlegen, welche Rollen unter DORA einer kontinuierlichen Überprüfung bedürfen

3. Lückenanalyse Ihrer aktuellen Access-Reviews

Für jedes Schlüsselsystem:

• Wie werden Konten bereitgestellt (SSO, lokale Admins, Tickets)?
• Wie und wie häufig werden Reviews durchgeführt?
• Wo werden Nachweise gespeichert? Lassen sie sich mit dem tatsächlichen Zustand abgleichen?
• Wie werden Austritte und Rollenwechsel gehandhabt?

Daraus ergeben sich Ihre DORA-Risikohotspots.

4. Kontinuierliche Governance in einem Kernbereich pilotieren

Wählen Sie einen kritischen Ausschnitt (z. B. Handel + SaaS oder Zahlungen + Fraud-Tools):

• Alle relevanten Anwendungen integrieren (mit oder ohne SCIM)
• Joiner/Mover/Leaver-Flows automatisieren
• Einen ersten automatisierten, richtliniengesteuerten Access-Review mit Beweisführung durchführen
• Aufwand, geschlossene Lücken und Erkenntnisse dokumentieren

Das belegt Umsetzbarkeit und liefert eine konkrete Story für Aufseher.

5. Skalieren und optimieren

Sobald der Pilot trägt:

• Abdeckung Anwendung für Anwendung erweitern, mit Fokus auf kritische Systeme und Dienstleister
• Richtlinien standardisieren (z. B. maximale Dauer erhöhter Rechte, Schwellwerte für Inaktivität)
• Governance-Nachweise in Ihr DORA-Programm einbetten (Risikoregister, Incident Response, Notfallpläne)

Kontinuierliche Access-Governance wird damit zum Betriebsstandard - nicht zur Last-Minute-Aktion.

Häufig gestellte Fragen

Schreibt DORA explizit Access-Reviews vor?

DORA nennt den Begriff "User Access Review" nicht wörtlich, verlangt aber:

• Rechte müssen dem Least-Privilege-Prinzip und SoD folgen.
• IKT-Rahmenwerke müssen unbefugte Zugriffe überwachen und steuern und die zugehörigen Ereignisse protokollieren.

Regelmäßige, dokumentierte und zunehmend automatisierte Reviews sind der einzig praktikable Weg, diese Vorgaben zu erfüllen.

Gibt es Erleichterungen für kleinere Institute?

DORA erlaubt vereinfachte Rahmenwerke für kleinere oder weniger komplexe Unternehmen, streicht aber nicht die Anforderungen an Zugriffskontrollen, Protokollierung oder Dienstleisterrisiken.

Wer im Geltungsbereich ist, muss privilegierte Zugriffe dennoch steuern, überwachen und prüfen - wenn auch in ggf. schlankerer Ausprägung.

Wie spielt DORA mit NIS2 und MaRisk zusammen?

DORA adressiert den Finanzsektor, NIS2 "wesentliche" und "wichtige" Einrichtungen in der gesamten Wirtschaft. In der Praxis gilt:

• Viele Finanzinstitute fallen unter beide Regime.
• Nationale Aufseher (z. B. BaFin) stellen klar, dass DORA MaRisk ergänzt, nicht ersetzt.

Gestalten Sie einmal eine Lösung für kontinuierliche Evidenz und umfassende Abdeckung - und mappen Sie diese dann auf DORA, NIS2, SOC 2, ISO 27001 usw. So vermeiden Sie parallele Programme.

Was ist mit SaaS-Anwendungen ohne SCIM oder APIs?

DORA interessiert sich nicht für Integrationshürden. Wenn ein System Zahlungen, Handel, Kundendaten oder Sicherheit betrifft, ist es im Scope. Sie müssen also Zugriffe steuern für:

• Kollaborationsplattformen mit sensiblen Freigaben
• Kritische, aber spezialisierte SaaS-Lösungen (Fraud-Tools, RegTech, Treasury)
• Konsolen von Drittdienstleistern, über die Sie diese Anbieter administrieren

Die Erfahrung von Iden: Die meisten Identitätsblinden Flecken und manuellen Aufwände stecken genau hier. DORA-Konformität erfordert, dieses "fehlende 80 %" Problem zu lösen.

Brauchen Sie zwingend eine IGA-Plattform für DORA?

Formal nein - DORA schreibt keine bestimmte IGA-Lösung vor. Aber Sie müssen liefern:

• Vollständige, aktuelle Verzeichnisse von Berechtigungen
• Durchgesetztes Least-Privilege und funktionale Trennung
• Kontinuierliches Monitoring und unveränderbare Log-Nachweise
• Zuverlässige, schnelle Antworten für Aufseher

Sie können das mit SSO, ITSM und Tabellen bauen - die meisten schlanken Teams stoßen aber bis 2026 unter dem DORA-Druck an ihre Grenzen. Eine leichte, vollständige Governance-Schicht (Iden oder vergleichbar) ist die realistische Antwort.

Fazit. DORA führt kein neues Konzept ein. Die Verordnung beendet lediglich die Illusion, dass teilweises, manuelles Berechtigungsmanagement ausreicht. Wenn Sie 2026 keine Live-Prüfung nach DORA bestehen können - mit Echtzeit-Abdeckung aller Systeme und Dienstleister -, ist jetzt der Zeitpunkt, diese Lücken zu schließen. Nicht im vierten Quartal 2026.