DORA-Compliance: Die Checkliste für Finanzunternehmen 2026

Inhalt

• Was ist DORA-Compliance?
• Was in der Verordnung steht: Artikel und Standards
• Wer unter DORA fällt
• Was sich 2026 geändert hat
• Die DORA-Checkliste, Säule für Säule
• Wo Finanzunternehmen tatsächlich scheitern: Identitäten und der SaaS-Bestand
• DORA-Anforderungen und die Identitäts- und SaaS-Ebene
• DORA, NIS2 und ISO 27001
• 90-Tage-Priorisierung
• Wie Corma bei DORA-Compliance hilft
• FAQ

Die meisten DORA-Programme wurden vor Januar 2025 unter Zeitdruck aufgebaut. Sie haben Richtlinien hervorgebracht, ein Informationsregister und eine Freigabe durch das Leitungsorgan. Was sie fast nie hervorgebracht haben, ist ein zutreffendes Bild der Software, die im Unternehmen tatsächlich läuft.

Genau diese Lücke ist jetzt das Problem. Nach Angaben von PwC gilt DORA für mehr als 22.000 Finanzunternehmen und IKT-Dienstleister in der EU, und 2026 ist das Jahr, in dem die Aufsicht vom Einsammeln von Dokumenten zur Prüfung übergeht, ob diese Dokumente der Realität entsprechen. Ein Register mit 40 Anbietern, während die Finanzabteilung 90 bezahlt, ist kein Dokumentationsthema. Es ist ein Prüfungsbefund.

Diese Checkliste deckt die fünf DORA-Säulen mit ihren Artikeln und technischen Standards ab und geht dann weiter als die üblichen Listen: sie isoliert die Anforderungen an Identitätsverwaltung, Zugriffskontrolle und SaaS-Transparenz, an denen mittelständische Finanzunternehmen regelmässig scheitern, und benennt klar, welche davon eine SaaS-Management- und IAM-Plattform abdecken kann und welche nicht.

Was ist DORA-Compliance?

DORA-Compliance ist der nachweisbare Zustand, in dem ein Finanzunternehmen in der EU alle Anforderungen der DORA-Verordnung (Digital Operational Resilience Act), Verordnung (EU) 2022/2554, erfüllt: IKT-Risikomanagement, Meldung von Vorfällen, Resilienztests, Management des Drittparteienrisikos und Informationsaustausch.

Die Verordnung gilt seit dem 17. Januar 2025. Da es sich um eine Verordnung und nicht um eine Richtlinie handelt, wurde sie unmittelbar wirksam, ohne Umsetzung in deutsches Recht. Zuständige Aufsichtsbehörde in Deutschland ist die BaFin, auf europäischer Ebene wirken EBA, ESMA und EIOPA zusammen.

Compliance wird durch Nachweise belegt, nicht durch Absicht. Jeder Punkt der folgenden Checkliste sollte einem Dokument, einem Protokoll oder einem Export entsprechen, den Sie der Aufsicht vorlegen können.

Was in der Verordnung steht: Artikel und Standards

Die DORA-Verordnung umfasst 64 Artikel. Das operative Detail steckt in den darunter verabschiedeten technischen Standards, und dort findet die eigentliche Umsetzungsarbeit statt.

• Delegierte Verordnung (EU) 2024/1774: Instrumente, Methoden, Prozesse und Richtlinien des IKT-Risikomanagements sowie der vereinfachte Rahmen. Dieser Text enthält die Anforderungen an Identitätsverwaltung und Zugriffskontrolle.
• Delegierte Verordnungen (EU) 2024/1772 und (EU) 2025/301: Klassifizierung von Vorfällen, Inhalt und Fristen der Erstmeldung.
• Durchführungsverordnung (EU) 2025/302: Vorlagen für die Meldung von Vorfällen.
• Durchführungsverordnung (EU) 2024/2956: Standardvorlagen für das Informationsregister.
• Delegierte Verordnungen (EU) 2024/1773 und (EU) 2025/532: Richtlinie zu IKT-Drittdienstleistern und Weitervergabe.
• Delegierte Verordnung (EU) 2025/1190: bedrohungsgeleitete Penetrationstests, anwendbar seit dem 8. Juli 2025.
• Delegierte Verordnung (EU) 2024/1502: Kriterien für die Einstufung eines IKT-Drittdienstleisters als kritisch.

Aufbau der Verordnung zum Mitnehmen: Artikel 5 bis 15 regeln das IKT-Risikomanagement, Artikel 17 bis 23 die Vorfälle, Artikel 24 bis 27 die Tests, Artikel 28 bis 44 das Drittparteienrisiko und Artikel 45 den Informationsaustausch.

Wer unter DORA fällt

DORA erfasst 20 Kategorien von Finanzunternehmen in der EU sowie deren IKT-Drittdienstleister. Der Anwendungsbereich ist breiter als "Banken und Versicherer", und die Ausnahmen sind enger, als die meisten Teams annehmen.

Zwei Punkte, die regelmässig übersehen werden:

• Der vereinfachte Rahmen nach Artikel 16 ist wirklich schmal. Er steht Unternehmen offen, die die Kleinstunternehmenskriterien erfüllen (weniger als 10 Beschäftigte und Umsatz oder Bilanzsumme unter 2 Millionen Euro), sowie einer kleinen Gruppe weiterer Unternehmen. Ein Zahlungsinstitut mit 120 Beschäftigten qualifiziert sich nicht.
• Die Verhältnismässigkeit nach Artikel 4 reduziert die Tiefe des Rahmens, nicht die Liste der Pflichten. Ein kleineres Unternehmen darf leichtere Kontrollen umsetzen. Es darf das Informationsregister und die Meldung von Vorfällen nicht auslassen.

Wer Software an Finanzunternehmen verkauft, wird von DORA ebenfalls erfasst. Ein SaaS-Anbieter, der eine kritische oder wichtige Funktion trägt, ist ein IKT-Drittdienstleister mit vertraglichen Pflichten, Auditrechten und Meldepflichten, und bei Einstufung als kritisch auch mit direkter EU-Aufsicht.

Was sich 2026 geändert hat

Der Rechtstext hat sich nicht geändert. Die Haltung der Aufsicht schon.

• Die Informationsregister wurden eingesammelt und gegengeprüft. Die Aufsicht hat inzwischen einen sektorweiten Blick darauf, wer von welchem Anbieter abhängt, wodurch ein unvollständiges Register leicht auffällt.
• Der TLPT-Standard ist in Kraft. Die Delegierte Verordnung (EU) 2025/1190 gilt seit Juli 2025, und die erste Welle von Meldungen zu bedrohungsgeleiteten Penetrationstests trifft 2026 ein.
• Die Fristen für die Vertragsanpassung sind verstrichen. Die Klauseln nach Artikel 30, die 2025 noch "in Bearbeitung" waren, werden jetzt unterschrieben erwartet.
• Die Frage hat sich verschoben. 2025 fragte die Aufsicht, ob Sie einen Rahmen haben. 2026 fragt sie, ob er wirkt, und verlangt die Nachweiskette dafür.

Deshalb genügt eine Checkliste, die nur auf Dokumenten beruht, nicht mehr. Entscheidend ist jetzt, ob die Dokumente beschreiben, was die Systeme tatsächlich tun.

Die DORA-Checkliste, Säule für Säule

Säule 1: IKT-Risikomanagement und Governance (Artikel 5 bis 15)

• Das Leitungsorgan hat den IKT-Risikomanagementrahmen formal genehmigt und trägt nach Artikel 5 weiterhin die Verantwortung dafür
• Eine IKT-Risikomanagementfunktion existiert mit angemessener Unabhängigkeit vom IKT-Betrieb
• Ein vollständiges Inventar der IKT-Assets und ihrer Abhängigkeiten besteht nach Artikel 8 und wird gepflegt, statt jährlich neu aufgebaut
• Geschäftsfunktionen sind klassifiziert, mit ausdrücklicher Benennung der kritischen oder wichtigen Funktionen
• Richtlinien zur Identitätsverwaltung und Zugriffskontrolle liegen in der Form vor, die die Delegierte Verordnung (EU) 2024/1774 verlangt
• Richtlinien zu Protokollierung, Verschlüsselung, Netzwerksicherheit, Änderungsmanagement und Personalsicherheit sind dokumentiert
• Der Rahmen wurde in den letzten 12 Monaten mindestens einmal überprüft, und die Überprüfung ist protokolliert

Säule 2: Management und Meldung von Vorfällen (Artikel 17 bis 23)

• Ein einheitlicher Prozess umfasst Erkennung, Klassifizierung, Eskalation und Ursachenanalyse
• Die Klassifizierung nach den Kriterien der Delegierten Verordnung (EU) 2024/1772 ist dokumentiert und wird nicht mitten in der Krise improvisiert
• Die Meldefristen sind geprobt: Erstmeldung, Zwischenmeldung, dann Abschlussmeldung in den Vorlagen der Durchführungsverordnung (EU) 2025/302
• Der Meldeweg zur BaFin ist getestet, mit namentlich benannten Vertretungen
• Ein Vorfallregister existiert, einschliesslich der Vorfälle, die geprüft und als nicht schwerwiegend eingestuft wurden

Säule 3: Testen der digitalen operationalen Resilienz (Artikel 24 bis 27)

• Ein risikobasiertes Testprogramm läuft mindestens jährlich, mit Schwachstellenbewertungen, Szenariotests und gegebenenfalls Quellcodeprüfung
• Befunde fliessen in ein nachverfolgtes Behebungs-Backlog mit Verantwortlichen und Terminen
• Unternehmen im Anwendungsbereich der bedrohungsgeleiteten Penetrationstests haben den Umfang nach der Delegierten Verordnung (EU) 2025/1190 festgelegt und ihre Behörde informiert
• Die Tester erfüllen die Unabhängigkeits- und Kompetenzanforderungen des Standards

Säule 4: Management des IKT-Drittparteienrisikos (Artikel 28 bis 44)

• Eine dokumentierte Strategie zum IKT-Drittparteienrisiko deckt Auswahl, Onboarding, Überwachung und Ausstieg ab
• Das Informationsregister wird in der amtlichen Vorlage der Durchführungsverordnung (EU) 2024/2956 geführt und der zuständigen Behörde jährlich sowie auf Anfrage bereitgestellt
• Verträge für kritische oder wichtige Funktionen enthalten die verpflichtenden Klauseln nach Artikel 30: Audit- und Zugangsrechte, Sicherheitsanforderungen, Grenzen der Weitervergabe, Kündigungsrechte
• Das Konzentrationsrisiko ist bewertet, auch für den Fall, dass mehrere scheinbar unabhängige Anbieter auf derselben Cloud aufsetzen
• Ausstiegspläne liegen für kritische oder wichtige Funktionen vor und wurden getestet, nicht nur geschrieben

Säule 5: Informations- und Erkenntnisaustausch (Artikel 45)

• Die Entscheidung über die Teilnahme an einem Verfahren zum Austausch von Bedrohungsinformationen ist dokumentiert, in beide Richtungen
• Bei Teilnahme respektiert das Verfahren Vertraulichkeit und die Vorgaben der DSGVO
• Eingehende Bedrohungsinformationen fliessen in den IKT-Risikoprozess und nicht in ein ungelesenes Postfach

Wo Finanzunternehmen tatsächlich scheitern: Identitäten und der SaaS-Bestand

Alles oberhalb dieser Linie findet sich in einem Dutzend anderer Artikel. Dieser Abschnitt behandelt das, worauf Prüfungsbefunde wirklich zulaufen.

Warum ein unvollständiges Informationsregister mit Schatten-IT beginnt

Artikel 28 verlangt ein Register aller vertraglichen Vereinbarungen über IKT-Dienstleistungen. Artikel 8 verlangt ein Inventar der IKT-Assets und ihrer Abhängigkeiten. Beide setzen voraus, dass Sie wissen, was läuft.

In der Praxis wird das Register aus Beschaffungsunterlagen und dem Finanzsystem zusammengesetzt. Diese Methode erfasst alles, was über eine Bestellung gekauft wurde, und verliert alles andere: das Analysetool, das ein Team über eine Firmenkreditkarte gestartet hat, den KI-Assistenten, den jemand per OAuth-Freigabe an das CRM angebunden hat, das Filesharing-Konto aus einer Übernahme. Das ist SaaS-Wildwuchs, und unter DORA hört er auf, ein Kostenthema zu sein, und wird zu einem regulatorischen.

Das Fehlerbild ist präzise. Ihr Register ist vollständig und korrekt für die Anbieter, die Sie kennen. Die Frage der Aufsicht betrifft die, die Sie nicht kennen. Eine kontinuierliche SaaS-Erkennung ist der einzige Weg, das ehrlich zu beantworten, denn eine punktuelle Prüfung ist eine Woche nach Abschluss bereits veraltet.

Was DORA bei Identitäts- und Zugriffsverwaltung wirklich verlangt

Das ist die Anforderung, die die meisten Checklisten auf eine Zeile eindampfen, obwohl sie deutlich präskriptiver ist.

Die Delegierte Verordnung (EU) 2024/1774 verpflichtet Finanzunternehmen, Richtlinien und Verfahren zur Identitätsverwaltung zu entwickeln, zu dokumentieren und umzusetzen, die die eindeutige Identifizierung und Authentifizierung jeder Person und jedes Systems sicherstellen, das auf ihre Informationen zugreift, damit Zugriffsrechte korrekt zugewiesen werden. Sie verlangt, dass Aufzeichnungen aller Identitätszuweisungen nach einer Umstrukturierung oder nach dem Ende eines Vertragsverhältnisses aufbewahrt werden. Und sie hält fest, dass Unternehmen automatisierte Lösungen für den Identitäts-Lebenszyklusprozess einsetzen sollten, wo dies machbar und angemessen ist.

Lesen Sie den letzten Punkt noch einmal. Der Standard erlaubt die Automatisierung der Identitäts-Governance nicht nur. Er erwartet sie dort, wo sie vernünftigerweise verfügbar ist. Für ein mittelständisches Unternehmen mit 80 bis 200 SaaS-Anwendungen und zwei IT-Mitarbeitenden ist eine vierteljährliche Tabelle schwer als angemessene Methode zu verteidigen.

Verwaiste Konten und Lücken beim Offboarding

Ein verwaistes Konto ist ein aktives Konto einer Person, die das Unternehmen verlassen oder die Rolle gewechselt hat. Unter DORA berührt es drei Anforderungen gleichzeitig: das Prinzip der geringsten Rechte nach Artikel 9, die Genauigkeit des Inventars nach Artikel 8 und die nachweisbare Kontrolle der Zugriffsrechte nach dem RTS.

Solche Konten sammeln sich aus einem banalen Grund an. Das Offboarding funktioniert im Identity Provider meist zuverlässig, und überall dort unzuverlässig, wo der Identity Provider nicht hinreicht: Tools ohne SCIM-Unterstützung, Anwendungen mit lokalen Logins, Administrationskonsolen, die vor der SSO-Einführung angelegt wurden. Automatisierte Deprovisionierung über den gesamten Bestand, nicht nur über den föderierten Teil, schliesst diese Lücke.

Ein Audit-Trail, den Sie auf Anfrage nicht liefern können

Artikel 10 und der RTS zum IKT-Risikomanagement verlangen eine Protokollierung, die zur Erkennung und Rekonstruktion von Ereignissen ausreicht. Im Kontext einer Zugriffsüberprüfung heisst das: zeigen können, wer eine konkrete Berechtigung erteilt hat, wann, auf welche Genehmigung hin, und wann sie entzogen wurde.

Die meisten Teams können das rekonstruieren. Wenige können es an einem Nachmittag exportieren. Der Unterschied zählt, denn eine Kontrolle, für die Sie den Nachweis nicht zügig erbringen, wird in der Praxis wie eine Kontrolle behandelt, die nicht gewirkt hat. Automatisierte Zugriffsüberprüfungen mit Export pro Kampagne machen aus einer Rekonstruktionsübung einen Bericht.

DORA-Anforderungen und die Identitäts- und SaaS-Ebene

Anbieterinhalte zu DORA legen häufig nahe, dass eine einzige Plattform alle fünf Säulen abdeckt. Keine tut das. Hier die ehrliche Variante, die für Budgetentscheidungen auch die nützlichere ist.

Das Muster ist eindeutig. Eine konvergente SaaS-Management- und IAM-Plattform leistet echte Arbeit bei Säule 1 und Säule 4, liefert Nachweise für Säule 2 und leistet bei Säule 3 und Säule 5 gar nichts. Wer etwas anderes behauptet, verkauft, statt zu beraten.

DORA, NIS2 und ISO 27001

Finanzunternehmen stehen selten nur DORA gegenüber. Viele fallen zusätzlich unter NIS2, und viele halten oder streben eine Zertifizierung nach ISO/IEC 27001 an. Da DORA das sektorspezifische Regime ist, hat es für Finanzunternehmen dort Vorrang, wo sich beide überschneiden.

Die praktische Konsequenz: die Kontrollebene ist weitgehend gemeinsam. Asset-Inventar, Identitätsverwaltung, Zugriffsüberprüfungen und Protokollierung erfüllen Artikel 9 der DORA-Verordnung, die entsprechenden NIS2-Anforderungen und die Anhang-A-Kontrollen 5.15 bis 5.18 sowie 8.2 bis 8.5 der ISO/IEC 27001:2022. Bauen Sie die Kontrolle einmal auf und legen Sie den Nachweis dann in drei verschiedenen Hüllen vor. Unser Leitfaden zu ISO 27001 und IAM beschreibt den Zertifizierungsweg im Detail, und unser Fahrplan für Benutzer-Zugriffsüberprüfungen beschreibt den Prüfzyklus selbst.

90-Tage-Priorisierung

Wenn Ihr DORA-Programm dokumentiert, aber nachweisarm ist, zählt die Reihenfolge mehr als der Aufwand.

Wie Corma bei DORA-Compliance hilft

Corma ist eine europäische Plattform, die SaaS-Management und Identitäts- und Zugriffsverwaltung in einem Produkt vereint, also genau in der Kombination, die die DORA-Kontrollebene verlangt. Erkennung und Zugriffs-Governance liegen im selben System, sodass das Asset-Inventar für Artikel 8 und das Register für Artikel 28 aus denselben lebenden Daten entstehen, statt von Hand abgeglichen zu werden.

Was das für ein DORA-Programm bedeutet:

• Kontinuierliche SaaS-Erkennung bringt die Anwendungen zum Vorschein, die in Ihrem Informationsregister fehlen, einschliesslich der Tools ohne IT-Beschaffung
• Automatisierte Prozesse für Eintritt, Wechsel und Austritt liefern die Automatisierung des Identitäts-Lebenszyklus, die der RTS erwartet
• Geplante Kampagnen zur Zugriffsüberprüfung mit Freigabe durch den Anwendungseigentümer und exportierbarem Nachweis pro Zyklus
• Ein vollständiger Audit-Trail über Vergabe, Genehmigung und Entzug von Zugriffen, exportbereit
• Transparenz über Verträge und Verlängerungen, damit die Anpassung nach Artikel 30 nicht erst am Verlängerungstermin auffällt
• Europäisches, DSGVO-konformes Hosting und die Zertifizierung nach ISO/IEC 27001:2022, was zählt, weil unter DORA Ihr eigener Dienstleister Teil Ihres Drittparteienrisikos ist

Der letzte Punkt verdient Nachdruck. Ein in den USA gehostetes Werkzeug zur Lösung eines DORA-Problems hinzuzufügen, bringt eine Übermittlungsfrage und einen weiteren zu verteidigenden Eintrag im Informationsregister mit sich. Corma wird in Europa entwickelt und gehostet und wurde im Gartner® Magic Quadrant™ 2025 für SaaS Management Platforms genannt.

Corma für Sicherheitsteams zeigt, wie Compliance und Zugriffs-Governance zusammenwirken. Für ein Beispiel aus einer regulierten Branche sehen Sie, wie Satelia die Identitäts-Governance im Gesundheitswesen steuert, und unsere Sicherheitsseite dokumentiert Hosting, Zertifizierungen und Subdienstleister, die Ihre eigene Anbieterprüfung abfragen wird.

Sie möchten wissen, was in Ihrem Informationsregister fehlt? Demo anfragen, und wir führen eine Erkennung über Ihren Bestand durch.

FAQ

Welche fünf Säulen hat die DORA-Compliance?

Die fünf Säulen sind IKT-Risikomanagement und Governance (Artikel 5 bis 15), Management, Klassifizierung und Meldung IKT-bezogener Vorfälle (Artikel 17 bis 23), Testen der digitalen operationalen Resilienz (Artikel 24 bis 27), Management des IKT-Drittparteienrisikos (Artikel 28 bis 44) sowie Informations- und Erkenntnisaustausch (Artikel 45). Die ersten vier sind verpflichtend. Der Informationsaustausch ist freiwillig, die Entscheidung sollte aber dokumentiert werden.

Ist DORA-Compliance verpflichtend?

Ja. DORA ist für betroffene Finanzunternehmen in der EU seit dem 17. Januar 2025 rechtlich verbindlich. Als EU-Verordnung gilt sie unmittelbar, ohne nationalen Umsetzungsschritt, weshalb es keine deutsche Übergangsfrist gibt.

Welche Sanktionen drohen bei Verstössen gegen DORA?

Finanzunternehmen werden von ihrer nationalen Aufsichtsbehörde sanktioniert, in Deutschland der BaFin, die Aufsichtsmassnahmen und Bussgelder verhängen, Nachbesserungen verlangen und in schweren Fällen Tätigkeiten einschränken kann. Als kritisch eingestufte IKT-Drittdienstleister unterliegen der EU-Aufsicht und können mit Zwangsgeldern von 1 Prozent ihres durchschnittlichen weltweiten Tagesumsatzes des vorangegangenen Geschäftsjahres belegt werden, täglich für bis zu sechs Monate, bis sie die Anforderungen erfüllen.

Was ist das Informationsregister nach DORA?

Das Informationsregister ist ein strukturiertes Verzeichnis aller vertraglichen Vereinbarungen, die ein Finanzunternehmen mit IKT-Drittdienstleistern geschlossen hat, geführt in den Standardvorlagen der Durchführungsverordnung (EU) 2024/2956. Es ist der zuständigen Behörde jährlich und auf Anfrage bereitzustellen. Es ist die häufigste Quelle von Prüfungsbefunden, weil es nie genauer ist als die Transparenz des Unternehmens über seinen eigenen Softwarebestand.

Verlangt DORA eine automatisierte Zugriffsverwaltung?

Nicht mit diesen Worten, aber nahe daran. Die Delegierte Verordnung (EU) 2024/1774 verlangt dokumentierte Richtlinien zur Identitätsverwaltung und Zugriffskontrolle, die Aufbewahrung der Identitätszuweisungen nach dem Austritt von Personen, und hält fest, dass Unternehmen automatisierte Lösungen für den Identitäts-Lebenszyklus einsetzen sollten, wo dies machbar und angemessen ist. Für ein Unternehmen mit hunderten SaaS-Anwendungen ist eine manuelle Überprüfung immer schwerer als angemessen darstellbar.

Wie unterscheidet sich DORA von der DSGVO?

Beide regeln Unterschiedliches. Die DSGVO schützt personenbezogene Daten und gilt für jede Organisation, die Daten von Personen in der EU verarbeitet. DORA regelt die digitale operationale Resilienz und gilt speziell für Finanzunternehmen in der EU und ihre IKT-Dienstleister. Ein Unternehmen kann vollständig DSGVO-konform sein und bei DORA scheitern, weil DORA das Überstehen und die Wiederherstellung nach einer IKT-Störung betrifft und nicht die Rechtmässigkeit der Datenverarbeitung.

Gilt DORA für britische oder US-amerikanische Unternehmen?

Nicht unmittelbar, aber die Ausstrahlung ist häufig. DORA bindet Finanzunternehmen, die in der EU tätig sind, sowie die IKT-Dienstleister, die sie bedienen. Ein britischer oder US-amerikanischer Anbieter, der eine kritische oder wichtige Funktion eines EU-Finanzunternehmens trägt, erbt über Artikel 30 vertragliche Pflichten, Auditrechte und Meldepflichten und kann als kritischer IKT-Drittdienstleister eingestuft und direkt EU-beaufsichtigt werden.

Kann ein mittelständisches Finanzunternehmen den vereinfachten Rahmen nutzen?

In der Regel nicht. Der vereinfachte Rahmen für das IKT-Risikomanagement nach Artikel 16 richtet sich an Kleinstunternehmen, also weniger als 10 Beschäftigte und Umsatz oder Bilanzsumme unter 2 Millionen Euro, sowie an eine kleine Gruppe weiterer Unternehmen. Ein Finanzunternehmen mit 50 bis 500 Beschäftigten liegt im vollen Anwendungsbereich, und die Verhältnismässigkeit nach Artikel 4 justiert die Tiefe der Kontrollen, ohne Pflichten zu entfernen.