DORA Anforderungen für IT

Seit dem 17. Januar 2025 gilt DORA verbindlich. Für viele IT-Organisationen in Finanzunternehmen ist damit klar: Die DORA Anforderungen für IT sind kein weiteres Compliance-Projekt neben dem Betrieb. Sie greifen direkt in Architekturentscheidungen, Incident-Prozesse, Cloud-Governance, Lieferantensteuerung und die Verantwortung des Managements ein.

Die Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor richtet sich zwar primär an regulierte Finanzunternehmen. Ihre Wirkung reicht aber weiter. Banken, Versicherungen, Zahlungsdienstleister, Wertpapierfirmen und weitere Finanzunternehmen müssen ihre IKT-Risiken beherrschen. Wer diese Organisationen als IT-Dienstleister, SaaS-Anbieter, Cloud-Provider oder Managed-Service-Partner unterstützt, wird deshalb mit deutlich konkreteren Nachweisen und Vertragsforderungen konfrontiert.

Die entscheidende Frage lautet nicht, ob bereits Richtlinien, ein ISMS oder ein Business-Continuity-Plan vorhanden sind. Entscheidend ist, ob sich Risiken, Abhängigkeiten und Kontrollwirksamkeit im tatsächlichen IT-Betrieb nachvollziehbar steuern lassen.

Was DORA von der IT-Organisation verlangt

DORA ist keine technische Norm mit einer abschließenden Kontrollliste. Die Verordnung verbindet Governance, Risikomanagement und operative Resilienz. Sie verlangt, dass ein Finanzunternehmen kritische oder wichtige Funktionen auch unter Störungslagen weiter erbringen oder in einen kontrollierten Zustand zurückführen kann.

Im Zentrum stehen fünf eng verknüpfte Bereiche:

• IKT-Risikomanagement mit klaren Verantwortlichkeiten, dokumentierten Kontrollen und einem vollständigen Blick auf Systeme, Daten, Schnittstellen und Abhängigkeiten.
• Management, Klassifizierung und Meldung schwerwiegender IKT-bezogener Vorfälle.
• Tests der digitalen operationalen Resilienz, von regelmäßigen Prüfungen bis zu bedrohungsorientierten Tests in den dafür vorgesehenen Fällen.
• Steuerung von IKT-Drittdienstleistern über den gesamten Lebenszyklus – von Auswahl und Vertrag bis Exit und Überwachung.
• Freiwilliger Austausch relevanter Informationen und Erkenntnisse zu Cyberbedrohungen innerhalb vertrauenswürdiger Vereinbarungen.

Diese Struktur klingt vertraut, wenn du mit ISO 27001, NIST-orientierten Sicherheitsprogrammen oder BSI-Methodik arbeitest. DORA ersetzt solche Grundlagen nicht einfach. Sie erhöht aber die Messlatte für Verbindlichkeit, Nachweisbarkeit und sektorbezogene Aufsicht. Ein sauber formuliertes Konzept genügt nicht, wenn Asset-Daten unvollständig sind, Eskalationen nur auf dem Papier existieren oder ein Cloud-Ausfall keine realistisch getestete Handlungsoption hat.

Governance: Verantwortung lässt sich nicht delegieren

DORA weist dem Leitungsorgan eine ausdrückliche Verantwortung für das IKT-Risikomanagement zu. Praktisch bedeutet das: Die Geschäftsleitung beziehungsweise das zuständige Management muss Risiken verstehen, die Strategie billigen, Kompetenzen aufbauen und die Umsetzung überwachen. Der CISO kann die operative Führung übernehmen. Die Verantwortung des Managements verschwindet dadurch nicht.

Für CIOs und CISOs entsteht hier ein produktiver, aber anspruchsvoller Übersetzungsauftrag. Technische Risiken müssen so aufbereitet werden, dass Entscheidungen über Risikoakzeptanz, Investitionen und Prioritäten möglich sind. Umgekehrt dürfen Management-Vorgaben nicht in abstrakten Policies enden. Sie müssen sich in Architekturprinzipien, Change-Freigaben, Betriebskennzahlen und Eskalationswegen wiederfinden.

Besonders häufig zeigt sich eine Lücke an den Übergängen: Wer entscheidet bei einem kritischen Sicherheitsbefund über eine temporäre Serviceeinschränkung? Wann wird ein Lieferantenvorfall zum meldepflichtigen Ereignis? Wer akzeptiert, dass eine Abhängigkeit kurzfristig nicht ersetzbar ist? Diese Fragen sollten vor dem Vorfall beantwortet und geübt sein.

DORA Anforderungen für IT beginnen mit Transparenz

Die wichtigste Grundlage ist ein belastbares Bild der eigenen IKT-Landschaft. Dazu gehören nicht nur Anwendungen und Infrastrukturkomponenten. Relevant sind auch Datenflüsse, Schnittstellen, Identitäten, Betriebsmodelle, externe Services, Unterauftragnehmer, unterstützte Geschäftsprozesse und Wiederanlaufabhängigkeiten.

Ein CMDB-Projekt allein löst das Problem nicht. In vielen Organisationen sind Konfigurationsdaten zwar vorhanden, aber für Resilienzfragen kaum nutzbar: Kritikalität ist uneinheitlich bewertet, Ownership fehlt, SaaS-Nutzung entsteht dezentral oder technische Beziehungen werden nicht gepflegt. DORA verlangt keine perfekte Datenbank. Sie verlangt jedoch eine Informationsbasis, auf der Risiken und Folgen realistisch beurteilt werden können.

Ein guter Startpunkt ist die Rückwärtsanalyse von kritischen oder wichtigen Funktionen. Welcher Geschäftsservice muss verfügbar bleiben? Welche Applikationen, Plattformen, Identitätsdienste, Netzverbindungen, Datenquellen und Dienstleister tragen ihn? Wo existieren Konzentrationsrisiken? Und welche Annahmen über Wiederherstellung wurden bislang nie getestet?

Dabei lohnt sich eine Trennung zwischen Verfügbarkeit und Resilienz. Multi-Region-Betrieb kann die Verfügbarkeit erhöhen. Er hilft aber wenig, wenn fehlerhafte Daten repliziert werden, ein zentraler Identity Provider ausfällt oder ein kompromittiertes Administratorkonto beide Umgebungen erreicht. Resilienz entsteht aus technischen Schutzmaßnahmen, Erkennung, Entscheidungsfähigkeit und erprobter Wiederherstellung.

Incident Management: Geschwindigkeit ohne Spekulation

DORA bringt für schwerwiegende IKT-Vorfälle verbindliche Meldeprozesse mit sich. Ergänzende technische Regulierungsstandards konkretisieren unter anderem Klassifizierungskriterien, Fristen und Inhalte. Die EU-Kommission führt die ergänzenden Durchführungs- und delegierten Rechtsakte zu DORA zentral auf. Für den Betrieb heißt das: Security Operations, IT-Service-Management, Fachbereiche, Compliance und Rechtsfunktion brauchen ein gemeinsames Lagebild.

Die Herausforderung liegt selten darin, ein Ticket anzulegen. Sie liegt darin, unter Zeitdruck belastbar zu bewerten. Wie viele Kunden, Transaktionen oder kritische Geschäftsprozesse sind betroffen? Welche geografische Reichweite hat der Vorfall? Gibt es Datenintegritäts- oder Vertraulichkeitsrisiken? Ist ein externer Dienstleister beteiligt? Ohne abgestimmte Datenquellen, Rollen und Kommunikationswege entstehen Verzögerungen oder voreilige Meldungen.

Daher sollten Incident-Runbooks nicht nur technische Eindämmung beschreiben. Sie müssen auch Entscheidungspunkte, Beweissicherung, interne Eskalation, externe Kommunikation und die Übergabe in die Ursachenanalyse abdecken. Tabletop-Übungen sind dafür wertvoll, sofern sie nicht bei einem Phishing-Szenario stehen bleiben. Teste auch den Ausfall eines zentralen Cloud-Dienstes, eine fehlerhafte Softwareauslieferung oder einen Dienstleister, der Informationen nur verzögert liefert.

Resilienztests müssen Architekturannahmen angreifen

DORA fordert ein Programm für Tests der digitalen operationalen Resilienz. Der Umfang muss verhältnismäßig sein. Nicht jedes Unternehmen braucht dieselbe Testtiefe, und nicht jedes System erfordert denselben Aufwand. Gerade deshalb ist eine nachvollziehbare Risikologik entscheidend.

Regelmäßige Schwachstellenscans und Penetrationstests bleiben notwendig, reichen aber nicht aus. Sie prüfen oft Einzelkomponenten. Resilienztests sollten zusätzlich untersuchen, ob ein kritischer Service nach einem Ausfall oder Angriff tatsächlich wiederhergestellt werden kann. Dazu gehören Restore-Tests mit realistischen Datenmengen, Failover-Übungen, Tests manueller Ersatzverfahren sowie Übungen zur Kommunikation über Teams und Dienstleister hinweg.

Für bestimmte Finanzunternehmen sieht DORA zudem Threat-Led Penetration Testing vor. Solche Tests sind kein Pentest mit neuem Etikett. Sie simulieren auf Basis relevanter Bedrohungsinformationen realistische Angriffswege gegen produktionsnahe Umgebungen und verlangen eine sorgfältige Steuerung. Der Nutzen liegt nicht allein in gefundenen Schwachstellen, sondern in der Erkenntnis, ob Erkennung, Reaktion und Wiederanlauf als Gesamtsystem funktionieren.

Drittanbietersteuerung ist eine Architekturfrage

Cloud, SaaS und spezialisierte Managed Services machen IT-Organisationen leistungsfähiger, können aber Abhängigkeiten verdichten. DORA verlangt ein Informationsregister über vertragliche Vereinbarungen mit IKT-Drittdienstleistern. Es geht dabei nicht um Vertragsablage, sondern um steuerbare Transparenz: Welche kritische Funktion hängt von welchem Dienst ab? Wo bestehen Konzentrationsrisiken? Welche Subunternehmer und Datenstandorte sind relevant? Welche Exit-Option ist praktisch vorhanden?

Ein Exit-Plan ist nur dann glaubwürdig, wenn er technische und wirtschaftliche Realität berücksichtigt. Ein Wechsel zu einem anderen Provider kann Monate dauern, Datenmigrationen können Integritätsrisiken erzeugen, und einzelne Managed Services sind möglicherweise gar nicht kurzfristig substituierbar. DORA verlangt nicht, jede Abhängigkeit sofort aufzulösen. Sie verlangt, dass du sie kennst, bewertest und mit angemessenen Maßnahmen absicherst.

Verträge müssen dafür ausreichend Prüf-, Zugangs-, Informations- und Kündigungsrechte enthalten. In der Praxis ist das bei großen Standardanbietern ein Verhandlungsthema mit begrenztem Spielraum. Dann wird es umso wichtiger, Kompensationsmaßnahmen transparent zu dokumentieren: zusätzliche technische Kontrollen, Multi-Vendor-Ansätze, Notfallverfahren oder eine bewusst akzeptierte Restrisikoentscheidung auf der richtigen Managementebene.

Vom Programm in den Betrieb

DORA-Umsetzung scheitert oft, wenn sie ausschließlich bei Compliance oder ausschließlich in der Security angesiedelt wird. Die Verordnung berührt Enterprise Architecture, Procurement, Vendor Management, Softwareentwicklung, Service Management, BCM, Datenschutz und die Fachbereiche. Ein zentrales Programm kann Standards, Steuerung und Reporting bündeln. Die Wirksamkeit entsteht aber in den Teams, die Services bauen und betreiben.

Sinnvoll ist eine Roadmap, die zunächst kritische Funktionen, größte Abhängigkeiten und offensichtliche Nachweislücken priorisiert. Parallel sollten Rollenmodell, Incident-Prozess, Dienstleisterregister und Testkalender so aufgesetzt werden, dass sie dauerhaft gepflegt werden können. Ein einmaliger Dokumentationssprint erzeugt keine operative Resilienz.

DORA ist damit auch ein Test für die Qualität der IT-Steuerung. Wenn du die Anforderungen nicht als regulatorische Zusatzschicht behandelst, sondern als Anlass nutzt, Entscheidungswege, Abhängigkeitswissen und Wiederherstellungsfähigkeit zu schärfen, entsteht ein Nutzen, der über jede Prüfung hinausreicht.