Nachweise zur Softwarequalität sind nicht dasselbe wie ein Testprogramm, und dieser Unterschied ist genau das, was die erste ernsthafte Aufsichtsprüfung offenlegt. Die meisten regulierten Finanzinstitute haben QA-Ingenieure, Testsuiten, CI/CD-Pipelines und Dashboards, die grün leuchten. Deutlich weniger haben Nachweise.
Ein Testprogramm sagt Ihnen, ob die Software funktioniert. Der Nachweis sagt einer Aufsichtsbehörde, einem Prüfer oder einer nationalen zuständigen Behörde, dass die richtigen Systeme auf die richtige Weise zur richtigen Zeit mit der richtigen Aufsicht getestet wurden und dass die Ergebnisse von Personen geprüft wurden, die befugt sind, ihre Angemessenheit zu bestätigen. Die Compliance-Kosten in regulierten Branchen sitzen überwiegend in dieser Lücke und nicht im Testen selbst.
Im Folgenden legen wir dar, was diese Lücke ist, was sie kostet, warum sie bestehen bleibt und was ihr Schließen tatsächlich verlangt.
Was die Aufsicht verlangt und eine Testsuite nicht beantwortet
DORA ging 2026 von der Vorbereitung in die aktive Aufsichtsprüfung über, was diesen Unterschied sichtbar machte wie nie zuvor. Die nationalen zuständigen Behörden prüfen nicht mehr, ob Institute ein Testprogramm haben. Sie prüfen, ob dieses Programm Aufzeichnungen erzeugt, die einer Prüfung standhalten.
Eine Anfrage legt die Lücke deutlicher offen als jede andere, und Aufsichtsbehörden stellen sie inzwischen in verschiedenen Formulierungen: legen Sie die Nachweise über Resilienztests für Ihre drei kritischsten IKT-Systeme vor. Nicht die Testergebnisse. Eine vollständige, nachvollziehbare Aufzeichnung darüber, was getestet wurde, warum, wann, von wem, mit welchem Ergebnis und wer bestätigt hat, dass das Ergebnis angemessen war. Kapitel IV der Verordnung (EU) 2022/2554Artikel 24 bis 27, ist die Rechtsgrundlage.
In Instituten mit ausgereifter Nachweisinfrastruktur ist diese Anfrage in Minuten erledigt. Wo gut getestet wird, die Nachweisebene aber aus CI/CD-Logs und Tabellen zusammengesetzt wurde, löst dieselbe Anfrage Tage manueller Arbeit aus. Ergebnisse kommen unvollständig und uneinheitlich formatiert, was ein zweites Problem schafft: eine Aufsichtsbehörde, die ein hastig gebautes Paket liest, bewertet nun die Praxis des Nachweismanagements neben der Testpraxis.
Warum die Lücke bei Nachweisen zur Softwarequalität entsteht
Die Lücke ist keine Nachlässigkeit. Sie ist das vorhersehbare Ergebnis davon, wie Testinfrastruktur entstand, bevor regulatorische Nachweispflichten existierten.
Warum manuelle Nachweisebenen scheitern
Manuelle Prozesse, die von individueller Disziplin abhängen, überleben keine Personalwechsel, keine Teamumbauten und nicht die knappen Fristen einer Aufsichtsanfrage. Sie scheitern zudem lautlos. Niemand merkt, dass die Freigabetabelle im März nicht mehr gepflegt wurde, bis im Oktober jemand die Märzaufzeichnungen verlangt. Genau dieser Abstand zwischen Fehler und Entdeckung macht den manuellen Weg riskanter, als er im Organigramm aussieht.
Was die Lücke bei Nachweisen zur Softwarequalität kostet
Die Kosten treten auf drei Wegen auf, und keiner davon erscheint in einer Budgetzeile namens Testen.
Ein vorhersehbarer Termin gehört ebenfalls in den Kalender. Das Informationsregister wird jährlich bis zum 30. April übermittelt, es gibt also mindestens eine Nachweisübung pro Jahr, mit oder ohne angesetzte Prüfung.
Die vier Anforderungen an eine Infrastruktur für Nachweise zur Softwarequalität
Die Lücke zu schließen ist vor allem eine Architekturentscheidung darüber, wo Nachweise liegen, wer sie verantwortet und wie sie entstehen. Vier Anforderungen leisten die Arbeit.
Ein 90-Tage-Weg zu Nachweisen zur Softwarequalität
Niemand baut eine Nachweisebene in einem Quartal neu. In ein Quartal passt genug Struktur, um die nächste Anfrage zu überstehen, deshalb ist die Reihenfolge unten nach dem geordnet, was das Risiko am schnellsten senkt, und nicht nach dem, was am vollständigsten ist.
Wochen 8 bis 12: Aufbewahrung und ein echter Probelauf
Zwei Gewohnheiten machen danach den Unterschied. Üben Sie den Abruf einmal pro Quartal, denn ein ungetesteter Prozess ist eine Annahme. Und behandeln Sie die jährliche Übermittlung des Informationsregisters als wiederkehrenden Termin, der die Kette aktuell hält, weil eine Ebene, die nur auf Anfrage gepflegt wird, zwischen den Anfragen verfällt.
Unter Druck: was ein schwerwiegender Vorfall offenlegt
Nichts prüft diese Infrastruktur so wie ein Ausfall. Ein kritisches IKT-System fällt aus, das Reaktionsteam aktiviert sich, und die erste Entscheidung ist die Klassifizierung, denn dort startet die 4-Stunden-Uhr.
Zwei Institute mit derselben Testsuite verhalten sich hier unterschiedlich. Eines hat die Aufzeichnung zum betroffenen System, den letzten Lauf, die zugehörige Freigabe und die abgedeckten Anforderungen binnen Minuten an einem Ort, sodass die Klassifizierung besser fundiert ist und die Meldung vollständig eintrifft. Beim anderen schickt dieselbe Frage Menschen in CI/CD-Logs, E-Mail-Threads und Tabellen, während die Uhr läuft. Deren Meldung spiegelt am Ende den Zustand der Nachweisinfrastruktur und nicht den Zustand des Testens.
Was Nachweise zur Softwarequalität nicht lösen
Über die Grenzen sollte man deutlich sprechen, denn Nachweisinfrastruktur wird gelegentlich als Compliance-Antwort für sich verkauft.
Eine schwache Testsuite bleibt schwach. Perfekt nachvollziehbare, unveränderlich gespeicherte Aufzeichnungen unzureichender Tests dokumentieren die Unzulänglichkeit mit großer Genauigkeit, die Nachweisebene verbessert also die Darstellung der Arbeit und nicht die Arbeit. Zu entscheiden, welche Systeme kritische oder wichtige Funktionen stützen, bleibt ebenfalls ein internes Urteil, denn diese Einordnung gehört zur eigenen Risikobewertung des Instituts. Bedrohungsgeleitete Penetrationstests behalten ihre eigenen Anforderungen und Frequenz für die erfassten Unternehmen, und keine Nachweisplattform ersetzt sie. Verantwortliche Menschen bleiben ebenso im Ablauf, weil die Freigabe der Teil ist, der sich per Konstruktion nicht automatisieren lässt. Verschwinden dagegen das Zusammentragen, die Uneinheitlichkeit und die Abhängigkeit davon, wer sich gerade erinnert, wo etwas liegt.
Wie Qualigentic die Nachweiskette zur Softwarequalität erzeugt
Qualigentic Qualigentic ist eine agentische QA-Plattform, die um die Nachweisebene herum gebaut ist und nicht um die Menge generierter Tests. Jeder Testfall trägt die Verknüpfung zur Anforderung, die ihn ausgelöst hat. Ausführungsprotokolle sind mit Zeitstempel versehen und unveränderlich. Freigaben laufen über rollenbasierte Workflows, sodass genehmigt, wer dazu befugt ist. Der Export erzeugt strukturierte Dokumente, die für die Lektüre durch die Aufsicht gedacht sind.
Der entscheidende Unterschied: Der Nachweis entsteht laufend, während getestet wird, und wird nicht zusammengesetzt, wenn jemand fragt. Der Betrieb ist on-premise, Aufzeichnungen bleiben also im eigenen Perimeter des Instituts, womit auch die Frage der Datenübermittlung an Dritte entfällt. Ein zeitlich begrenzter Pilot umfasst eine Anwendung und ein Framework und liefert aufsichtstaugliche Nachweise in sechs bis acht Wochen. Unsere Notizen zu KI-gestützter QA in regulierten Branchen und zu den Kosten der Softwarequalität behandeln die Argumente ringsum.
Häufige Fragen
Nachweise zur Softwarequalität und DORA
Was ist der Unterschied zwischen einem Testprogramm und einer Nachweiskette unter DORA?
Warum haben die meisten Institute eine Lücke zwischen Testen und Nachweis?
Aufsichtsanfragen und Vorfälle
Wie sieht eine Aufsichtsanfrage nach Nachweisen über Resilienztests aus?
Wie funktioniert die 4-Stunden-Uhr von DORA?
Werkzeuge und Betrieb
Wie schließt Qualigentic die Lücke in der Nachweisinfrastruktur?
Können bestehende Testwerkzeuge eine konforme Nachweiskette erzeugen?
