DORA - eine Weiterentwicklung der BAIT/VAIT?

DORA

Gerade im Beratungsumfeld für Testmanagement-Aufgaben ist es spannend mitzu-erleben, wie sich nationale, aber auch europäische Vorgaben und Anforderungen an die Finanzinstitute fortentwickeln.

Was bedeutet nun der seit Beginn dieses Jahres in Kraft getretene Digital Operational Resilience Act (kurz: DORA) z. B. für das Testmanagement von Banken und Versicherungen im Vergleich zu den bisherigen Regularien der BAIT oder VAIT?

An der Zielsetzung - Risiken zu minimieren und die Qualität der eingesetzten IT-Systeme zu sichern, um im Einklang mit den Banken- und Versicherungs-Aufsichtlichen Anforderungen zu sein, sollte sich nichts geändert haben. Es wurden jedoch weitere, relevante Aspekte durch DORA ergänzt, auf die wir teilweise eingehen werden.

Ausgangslage: BAIT/VAIT

Das Testmanagement in den Finanzinstituten (u.a. Banken und Versicherungen) konnte sich in den letzten Jahren auf die Vorgaben der Banken- und Versicherungs-aufsichtlichen Anforderungen an die IT (BAIT/ VAIT) einstellen. Aspekte der IT-Sicherheit und -Zuverlässigkeit der eingesetzten IT-Systeme, einschließlich individueller Datenverarbeitungsanwendungen (IDVen), stehen hierbei im Vordergrund.

Die bisher angestrebte BAIT / VAIT-Konformität aus Sicht eines Testmanagements beinhaltete erfahrungsgemäß folgende Kernaufgaben:

      • Festlegung einer Teststrategie und Testplanung
        • Testziele
        • Umfang und Methoden
        • Ressourcen

      • Planung und Unterstützung der Testdurchführung und Ergebnisdokumentation
        • Testfalldefinition
        • Ausführungsdokumentation
        • Erfassung von Abweichungen und Korrekturmaßnahmen
        • Erstellung von Testabschlußberichten

      • Bereitstellung einer Testumgebung
        • Dreistufiges Staging-Konzept (DEV/TEST/PROD)
        • Unabhängig von Produktivumgebung (Infrastruktur, Testdaten)

      • Planung und Unterstützung der Abnahmetests
        • Freigabe der IT-Systeme einschl. IDV (z. B. durch die Fachbereiche)

      • Planung und Unterstützung der Testautomatisierung
        • Auswahl geeigneter Tests (Regression)
        • Steigerung der Effizienz und Wiederholbarkeit von Tests

      • Planung und Unterstützung einer kontinuierlichen Testverbesserung
        • Fokussierte Testprozesse und Methoden

      • Fokussierung auf dem Risikobasierten Ansatz
        • Basierend auf Testausführungen und Fehler wesentliche Risiken ermitteln.


Dabei ist die BAIT/ VAIT nicht nur für den IT-Bereich relevant, sondern auch für die Fachbereiche, die IDV-Anwendungen nutzen, sowie auch in einer Mitverantwortung via Akzeptanz und Freigabe für die eingesetzten IT-Systeme stehen.

Neuerungen mit Einführung der DORA

Ab dem 17. Januar 2025 verpflichtet nun DORA „Digital Operational Resilience Act“ alle Finanzunternehmen ihre Informations- und Kommunikationstechnologie (IKT) auf Herz und Nieren zu prüfen, indem sie ein risikobasiertes, proportionales Testsystem auf Grundlage ihrer IKT-Geschäftsfortführungspläne (IKT-GFP) etablieren sollen.

Zu berücksichtigen sind dabei u.a. auch die Vorgaben aus Artikel 37 „Beschaffung, Entwicklung und Wartung von IKT-Systemen“ sowie Artikel 38 „IKT-Projekt- und Änderungsmanagement“.

Gemäß ergänzenden Hinweisen von BaFin vom 08.07.2024 ist die individuelle Datenverarbeitung (IDV) im RTS RMF (DORA) nur implizit enthalten. So wird keine Unterscheidung zwischen IDV und zugekauften (Standard-) Anwendungen getroffen, sondern darauf hingewiesen, dass Entwicklungen außerhalb der IT-Funktion auf Risiken hin zu überprüfen sind (Art. 16 Abs. 9 RTS RMF). Die wesentlichen aufsichtlichen Anforderungen an IDVen bleiben jedoch bestehen.

DORA legt insgesamt seinen regulatorischen Schwerpunkt auf fünf (5) wichtige Säulen:

      • Risikomanagement im Bereich der Informations- und Kommunikations-technologie (IKT)
      • Berichterstattung über sicherheitsrelevante Vorfälle
      • Zrüfung der digitalen operativen Resilienz
      • Risikomanagement für Drittparteien
      • Gemeinsame Nutzung von Informationen

dora graphics

Es stellt sich die Frage, was dies konkret für das jeweilige Testmanagement eines Finanzunternehmens bedeutet und welche Anpassungen – ausgehend vom bisherigen Testvorgehen basierend auf einer BAIT/ VAIT-Konformität – dies ggf. nach sich zieht.

Hierfür werden für das Testmanagement zwei zentrale Artikel der DORA etwas genauer beleuchtet.

Artikel 24 - Allgemeine Anforderungen für das Testen der digitalen operationalen Resilienz

1.    Finanzunternehmen müssen ihre Vorbereitung auf die Handhabung von IKT-bezogenen Vorfällen bewerten und Schwächen sowie Lücken in ihrer digitalen Resilienz identifizieren und entsprechende Korrekturmaßnahmen umgehend qualitätsgesichert umzusetzen.

2.    Es wird gefordert, dass Unternehmen ein risikobasiertes Testprogramm einrichten, um die Wirksamkeit ihrer Informations- und Kommunikationstechnologie zu überprüfen. Dafür sind Methoden, Verfahren und Tools einzusetzen, die gemäß den Artikeln 25 und 26 anzuwenden sind.

3.    Die Ergebnisse dieser Tests sollen dazu dienen, Korrekturmaßnahmen zeitnah umzusetzen, um die digitale operationale Resilienz zu verbessern.

4.    Bei der Testdurchführung ist darauf zu achten, dass Tests von unabhängigen, internen oder externen Parteien durchzuführen sind. Werden die Tests von einem internen Tester durchgeführt, stellen die Finanzunternehmen ausreichende Ressourcen bereit und tragen dafür Sorge, dass während der Konzeptions- und Durchführungsphase der Prüfung keine Interessenkonflikte entstehen.

5.    Finanzunternehmen legen Verfahren und Leitlinien zur Priorisierung, Klassifizierung und Behebung aller während der Durchführung der Tests zutage getretenen Probleme fest sowie die internen Validierungsmethoden, um sicherzustellen, dass alle ermittelten Schwächen, Mängel oder Lücken vollständig angegangen werden.

6.    Finanzunternehmen stellen sicher, dass bei allen IKT-Systemen und -Anwendungen, die kritische oder wichtige Funktionen unterstützen, mindestens einmal jährlich angemessene Tests durchgeführt werden.

7.    Für detaillierte Informationen kann der vollständige Text von Artikel 24 auf der offiziellen Webseite eingesehen werden: https://www.bafin.de/DE/Aufsicht//DORA_artikel

Artikel 25 - Testen von IKT-Tools und -Systemen

Hier werden spezifische Anforderungen an Testverfahren festgelegt, die auf die Erkennung von Schwachstellen und die Stärkung der Widerstandsfähigkeit von IT-Systemen abzielen.

Das digitale Resilienz-Testprogramm muss angemessene Tests wie Schwachstellen-Bewertungen, Open-Source-Analysen und Netzwerksicherheits-Bewertungen umfassen, um die operationale Resilienz zu gewährleisten.

Wer ist vom DORA-Regelwerk betroffen?

dora graphics

DORA-Vorschriften gelten für Finanzunternehmen und IKT-Dienstleister, bei denen es sich nicht um Kleinstunternehmen handelt.

Dokumentation von Tests für den IKT-GFP

Der IKT-Geschäftsfortführungsplan (IKT-GFP) ist das Herzstück der digitalen Resilienz-Strategie. Mit Art. 25 Abs. 5 der Delegierten Verordnung (EU) 2024/1774 (RTS RMF) verpflichten sich Finanzunternehmen, sämtliche Testergebnisse systematisch zu dokumentieren, Schwachstellen zu analysieren und dem Leitungsorgan zu berichten.

Vorschlag zum Umfang der Dokumentation

Dokumentationspflicht

Inhalt lt. DORA-Richtlinie

Testfälle

Grundlage der Testfall-Beschreibung ist die Dokumentation (Anforderungen) eines jeweiligen IKT-Systems und die in Artikel 37 Ziffer b) sowie Artikel 38 Absatz 2 geforderten QS-Maßnahmen

Testszenarien

Weitere, übergreifende Tests (zur Abbildung der IKT-GFP) leiten sich aus der IT-Strategie und der operationellen Abhängigkeit zwischen den einzelnen IKT-Systemen sowie der Organisation des IKT-Risikomanagements ab

Testergebnisse

Alle Ergebnisse der regelmäßigen GFP-Tests (gem. Art. 25 Abs.1)

Schwachstellen

Identifizierte Lücken, Fehler oder Unwirksamkeiten im Plan

Analysemaßnahmen

Ursachenanalyse, Risikobewertung, Folgenabschätzung

Behebungsmaßnahmen

Konkrete technische und organisatorische Verbesserungen

Bericht an Leitung

Weiterleitung der Analyse- und Behebungsmaßnahmen an das Leitungsgremium zur Genehmigung und Steuerung.

 

Warum ist diese Dokumentation notwendig

Eine lückenlose Testdokumentation ist kein formaler Selbstzweck, sondern dient:

      • der fundierten Qualitätssicherung aller (wesentlichen) IKT-Systeme und IDVen, die die Basis für den GFP bilden
      • der Sicherstellung der Wirksamkeit des IKT-GFPs
      • der Ableitung gezielter Verbesserungsmaßnahmen
      • der Haftungsvermeidung auf Leitungsebene
      • der Vorbereitung auf DORA-Aufsichtsprüfungen.


Eine fehlende oder unvollständige Dokumentation ist ein direkter DORA-Compliance-Verstoß.

Fazit

Folglich liegt das Erstellen, Testen und Überwachen von Geschäftsfortführungsplänen durchaus in der Verantwortung mehrerer Bereiche, z. B. IT-Bereiche, Test- und Risiko-Management.

Auch wenn sich das DORA-Regelwerk recht umfangreich und weiter als bisher gefasst darstellt, in Anbetracht des zunehmend komplexeren Einsatzes von IT-Systemen mit Bildung umfassender Netzwerke, sind die Herausforderungen von Cyber-Sicherheit für Unternehmen und deren Kunden immens. Deshalb ist die „Digitale Resilienz“ kein „Luxus“, sondern stellt ein verantwortungsbewusstes Handeln dar.

Es ist wichtig hervorzuheben, dass die zuvor genannten Hinweise nicht nur vom Testmanagement zu beherzigen sind, sondern die DORA-Regularien in einer Gesamtverantwortung eines jeweiligen Unternehmens zu sehen sind.

Weiterführende Umsetzungstipps und praktische Hinweise sind bereits in Arbeit und können zeitnah zur Verfügung gestellt werden.

Autoren des Blogs: Michael Kister und Matthias Wolf

Kontakt aufnehmen

Michael Kister und Matthias Wolf zeigen, wie Software-Qualitätssicherung (SQA) Finanz- und Versicherungsunternehmen dabei unterstützt, DORA-Compliance zu erreichen – anhand risikobasierter Teststrategien, durchgängiger Dokumentation und widerstandsfähiger ICT-Business-Continuity-Pläne. Weniger Risiko, mehr Vertrauen.

Bleiben Sie compliant und resilient! (Link einfügen)

Für die englische Version klicken Sie hier 

1 (1)-1

Michael Kister

Consultant

Contact

MWO-2a

Matthias Wolf

Consultant

Contact