Bildquelle: Pexels: https://www.pexels.com/photo/computer-server-in-data-center-room-17489163/
DORA im Regelbetrieb: Welche 5 Betriebsnachweise IT- und Service-Teams jederzeit vorlegen können müssen
Viele Finanzunternehmen haben DORA bis Anfang 2025 noch als Umsetzungsprojekt behandelt. 2026 zeigt sich jedoch, worauf es wirklich ankommt: nicht auf Folien, Richtlinienordner oder einmalige Gap-Analysen, sondern auf belastbare Nachweise im laufenden Betrieb. Genau hier geraten IT-Organisationen, Service-Desks, Informationssicherheitsfunktionen und Provider-Manager unter Druck. Denn sobald Prozesse, Lieferantensteuerung und Incident-Abläufe nicht nachvollziehbar dokumentiert sind, wird aus formal erfüllter Regulierung schnell ein operatives Risiko.
DORA gilt seit dem 17. Januar 2025. Die BaFin betont, dass die Verordnung den Finanzsektor in sechs zentralen Bereichen stärkt, von IKT-Risikomanagement über Vorfallbehandlung bis zum Management von IKT-Drittparteienrisiken. Für deutsche Institute kommt ein praktischer Punkt hinzu: Die BaFin fungiert als nationaler Melde-Hub für IKT-Vorfälle. Das heißt im Alltag, dass Teams nicht nur sauber arbeiten, sondern ihre Arbeitsfähigkeit auch strukturiert nachweisen müssen.
Für ITSM-Verantwortliche ist das die eigentliche Zäsur. DORA ist kein reines Compliance-Thema mehr, sondern greift direkt in Service-Architektur, Betriebssteuerung, Lieferantenmanagement und Major-Incident-Prozesse ein.
1. Ein belastbares IKT-Risikobild pro kritischem Service
Der erste Nachweis ist ein aktuelles, belastbares Bild der IKT-Risiken. In der Praxis reicht dafür keine isolierte Risikoliste im GRC-Tool. Gefragt ist eine Verbindung aus kritischen Geschäftsprozessen, unterstützenden IT-Services, technischen Abhängigkeiten, Verantwortlichkeiten und Schutzmaßnahmen.
Wenn ein Institut beispielsweise den Zahlungsverkehr, das Depotgeschäft oder digitale Kundenkanäle als kritisch einstuft, muss nachvollziehbar sein, welche Anwendungen, Infrastrukturen, Schnittstellen und Dienstleister daran hängen. Für den Betrieb bedeutet das: Servicekatalog, CMDB, Architekturübersicht und Risikobewertung dürfen nicht nebeneinander herlaufen. Sie müssen aufeinander verweisen und in Review-Zyklen gepflegt werden.
Praxisnah wird dieser Punkt erst dann, wenn Service Owner für jeden kritischen Service beantworten können: Welche Risiken sind aktuell offen? Welche Kontrollen mindern sie? Wo bestehen Single Points of Failure? Welche externen Leistungen sind kritisch?
2. Ein Incident-Prozess, der regulatorische Meldefähigkeit wirklich trägt
Der zweite Nachweis betrifft den Umgang mit IKT-bezogenen Vorfällen. Viele Organisationen haben zwar ein Major-Incident-Verfahren, aber kein Verfahren, das regulatorische Klassifizierung, Eskalation, Dokumentation und externe Meldung sauber zusammenführt. Genau das wird unter DORA zum Problem.
Ein belastbarer DORA-Prozess braucht mindestens vier Dinge: eine klare Schweregradlogik, definierte Entscheidungsrollen, einen dokumentierten Eskalationspfad und vollständige Ereignisprotokolle. Entscheidend ist nicht nur, dass ein Incident gelöst wird, sondern dass später nachvollziehbar bleibt, wann er erkannt, wie er eingestuft, wer informiert und welche Maßnahmen ausgelöst wurden.
Für Service-Desks und NOCs heißt das konkret: Ticketdaten, Kommunikationsprotokolle, forensische Spuren und Management-Entscheidungen müssen zusammenpassen. Wer hier noch mit parallelen Excel-Listen, Chat-Verläufen ohne Ablage oder manuellen Ad-hoc-Entscheidungen arbeitet, erzeugt im Ernstfall sofort Nachweislücken.
3. Ein vollständiges Register der IKT-Drittdienstleister
Besonders operativ wird DORA beim Drittparteienrisiko. Die EBA weist darauf hin, dass alle betroffenen Finanzunternehmen ein umfassendes Register ihrer vertraglichen Vereinbarungen mit IKT-Drittdienstleistern auf Ebene des Einzelinstituts, gegebenenfalls aber auch auf teilkonsolidierter und konsolidierter Ebene verfügbar halten müssen. Dieses Register dient nicht nur der internen Steuerung, sondern auch der Aufsicht und der Einstufung kritischer IKT-Drittdienstleister auf EU-Ebene.
In der Praxis scheitert dieser Punkt oft nicht am fehlenden Vertrag, sondern an fehlender Struktur. Häufig liegen Einkaufsdaten, Vertragsanlagen, Auslagerungsbewertungen, Subdienstleister-Informationen und technische Service-Abhängigkeiten in getrennten Systemen. Damit entsteht kein belastbares Register, sondern nur ein Dokumentensilo.
IT- und Provider-Management sollten deshalb nicht erst beim Reporting ansetzen. Sinnvoll ist eine einheitliche Lieferantenakte mit Pflichtfeldern für kritische oder wichtige Funktionen, betroffene Services, Laufzeiten, Exit-Regelungen, Prüf- und Zugriffsrechte, Subunternehmer sowie verantwortliche interne Ansprechpartner. Spätestens mit den standardisierten Vorlagen aus der Durchführungsverordnung (EU) 2024/2956 ist klar: Freitext reicht hier nicht mehr.
4. Nachweise aus Resilienztests, nicht nur aus Penetrationstests
Wenn über DORA gesprochen wird, denken viele zuerst an Threat-led Penetration Testing. Das greift zu kurz. TLPT ist nur für einen begrenzten Kreis besonders relevanter Unternehmen vorgesehen. Für den breiten Markt ist wichtiger, dass Resilienz regelmäßig praktisch getestet wird.
Ein guter Nachweis ist deshalb kein einzelner Pentest-Bericht, sondern ein Testportfolio: Wiederherstellungstests, Failover-Proben, Backup-Restores, Kommunikationsübungen, Tabletop-Szenarien und Nachtests nach Schwachstellenbehebungen. Relevant ist dabei immer die betriebliche Frage: Konnte der Service in der vorgesehenen Zeit wiederhergestellt werden und war die Entscheidungs- und Kommunikationskette funktionsfähig?
Gerade hier haben ITSM-Teams eine Schlüsselrolle. Sie koordinieren Changes, führen Runbooks, kennen Abhängigkeiten und moderieren viele Wiederanlaufprozesse. Wenn diese Artefakte sauber versioniert und mit Testergebnissen verknüpft sind, entsteht ein Nachweis, der im Audit trägt. Wenn nicht, bleibt nur die Behauptung, man habe getestet.
5. Eine Dokumentation, die im Alltag gepflegt wird
BaFin hat 2025 eigens einen Überblick zu Dokumentationsanforderungen unter DORA veröffentlicht. Das ist ein wichtiges Signal: Dokumentation ist kein Nebenprodukt, sondern ein zentrales Steuerungsinstrument. Gefordert ist nicht maximale Papiermenge, sondern nachvollziehbare, konsistente und gepflegte Evidenz.
Für die Praxis heißt das, Richtlinien, Prozesse, Kontrollnachweise, Schulungen, Testprotokolle, Auslagerungsakten und Incident-Dokumentation müssen zusammenpassen. Besonders kritisch sind Brüche zwischen Soll und Ist. Wenn etwa ein Prozesshandbuch vierteljährliche Reviews vorsieht, im Ticket- oder GRC-System aber seit neun Monaten nichts dokumentiert wurde, ist das nicht nur eine Formalie, sondern ein sichtbarer Steuerungsmangel.
Was ITSM-Organisationen jetzt konkret ändern sollten
- Servicekatalog und CMDB erweitern: Kritische Funktionen, regulatorische Relevanz, zugeordnete Dienstleister und Wiederanlaufziele sollten als Pflichtattribute gepflegt werden.
- Major-Incident-Prozess schärfen: Klassifizierung, Meldepflicht, Kommunikationsfreigabe und Beweissicherung müssen in einem Ablauf zusammenlaufen.
- Provider-Management industrialisieren: Verträge, Subunternehmer, Exit-Pläne und Kontrollrechte gehören in ein strukturiertes Register, nicht in E-Mail-Postfächer.
- Testnachweise zentral ablegen: Übungen, Restore-Tests und Lessons Learned sollten revisionssicher an einem Ort auffindbar sein.
- Quartalsweise Evidenz-Checks einführen: Nicht nur Prozesse prüfen, sondern gezielt die Nachweisfähigkeit für kritische Services testen.
Die eigentliche Reife unter DORA zeigt sich 2026 also nicht daran, ob ein Institut ein Programm aufgesetzt hat, sondern ob Betrieb, Service Management und Governance sauber ineinandergreifen. Wer Nachweise erst erstellt, wenn Aufsicht oder Revision fragen, ist bereits zu spät. Wer sie im Alltag mitführt, gewinnt nicht nur regulatorische Sicherheit, sondern meist auch einen deutlich besseren Blick auf die eigene Betriebsstabilität.
