Einleitung
Wer heute in Banken über Testmanagement spricht, landet schnell bei Testfällen, Fehlerprotokollen und Release-Abnahmen. Das war lange Zeit ausreichend – Testteams sorgten dafür, dass Software funktioniert, bevor sie produktiv ging. Punkt. Mit dem Digital Operational Resilience Act (DORA) hat sich dieses Verständnis fundamental verändert. Testing ist längst keine rein operative Funktion mehr, die irgendwo im Projektplan auftaucht. Es wird zur Governance-Aufgabe – eng verzahnt mit Risikomanagement, Compliance und der Frage, wie widerstandsfähig eine Bank wirklich ist, wenn es darauf ankommt.
Unter DORA geht es nicht mehr nur darum, ob ein System fehlerfrei läuft. Die entscheidende Frage ist:
Kann eine Bank nachweisbar belegen, dass ihre kritischen digitalen Services systematisch getestet, gesteuert und überwacht werden?
Das ist der Kern dessen, was wir als Test Governance bezeichnen.
Warum DORA Testing neu definiert
DORA verpflichtet Finanzinstitute zu einem strukturierten Programm für das Testen der digitalen operationalen Resilienz¹.
Konkret betrifft das:
- Kritische ICT-Services und deren Verfügbarkeit
- Geschäftsprozesse mit Systemabhängigkeiten
- Drittanbieter als potenzielle Risikofaktoren
- Störfall- und Wiederherstellungsszenarien
Viele Banken reagieren darauf zunächst mit mehr Tests, mehr Automatisierung, mehr Coverage. Das ist nachvollziehbar – trifft aber nicht den Kern von DORA.
Die entscheidende Frage lautet nicht:
„Wie viele Tests haben wir durchgeführt?“
Sondern:
„Wie wird Testing gesteuert, priorisiert und in das Risikomanagement integriert?“
DORA verändert damit auch die Rolle einzelner Testartefakte: Testfälle selbst werden zu einem regulatorischen Nachweis digitaler Resilienz.
Wie sich ihre Bedeutung unter DORA verändert, habe ich in einem separaten Beitrag ausführlich beschrieben – Warum Testfälle unter DORA regulatorisch relevant werden
Test Governance statt Testfabrik
Klassische Testorganisationen sind auf Effizienz ausgelegt. Testfälle erstellen, Tests koordinieren, Fehler dokumentieren, Releases absichern, weil das ihr Kerngeschäft ist und auch wichtig bleibt.
Aber diese operative Perspektive reicht unter DORA nicht mehr aus. Was fehlt, ist die strategische und regulatorische Dimension.
Test Governance ergänzt das klassische Testmanagement um genau das:
- Eine klare Test Policy, die unternehmensweiten Prinzipien definiert
- Eine übergreifende Test Strategy, die Risiken, Prozesse und regulatorische Anforderungen verbindet
- Risk Based Testing, das Ressourcen dort konzentriert, wo der Schaden am größten wäre
- Strukturierte Test Governance Prozesse, die nachvollziehbar und auditierbar sind
- Belastbare Evidence für Prüfer und Aufsichtsbehörden
Testing wird damit zu einem echten Instrument der Steuerung digitaler Resilienz und nicht länger nur ein Qualitätsfilter am Ende eines Projekts.
Die Rolle einer Test Policy
Eine Test Policy ist mehr als ein internes Regelwerk. Sie ist das Fundament jeder Test Governance und der erste Schritt, den Banken gehen müssen, die DORA ernst nehmen.
Sie definiert die grundsätzlichen Prinzipien und Verantwortlichkeiten im Testing. Im DORA-Kontext sollte eine Test Policy klare Antworten auf folgende Fragen liefern:
- Welche Ziele verfolgt Testing im Kontext von Operational Resilience?
- Wer trägt Verantwortung für Test Governance und auf welcher Ebene?
- Welche Standards gelten speziell für kritische ICT-Services?
- Wie wird sichergestellt, dass Testergebnisse prüfbar dokumentiert und abrufbar sind?
Eine gut formulierte Test Policy sorgt dafür, dass Testing nicht mehr projektbezogen und fragmentiert passiert, sondern unternehmensweit einheitlichen Governance-Prinzipien folgt. Das ist der Unterschied zwischen einem gut geführten Testteam und einer regulatorisch tragfähigen Testorganisation.
Test Strategy als Steuerungsinstrument
Während die Test Policy die Leitplanken setzt, zeigt die Test Strategy, wie Testing in der Praxis funktioniert. Sie verbindet Geschäftsprozesse, ICT-Services, Risiken, regulatorische Anforderungen und macht daraus eine handlungsfähige Logik.
Eine moderne, DORA-konforme Test Strategy enthält typischerweise:
- Eine klare Priorisierung von Tests nach Business Criticality
- Definition von Teststufen und Testarten, angefangen von Unit-Tests bis hin zu Resilience-Tests
- Explizite Integration von Resilience-Tests für Ausfall- und Wiederherstellungsszenarien
- Governance-Strukturen, die Testentscheidungen transparent und nachvollziehbar machen
- Direkte Verknüpfung von Tests mit Risiko- und Kontrollframeworks
Eine solche Strategie stellt sicher, dass Testing nicht isoliert in Projekten stattfindet, sondern Teil einer übergeordneten Resilienzstrategie ist. Das ist der Übergang von reaktivem Testen zu echter digitaler Governance.
Risk Based Testing im Zentrum von DORA
Nicht jedes System ist gleich kritisch. Diese einfache Erkenntnis ist der Ausgangspunkt für Risk Based Testing und gleichzeitig einer der zentralen Bausteine moderner Test Governance.
Im DORA-Kontext bedeutet dieser Ansatz konkret:
- Identifikation der kritischsten Business Services und der dahinterliegenden ICT-Abhängigkeiten
- Systematische Bewertung von Risiken und potenziellen Auswirkungen bei Ausfällen
- Priorisierung von Tests dort, wo Schadensausmaß und Eintrittswahrscheinlichkeit am höchsten sind
- Nachvollziehbare Dokumentation der Priorisierungsentscheidungen für Audits
Risk Based Testing macht Testing nicht nur effizienter, es macht es auch argumentierbar gegenüber Prüfern, gegenüber Aufsichtsbehörden, gegenüber dem eigenen Vorstand. Auch die Bundesanstalt für Finanzdienstleistungsaufsicht betont, dass Finanzinstitute ein risikobasiertes Testprogramm etablieren müssen².
Der Left-Shift-Ansatz in der Test Governance
Resilienz entsteht nicht im Testlabor. Sie entsteht im Design von Systemen und Prozessen. Genau das ist der Grundgedanke hinter dem Left-Shift-Ansatz.
Statt Testing erst am Ende eines Entwicklungszyklus anzusetzen, wird es frühzeitig integriert, und zwar in Anforderungsdefinitionen, Architekturentscheidungen und Sprint-Planungen. Für Banken unter DORA hat das eine besondere Relevanz: Wer Resilienz erst beim Testen prüft, ist zu spät dran.
Left Shift in der Praxis bedeutet:
- Test Governance wird frühzeitig in Projekte eingebunden, nicht erst am Ende
- Qualitäts- und Resilienzanforderungen fließen direkt in User Stories und Architekturentscheidungen ein
- Automatisierte Tests sind fester Bestandteil von CI/CD Pipelines und nicht als optionales Add-on zu sehen
- Risiken werden kontinuierlich gemonitort, nicht nur punktuell geprüft
Durch diese frühzeitige Verankerung wird Testing zu einem integralen Bestandteil der digitalen Governance-Struktur und nicht länger zum lästigen Flaschenhals kurz vor dem Go-live.
Evidence – der oft unterschätzte Erfolgsfaktor
Wer gut testet und das nicht beweisen kann, hat für DORA ein Problem. Das klingt banal – ist aber in der Praxis einer der häufigsten Stolpersteine.
Regulatorische Prüfungen konzentrieren sich nicht primär auf Konzepte oder Absichtserklärungen. Sie suchen nach nachvollziehbaren Nachweisen. Konkret:
- Dokumentierte Teststrategien und Test Policies
- Risikoanalysen mit klaren Priorisierungsentscheidungen
- Testpläne und Testberichte, die auch für Externe verständlich sind
- Nachweise über durchgeführte Tests und das vollständig und lückenlos
- Dokumentation von Schwachstellen und Maßnahmen zu ihrer Behebung
Eine reife Test Governance sorgt dafür, dass diese Evidence nicht kurz vor dem Audit zusammengestellt wird, sondern kontinuierlich und automatisiert entsteht. Das ist der Unterschied zwischen einem Betrieb, der auf Prüfungen reagiert und einem, der immer bereit ist.
Die Bedeutung von Evidence im Kontext von DORA habe ich bereits in einem separaten Beitrag erläuter – Warum DORA an fehlender Evidence scheitert
Fazit
DORA verändert Testing grundlegend.
Testing wird:
- Governance-Thema
- Management-Thema
- regulatorischer Nachweis
Die Antwort darauf ist Test Governance.
Banken, die diesen Schritt gehen, schaffen nicht nur Compliance, sie schaffen Steuerbarkeit, Transparenz und Resilienz.
Testing als Governance-Funktion ist die Zukunft.
Referenzen
¹ Verordnung (EU) 2022/2554 – Digital Operational Resilience Act (DORA), Art. 23–27 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554
² Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) Testen der digitalen operationalen Resilienz https://www.bafin.de/DE/Aufsicht/DORA/Digitale_Resilienz_TLPT/Digitale_Resilienz_TLPT_node.html