DORA-Durchsetzung wird 2026 ernst: Bestehen 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 Übergang von Orientierung zu echter Durchsetzung. Aufsichtsbehörden wie die BaFin starten 2026 gezielte DORA- und NIS2-Prüfungen, wobei BaFin bereits im Q1 2026 mit DORA-IKT-Risikoprüfungen beginnt. Die Frage lautet nicht mehr "Haben wir eine Zugriffsrichtlinie?", sondern: "Können wir jetzt sofort nachweisen, dass jede privilegierte Zugriffskette unter Kontrolle ist?"

Dieser Beitrag erklärt, was DORA konkret für Access Governance verändert, wie eine "Live-Prüfung" im Jahr 2026 praktisch abläuft und warum Excel-Listen und reine SSO-Abdeckung die aufsichtsrechtlichen Anforderungen nicht erfüllen werden.

Von Papier zur Beweisführung: Wie DORA das Audit-Spiel verändert

Seit Jahren gleichen Access Reviews oft einem Compliance-Theater: Exporte aus ein paar Kernsystemen, Verteilen von Tabellen, und kurz vor Jahresende wird alles durchgewunken.

DORA beendet diesen Ansatz.

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

DORA (Verordnung (EU) 2022/2554) zielt auf digitale operationelle Resilienz - also die Fähigkeit, IKT-Vorfälle zu verkraften, ohne kritische Services zu unterbrechen. Daraus ergeben sich vier wesentliche Auswirkungen auf Ihr Identity- und Access-Stack:

• Einheitliches IKT-Risikomanagement. DORA vereinheitlicht die IKT-Risikopflichten für Banken, Versicherer, Wertpapierfirmen und Zahlungsinstitute und ersetzt zersplitterte frühere Leitlinien.
• Enormer Geltungsbereich. Über 22.000 Finanzunternehmen und IKT-Dienstleister fallen in der EU unter DORA - es handelt sich um eine sehr weitreichende Regulierung.
• Direkte Pflichten für Dienstleister. Kritische IKT-Drittdienstleister (CTPPs) unterliegen jetzt einer EU-weiten Aufsicht. Die Zugriffskontrollen Ihrer Provider fallen damit ebenfalls in den Umfang Ihrer Prüfungen.
• Beweise statt Erzählungen. Aufseher arbeiten mit RTS/ITS-Templates und Registern und erwarten abrufbare, abfragbare Access-Daten - keine zusammengehefteten PDF-Reportings.

Statische Momentaufnahmen und reine "Attestierungen" sind vorbei. Kontinuierliche, datengetriebene Aufsicht ist der neue Standard.

2026: Von der Vorbereitung zur Inspektion

2024-2025 standen technische Standards, Leitfäden und Gap-Analysen im Vordergrund. 2026 gilt:

• Institute und Aufseher deklarieren 2026 als erstes echtes Prüfjahr für DORA, mit geplanten thematischen Reviews zu IKT-Risiken und Dienstleistersteuerung.
• BaFin und Bundesbank haben bereits DORA-Hinweise und Umsetzungshinweise veröffentlicht und damit künftige Prüfungsmaßstäbe konkretisiert.
• Ab 2026 werden Berichte IKT-Governance direkt mit Kapital- und Risikoeinschätzungen verknüpfen - digitale Resilienz wird damit ein echtes Board-Thema.

Sie sollten damit rechnen, dass Prüfer tief einsteigen in wer worauf zugreifen kann, wie Zugriffe vergeben werden, wie sie kontrolliert werden - und ob Sie das sofort belegen können.

Warum Access Governance auf DORAs kritischem Pfad liegt

DORA ist kein "Access-Control-Gesetz" dem Namen nach. Wer aber in die Artikel, RTS und Leitlinien schaut, findet Identity- und Access Governance an allen Ecken.

Was DORA konkret für Zugriffe verlangt

Zentrale Punkte mit unmittelbarem Einfluss auf Access Reviews:

• Schutz & Prävention (Artikel 9). Artikel 9 verlangt eine kontinuierliche Überwachung und Steuerung der IKT, um Korruption, Verlust oder unbefugten Datenzugriff zu verhindern - Sie brauchen also jederzeit ein aktuelles Bild Ihrer Zugriffe.
• Protokollierung und Audit Trails. Die DORA-RTS fordern eine Protokollierung von logischen und physischen Zugriffen im IKT-Risikomanagement-Rahmen - inklusive privilegierter Zugriffe.
• Grundsätze für Zugriffsrechte. Zugriffsrechte müssen sich an Need-to-know, Least Privilege und Funktionstrennung (Segregation of Duties, SoD) gemäß Artikel 9(4)(c) und RTS orientieren. Spontane Privilegienaufblähung bedeutet Nicht-Compliance
• IKT-Drittdienstleister-Register. Führen Sie ein vollständiges Register aller Verträge mit IKT-Drittdienstleistern, einschließlich Informationen zu Zugriffen und Sicherheit

Wenn Ihre Reviews nur einige interne Systeme abdecken und SaaS, Datenplattformen und Provider-Konsolen ausklammern, verfehlen Sie sowohl den Geist als auch inzwischen den Buchstaben von DORA.

Live-Prüfungen brauchen Live-Daten

Die Botschaft der Aufseher ist eindeutig: Sie erwarten laufende Aufsicht, nicht starre Jahresberichte.

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

Übertragen auf Identity: Wenn Sie nicht auf Zuruf beantworten können "Welche privilegierten Identitäten haben über welche Pfade Zugriff und wann wurden diese zuletzt überprüft?", haben Sie ein Aufsichtsrisiko.

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

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

Aufseher werden sich nicht mit Richtlinienordnern zufriedengeben - sie setzen sich mit Ihrem CISO, IT- und Compliance-Verantwortlichen zusammen und wollen Access Governance in Aktion sehen.

Die Fragen, die auf Sie zukommen

Die meisten Institute müssen mit Fragen rechnen wie:

• Abdeckung:
  • "Zeigen Sie uns Ihr vollständiges Inventar der Systeme im DORA-Geltungsbereich - inklusive SaaS, Cloud und zentralen IKT-Dienstleistern."
  • "Welche Systeme werden zentral gesteuert? Welche benötigen manuelle Administration?"
• Zugriffssituation:
  • "Für diese zentrale Plattform: Ziehen Sie eine Echtzeitliste aller privilegierten Accounts - inklusive Service- und Maschinenidentitäten."
  • "Zeigen Sie, wann diese Rechte zuletzt überprüft wurden, von wem und was sich geändert hat."
• Lifecycle-Kontrolle:
  • "Für einen zufällig gewählten Joiner und Leaver: Zeigen Sie den vollständigen Access Lifecycle mit Zeitstempeln und Freigabeentscheidungen."
• Drittrisiko:
  • "Aus Ihrem IKT-Drittdienstleister-Register: Wer kann Provider-Konsolen administrieren und wie werden diese Rechte überprüft?"
• Integrität der Nachweise:
  • "Wo liegen Logs zu Access Reviews und Provisionierung? 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 Evidenz, keine ad-hoc erzeugten Reports.

Manuell + SSO vs. kontinuierliche Access Governance

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

DORA wird diese Lücke 2026 schonungslos offenlegen.

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

Lassen Sie uns deutlich werden.

"Wir haben SSO, also sind wir durch"

SSO-Lösungen wie Okta oder Entra ID lösen Authentifizierung. Identity Governance liefern sie nicht:

• Sie automatisieren Zugriffe typischerweise nur für SCIM-fähige oder SSO-angebundene Apps - oft nur rund 20 % Ihres Stacks. Daten von Iden zeigen, dass die meisten Mid-Market-Unternehmen genau diesen kleineren Teil automatisieren und den Rest manuell bereitstellen.
• SSO steuert Gruppen/Rollen, aber DORA verlangt Entitlement-Level-Rechte. Aufseher werden in Kanäle, Repositories, Projekte hineinzoomen - genau dort, wo SCIM und SSO unscharf werden.

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

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

Jährliche Tabellenzertifizierungen scheitern aus drei Kernursachen an DORA:

1. Unvollständig. Long-Tail-SaaS, Fachanwendungen und Admin-Konsolen werden oft gar nicht überprüft.
2. Nicht verifizierbar. CSVs und E-Mails lassen sich leicht ändern, gehen verloren oder werden nie mit dem realen Zugriff abgeglichen. Es gibt keinen belastbaren Nachweis, dass Reviews mit aktuellen Daten gearbeitet haben.
3. Nicht kontinuierlich. DORA erwartet Echtzeit-Monitoring und schnelle Entzüge, nicht jährliche Rituale.

Sobald Aufseher Live-Evidenz aus dem System of Record verlangen, werden Tabellen obsolet.

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

Das ist gefährliches Wunschdenken.

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

Kontinuierliche Access Governance - insbesondere für SaaS, Cloud und Dritte - lässt sich nicht in letzter Minute aufbauen. Sie braucht Struktur statt Hauruck.

Wie "DORA-ready" Access Governance tatsächlich aussieht

Vergessen wir Buzzwords. Hier ist ein praxisnahes Zielbild - für DORA ebenso wie für schlanke IT-Teams.

1. Universelle Abdeckung aller in-scope Systeme

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

• Kernsysteme für Banking/Trading/Payments
• Interne Fachanwendungen
• Kritische SaaS-Tools (CRM, E-Signatur, Cloud-Speicher, Collaboration)
• Cloud und Infrastruktur (IaaS, Kubernetes, DB-Konsolen, Security-Tools)

DORA interessiert nicht, ob eine App kein SCIM oder keine API bietet. Sie müssen SSO-"Coverage-Gaps" schließen.

2. Lifecycle-Automatisierung mit policy-gesteuertem Zugriff

Manuelle Joiner/Mover/Leaver-Prozesse hinken zwangsläufig hinterher. DORA-fähiger Zugriff setzt auf policy-gesteuerte Automatisierung:

• Basiszugriffe ("Birthright Access") nach Rolle, Abteilung, Standort und Risikoprofil
• Zeitlich begrenzte Privilegien mit automatischem Entzug
• Event-gesteuerte Deprovisionierung bei HR-/Verzeichnis-Triggern
• Einheitliche, automatisierte Behandlung von externen Kräften, Service Accounts und AI Agents

So belegen Sie Least Privilege und Durchsetzung - nicht nur Häkchen auf einer Liste.

3. Automatisierte, risikobasierte Access Reviews

Sie brauchen nicht weniger, sondern intelligentere Reviews:

• Risikobasierte Auswahl: Hochrisikosysteme werden häufiger geprüft
• Kontextsensitive Informationen: wann/wer/wie Zugriff erhalten hat; letzte Nutzung
• Standardaktionen (z. B. automatische Entziehung inaktiver Zugriffe, begründete Ausnahmen)
• Unveränderbare Zertifizierungsnachweise

Kunden von Iden berichten, dass sie durch automatisierte Evidenz rund 120 Stunden pro Quartal bei Reviews einsparen - Zeit, die von Excel-Pflege in echtes Risikomanagement verlagert wird.

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

Ihre Logs müssen sowohl SOC als auch Aufsehern dienen. Grundanforderungen:

• Zeitstempel und Auslöser für alle Zugriffsereignisse
• Verknüpfung der Logs mit allen Identitäten (inklusive Agents, Service Accounts)
• Kryptographisch geschützte/unveränderbare Speicherung
• Möglichkeit, den Zugriffsstand zu jedem beliebigen Zeitpunkt rückwirkend nachzuvollziehen

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

5. Drittrisiko entlang tatsächlicher Zugriffspfade steuern

Die IKT-Drittregeln von DORA verlangen mehr als Formulierungen im Vertrag. Konkret brauchen Sie:

• Ausgangspunkt Drittdienstleister-Register: Abbildung, wer diese Provider administrieren kann
• Anwendung von Least Privilege und SoD auf genau diese kritischen Rechte
• Nachweis, wann diese Rechte zuletzt von wem überprüft wurden

Wenn Vertrags- und Access-Daten getrennt laufen, zwingt DORA Sie, diese Lücke zu schließen.

Wie Iden DORA-taugliche Governance angeht

Das hier ist kein Pitch, sondern Erfahrungsbericht aus der Praxis. Iden wurde speziell für Organisationen entwickelt, die über SSO und manuelle Provisionierung hinausgewachsen sind, ohne den Ballast klassischer IGA-Suiten. Genau das ist heute der DORA-Sweet-Spot: 50-2.000 Mitarbeitende, hoher SaaS-Anteil, schlanke IT/Security.

Der Ansatz von Iden:

• Volle Abdeckung ohne SCIM-Steuer. Universelle Konnektoren unterstützen SCIM, APIs und sogar schwer integrierbare oder "geschlossene" SaaS-Anwendungen - genau den Long Tail, in dem besonders sensible Daten liegen.
• Feingranulare Steuerung. Governance bis auf Kanal-, Repo- und Projektebene - nicht nur "App ja/nein". Genau dort entstehen reale SoD-Konflikte.
• Kontinuierliche Governance und automatisierte Reviews. Agentische (AI-gesteuerte, autonome) Workflows führen Reviews durch, sammeln Evidenz und flaggen Auffälligkeiten - ohne Ticket-Stau.
• Unveränderbare Audit Trails. Banktaugliche Verschlüsselung und Logs, die Sie einem Prüfer direkt zeigen können - nicht nur einen SharePoint-Ordner namens "DORA 2026".
• Zero SCIM Tax. Vollautomatisierung ohne erzwungene Enterprise-Pläne Ihrer SaaS-Anbieter - so geraten DORA-Anforderungen und Kostendisziplin nicht in Konflikt.

Sie brauchen Iden nicht, um compliant 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 Ihren Prüfungen 2026

Wenn Sie im DORA-Fokus stehen und noch mit Tabellen arbeiten, bietet sich folgende Reihenfolge an:

1. Ihre tatsächliche Access-Fläche kartieren

• Definieren Sie die DORA-regulierten Einheiten in Ihrem Geschäft
• Erstellen/aktualisieren Sie ein Applikationsinventar mit Risikoklassifizierung (kritisch, unterstützend, geringes Risiko)
• Beziehen Sie SaaS und IKT-Drittsysteme ein

2. Identitäten und Hochrisiko-Zugriffe klassifizieren

• Inventarisieren Sie Identitäten: Mitarbeitende, Dienstleister, Drittoperatoren, AI Agents, Service Accounts
• Markieren Sie Rollen mit sensiblen Befugnissen (Geldbewegung, Handel, Konfiguration, Security)
• Legen Sie fest, welche Rollen unter DORA einer kontinuierlichen Überwachung unterliegen sollen

3. Gap-Analyse Ihrer aktuellen Access Reviews

Für jedes Schlüsselsystem:

• Wie werden Accounts bereitgestellt (SSO, lokale Admins, Tickets)?
• Wie und wie häufig finden Reviews statt?
• Wo liegen Nachweise? Lassen sie sich mit dem tatsächlichen Zustand verknüpfen?
• Wie werden Abgänge und Rollenwechsel umgesetzt?

So identifizieren Sie Ihre Hotspots im DORA-Exposure.

4. Kontinuierliche Governance in einem Kernbereich pilotieren

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

• Binden Sie alle relevanten Apps an (SCIM oder nicht)
• Automatisieren Sie Joiner/Mover/Leaver-Flows
• Führen Sie einen automatisierten, policy-gesteuerten Access Review mit Evidenz durch
• Dokumentieren Sie Aufwand, geschlossene Lücken und Erkenntnisse

Das zeigt Machbarkeit und liefert eine greifbare Story für Aufseher.

5. Skalieren und optimieren

Wenn der Pilot läuft:

• Weiten Sie die Abdeckung App für App aus, mit Fokus auf kritische Systeme und Provider
• Standardisieren Sie Policies (z. B. maximale Dauer erhöhter Privilegien, Inaktivitäts-Schwellen)
• Verknüpfen Sie Governance-Evidenz mit Ihrem DORA-Programm (Risikoregister, Incident Response, BCP)

Kontinuierliche Access Governance wird so zu Ihrem operativen Normalzustand - nicht zu einer Last-Minute-Aktion.

Häufig gestellte Fragen

Verlangt DORA ausdrücklich Access Reviews?

DORA schreibt das Wort "User Access Review" nicht direkt, verlangt aber:

• Rechte müssen dem Least-Privilege-Prinzip und SoD folgen.
• IKT-Rahmen müssen unbefugte Zugriffe überwachen und steuern sowie zugehörige Ereignisse protokollieren.

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

Bekommen kleinere Institute unter DORA Erleichterungen?

DORA erlaubt vereinfachte Rahmenwerke für kleinere oder weniger komplexe Unternehmen, verzichtet aber nicht auf Anforderungen zu Zugriffskontrolle, Logging oder Lieferantenrisiko.

Wenn Sie im Geltungsbereich sind, müssen Sie privilegierte Zugriffe trotzdem steuern, überwachen und überprüfen - auch wenn das in einer schlankeren Form geschieht.

Wie spielt DORA mit NIS2 und MaRisk zusammen?

DORA richtet sich an den Finanzsektor, NIS2 an wesentliche/wichtige Akteure in der Gesamtwirtschaft. In der Praxis gilt:

• Die meisten Finanzinstitute fallen unter beide Regime
• Nationale Aufseher (z. B. BaFin) betonen, dass DORA MaRisk ergänzt, nicht ersetzt

Gestalten Sie einmal für kontinuierliche Evidenz und universelle Abdeckung - und mappen Sie dies dann auf DORA, NIS2, SOC 2, ISO 27001 etc. Vermeiden Sie Parallelprogramme.

Was ist mit SaaS-Apps ohne SCIM oder APIs?

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

• Kollaborationsplattformen mit sensiblen Freigaben
• Kritische, aber spezialisierte SaaS-Lösungen (Fraud-Tools, Regtech, Treasury)
• Third-Party-Konsolen, über die Sie Provider administrieren

Erfahrungen von Iden: Die meisten Blindspots bei Identitäten und der meiste manuelle Aufwand liegen genau hier. DORA-Compliance erfordert, dieses "fehlende 80 %"-Segment in den Griff zu bekommen.

Braucht man eine IGA-Plattform, um DORA zu erfüllen?

Streng genommen nein - DORA schreibt keine IGA-Anschaffung vor. Sie müssen aber liefern:

• Vollständige, aktuelle Zugriffsinventare
• Durchgesetztes Least Privilege und SoD
• Kontinuierliches Monitoring und unveränderbare Log-Evidenz
• Verlässliche, schnelle Antworten gegenüber Aufsehern

Man kann das aus SSO, ITSM und Tabellen zusammenbauen - aber die meisten schlanken Teams stoßen unter dem DORA-Druck bis 2026 an Grenzen. Eine leichte, vollständige Governance-Schicht (Iden oder Ähnliches) ist die realistische Antwort.

Fazit. DORA führt kein völlig neues Konzept ein. Die Verordnung beendet lediglich die Illusion, dass teilweise, manuell organisierte Access Governance ausreicht. Wenn Sie 2026 keine Live-, DORA-getriebene Prüfung mit Echtzeit-Abdeckung aller Systeme und Provider bestehen könnten, ist jetzt der Zeitpunkt, diese Lücken zu schließen - nicht Q4 2026.