Der Ausgangspunkt von DORA ist eine schlichte Beobachtung: Das Finanzwesen ist heute vollständig von Informations- und Kommunikationstechnik abhängig. Zahlungsverkehr, Wertpapierhandel, Kreditvergabe, Versicherungsabwicklung – nichts davon funktioniert ohne funktionierende IT-Systeme, Netzwerke und zunehmend ausgelagerte Dienste. Fällt ein zentrales System aus oder wird es kompromittiert, sind nicht nur einzelne Unternehmen betroffen, sondern potenziell die Stabilität des gesamten Finanzsystems. Genau dieses Risiko adressiert DORA, indem es die digitale operationale Resilienz zu einer verbindlichen aufsichtsrechtlichen Anforderung macht.
Vor DORA war die Regulierung des IKT-Risikos im europäischen Finanzsektor fragmentiert: Verschiedene Aufsichtsbehörden, unterschiedliche nationale Regeln und uneinheitliche Leitlinien führten zu einem Flickenteppich, der weder für Unternehmen noch für die Aufsicht überzeugend funktionierte. DORA harmonisiert diese Anforderungen europaweit und schafft ein einheitliches Regelwerk, das für alle erfassten Finanzunternehmen dieselben Grundprinzipien vorgibt – unabhängig von Größe, Sektor und Mitgliedstaat.
Rechtlich handelt es sich bei DORA um eine EU-Verordnung – konkret die Verordnung (EU) 2022/2554. Das ist ein wichtiger Unterschied zu einer Richtlinie: Eine Verordnung gilt in den Mitgliedstaaten unmittelbar und muss nicht erst in nationales Recht umgesetzt werden. Damit entfällt der übliche Spielraum bei der nationalen Ausgestaltung, den man von Richtlinien kennt. In Deutschland flankieren begleitende Anpassungsgesetze und die bestehende Aufsichtspraxis die Verordnung, das Kernregelwerk ist jedoch europaweit dasselbe.
Ergänzt wird die Verordnung durch eine Reihe technischer Standards – sogenannte technische Regulierungs- und Durchführungsstandards (RTS und ITS) –, welche die Anforderungen konkretisieren. Diese Standards präzisieren beispielsweise, wie ein Risikomanagement-Rahmen auszusehen hat oder wie Vorfälle zu klassifizieren sind. Für die Praxis bedeutet das: DORA ist kein statischer Text, sondern ein lebendes Regelwerk, dessen Detailanforderungen sich über die technischen Standards weiter ausdifferenzieren. Den jeweils aktuellen Stand dieser Standards sollte man deshalb gezielt prüfen, statt sich auf einen einmal erreichten Wissensstand zu verlassen.
Inhaltlich lässt sich DORA gut über fünf thematische Bereiche erschließen, die häufig als Säulen beschrieben werden. Erstens das IKT-Risikomanagement, das ein umfassendes internes Rahmenwerk zum Umgang mit IT-Risiken verlangt. Zweitens die Behandlung, Klassifizierung und Meldung IKT-bezogener Vorfälle, die einen strukturierten Umgang mit Störungen und Angriffen vorschreibt. Drittens das Testen der digitalen operationalen Resilienz, das von regelmäßigen Prüfungen bis hin zu fortgeschrittenen, bedrohungsgeleiteten Tests reicht.
Viertens das Management des IKT-Drittparteienrisikos, das den Umgang mit ausgelagerten IT-Diensten und Anbietern regelt – ein für den Mittelstand besonders relevanter Bereich. Und fünftens der Informationsaustausch über Cyberbedrohungen, der die freiwillige Zusammenarbeit der Finanzunternehmen bei der Abwehr von Angriffen fördern soll. Diese fünf Bereiche greifen ineinander: Ein gutes Risikomanagement ist die Grundlage, das Vorfallmanagement die Reaktion, das Testen die Überprüfung, das Drittparteienmanagement die Absicherung der Lieferkette und der Informationsaustausch die kollektive Verteidigung.
Der persönliche Anwendungsbereich von DORA ist bewusst weit gefasst. Er soll möglichst alle Teile des Finanzsystems abdecken, die auf IKT angewiesen sind – und das ist heute praktisch der gesamte Sektor. Die Verordnung zählt eine lange Liste von Finanzunternehmen auf, die den Anforderungen direkt unterliegen. Wichtig ist dabei zu verstehen, dass der Begriff des Finanzunternehmens hier deutlich breiter ist als das umgangssprachliche Bild von „Banken und Versicherungen“.
Zu den unmittelbar erfassten Adressaten zählen unter anderem Kreditinstitute (Banken), Versicherungs- und Rückversicherungsunternehmen, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Handelsplätze, zentrale Gegenparteien und Zentralverwahrer, Verwalter alternativer Investmentfonds und Verwaltungsgesellschaften sowie weitere Kategorien von Anbietern von Finanzdienstleistungen. Auch vergleichsweise junge Bereiche – etwa Anbieter im Kontext von Krypto-Werten – werden je nach Ausgestaltung erfasst. Die Liste ist lang und im Detail differenziert; entscheidend ist die konkrete regulatorische Einordnung des eigenen Unternehmens.
DORA sieht dabei ein Grundprinzip vor, das man aus dem Aufsichtsrecht kennt: Die Anforderungen sollen verhältnismäßig angewendet werden. Größe, Risikoprofil sowie Art, Umfang und Komplexität der Tätigkeiten eines Unternehmens spielen eine Rolle dabei, wie tief die Anforderungen im Einzelfall auszugestalten sind. Für kleine und wenig komplexe Finanzunternehmen kann es erleichterte Regelungen geben, während für große, systemrelevante Institute der volle Umfang gilt. Das Prinzip der Verhältnismäßigkeit befreit jedoch nicht grundsätzlich von den Kernpflichten – es moduliert lediglich deren Ausgestaltung.
Eine Besonderheit von DORA ist, dass die Verordnung nicht bei den Finanzunternehmen selbst haltmacht, sondern auch deren IKT-Drittdienstleister in den Blick nimmt. Damit sind Anbieter gemeint, die dem Finanzsektor IT-Dienste bereitstellen – von Rechenzentren und Cloud-Diensten über Software bis zu spezialisierten Datenverarbeitungsdiensten. DORA sieht vor, dass besonders bedeutende Anbieter als kritische IKT-Drittdienstleister eingestuft werden können und dann einer eigenen europäischen Überwachung unterliegen.
Für die Praxis ist diese Konstruktion doppelt wichtig. Zum einen bedeutet sie, dass ein IT-Dienstleister, der viele oder besonders wichtige Finanzunternehmen bedient, selbst unmittelbar ins Visier der Aufsicht geraten kann. Zum anderen – und das betrifft den Mittelstand weit häufiger – wirken die Anforderungen mittelbar über die Vertragsketten: Finanzunternehmen müssen ihre Dienstleister vertraglich und organisatorisch so einbinden, dass die DORA-Vorgaben eingehalten werden. Dadurch werden auch Zulieferer, die formal nicht selbst reguliert sind, faktisch in die Pflicht genommen.
Gerade für mittelständische IT-Dienstleister ist die entscheidende Frage selten „Bin ich ein Finanzunternehmen?“, sondern „Beliefere ich Finanzunternehmen mit IKT-Diensten – und was verlangt DORA dann von mir über meine Kunden?“. Ein Softwarehaus, ein Hosting-Anbieter oder ein spezialisierter Dienstleister für ein Kreditinstitut wird zwar nicht automatisch selbst zum Adressaten der Verordnung, spürt DORA aber sehr deutlich in Form von veränderten Vertragsanforderungen, Prüf- und Auskunftsrechten und Erwartungen an die eigene Sicherheits- und Resilienzorganisation.
Diese Unterscheidung zwischen unmittelbarer und mittelbarer Betroffenheit ist die vielleicht wichtigste Erkenntnis dieses Kapitels. Wer die eigene Rolle nicht sauber bestimmt, läuft Gefahr, entweder Anforderungen zu übersehen, die über Kundenverträge auf ihn zukommen, oder umgekehrt einen Aufwand zu treiben, der für die eigene Rolle gar nicht erforderlich ist. Eine belastbare Einordnung im Einzelfall – idealerweise mit fachlicher und rechtlicher Begleitung – steht deshalb am Anfang jeder sinnvollen DORA-Befassung.
Im Kern verlangt DORA, dass ein betroffenes Unternehmen den Umgang mit IKT-Risiken nicht dem Zufall oder einzelnen Fachleuten überlässt, sondern in einem strukturierten Rahmenwerk organisiert. Dieses Rahmenwerk beschreibt, welche Strategien, Leitlinien, Verfahren und Werkzeuge das Unternehmen einsetzt, um seine informationstechnischen Systeme zu schützen und funktionsfähig zu halten. Es ist damit weit mehr als eine Sammlung technischer Sicherheitsmaßnahmen – es ist ein Managementsystem mit klarer Verantwortungszuweisung.
Ein prägendes Element von DORA ist die ausdrückliche Verankerung der Verantwortung beim Leitungsorgan. Die Geschäftsleitung darf das IKT-Risiko nicht als reines Fachthema an die IT-Abteilung delegieren, sondern trägt die Gesamtverantwortung: Sie muss den Rahmen genehmigen, die notwendigen Ressourcen bereitstellen, sich regelmäßig mit dem Thema befassen und über hinreichende Kenntnisse verfügen. Damit rückt digitale Resilienz von der technischen auf die strategische Ebene und wird zur Führungsaufgabe.
Diese Verlagerung hat praktische Folgen. Sie bedeutet, dass sich die Leitung nachweisbar mit IKT-Risiken auseinandersetzen, entsprechende Berichte erhalten und Entscheidungen dokumentieren muss. In der Aufsichtslogik ist das kein Formalismus, sondern Ausdruck der Überzeugung, dass Resilienz nur dann gelingt, wenn sie von oben getragen und mit den nötigen Mitteln ausgestattet wird. Für Unternehmen heißt das, Governance-Strukturen zu schaffen oder anzupassen, in denen das Thema regelmäßig auf der Agenda der Leitung steht.
Inhaltlich orientiert sich das Rahmenwerk an einem Regelkreis, der aus dem klassischen Sicherheitsmanagement vertraut ist. Am Anfang steht das Identifizieren: Ein Unternehmen muss wissen, welche IKT-Systeme, Prozesse und Informationswerte es hat und welche davon für den Geschäftsbetrieb besonders wichtig sind. Ohne diesen Überblick lässt sich kein Risiko sinnvoll bewerten. Darauf folgt das Schützen und Verhindern durch geeignete Sicherheitsmaßnahmen sowie das Erkennen von Anomalien und Vorfällen durch Überwachung.
Ergänzt wird dieser Kreis durch die Fähigkeit zu reagieren und wiederherzustellen: Notfall- und Wiederanlaufpläne, Datensicherungen und Wiederherstellungsverfahren sorgen dafür, dass der Betrieb nach einer Störung möglichst schnell und geordnet wieder aufgenommen werden kann. Über allem steht das Lernen und Weiterentwickeln – die Erkenntnisse aus Vorfällen und Tests müssen in eine kontinuierliche Verbesserung des Rahmenwerks einfließen. Dieser zyklische Charakter ist wichtig: DORA fordert keinen einmaligen Zustand, sondern einen dauerhaften, sich verbessernden Prozess.
Ein durchgängiges Motiv von DORA ist die Nachweisbarkeit. Was nicht dokumentiert ist, gilt im aufsichtsrechtlichen Sinn faktisch als nicht vorhanden. Das Rahmenwerk, die Risikoanalysen, die getroffenen Maßnahmen, die durchgeführten Tests und die Behandlung von Vorfällen müssen so dokumentiert sein, dass sowohl die eigene Leitung als auch die Aufsicht die Angemessenheit nachvollziehen können. Diese Dokumentationspflicht ist kein Selbstzweck, sondern Grundlage für Überprüfung, Verbesserung und Aufsicht.
Für die praktische Umsetzung bedeutet das, bestehende Dokumente – etwa vorhandene Sicherheitsrichtlinien, Notfallkonzepte oder Auslagerungsunterlagen – auf die DORA-Anforderungen hin zu prüfen und gezielt zu ergänzen, statt bei null zu beginnen. Viele Unternehmen verfügen bereits über Bausteine eines Informationssicherheits-Managements; die Aufgabe besteht dann darin, diese in das von DORA geforderte, kohärente Rahmenwerk zu überführen und die Lücken sauber zu schließen.
Wenn das Risikomanagement das Fundament ist, dann ist das Vorfallmanagement die Antwort auf den Ernstfall. DORA geht realistisch davon aus, dass sich Störungen und Angriffe nie vollständig verhindern lassen. Entscheidend ist deshalb, dass ein Unternehmen Vorfälle systematisch erkennt, einordnet, behandelt und – bei hinreichender Schwere – den zuständigen Behörden meldet. Damit wird aus einem chaotischen Ausnahmezustand ein geordneter Prozess mit klaren Rollen und Abläufen.
Zunächst verlangt DORA, dass Unternehmen einen Prozess für die Behandlung IKT-bezogener Vorfälle etablieren: Vorfälle müssen erfasst, dokumentiert, analysiert und behoben werden, und die daraus gewonnenen Erkenntnisse fließen in die Verbesserung zurück. Ein zentraler Baustein ist die Klassifizierung nach einheitlichen Kriterien – etwa nach der Zahl der betroffenen Kunden, der Dauer, der geografischen Ausbreitung, den Auswirkungen auf Daten und dem wirtschaftlichen Schaden. Anhand dieser Kriterien wird bestimmt, ob ein Vorfall als schwerwiegend gilt.
Diese Klassifizierung ist mehr als eine Formalie: Sie entscheidet darüber, welche Pflichten ausgelöst werden. Ein nachvollziehbares, konsistentes Klassifizierungsschema ist deshalb Voraussetzung dafür, dass ein Unternehmen im Ernstfall schnell und richtig reagieren kann. Werkzeuge zur Erfassung, Korrelation und Auswertung von Ereignissen können diesen Prozess unterstützen, indem sie Informationen zusammenführen und die Einordnung erleichtern – die Bewertung und Verantwortung bleiben jedoch beim Unternehmen und seinen Fachleuten.
Erreicht ein Vorfall die Schwelle zur Schwere, greift die Meldepflicht. DORA sieht vor, dass schwerwiegende IKT-Vorfälle den zuständigen Behörden gemeldet werden – typischerweise in mehreren Schritten: eine erste Meldung, ein Zwischenbericht und ein Abschlussbericht. Ziel ist, dass die Aufsicht ein Lagebild erhält, betroffene Stellen frühzeitig informiert werden und aus Vorfällen gelernt werden kann. Diese gestufte Meldung verlangt vom Unternehmen, die relevanten Informationen schnell verfügbar zu haben.
Da die konkreten Fristen, Schwellenwerte und Meldeformate über technische Standards ausgestaltet werden und sich weiterentwickeln können, verzichtet dieser Beitrag bewusst auf die Nennung exakter Zeitangaben – der jeweils aktuelle Stand ist verbindlich zu prüfen. Praktisch bedeutet die Meldepflicht, dass ein Unternehmen im Vorfeld klären muss, wer im Ernstfall welche Informationen zusammenträgt, wer meldet und über welchen Kanal. Eine vorbereitete Meldekette und passende Vorlagen verhindern, dass unter Zeitdruck wertvolle Zeit verloren geht.
Die dritte Säule betrifft das Testen der digitalen operationalen Resilienz. DORA verlangt, dass Unternehmen ihre Systeme und Prozesse regelmäßig auf Widerstandsfähigkeit prüfen – von grundlegenden Verfahren wie Schwachstellenanalysen und Prüfungen bis hin zu anspruchsvolleren Testformaten. Der Gedanke dahinter ist einfach: Nur was geprüft wird, ist verlässlich; ungetestete Notfallpläne und Sicherheitsmaßnahmen bieten trügerische Sicherheit.
Für bestimmte, besonders bedeutende Unternehmen sieht DORA zusätzlich fortgeschrittene Tests in Form des Threat-Led Penetration Testing (TLPT) vor – also bedrohungsgeleitete Penetrationstests, die reale Angriffsszenarien nachstellen, um die Abwehr unter möglichst realistischen Bedingungen zu prüfen. Solche Tests sind aufwendig und werden nach anerkannten Rahmenwerken durchgeführt. Werkzeuge und teilautomatisierte Verfahren können das Testen unterstützen, indem sie wiederkehrende Prüfungen effizienter machen; die anspruchsvollen, bedrohungsgeleiteten Tests bleiben jedoch stark von spezialisierter Expertise geprägt. Ob und in welchem Umfang TLPT für ein Unternehmen einschlägig ist, hängt von dessen Einstufung ab und ist konkret zu klären.
Die Auslagerung von IT-Diensten bringt Effizienz und Spezialisierung, verlagert aber Risiken in die Lieferkette. Fällt ein zentraler Cloud- oder Rechenzentrumsdienst aus, kann das viele Finanzunternehmen gleichzeitig treffen – ein Konzentrationsrisiko, das die Aufsicht besonders beschäftigt. DORA reagiert darauf, indem es Finanzunternehmen verpflichtet, ihre IKT-Dienstleister systematisch zu erfassen, zu bewerten und vertraglich so einzubinden, dass die Resilienz der gesamten Kette gewahrt bleibt.
Ein zentrales Instrument ist das Informationsregister: Finanzunternehmen müssen sämtliche vertraglichen Vereinbarungen über die Nutzung von IKT-Diensten strukturiert dokumentieren. Dieses Register schafft Transparenz darüber, welche Dienste von welchen Anbietern bezogen werden, welche Funktionen sie unterstützen und wie kritisch sie für den Geschäftsbetrieb sind. Es ist zugleich Steuerungsinstrument für das Unternehmen und Auskunftsgrundlage für die Aufsicht.
Für die Praxis bedeutet das eine erhebliche Sorgfaltsaufgabe: Wer nicht weiß, welche Dienstleister er in welcher Tiefe nutzt, kann sein Drittparteienrisiko nicht steuern. Gerade in gewachsenen IT-Landschaften ist die vollständige Erfassung aller relevanten Verträge und Unterauftragsverhältnisse anspruchsvoll. Das Register zwingt Unternehmen dazu, ihre Lieferkette bewusst zu durchdringen – ein Aufwand, der über die reine Dokumentation hinaus zu einem besseren Verständnis der eigenen Abhängigkeiten führt.
DORA stellt konkrete Erwartungen an die Verträge mit IKT-Dienstleistern, insbesondere wenn diese kritische oder wichtige Funktionen unterstützen. Dazu gehören etwa klare Regelungen zu Leistungsbeschreibung, Sicherheitsanforderungen, Zugriffs-, Prüf- und Auskunftsrechten, Kündigungs- und Ausstiegsszenarien sowie zum Umgang mit Unterauftragnehmern. Ziel ist, dass das Finanzunternehmen die Kontrolle über ausgelagerte Funktionen behält und im Krisenfall handlungsfähig bleibt.
Genau an dieser Stelle entsteht die mittelbare Betroffenheit vieler mittelständischer Dienstleister: Weil Finanzunternehmen ihre Verträge DORA-konform gestalten müssen, geben sie die entsprechenden Anforderungen an ihre Anbieter weiter. Ein IT-Dienstleister sieht sich dann mit Prüf- und Auskunftsrechten, Sicherheits- und Meldeanforderungen sowie Nachweispflichten konfrontiert, die vertraglich eingefordert werden. Wer diese Erwartungen versteht und proaktiv bedient, kann sie als Wettbewerbsvorteil nutzen; wer sie ignoriert, riskiert, für Finanzkunden als Partner auszufallen.
DORA fügt sich in ein mehrstufiges Aufsichtsgefüge ein. Auf europäischer Ebene wirken die Europäischen Aufsichtsbehörden (ESAs) zusammen: die Europäische Bankenaufsichtsbehörde (EBA), die Europäische Aufsichtsbehörde für das Versicherungswesen (EIOPA) und die Europäische Wertpapier- und Marktaufsichtsbehörde (ESMA). Sie erarbeiten die technischen Standards, sorgen für eine einheitliche Auslegung und übernehmen im Fall der als kritisch eingestuften IKT-Drittdienstleister eine eigene Überwachungsrolle.
Auf nationaler Ebene bleibt in Deutschland die BaFin die zentrale Aufsichtsbehörde für die beaufsichtigten Finanzunternehmen; die Deutsche Bundesbank wirkt in ihrem Zuständigkeitsbereich mit. Für Unternehmen bedeutet dieses Zusammenspiel, dass Anforderungen und Auslegungen aus mehreren Quellen stammen können und sich weiterentwickeln. Es empfiehlt sich daher, die Veröffentlichungen der zuständigen Behörden gezielt zu verfolgen und den aktuellen Stand regelmäßig zu prüfen, statt sich auf einen einmaligen Kenntnisstand zu verlassen.
Wer sich mit DORA befasst, stellt schnell fest, dass viele der geforderten Prinzipien vertraut klingen: Risikomanagement, Vorfallbehandlung, Zugriffskontrollen, Notfallplanung. Das ist kein Zufall, denn DORA teilt viele Grundgedanken mit etablierten Ansätzen der Informationssicherheit. Der Schlüssel liegt darin, die unterschiedlichen Ebenen und Zwecke zu verstehen, statt die Regelwerke als konkurrierend zu begreifen.
Die NIS2-Richtlinie ist das breit angelegte europäische Regelwerk zur Cybersicherheit für viele Sektoren kritischer und wichtiger Einrichtungen. DORA verhält sich dazu als sektorspezifische Spezialregelung für den Finanzsektor. Nach dem Grundsatz, dass die speziellere Regelung vorgeht, ist DORA für die von ihm erfassten Finanzunternehmen im Bereich der digitalen Resilienz das maßgebliche Regelwerk, während NIS2 die breitere Grundlage für andere Sektoren bildet. Ein wesentlicher Unterschied liegt zudem in der Rechtsform: DORA ist eine unmittelbar geltende Verordnung, NIS2 eine Richtlinie, die nationaler Umsetzung bedarf.
Für Unternehmen mit gemischtem Profil kann die Abgrenzung im Detail anspruchsvoll sein – etwa wenn ein Konzern sowohl Finanz- als auch andere Aktivitäten umfasst. Hier ist genau zu prüfen, welches Regelwerk für welche Einheit und welche Tätigkeit greift. Diese Einordnung sollte fachlich und rechtlich begleitet erfolgen, weil sie über den anzuwendenden Pflichtenkatalog entscheidet.
Die Norm ISO/IEC 27001 beschreibt ein international anerkanntes Managementsystem für Informationssicherheit (ISMS). Sie ist kein Gesetz, sondern ein freiwilliger, zertifizierbarer Standard. Zwischen ISO 27001 und DORA gibt es erhebliche inhaltliche Überschneidungen: Beide verlangen ein systematisches, risikobasiertes Management der Informationssicherheit mit klaren Verantwortlichkeiten, Maßnahmen und kontinuierlicher Verbesserung. Ein bestehendes, gelebtes ISMS ist deshalb eine sehr gute Ausgangsbasis für die DORA-Umsetzung.
Entscheidend ist jedoch die Erkenntnis, dass ein ISO-27001-Zertifikat DORA nicht automatisch erfüllt. DORA enthält spezifische aufsichtsrechtliche Anforderungen – etwa zur Vorfallmeldung an Behörden, zum Drittparteienregister oder zu bestimmten Testformaten –, die über den generischen Standard hinausgehen. Umgekehrt deckt ein ISMS viele der von DORA geforderten Maßnahmen bereits ab. Die sinnvolle Strategie lautet daher, vorhandene ISO-Strukturen als Fundament zu nutzen und gezielt um die DORA-spezifischen Elemente zu ergänzen.
Der BSI IT-Grundschutz des deutschen Bundesamts für Sicherheit in der Informationstechnik ist eine bewährte, sehr detaillierte Methodik zum Aufbau von Informationssicherheit, die im deutschen Raum weit verbreitet ist. Auch hier gilt: Der IT-Grundschutz liefert einen umfangreichen Katalog konkreter Maßnahmen und eine strukturierte Vorgehensweise, die viele DORA-Anforderungen inhaltlich unterstützen kann. Er ist jedoch eine Methodik und kein Ersatz für die spezifischen aufsichtsrechtlichen Pflichten von DORA.
In der Praxis lassen sich diese Ansätze gut kombinieren: DORA gibt das aufsichtsrechtliche „Was“ und „Warum“ vor, während Standards wie ISO 27001 oder der BSI IT-Grundschutz beim „Wie“ helfen und konkrete Maßnahmen und Strukturen liefern. Wer bereits nach einem dieser Standards arbeitet, sollte diesen Vorsprung nutzen und in einer Gap-Analyse ermitteln, welche zusätzlichen, DORA-spezifischen Anforderungen noch zu erfüllen sind – statt parallele Strukturen aufzubauen.
DORA wird selten „auf der grünen Wiese“ umgesetzt. Fast immer gibt es bereits eine IT-Organisation, Sicherheitsrichtlinien und gewachsene Auslagerungsbeziehungen. Ein tragfähiges Vorgehen respektiert diese Ausgangslage, verschafft sich zunächst einen ehrlichen Überblick über den Ist-Zustand und leitet daraus die notwendigen Schritte ab. Überstürzte, rein dokumentengetriebene Projekte, die an der gelebten Praxis vorbeigehen, sind eine häufige Ursache für teure Fehlläufe.
Weil DORA die Verantwortung ausdrücklich beim Leitungsorgan verankert, beginnt die Umsetzung bei der Governance. Es muss klar sein, wer die digitale Resilienz verantwortet, wer sie operativ steuert und wie die Leitung informiert und eingebunden wird. Rollen wie eine verantwortliche Person für Informationssicherheit, klare Meldewege und definierte Entscheidungsgremien sind hier zentral. Ohne diese Struktur bleiben auch technisch gute Maßnahmen wirkungslos, weil Verantwortung und Entscheidung im Ernstfall unklar sind.
Bewährt hat sich, DORA nicht als isoliertes IT-Projekt, sondern als organisationsweite Aufgabe zu begreifen, an der IT, Sicherheit, Recht, Einkauf und Leitung zusammenwirken. Gerade die Verzahnung mit dem Einkauf und dem Vertragsmanagement ist wichtig, weil das Drittparteienrisiko genau dort gesteuert wird. Ein interdisziplinäres Vorgehen verhindert, dass Anforderungen zwischen den Abteilungen verloren gehen.
Ein praktisch bedeutsames Thema ist die Frage, wo und wie die IT betrieben wird. DORA ist technologieneutral formuliert und schreibt kein bestimmtes Betriebsmodell vor – die Anforderungen gelten unabhängig davon, ob Systeme im eigenen Rechenzentrum, in der Cloud oder in einer hybriden Landschaft betrieben werden. Entscheidend ist, dass das Unternehmen die Risiken des gewählten Modells versteht und beherrscht.
DORA ist kein Projekt mit Enddatum, sondern eine Daueraufgabe. Nach dem erstmaligen Aufbau von Rahmenwerk, Register und Prozessen entscheidet der laufende Betrieb über die tatsächliche Resilienz: regelmäßige Risikoüberprüfungen, gepflegte Register, geübte Notfall- und Meldeprozesse sowie eine aktuelle Dokumentation. Was einmal aufgebaut und dann sich selbst überlassen wird, verliert schnell seinen Wert – Systeme, Verträge und Bedrohungen verändern sich fortlaufend.
Der DACH-Mittelstand ist ein wichtiger IT-Zulieferer des Finanzsektors: Softwarehäuser, Hosting- und Rechenzentrumsanbieter, spezialisierte Dienstleister für Zahlungsverkehr, Datenverarbeitung oder Sicherheit. Für diese Unternehmen stellt sich DORA selten als direkte Pflicht, aber sehr oft als geänderte Erwartung ihrer Finanzkunden dar. Wer diese Dynamik versteht, kann sich frühzeitig aufstellen und daraus einen Vorteil ziehen.
DORA wird für ein mittelständisches Unternehmen relevant, sobald es entweder selbst ein erfasstes Finanzunternehmen ist oder IKT-Dienste an den Finanzsektor liefert. Für die zweite, häufigere Gruppe zeigt sich die Verordnung vor allem in geänderten Vertragsanforderungen: Finanzkunden verlangen Prüf- und Auskunftsrechte, Sicherheits- und Meldeverpflichtungen sowie Nachweise über die eigene Resilienz. Wer solche Anforderungen bereits erfüllt oder proaktiv anbietet, verschafft sich einen spürbaren Vorteil gegenüber Wettbewerbern, die hier unvorbereitet sind.
Weniger unmittelbar betroffen sind Unternehmen ohne jede Berührung zum Finanzsektor. Auch für sie lohnt jedoch ein Blick auf die Grundprinzipien, denn gute digitale Resilienz ist branchenübergreifend wertvoll, und angrenzende Regelwerke wie NIS2 können durchaus einschlägig sein. Die ehrliche Einordnung der eigenen Rolle und Kundenbeziehungen ist wichtiger als eine pauschale Antwort – und sie sollte im Zweifel fachlich und rechtlich begleitet erfolgen.
Verlässliche Aussagen zum Aufwand lassen sich seriös nur eingeschränkt treffen: Der Umfang hängt von der eigenen Rolle, der Größe und Komplexität des Unternehmens, dem bestehenden Reifegrad der Informationssicherheit und der Zahl der relevanten Dienstleister ab. Dieser Beitrag nennt deshalb bewusst keine konkreten Kostenzahlen, sondern erläutert die Aufwandslogik und die wesentlichen Kostentreiber.
Der Aufwand einer DORA-Umsetzung setzt sich aus mehreren Bausteinen zusammen: der einmaligen Analyse von Betroffenheit und Ist-Zustand, dem Aufbau oder der Anpassung von Governance, Rahmenwerk, Prozessen und Register, der Anpassung von Verträgen mit Dienstleistern sowie dem dauerhaften Aufwand für Betrieb, Überprüfung, Tests und Dokumentation. Wichtig ist der Blick auf die Gesamtbelastung über die Zeit – gerade der laufende Betrieb und die kontinuierliche Pflege dominieren die Rechnung oft stärker als der einmalige Aufbau.
Ein wesentlicher, häufig unterschätzter Hebel ist der bereits erreichte Reifegrad: Unternehmen mit einem gelebten Informationssicherheits-Managementsystem oder etablierten Auslagerungsprozessen haben deutlich weniger nachzuholen als solche, die bei null beginnen. Für eine belastbare Einschätzung empfiehlt sich eine strukturierte Gap-Analyse, die den konkreten Handlungsbedarf sichtbar macht, statt pauschale Aufwandsschätzungen zu übernehmen, die dem Einzelfall selten gerecht werden.
Weil digitale Resilienz und Auslagerung eng zusammenhängen, rückt die Frage der Datenhoheit in den Vordergrund. Wer IKT-Dienste – insbesondere Cloud-Dienste – nutzt, sollte wissen, wo Daten verarbeitet und gespeichert werden, ob eine Verarbeitung innerhalb der EU beziehungsweise in Rechenzentren in Deutschland oder der EU angeboten wird und ob ein Datentransfer in Drittländer stattfindet. Diese Fragen sind für DORA (Beherrschung des Drittparteienrisikos) und für den Datenschutz gleichermaßen relevant.
Praktisch bedeutet das, den Serverstandort und die datenschutzfreundlichere Option aktiv zu prüfen und, sofern verfügbar, zu bevorzugen. Ebenso gehören der Auftragsverarbeitungsvertrag, die Liste der Unterauftragsverarbeiter und die vertraglichen Garantien in jede Prüfung. Hier zeigt sich, dass DORA und DSGVO in vielen Punkten in dieselbe Richtung wirken: Beide verlangen ein bewusstes, dokumentiertes Management der Zusammenarbeit mit Dienstleistern.
DORA und die Datenschutz-Grundverordnung verfolgen unterschiedliche, sich ergänzende Ziele. Die DSGVO schützt personenbezogene Daten und die Rechte betroffener Personen; DORA zielt auf die operationale Resilienz des Finanzsystems. In der Praxis überschneiden sie sich dort, wo es um die Sicherheit der Verarbeitung, den Umgang mit Vorfällen und die Zusammenarbeit mit Dienstleistern geht. Ein Sicherheitsvorfall kann gleichzeitig eine DORA-relevante Störung und eine datenschutzrelevante Datenpanne sein und damit unterschiedliche Melde- und Reaktionspflichten auslösen.
Für Unternehmen ist deshalb wichtig, beide Regime zusammen zu denken, statt sie in getrennten Silos zu bearbeiten. Vorfall- und Meldeprozesse sollten so gestaltet sein, dass sie sowohl den aufsichtsrechtlichen als auch den datenschutzrechtlichen Anforderungen genügen. Wie diese Pflichten im Einzelfall zusammenspielen, welche Fristen gelten und welche Meldungen an welche Stellen zu erstatten sind, ist eine rechtlich geprägte Frage, die mit dem Datenschutzbeauftragten und einer zur Rechtsberatung befugten Person zu klären ist.
