Es gibt eine Version der DORA-Konformität, mit der die meisten Finanzinstitute seit anderthalb Jahren leben – eine, bei der es hauptsächlich darum ging, Rahmenbedingungen zu schaffen, Dokumentationen zu erstellen und interne Richtlinien an die fünf Säulen der Verordnung anzupassen. Diese Version ist vorbei. Am 17. Januar 2025 trat die DORA in Kraft, und damit auch die Anforderungen an die QA für DORA-Resilienztests. Im Jahr 2026 gingen die nationalen zuständigen Behörden in der gesamten EU von einer aufsichtsrechtlichen Kulanz zu einer aktiven Überprüfung über. Die Frage, die die Aufsichtsbehörden jetzt stellen, ist nicht mehr, ob eine Bank ein DORA-Konformitätsprogramm hat. Es geht darum, ob dieses Programm Beweise liefert, die einer Überprüfung standhalten.
Für QA-Teams bei Banken, Versicherungen und Zahlungsdienstleistern verändert dieser Wandel die Art der Arbeit auf eine Weise, die präziser beschrieben werden sollte. Die Anforderungen an Resilienztests von DORA – Artikel 24 bis 27 und die zugehörigen technischen Regulierungsstandards – verlangen keine Testergebnisse. Sie verlangen eine dokumentierte, prüffähige Kette von den ICT-Systemen, die kritische Funktionen unterstützen, über die Tests, welche ihre Resilienz verifiziert haben, bis hin zu den Ergebnissen, die diese Tests erbracht haben. Das ist etwas völlig anderes, als eine Testsuite auszuführen und auf das grüne Dashboard zu zeigen.
Beim Aufbau von Qualigentic – unserer KI-gestützten QA-Plattform für regulierte Branchen – mussten wir sorgfältig darüber nachdenken, wie diese Beweiskette in der Praxis aussieht und warum herkömmliche Testinfrastrukturen, egal wie ausgereift sie sind, hinter dem zurückbleiben, was die Aufsichtsphase von DORA tatsächlich verlangt.
Was die Aufsichtsverschiebung für Testteams tatsächlich bedeutet
José Manuel de Araluce, schreibt in Finanzielle Qualitätssicherung im März 2026, nehmen Sie die Änderung direkt vor: "Nachdem die 'Stützräder' nun abmontiert sind, markiert 2026 den ersten wirklichen Test für DORA, und sowohl Finanzinstitute als auch CTPPs werden den Unterschied spüren." Die von ihm beschriebene Verlagerung ist spezifisch: Vorgesetzte gehen weg von der Bewertung von Richtlinien hin zur Bewertung operativer Beweise. Ein gut geschriebenes Incident-Response-Verfahren ist nicht dasselbe wie der Beweis, dass das Verfahren bei einem echten Vorfall funktioniert. Ein Testplan, der beschreibt, was getestet wird, ist nicht dasselbe wie ein unterschriebener Bericht, der zeigt, was, wann, gegen welche Anforderung getestet wurde und was das Ergebnis war.
Diese Unterscheidung – zwischen der Dokumentation der Absicht und der Dokumentation der Ausführung – ist die Schwachstelle der meisten Testprogramme bei Finanzinstituten. Die Lücke liegt nicht unbedingt am mangelnden Testaufwand. Die meisten erfahrenen Ingenieurteams bei Banken führen umfangreiche Testsuiten mit Abdeckungsmetriken durch, die auf einem Dashboard glaubwürdig aussehen. Die Lücke liegt in der Rückverfolgbarkeit dieser Tests zu regulatorischen Anforderungen und im Format der erzeugten Ergebnisse. Ein Ab.
Aufseher beurteilen nicht mehr, ob eine Bank ein Testprogramm hat. Sie beurteilen, ob dieses Programm Ergebnisse liefert, die einer behördlichen Prüfung standhalten.
Die fünf Säulen und wo das Testen hineinpasst
DORA strukturiert seine Anforderungen über fünf Domänen. Es lohnt sich, genau zu bestimmen, welche davon die QA-Funktion direkt betreffen, denn die Versuchung, DORA primär als Sicherheits- oder Governance-Thema zu betrachten, verkennt, wo der operative Druck auf die Testteams tatsächlich liegt.
Welche DORA-Resilienztest-QA-Nachweise tatsächlich erforderlich sind
Das Konzept einer Beweiskette ist im Prinzip einfach und in der Praxis anspruchsvoll. Ein Vorgesetzter, der Ihr DORA-Resilienztestprogramm überprüft, muss für jedes ICT-System, das eine kritische Funktion unterstützt, den Weg von der Anforderung, die das System erfüllen muss, über den Testfall, der zu seiner Überprüfung entworfen wurde, bis hin zum Ausführungsdatensatz, der zeigt, was bei der Ausführung dieses Tests passiert ist, und der Freigabe, die bestätigt, dass das Ergebnis von einer autorisierten Person überprüft wurde, nachvollziehen können. Jedes Glied in dieser Kette muss vorhanden, mit Zeitstempel versehen und unveränderlich – nicht nachträglich editierbar – sein.
Die meisten Testinfrastrukturen sind nicht für diesen Zweck ausgelegt. Testmanagement-Tools zeichnen Ergebnisse auf, erzwingen aber keine Rückverfolgbarkeit zu den Anforderungen. CI/CD-Pipelines führen Tests aus, aber die Protokolle werden überschrieben oder in Formaten archiviert, die nicht für die regulatorische Abfrage strukturiert sind. Abdeckungsberichte fassen Ergebnisse zusammen, verwerfen aber die einzelnen Ausführungsdatensätze, die eine regulatorische Überprüfung tatsächlich benötigt. Dies ist kein Designfehler – diese Tools wurden entwickelt, um die Entwicklungsgeschwindigkeit zu unterstützen, nicht die Prüfung von Vorschriften. Das Problem ist, dass die Prüfung von Vorschriften nun eine Anforderung ist und die Lücke zwischen Entwicklungstools und prüfungsbereiten Nachweisen real ist.
Das spezifische Problem von KI-Testwerkzeugen und DORA
Im Januar 2026 gab die deutsche BaFin unverbindliche Leitlinien heraus, die bestätigten, dass KI-Systeme – einschließlich generativer KI-Tools und großer Sprachmodelle – kein separater Regulierungsrahmen gemäß DORA sind und in bestehende ICT-Governance-, Test- und Outsourcing-Risikorahmen integriert werden müssen. Die praktische Konsequenz für Finanzinstitute, die KI-gestützte Testtools einsetzen, ist unmittelbar: Diese Tools sind selbst ICT-Systeme im Sinne von DORA. Wenn sie Testdaten in einer Cloud-Umgebung verarbeiten, schaffen sie eine kritische Abhängigkeit von externen ICT-Anbietern, die gemäß den Artikeln 28-31 formell gemanagt werden muss.
Dies ist keine theoretische Sorge. Eine Bank, die eine Cloud-basierte KI-Testplattform annimmt, um ihr DORA-Resilienztestprogramm zu verbessern, kann gleichzeitig das Drittparteienrisiko schaffen, das DORA zu verwalten bestimmt ist. Die institutionelle Logik ist stichhaltig — KI nutzen, um mehr Tests zu generieren, schneller und mit besserer Abdeckung — aber die architektonische Konsequenz, wenn das Werkzeug Cloud-abhängig ist, ist ein neuer Eintrag im DORA-Risikoregister für Drittparteien der Institution.
On-Premise-Bereitstellung löst dieses Problem. Wenn die Testinfrastruktur innerhalb des eigenen Umfangs der Institution betrieben wird, gibt es keine Beziehung zu einem externen ICT-Anbieter, die gemäß DORA verwaltet werden muss. Die Daten verlassen das Haus nicht. Die Ausführungsaufzeichnungen bleiben innerhalb der eigenen Audit-Infrastruktur der Institution. Die Beweiskette ist vollständig und in sich geschlossen.
Der Unterschied zwischen mehr testen und mit Beweisen testen
Es gibt eine Variante der DORA-Vorbereitung, die sich auf das Testvolumen konzentriert – also darauf, mehr Tests auszuführen, einen größeren Teil der Codebasis abzudecken und mehr Szenarien zu generieren. Der Umfang ist zwar nicht irrelevant, aber er ist nicht das, was in der Aufsichtsphase von DORA bewertet wird. Eine Testsuite, die 10.000 Testfälle durchführt und ein Dashboard mit einer 94%-Erfolgsquote anzeigt, erfüllt für sich genommen nicht die Anforderung von Artikel 25 hinsichtlich einer Dokumentation, die die aufsichtsrechtliche Überprüfung unterstützt. Entscheidend ist vielmehr, ob die Tests den IKT-Systemen und -Funktionen entsprechen, die DORA als im Geltungsbereich liegend identifiziert, und ob die Aufzeichnungen dieser Tests so strukturiert sind, dass sie die Fragen beantworten, die ein Aufsichtsbeauftragter stellen wird.
Die Frage, die ein DORA-Supervisor stellt, lautet nicht: "Wie viele Tests haben Sie durchgeführt?". Sie lautet: "Zeigen Sie mir die Beweise dafür, dass das IKT-System, das diese kritische Funktion unterstützt, getestet wurde, wann, mit welchem Ergebnis und wer hat die Abnahme erteilt."
Diese Neuausrichtung verändert die Priorität der Qualitätssicherungsarbeit in einer regulierten Institution auf eine Weise, die es wert ist, durchdacht zu werden. Die Verschiebung bedeutet nicht von weniger Tests zu mehr Tests. Es geht vom Testen als Qualitätssicherungsmaßnahme zum Testen als beweisgenerierender Aktivität mit einem definierten regulatorischen Zweck. Das Ergebnis des Prozesses ist keine Abdeckungsmetrik – es ist eine strukturierte Aufzeichnung, die spezifische regulatorische Fragen beantwortet und intakt und unverändert abgerufen werden kann, wenn ein Vorgesetzter danach fragt.
Was DORA nicht verlangt – und wo das Risiko einer Überkorrektur liegt
Es lohnt sich, präzise zu definieren, was die Anforderungen an Resilienztests von DORA nicht verlangt, da der regulatorische Druck zur Nachweisführung zur Einhaltung von Vorschriften Reaktionen hervorrufen kann, die belastender sind als die tatsächlich erforderliche Regelung.
Die Frage, die sich vor Ihrem nächsten Betreuungsgespräch stellt
Die sinnvollste Vorbereitung auf eine DORA-Aufsichtsprüfung ist nicht die Überprüfung einer Compliance-Checkliste. Es ist eine Simulation: Wenn ein Aufsichtsbeamter Ihr Team heute auffordern würde, die vollständigen Nachweise für die Resilienztests Ihrer drei wichtigsten IKT-Systeme vorzulegen – was könnten Sie ihm dann vorlegen, und wie lange würde es dauern, diese Unterlagen zusammenzustellen?
Wenn die Antwort darin besteht, mehrere Tools zu durchsuchen, Datensätze aus verschiedenen Systemen zusammenzustellen und darauf zu hoffen, dass die Protokolle nicht gelöscht wurden, handelt es sich um eine strukturelle Lücke – und nicht darum, weitere Tests durchzuführen. Die Tests sind möglicherweise bereits vorhanden. Was fehlt, ist die Infrastruktur, um sie bei Bedarf als Nachweis vorzulegen – in dem Format, das ein Vorgesetzter erwartet, und mit einer lückenlosen Kette von der Anforderung bis zum Ergebnis.
Das ist genau das Problem, das Qualigentic lösen soll. Nicht um die Testarbeit, die QA-Teams bereits gut machen, zu ersetzen, sondern um die Beweisschicht zu produzieren, die die Aufsichtsphase von DORA erfordert – mit On-Premise-Bereitstellung, die Daten innerhalb des eigenen Systems der Institution hält, RBAC-gesteuerten Genehmigungsworkflows und nachvollziehbaren Beweisketten, die als strukturierte Datensätze abrufbar sind und nicht erst am Tag der Anfrage eines Prüfers aus CI-Logs zusammengesucht werden müssen.
2026 ist das Jahr, in dem diese Unterscheidung in der Praxis an Bedeutung gewinnt. Die Institutionen, die sich darauf vorbereitet haben, sind besser aufgestellt als diejenigen, die sich erst jetzt darauf vorbereiten. Doch sowohl vorbereitet als auch unvorbereitet zu sein, ist immer noch besser, als davon auszugehen, dass die Testsuite als Beweis ausreicht.
