Performance Engineering als Compliance Thema:
Wie DORA die Rolle des Testens ändert
Veröffentlicht Juli, 2026 | 5 Min Lesezeit
Mit dem Inkrafttreten des Digital Operational Resilience Act (DORA) stehen Finanzdienstleister vor der Herausforderung digitale Resilienz nicht nur herzustellen, sondern auch nachzuweisen. Diese regulatorische Aufgabe betrifft direkt die Arbeit von
Performance Engineers, Testern und Observability-Teams. DORA verlangt nämlich die Stabilität, Verfügbarkeit und Belastbarkeit kritischer
Anwendungen regelmäßig zu testen. Damit wandern Testing und Monitoring von Quality Assurance nach Compliance.
DORA verlangt risikobasiertes Testen kritischer Anwendungen
Digital Operational Resilience Testing ist die dritte von fünf Säulen von DORA. Dazu müssen kritische Anwendungen und Dienste identifiziert werden. DORA liefert zum Prozess der Identifikation keine allgemeingültige Liste. Jedes Unternehmen muss selbst entscheiden,
welche Anwendungen es als kritisch einstuft. Im Falle eines Audits muss diese Entscheidung nachvollziehbar dokumentiert und begründet sein.
Da DORA hierbei keine Hilfestellung liefert, kommen die Unternehmen in eine schwierige Situation: Kritische Anwendungen müssen identifiziert werden und die Entscheidung muss anschließend bei einem Audit argumentiert werden. Obwohl es keinen Anhaltspunkt gibt,
was eine Anwendung kritisch macht oder nicht. Um es den Unternehmen einfacher zu machen, verweist die Wirtschaftskammer Österreich (WKO) auf das Dokument 32024R1772, die Delegierte Verordnung (EU) 2024/1772. Dabei handelt es sich um eine Kategorisierung von IKT-Vorfällen nach deren Schwere und Ausmaß. Die hier geschilderten Folgen können als Ausgangspunkt für Überlegungen fungieren.
Wird dieser Ansatz verfolgt, ergibt sich:
Nicht die Anwendung selbst ist kritisch, sondern die Auswirkungen eines Ausfalls auf das Unternehmen, die Kunden und den Finanzmarkt.
Die entscheidenden Fragen lauten also:
Welche Konsequenzen hätte ein Ausfall dieser Anwendung?
Welche Tests müssen durchgeführt werden um das Risiko des Ausfalls zu minimieren?
Da das entsprechende Dokument von der EU selbst veröffentlicht wurde, bildet es also eine gute Basis auf der Entscheidungen getroffen werden können. Im Falle eines Audits muss jederzeit nachvollziehbar begründet werden können:
- Warum wurde die Anwendung als kritisch/nicht kritisch eingestuft?
- Warum wurden bestimmte Testverfahren durchgeführt, während auf andere verzichtet
wurde?
Fehlende Dokumentation ist dabei ebenso problematisch wie fehlende Tests.
Abbildung: Einjähriger DORA Test-Zyklus
Artikel 24: Kritische Anwendungen müssen regelmäßig getestet werden
Sobald eine Anwendung als kritisch identifiziert wurde, schreibt DORA Artikel 24 vor, dass sie mindestens einmal jährlich getestet werden muss (für Penetrationstests gilt ein längerer Zeitraum von drei Jahren).
Diese Tests sollen sicherstellen, dass die Systeme auch unter außergewöhnlichen Bedingungen funktionsfähig bleiben und potenzielle Schwachstellen frühzeitig erkannt werden.
Artikel 25: Performance Testing wird explizit erwähnt
Für Performance Tester besonders interessant ist Artikel 25. Hier wird Performance Testing (Leistungstests in deutscher Übersetzung) explizit erwähnt. Die bloße Erwähnung bedeutet allerdings nicht, dass jede, als kritisch eingestufte, Anwendung einem Performance-Test
unterzogen werden muss. Stattdessen ist auch hier ein risikobasiertes Vorgehen notwendig. Führt das Nicht-Testen einer Anwendung im schlimmsten Fall zu einer Auswirkung, wie sie in DV(EU)2024/1772 (siehe oben) beschrieben ist? Dann ist eine Performance-Test angesagt. Wenn nicht, dann nicht.
Bei der Entscheidung, ob eine Applikation einem Performance-Test unterzogen werden muss, können die folgenden Fragen helfen:
🛈 Fragen, die dabei helfen, Anwendungen einzustufen
Geschäftskritikalität
- Ist die Anwendung direkt an geschäftskritischen Prozessen beteiligt?
- Würde ein Ausfall finanzielle Verluste verursachen?
- Wären Kernunternehmen des Unternehmens stillstehend?
- Ist die Anwendung notwendig, um regulatorische Anforderungen einzuhalten?
- Unterstützt die Anwendung Zahlungs-, Handels- oder Abwicklungsprozesse?
Kundenrelevanz
- Wie viele Kunden wären betroffen?
- Würden Kunden ihre Geschäfte nicht mehr durchführen können?
- Gibt es alternative Wege, die Dienstleistung bereitzustellen?
- Würde die Kundenzufriedenheit erheblich beeinträchtigt?
Abhängigkeiten
- Sind andere kritische Systeme von der Anwendung abhängig?
- Würde ein Ausfall zu Kaskadeneffekten führen?
- Ist die Anwendung Bestandteil einer zentralen Prozesskette?
- Würde ein Fehler weitere Dienste beeinträchtigen?
Verfügbarkeit
- Wie lange darf die Anwendung maximal ausfallen (RTO)?
- Wie viel Datenverlust wäre akzeptabel (RPO)?
- Gibt es definierte Service-Level-Agreements?
- Welche Verfügbarkeitsanforderungen bestehen?
Reputationsrisiken
- Würde ein Ausfall öffentlich wahrgenommen werden?
- Könnte das Vertrauen von Kunden oder Partnern nachhaltig geschädigt werden?
- Könnte ein Vorfall mediale Aufmerksamkeit erzeugen?
Regulatorische Auswirkungen
- Würde ein Ausfall zu einer Meldepflicht führen?
- Würden regulatorische Anforderungen verletzt werden?
- Könnte der Vorfall als schwerwiegender IKT-Vorfall eingestuft werden?
Im Auditfall muss klar argumentiert werden können:
Warum wurde ein Perfomance-Test durchgeführt, bzw. warum wurde darauf verzichtet?
Artikel 6: DORA als kontinuierlicher Prozess
Wurde eine Anwendung einmal als kritisch oder nicht-kritisch eingestuft, endet der Prozess nicht. Stattdessen verlangt Artikel 6, dass das Risikomanagementframework jährlich überprüft und aktualisiert wird. Dabei werden eingesetzte Werkzeuge und Tests beurteilt und
bei Bedarf ersetzt oder erweitert. Basis für diese Beurteilung bilden Erkenntnisse aus Betrieb und Monitoring der Anwendungen.
Im Falle von schwerwiegenden IKT-bezogenen Vorfällen oder nach aufsichtsrechtlichen Anweisungen, wird das Risikomanagementframework sofort überprüft.
Die Konsequenzen eines Ausfalls gehen über technische Probleme hinaus
Sollte es trotz allem zu einem Vorfall kommen, beschreibt die DV(EU)2024/1772, wie dessen Schweregrad beurteilt wird.
Zu den relevanten Bewertungskriterien gehören:
- Anzahl der betroffenen Kunden
- Anzahl der betroffenen Finanzpartner
- Anzahl der beeinträchtigten Transaktionen
- Auswirkungen auf die Reputation des Unternehmens
- Dauer des Vorfalls und Ausfallzeiten
- Geografische Ausbreitung
- Vorliegen von Datenverlusten
- Kritikalität der betroffenen Dienste
- Wirtschaftliche Auswirkungen
Da ein langsames System häufig die erste Warnung vor einem größeren Ausfall ist, wird Performance Engineering dadurch zu einem Instrument der Risikominimierung.
Artikel 10: Durchgängiges Monitoring ist verpflichtend
Monitoring ist im Performance Engineering allgegenwärtig. DORA verlangt Monitoring nicht nur während Performance Tests, sondern permanent. Die Ziele ständigen Monitorings sind unter anderem die Sicherstellung einer hohen Verfügbarkeit, die frühzeitige Erkennung potenzieller Störungen und das Auslösen von Alarmen bei untypischen Vorfällen.
Hervorgehoben werden Mechanismen zur Erkennung von
- Anomalien im Netzwerk
- Netzwerk-Performance Probleme
- Risiken für die Verfügbarkeit von Diensten
Zu den vorgeschriebenen Überwachungsmechanismen gehören:
- Threshold-basierte Alarme
- Automatische Warn- und Benachrichtigungssysteme
- Definierte Kriterien zur Auslösung von Maßnahmen zur Auswirkungsminderung
Damit wird Observability von einer technischen Best Practice zu einer regulatorischen Anforderung.
Artikel 17: Monitoring endet nicht bei Dashboards
Auch wenn Dashboards ein wirkungsvolles Instrument sind, um einen Überblick über das System zu erhalten, geht DORA noch weiter.
Artikel 17 fordert, dass Monitoring-Systeme in der Lage sein müssen:
- Root Causes zu identifizieren
- Ursachen zu dokumentieren
- Gegenmaßnahmen abzuleiten und umzusetzen
Entscheidend ist also die Fähigkeit, Zusammenhänge zwischen Infrastruktur, Netzwerk, Anwendungen und Business-Prozessen herzustellen.
| DORA Artikel | Anforderung | Relevanz für Performance Engineers |
|---|---|---|
| Artikel 6 | Kontinuierliche Überprüfung und Verbesserung des IKT-Risikomanagements | Kritikalität von Anwendungen regelmäßig neu bewerten, Teststrategien anpassen |
| Artikel 10 | Kontinuierliches Monitoring | Observability, Alerting |
| Artikel 17 | Root Cause Analyse | Tracing, Korrelation |
| Artikel 24 | Jährliche Tests | Teststrategie |
| Artikel 25 | Performance Tests | Alle Arten von Performance-Test |
Performance Engineering und Observability unter DORA
Da Performance Engineering immer eine nicht-funktionale Tätigkeit ist, die keine einfache Antwort hat, war Monitoring immer notwendig, um aussagekräftige Ergebnisse und effektive Änderungen zu liefern. Durch DORA ändert sich die Rolle dieser beiden Aktivitäten.
Performance Engineering wird zu einem elementaren Teil der Resilienz und Monitoring weitet sich auf den Produktivbetrieb aller kritischen Anwendungen aus. Im Finanzsektor ändert sich dadurch der Charakter des Performance Engineering. In der Welt vor DORA war das Ziel allein technische Optimierung. Nun, nach dem Inkrafttreten DORAs kommt nachweisbare digitale Resilienz hinzu.
Denn es gilt:
Nicht dokumentierte Resilienz existiert aus regulatorischer Sicht nicht.
Eine Anmerkung für Kleinstunternehmen
Bei DORA gilt immer der Grundsatz der Verhältnismäßigkeit. Daher sind Kleinstunternehmen von den strikten jährlichen Prozessen ausgenommen. Stattdessen müssen sie nur regelmäßig stattfinden. Wie regelmäßig ist den Unternehmen überlassen. Auch hier gilt, dass in einem Audit-Fall argumentiert werden muss, wieso das Unternehmen sich für ein bestimmtes Kontrollintervall entschieden hat