DORA für Engineering-Teams: Was die Verordnung tatsächlich von Ihren Systemen verlangt

Der Digital Operational Resilience Act wird Engineering-Teams meist als Compliance-Projekt vorgestellt, das jemand anderes verantwortet. Eine Richtlinie wird geschrieben, ein Fragebogen kommt, ein paar Kästchen werden angekreuzt. Dann verlangt eine Prüfung Nachweise — eine Vorfallchronologie, einen Testbericht, eine Liste jedes externen Dienstes, von dem die Plattform abhängt —, und aus dem Compliance-Projekt wird doch ein Engineering-Projekt, unter Zeitdruck.

Dieser Leitfaden liest DORA als das, was es für die Menschen ist, die Systeme bauen und betreiben: ein Satz von Anforderungen daran, wie IKT-Dienste inventarisiert, überwacht, getestet und beschafft werden. Wer es so versteht, erfüllt das meiste günstiger durch Design als durch Papier.

Wer im Geltungsbereich ist — und warum das Sie einschließt

DORA gilt für ein breites Spektrum von Finanzunternehmen — Banken, Versicherer, Wertpapierfirmen, Zahlungsinstitute, Anbieter von Kryptowerte-Dienstleistungen und mehr — und mittelbar für die IKT-Drittdienstleister, auf die diese Unternehmen angewiesen sind. Seit die Verordnung im Januar 2025 anwendbar wurde, hat sich der Aufsichtsfokus von „Haben Sie ein Rahmenwerk?“ zu „Zeigen Sie uns, dass es funktioniert“ verschoben.

Sind Sie ein Engineering-Team innerhalb eines Finanzunternehmens, liegt die Umsetzung bei Ihnen. Bauen Sie Plattformen, KI-Systeme oder Hosting für Finanzkunden, werden deren Verträge DORA-Anforderungen an Sie durchreichen: Prüfrechte, Vorfallbenachrichtigung, Exit-Unterstützung, Transparenz über Subunternehmer. So oder so hat die Verordnung eine konkrete Gestalt in Ihrer Architektur.

Die fünf Säulen, übersetzt

1. IKT-Risikomanagement — das Inventar und die Kontrollen

DORA verlangt ein IKT-Risikomanagement-Rahmenwerk: Assets, Abhängigkeiten und Risiken identifizieren; schützen und vorbeugen; erkennen; reagieren und wiederherstellen; lernen. Technisch heißt das: ein korrektes, gepflegtes Inventar von Systemen und Datenflüssen, Kontrollen, die tatsächlich umgesetzt sind (Zugriffs- und Änderungsmanagement, Backups, Verschlüsselung), und Monitoring, das Anomalien erkennen kann.

Die häufigste Lücke, die ich finde, ist keine fehlende Kontrolle, sondern eine fehlende Landkarte. Teams können nicht jeden Dienst benennen, der einen bestimmten Datenbestand verarbeitet, oder jeden externen Endpunkt, den ein Workload aufruft. Infrastructure-as-Code, Servicekataloge und Dependency-Scanning machen daraus statt einer vierteljährlichen Tabellenübung ein generiertes Artefakt.

2. Vorfallmanagement und -meldung — die Pipeline

Schwerwiegende IKT-Vorfälle müssen klassifiziert und der zuständigen Behörde in einem strikten Zeitrahmen gemeldet werden: eine Erstmeldung innerhalb von Stunden nach der Klassifizierung, ein Zwischenbericht innerhalb von Tagen und ein Abschlussbericht innerhalb eines Monats, gemäß den technischen Regulierungsstandards. Dieser Zeitrahmen ist nur erreichbar, wenn Erkennung, Klassifizierung und Beweissicherung konstruiert und nicht improvisiert sind.

Konkret: Alarme, die einen Menschen mit Kontext erreichen; ein Vorfalldatensatz, der Zeitstempel und Auswirkungen automatisch erfasst; Logs, die unveränderbar sind und aufbewahrt werden; und ein Regelwerk zur Klassifizierung, das technische Signale (betroffene Kunden, Dauer, Datenverlust, geografische Ausbreitung) auf die Wesentlichkeitskriterien von DORA abbildet.

3. Tests der digitalen operationalen Resilienz — Wiederherstellung beweisen

Unternehmen müssen ihre IKT-Systeme regelmäßig testen — Schwachstellenanalysen, Szenariotests und, für bedeutende Unternehmen, bedrohungsorientierte Penetrationstests alle drei Jahre. Für das Engineering heißt das: Wiederherstellung wird getestet, nicht angenommen. Aus dem Backup nach Zeitplan wiederherstellen. Umschalten und die Zeit messen. Game Days zu realistischen Szenarien durchführen, einschließlich „Der KI-Anbieter ist ausgefallen“ und „Der Vektorspeicher wurde beschädigt“.

Das Ergebnis von Tests sind Nachweise: Was wurde wann von wem getestet, was brach, was wurde behoben. Behandeln Sie Testberichte als versionierte Artefakte im Repository neben dem Code, den sie abdecken.

4. IKT-Drittparteienrisiko — der Abhängigkeitsgraph

Hier greift DORA bei modernen Architekturen am härtesten. Unternehmen müssen ein Informationsregister über alle vertraglichen Vereinbarungen mit IKT-Drittdienstleistern führen, Konzentrationsrisiken bewerten, sicherstellen, dass Verträge bestimmte Klauseln enthalten (Prüfrechte, Service-Level, Kündigung, Exit-Unterstützung), und Exit-Strategien für kritische Dienste vorhalten.

Für ein Team, das KI-Systeme baut, ist die Drittparteienliste lang und oft unsichtbar: die Modell-API, der Embedding-Dienst, die Vektordatenbank, die GPU-Cloud, das Observability-SaaS, der CI-Runner. Jedes davon ist eine IKT-Abhängigkeit. Konzentrationsrisiko ist real, wenn Modell, Hosting und Identitätsanbieter alle bei einem Hyperscaler in einer Region liegen.

5. Informationsaustausch

Unternehmen dürfen im Rahmen von DORA Informationen über Cyberbedrohungen untereinander austauschen. Für das Engineering ist relevant, dass Kompromittierungsindikatoren, Angriffsmuster und Erkenntnisse in einer teilbaren Form erfasst werden — strukturiert, anonymisiert, zeitnah.

Was das für KI- und Plattformsysteme bedeutet

KI-Workloads sind IKT-Dienste wie alle anderen im Sinne von DORA, bringen aber spezifische Anliegen mit:

• Datenintegrität. Ein Modell, das aus beschädigten oder manipulierten Quelldaten antwortet, erzeugt selbstbewusst falsche Ausgaben in großer Zahl. Herkunft, Hashing und Verifikation des Dokumentenkorpus sind Resilienzkontrollen, keine Kür.
• Modell- und Anbieterabhängigkeit. Behandeln Sie Modellanbieter als kritische Drittparteien: Vertragsklauseln, Monitoring, Exit-Strategie und die Fähigkeit, auf ein selbst gehostetes oder alternatives Modell zurückzufallen.
• Observability des KI-Verhaltens. Prompt- und Retrieval-Logs, Evaluationsmetriken und Drift-Monitoring sind die Vorfallerkennungsschicht für KI-Systeme. Ohne sie können Sie einen KI-Vorfall nicht klassifizieren, geschweige denn fristgerecht melden.
• Änderungsmanagement. Eine Prompt-Änderung, ein Modellversionswechsel oder eine Neuindizierung ist eine Produktionsänderung. Sie braucht dieselbe Prüfung, dieselben Tests und denselben Rückfallpfad wie ein Code-Deployment.

Eine pragmatische Reihenfolge

Wenn Sie mit einem Richtliniendokument und einer besorgten Compliance-Verantwortlichen starten, hat sich diese Abfolge bewährt:

1. Das Inventar aus der Realität erzeugen: Infrastrukturcode, Servicekatalog, Netzwerk-Egress-Logs. Mit dem vergleichen, was Compliance für existent hält. Die Differenz ist Ihr erster Befund.
2. Das Drittparteienregister aus dem Inventar bauen, Verträge anhängen. Kritikalität und Konzentration klassifizieren.
3. Vorfallnachweise automatisch machen: unveränderbare Logs, Vorfalldatensätze mit Zeitstempeln, ein Klassifizierungsregelwerk.
4. Wiederherstellungstests planen und durchführen. Berichte aufbewahren.
5. Die Exit-Strategie für die drei kritischsten Anbieter schreiben und den günstigsten Schritt jeder Strategie testen.
6. Erst dann die Richtlinie so überarbeiten, dass sie beschreibt, was Sie tatsächlich tun.

So umgesetzt hört DORA-Compliance auf, ein separates Ergebnis zu sein. Sie wird zur Betriebsdisziplin, die Sie ohnehin wollten — mit Prüfpfad.