Was Finanzunternehmen nach DORA zur Zugangskontrolle nachweisen müssen

DORA reduziert die Zugangskontrolle nicht auf Multi-Faktor-Authentifizierung oder eine jährliche Überprüfung der Benutzer. Für Finanzunternehmen im Geltungsbereich verbindet der Rechtsrahmen den Zugriff mit dem IKT-Risikomanagement: Personen und Systeme müssen eindeutig identifizierbar sein, Konten müssen über ihren gesamten Lebenszyklus gesteuert werden, Rechte müssen den Grundsätzen „Kenntnis nur, wenn nötig“ (Need-to-know), der Nutzungsnotwendigkeit (Need-to-use) und der minimalen Berechtigung (Least Privilege) folgen, unvereinbare Rechte müssen getrennt werden, und nicht benötigte Zugriffsrechte müssen umgehend entzogen werden.

Gerade die detailliertesten Regeln stehen zum Teil nicht im Haupttext von DORA. Die Verordnung (EU) 2022/2554 schafft den Rahmen für die digitale operationale Resilienz und gilt seit dem 17. Januar 2025. Die Delegierte Verordnung (EU) 2024/1774 der Kommission präzisiert die Richtlinien für das IKT-Risikomanagement und enthält ausdrückliche Anforderungen an Identitätsmanagement und Zugangskontrolle. Wer nur eine kurze Zusammenfassung von DORA liest, übersieht deshalb die operativen Details, die Aufsichtsbehörden prüfen können.

Die praktische Antwort: Ein Finanzunternehmen sollte zeigen können, wer oder was Zugriff erhalten hat, warum er notwendig war, wer ihn genehmigt hat, welche Kontrollen ihn begrenzt haben, wann er überprüft wurde, wie schnell er geändert oder beendet wurde und welche Nachweise belegen, dass die Maßnahme jedes relevante IKT-Asset erreicht hat.

Dieser Leitfaden erläutert diese Nachweiskette. Grundlage sind EU-Rechtstexte und Unterlagen der Europäischen Aufsichtsbehörden (Stand der Prüfung: 12. September 2026). Anwendbarkeit, Verhältnismäßigkeit und aufsichtliche Erwartungen hängen weiterhin vom jeweiligen Unternehmen, seinem Sektor, seinem IKT-Risikoprofil und der zuständigen Behörde ab.

Mit den rechtlichen Ebenen beginnen

DORA ist unmittelbar geltendes EU-Recht. Die Verordnung erfasst ein breites Spektrum von Finanzunternehmen, darunter Kreditinstitute, Zahlungsinstitute, Wertpapierfirmen, Versicherungs- und Rückversicherungsunternehmen, Einrichtungen der betrieblichen Altersversorgung, Anbieter von Krypto-Dienstleistungen und mehrere weitere in Artikel 2 genannte Kategorien. Außerdem schafft sie einen Überwachungsrahmen für kritische IKT-Drittdienstleister.

Der Rahmen ist bewusst breiter angelegt als die Zugangskontrolle. Er umfasst das IKT-Risikomanagement, die Behandlung und Meldung IKT-bezogener Vorfälle, das Testen der digitalen operationalen Resilienz, das IKT-Drittparteienrisiko und den Informationsaustausch. Die Steuerung der Zugriffsrechte ist Teil dieses Systems. Ein schwacher Prozess für Eintritt, Wechsel oder Austritt ist kein isoliertes Problem der Verzeichnisverwaltung, wenn er kritische oder wichtige Funktionen gefährden, Untersuchungen behindern oder ein Unternehmen daran hindern kann, seine Verantwortlichkeiten nachzuweisen.

Die detaillierten Pflichten zur Zugangskontrolle, die für die meisten Finanzunternehmen relevant sind, stehen in der Delegierten Verordnung 2024/1774:

• Artikel 20 regelt das Identitätsmanagement;
• Artikel 21 regelt die Zugangskontrolle;
• Artikel 19 verknüpft die Personalpolitik mit Zuständigkeiten für die IKT-Sicherheit und mit der Rückgabe von IKT- und Informationsassets;
• Artikel 12 behandelt Verfahren und Systeme für die Protokollierung sowie die Aufbewahrung der Protokolle;
• weitere Bestimmungen verknüpfen die Klassifizierung von Assets, das Änderungsmanagement, die Behandlung von Vorfällen und die Geschäftsfortführung mit demselben IKT-Risikomanagementrahmen.

Die Artikel 20 und 21 stehen in Titel II. Finanzunternehmen, die unter Artikel 16 Absatz 1 DORA fallen, folgen stattdessen dem vereinfachten IKT-Risikomanagementrahmen in Titel III, einschließlich Artikel 33 zur Zugangskontrolle. Artikel 33 verlangt eine regelmäßige Überprüfung und den Entzug nicht benötigter Rechte, wiederholt aber nicht das jährliche und das sechsmonatige Intervall aus Artikel 21. Klären Sie, welches Regime für Sie gilt, bevor Sie diese Intervalle als gesetzliches Minimum übernehmen.

Was Artikel 20 für das Identitätsmanagement verlangt

Artikel 20 verlangt dokumentierte und implementierte Richtlinien und Verfahren für das Identitätsmanagement, die die eindeutige Identifizierung und Authentifizierung der natürlichen Personen und Systeme ermöglichen, die auf Informationen des Finanzunternehmens zugreifen. Er gilt nicht nur für eigene Mitarbeitende. Ausdrücklich relevant ist auch das Personal von IKT-Drittdienstleistern, das auf Informationen oder IKT-Assets zugreift.

Die Richtlinie muss jeder Person des eigenen Personals und jeder relevanten Person aus dem Personal von Drittdienstleistern eine eindeutige Identität zuweisen, die einem eindeutigen Nutzerkonto entspricht. Das Unternehmen muss Aufzeichnungen über die zugewiesenen Identitäten führen, vorbehaltlich der geltenden Aufbewahrungsvorschriften nach EU-Recht und nationalem Recht. Außerdem muss es einen Lebenszyklusprozess betreiben, der die Erstellung, Änderung, Überprüfung, Aktualisierung, vorübergehende Deaktivierung und Beendigung aller Konten umfasst.

Laut der Verordnung sollten für das Lebenszyklusmanagement von Identitäten soweit möglich und angemessen automatisierte Lösungen eingesetzt werden. Diese Formulierung ist wichtig. Sie begründet keine allgemeine Pflicht, ein bestimmtes IGA-Produkt zu kaufen. Sie macht einen dauerhaft manuellen Prozess aber schwerer zu rechtfertigen, wenn Automatisierung möglich ist, die Risiken wesentlich sind und der manuelle Prozess keine rechtzeitigen oder vollständigen Nachweise liefern kann.

Ein brauchbarer Identitätsdatensatz verknüpft deshalb mindestens:

1. die Identität der Person, des Dienstes oder des Systems;
2. die maßgebliche Quelle und den Beschäftigungs- oder Vertragsstatus;
3. die eindeutigen Konten, die dieser Identität zugeordnet sind;
4. die verantwortliche Person und den geschäftlichen Zweck nicht-menschlicher Identitäten;
5. die Rechte, Gruppen, Rollen und privilegierten Zuweisungen jedes Kontos;
6. Genehmigung, Gültigkeitsdaten und Ablaufbedingungen;
7. die Historie der Überprüfungen und Entzüge; und
8. Ausnahmen, kompensierende Kontrollen und die Risikoverantwortlichen.

Ohne diese Verknüpfungen kann ein Unternehmen ein Verzeichniskonto deaktivieren und trotzdem aktiven Zugriff in einer lokalen Anwendung, einem Cloud-Dienst, einer Datenbank, einem Notfallkonto oder dem Portal eines Dritten bestehen lassen.

Was Artikel 21 für Kontrollnachweise bedeutet

Artikel 21 verlangt eine dokumentierte und implementierte Richtlinie für die Zugangskontrolle. Die folgende Tabelle trennt den rechtlich geforderten Kontrollbereich von den Nachweisen, mit denen eine Organisation den tatsächlichen Betrieb der Kontrolle belegen kann. Die Nachweisbeispiele sind praktische Umsetzungsentscheidungen und kein zusätzlicher Gesetzestext.

Prüfintervalle sind vorgegeben

Die Delegierte Verordnung lässt nicht jedes Überprüfungsintervall offen. Artikel 21 Buchstabe e Ziffer iv verlangt, dass Zugangsrechte aktualisiert werden, wenn Änderungen notwendig sind, mindestens aber einmal jährlich bei IKT-Systemen, die keine kritischen oder wichtigen Funktionen unterstützen; bei IKT-Systemen, die solche Funktionen unterstützen, mindestens alle sechs Monate. Eine Zugriffsüberprüfung sollte die notwendigen Aktualisierungen ermitteln und ihre Umsetzung verifizieren. Eine Überprüfung, die Entscheidungen festhält, ohne sie anzuwenden, erfüllt die Aktualisierungspflicht nicht.

Diese Intervalle sind Höchstabstände und keine Aufforderung zu warten. Eine Beendigung des Beschäftigungsverhältnisses, eine Versetzung, eine Änderung des Zugriffsrisikos oder die Feststellung, dass ein Zugriff nicht mehr erforderlich ist, sollte eine ereignisbasierte Aktualisierung auslösen. Eine halbjährliche Rezertifizierung behebt nicht, dass das Konto einer ausgeschiedenen Person fünf Monate lang aktiv geblieben ist.

Eine wirksame Überprüfungskampagne sollte der prüfenden Person die Person oder das System, die aktuellen Rechte, den geschäftlichen Zweck, die verantwortliche Person, die letzte Nutzung (soweit verfügbar), den privilegierten Status, konfliktbehaftete Kombinationen und die Auswirkungen eines Entzugs zeigen. Die Entscheidung muss dann das Zielsystem erreichen, und das Unternehmen sollte das Ergebnis abgleichen. Eine Tabelle mit Einträgen „genehmigt“ ohne Nachweis der Umsetzung ist ein unvollständiger Kontrollnachweis.

Privilegierte, Notfall- und gemeinsam genutzte Zugänge brauchen eigene Wege

Privilegierter Zugang kann Konfigurationen, Sicherheitseinstellungen, Daten oder Identitäten verändern. Artikel 21 verlangt, dass privilegierter Zugang, Notfallzugang und Administratorzugang bei IKT-Systemen nach dem Grundsatz der Nutzungsnotwendigkeit oder ad hoc zugewiesen werden. Außerdem verlangt er starke Authentifizierung für privilegierten Zugang und für den Zugang zu IKT-Assets, die kritische oder wichtige Funktionen unterstützen, sowie für den Fernzugang und für öffentlich zugängliche Assets.

Das wirksamste Betriebsmodell trennt die normale Identität von der administrativen Identität, genehmigt eine Rechteerhöhung für eine festgelegte Aufgabe, begrenzt ihre Dauer, protokolliert die Nutzung und überprüft außergewöhnliche Aktivitäten. Eine dauerhafte Administratorrolle, die vergeben wird, weil jemand sie „später vielleicht braucht“, widerspricht dem Zweck von Nutzungsnotwendigkeit und minimaler Berechtigung.

Generische und gemeinsam genutzte Konten verdienen eine ähnlich genaue Prüfung. DORA sagt nicht, dass es sie nie geben darf. Verlangt wird, ihre Nutzung so weit wie möglich einzuschränken und sicherzustellen, dass die handelnden Personen identifizierbar bleiben. Eine vertretbare Ausnahme nennt die verantwortliche Person, den Zweck, die nutzenden Personen oder den Ausgabemechanismus, die Authentifizierungskontrolle, die Protokollierungsmethode, das Ablaufdatum und den Überprüfungsrhythmus. Wenn mehrere Personen dasselbe Passwort kennen und kein zuverlässiger Mechanismus eine Handlung zuordnet, fehlt die Zurechenbarkeit.

Soweit möglich und angemessen erwartet die Delegierte Verordnung außerdem ein automatisiertes Management des privilegierten Zugangs. Automatisierung sollte dauerhafte Privilegien reduzieren, Ablaufzeiten durchsetzen und Nachweise erzeugen. Sie sollte nicht einfach die Genehmigung schlecht gestalteter dauerhafter Rollen automatisieren.

Rechteentzug beim Offboarding testen

Artikel 21 verlangt den umgehenden Entzug der Zugangsrechte bei Beendigung des Beschäftigungsverhältnisses oder wenn der Zugriff nicht mehr erforderlich ist. Artikel 19 verlangt, dass Mitarbeitende bei Beendigung des Beschäftigungsverhältnisses die IKT-Assets und materiellen Informationsassets zurückgeben, die Eigentum des Unternehmens sind. Artikel 20 verlangt, dass das Lebenszyklusmanagement die Beendigung von Konten umfasst.

Diese Bestimmungen machen das Offboarding zu einem guten Test der gesamten Identitätsarchitektur. Die Organisation sollte den maßgeblichen Zeitpunkt der Beendigung kennen, jedes verbundene Konto ermitteln, aktive Zugriffe entziehen, privilegierte Rechte und Notfallrechte behandeln, Geräte zurückholen und den Endzustand nachweisen. Für externe Mitarbeitende und das Personal von Dritten gilt dieselbe Disziplin, wenn ihr vertraglicher Bedarf endet.

„Umgehend“ hängt vom Kontext ab; die Verordnung nennt keine allgemeingültige Zahl von Minuten für jedes Ausscheiden. Das Unternehmen sollte risikobasierte Service-Level festlegen. Bei einem unfreiwilligen Ausscheiden mit privilegiertem Zugang zur Produktion kann ein koordinierter Entzug genau zum Zeitpunkt des Trennungsgesprächs erforderlich sein. Ein geplanter Ruhestand ohne privilegierten Zugang kann einen terminierten Workflow rechtfertigen. Begründung und Ergebnis müssen dokumentiert werden.

Systemidentitäten in die Berechtigungssteuerung einbeziehen

Artikel 20 bezieht sich auf natürliche Personen und Systeme, die auf Informationen zugreifen. Servicekonten, Workloads, Integrationen, Software-Roboter, API-Clients und Automatisierungsidentitäten können deshalb unter das Thema Identitätsmanagement fallen. Sie überdauern oft Projekte, verwenden nicht-interaktive Anmeldedaten und sammeln weitreichende Berechtigungen an.

Erfassen Sie für jede nicht-menschliche Identität eine verantwortliche Person, eine technisch betreuende Person, Zweck, Umgebungen, Berechtigungen, Authentifizierungsmethode, Speicherort der Anmeldedaten, Rotationsregel, zuletzt beobachtete Nutzung, Abhängigkeiten und Bedingung für die Außerbetriebnahme. Die Verantwortung sollte neu zugewiesen werden, wenn Mitarbeitende ausscheiden. Wer eine ausgeschiedene Person deaktiviert, aber ein Skript, ein Token oder eine Integration in ihrer informellen Verantwortung belässt, schafft eine verwaiste Kontrolle.

Der Prozess der Zugriffsüberprüfung sollte zwischen einem Benutzerkonto und einer Dienstidentität unterscheiden. Fragt man eine Führungskraft, ob ein kryptisch benanntes Servicekonto „noch benötigt“ wird, entsteht kaum ein verlässlicher Nachweis. Die prüfende Person braucht Kontext zu Zweck, Abhängigkeiten und Nutzung.

Der Zugang Dritter bleibt das Risiko des Finanzunternehmens

DORA widmet dem IKT-Drittparteienrisiko viel Aufmerksamkeit. Vertragliche Kontrollen ersetzen keine interne Steuerung der Zugriffsrechte. Das Finanzunternehmen braucht Transparenz über die externen Personen und Systeme, die seine IKT-Assets erreichen können, soweit relevant einschließlich Unterauftragnehmern.

Der Zugang von Dritten sollte mindestens einen Sponsor, eine Vertrags- oder Leistungsreferenz, einen genehmigten Umfang, ein Start- und ein Ablaufdatum, eine Authentifizierungskontrolle und eine für die Überprüfung verantwortliche Person haben. Fernzugang und privilegierter Zugang sollten den oben beschriebenen strengeren Kontrollen folgen. Wenn ein Vertrag, ein Auftrag oder ein individueller Einsatz endet, muss das Entzugsereignis die betroffenen Systeme erreichen.

Das Unternehmen sollte Zugriffsnachweise außerdem mit seinem Informationsregister zu den vertraglichen Vereinbarungen verknüpfen können, wo dies hilft, die Abhängigkeit von IKT-Dienstleistungen zu erkennen. Das Material der Europäischen Bankenaufsichtsbehörde zum DORA-Informationsregister bestätigt, dass DORA seit dem 17. Januar 2025 gilt und dass Finanzunternehmen im Geltungsbereich umfassende Informationen über vertragliche Vereinbarungen mit IKT-Drittdienstleistern vorhalten müssen. Das Register und das Identitätsinventar beantworten unterschiedliche Fragen, aber jedes kann Lücken im jeweils anderen aufdecken.

Nachweispaket für die Aufsicht erstellen

Eine Richtlinie belegt, wie eine Kontrolle gestaltet ist. Aufsichtsbehörden und Prüfende brauchen zusätzlich Nachweise, dass die Kontrolle im Betrieb funktioniert. Ein brauchbares Nachweispaket zur Zugangskontrolle lässt sich entlang von fünf Fragen gliedern.

1. Was soll geschehen?

Bewahren Sie die genehmigten Richtlinien für Identitätsmanagement, Zugangskontrolle, Authentifizierung, privilegierten Zugang, Funktionstrennung, physischen Zugang und Aufbewahrung auf. Zeigen Sie Geltungsbereich, Verantwortliche, Gültigkeitsdaten, Überprüfungshistorie und die Verbindung zum IKT-Risiko und zur Asset-Klassifizierung.

2. Warum wurde der Zugriff gewährt?

Bewahren Sie für eine Stichprobe von Zugriffen mit hohem Risiko die Anfrage, den geschäftlichen Zweck, System und Berechtigung, die genehmigende Person, die Richtlinienprüfung, das SoD-Ergebnis, den Gültigkeitszeitraum und das Ergebnis der Umsetzung auf. Beim Notfallzugang sollte erkennbar sein, warum der Notfallweg gerechtfertigt war.

3. Was hat sich geändert?

Bewahren Sie die maßgeblichen Eintritts-, Wechsel- und Austrittsereignisse und die daraus folgenden Kontoaktionen auf. Der Eintrag sollte die Zustände „beantragt“, „genehmigt“, „versucht“, „abgeschlossen“ und „abgeglichen“ unterscheiden. Eine fehlgeschlagene Umsetzung sollte eine Ausnahme mit klarer Verantwortung auslösen, statt in einem technischen Protokoll zu verschwinden.

4. Wurden die Zugriffsrechte überprüft?

Bewahren Sie Kampagnenumfang, Identität der prüfenden Person, angezeigten Kontext, Entscheidung, Zeitstempel, Eskalation, Entzugsmaßnahme und Erledigungsnachweis auf. Sie sollten den halbjährlichen Prüfumfang für Systeme, die kritische oder wichtige Funktionen unterstützen, und den jährlichen Prüfumfang für andere IKT-Systeme nachweisen können.

5. Hat die Kontrolle funktioniert?

Nutzen Sie Abgleiche, Stichproben in Zielsystemen, Kennzahlen zu überfälligen Maßnahmen, die Erkennung verwaister Konten, Berichte über ruhende privilegierte Konten und Tests von Austrittsszenarien. Weisen Sie nach, dass fehlgeschlagene oder verspätete Maßnahmen korrigiert wurden.

90-Tage-Plan für eine bessere Zugangskontrolle

Die folgende Abfolge erzeugt brauchbare Nachweise, ohne so zu tun, als ließe sich Governance mit einer einmaligen Rezertifizierung erledigen.

Tage 1 bis 30: festlegen und ermitteln. Bestätigen Sie die anwendbaren DORA-Bestimmungen. Ermitteln Sie kritische oder wichtige Funktionen und die sie unterstützenden IKT-Assets. Erfassen Sie maßgebliche Identitätsquellen, Speicherorte privilegierter Konten und Zugangsdaten, Zugänge von Dritten und nicht-menschliche Identitäten. Lassen Sie Verantwortliche und risikobasierte Service-Level für den Entzug genehmigen. Dokumentieren Sie bekannte Abdeckungslücken.

Tage 31 bis 60: steuern und anbinden. Führen Sie einen einheitlichen Nachweis für Anfragen und Genehmigungen ein. Binden Sie die Systeme mit dem höchsten Risiko an Lebenszyklusereignisse an. Setzen Sie zeitlich befristeten privilegierten Zugang um, wo dies möglich ist. Definieren Sie SoD-Regeln für wesentliche Konflikte. Konfigurieren Sie Prüfumfänge und Eskalation. Stellen Sie sicher, dass Identitäten nach dem Austritt keine aktiven Sitzungen oder alternativen lokalen Konten behalten.

Tage 61 bis 90: nachweisen und verbessern. Führen Sie einen durchgängigen Austrittstest, eine Stichprobe zum privilegierten Zugang und eine Überprüfungskampagne für einen kritischen Prüfumfang durch. Gleichen Sie die Ergebnisse in den Zielsystemen ab. Messen Sie verspätete Entzüge, fehlgeschlagene Umsetzungen, verwaiste Konten und offene Überprüfungsentscheidungen. Legen Sie der für das IKT-Risiko verantwortlichen Person die Ausnahmen und die Termine für deren Behebung vor.

Häufige Fehler, die Scheinsicherheit erzeugen

„Mit MFA ist das Konto konform.“ Starke Authentifizierung schützt, wie sich eine Identität anmeldet. Sie beweist nicht, dass die Identität das Konto oder die Rechte haben sollte.

„Im Verzeichnis ist das Konto deaktiviert, also ist der Zugriff weg.“ Lokale Konten, Anwendungssitzungen, Tokens, Dienstidentitäten und physischer Zugang können bestehen bleiben.

„Die Führungskraft hat die Tabelle genehmigt.“ Eine Genehmigung ohne genauen Kontext zu den Berechtigungen und ohne abgeschlossene Umsetzung ist ein schwacher Nachweis.

„Für seine Benutzerkonten ist der Anbieter zuständig.“ Der Anbieter mag die Konten verwalten, aber das Finanzunternehmen braucht trotzdem eine Steuerung des Zugriffs auf seine Assets und Informationen.

„Jährliche Überprüfung heißt jährliches Aufräumen.“ Ereignisgesteuerte Änderungen und das Sechsmonatsintervall für Systeme, die kritische oder wichtige Funktionen unterstützen, machen diese Auslegung riskant.

„DORA verlangt dieses Produkt.“ DORA und die Delegierte Verordnung beschreiben Ergebnisse, Richtlinien und Kontrollen. Technologie sollte ausgewählt werden, weil sie diese Ergebnisse für Größe und Risiko des Unternehmens zuverlässig liefert.

Was die Geschäftsleitung fragen sollte

1. Welche IKT-Systeme unterstützen unsere kritischen oder wichtigen Funktionen, und können wir ihre halbjährlichen Zugriffsüberprüfungen nachweisen?
2. Lässt sich jede privilegierte Handlung einer identifizierbaren Person und einem genehmigten Bedarf zuordnen?
3. Wie viele aktive Konten haben keine aktuell zugeordnete Person, keinen Systemzweck oder keine verantwortliche Person?
4. Welche Zeit messen wir von einem maßgeblichen Beendigungsereignis bis zum verifizierten Entzug in jedem kritischen Zielsystem?
5. Welche wichtigen Anwendungen liegen noch außerhalb des automatisierten Lebenszyklusmanagements von Identitäten, und warum ist das noch verhältnismäßig?
6. Können wir eine Zugriffsentscheidung von der Anfrage über Genehmigung, Richtlinienprüfung, Umsetzung und Überprüfung bis zum Entzug rekonstruieren?
7. Welche Identitäten von Dritten und welche nicht-menschlichen Identitäten blieben aktiv, wenn ihr aktueller Sponsor heute ausschiede?

Mit klaren Antworten wird die Zugangskontrolle von einer Sammlung von Einstellungen zu einer Fähigkeit der operationalen Resilienz. Diesen Maßstab legt DORA an: dokumentierte Governance, verhältnismäßige Kontrolle und Nachweise, dass die Kontrolle in der gesamten IKT-Landschaft wirkt.

Vor der Wahl einer Plattform den Produktumfang prüfen

Vergleichen Sie die Nachweisabdeckung von easyIGA mit den Einträgen, die Ihre Kontrolle erfordert. easyIGA bewahrt erfasste Genehmigungsstufen auf und erkennt Zugriffe, die an anderer Stelle gewährt wurden; fehlende historische Einträge bleiben ausdrücklich als fehlend gekennzeichnet. Prüfungen auf Richtlinienkonflikte zum Entscheidungszeitpunkt sind verfügbar, das Erstellen und Simulieren von Regeln in easyIGA ist geplant. Die mindestens 14 midPoint-Einführungen unseres Teams liefern die Projekterfahrung, um diese Prozesse abzugrenzen und zu betreiben.

Weiter mit der Umsetzung

Die Umsetzungsdetails zur Entfernung von Konten finden Sie im Playbook für das Offboarding von Mitarbeitenden. Die übergeordnete Kategorie und die Auswahlkriterien beschreibt unser IGA-Leitfaden.

Quellen und Prüfvermerk

Produktumfang und redaktionelle Formulierungen aktualisiert am 24. September 2026. Die unten genannten Datumsangaben beziehen sich weiterhin auf die ursprüngliche Prüfung der Quellen.

Die Prüfung aller Quellen und der Bildlizenz erfolgte am 12. September 2026.

1. Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor, EUR-Lex
2. Delegierte Verordnung (EU) 2024/1774 der Kommission, EUR-Lex
3. Delegierte Verordnung (EU) 2024/1774, konsolidierte Fassung, EUR-Lex
4. DORA register-of-information preparation, European Banking Authority
5. Harmonised DORA incident reporting applies from 17 January 2025, European Banking Authority
6. Foto von Jakub Żerdzicki, Unsplash, frei nutzbar gemäß der Unsplash License

Dieser Artikel bietet operative Orientierung und eine Lesart der zitierten EU-Texte. Er ist keine Rechtsberatung. Klären Sie Anwendbarkeit und nationale aufsichtliche Erwartungen mit qualifizierten Rechts- und Compliance-Fachleuten.