DORA Kapitel IV / Methodik
Testprogramm der digitalen Resilienz.
Risikobasiertes Testprogramm nach DORA Art. 24/25: Systematische Prüfung der digitalen operationalen Resilienz durch abgestimmte Testklassen, priorisierte Testarten und ein mehrjähriges, rollierendes Testkalender-System.
Management-Zusammenfassung
- Risikobasiertes Testprogramm nach DORA Art. 24/25 mit drei Testklassen: regulär, prozessgetrieben und risikoorientiert.
- Governance-Struktur mit Resilience Board, CISO und Test-Koordinator für die Steuerung des Testprogramms.
- 12 operative Testtypen mit festgelegter Frequenz, Umgebung und Verantwortlichkeit — gesteuert durch ein 10-Faktor-Scoring-Modell (max. 295 Punkte).
- Grundschutz-Validierung (GSV) und Periodischer Resilienz-Test (PRT) bilden das Mindestprüfprogramm für alle IKT-Assets.
- Betriebsart-Logik (intern/gemischt/ausgelagert) bestimmt Testausführung und Nachweisform.
Governance & Resilience Board
Das Resilience Board plant jährlich die risikoorientierten Tests für das Folgejahr, überprüft die Umsetzung des Vorjahres, entscheidet über Anpassungen bei geänderter IKT-Risikolage und fungiert als Eskalationsinstanz bei Testverschiebungen und Testausfällen.
Resilience Board
Das Resilience Board plant jährlich die risikoorientierten Tests für das Folgejahr, überprüft die Umsetzung des Vorjahres, entscheidet über Anpassungen bei geänderter IKT-Risikolage und fungiert als Eskalationsinstanz bei Testverschiebungen und Testausfällen.
- Jährliche Planung der risikoorientierten Tests für das Folgejahr auf Basis der IKT-Risikolage
- Überprüfung der Umsetzung und Wirksamkeit der Tests des Vorjahres
- Entscheidung über Anpassungen des Testportfolios bei geänderter IKT-Risikolage
IKT-Risikocontrollfunktion
Die IKT-Risikocontrollfunktion überwacht und bewertet die IKT-Risiken im Zusammenhang mit den Resilienztests und stellt die Einhaltung der DORA-Anforderungen sicher.
- Risikobewertung der Testergebnisse und Identifikation von Risikotrends
- Überwachung der Einhaltung von DORA-Anforderungen an das Testmanagement
- Bewertung der Risikoorientierung des Testportfolios
IT-Leitung
Die IT-Leitung ist verantwortlich für die operative Umsetzung der geplanten Resilienztests und die Bereitstellung der erforderlichen technischen Ressourcen und Umgebungen.
- Sicherstellung der technischen Durchführbarkeit der geplanten Tests
- Bereitstellung von Testumgebungen und technischen Ressourcen
- Koordination der IT-internen Testdurchführung
Drittdienstleister-Risikobeauftragter
Der Drittdienstleister-Risikobeauftragte bewertet und überwacht die Risiken aus der Einbindung externer Dienstleister bei der Durchführung von Resilienztests.
- Bewertung der Eignung externer Testdienstleister
- Überwachung der Einhaltung von Vertraulichkeits- und Datenschutzanforderungen
- Prüfung von Zertifizierungen und Qualifikationen externer Tester
BCM-Beauftragter
Der BCM-Beauftragte stellt die Integration von Business Continuity Management und IT-Service-Continuity-Anforderungen in die Resilienztests sicher.
- Sicherstellung der BCM/ITSCM-Relevanz der geplanten Tests
- Bewertung von Testergebnissen auf BCM/ITSCM-Auswirkungen
- Koordination szenariobasierter Resilienztests
Kommunikationsfunktion
Die Kommunikationsfunktion stellt die Transparenz des Resilienz-Testportfolios gemäß Art. 25 DORA sicher und kommuniziert Ergebnisse an relevante Stakeholder.
- Erstellung und Veröffentlichung von Statusberichten zum Testportfolio
- Kommunikation von Testergebnissen an relevante Stakeholder
- Sicherstellung der Transparenz gemäß Art. 25 DORA
Verantwortlicher für kritische Funktionen
Der Verantwortliche für kritische Funktionen stellt sicher, dass die seinen kritischen IKT-Funktionen zugeordneten Resilienztests durchgeführt und die Ergebnisse bewertet werden.
- Identifikation und Meldung kritischer IKT-Funktionen für das Testportfolio
- Bereitstellung von Fachwissen für die Testfallerstellung
- Bewertung der Testergebnisse aus Fachbereichsperspektive
Test Owner
Der Test Owner ist verantwortlich für die vollständige Planung, Durchführung, Dokumentation und den Abschluss eines zugewiesenen Resilienztests gemäß DORA-Anforderungen.
- Erstellung der Testplanung inkl. Umfang, Methode und Zeitplan
- Koordination der Testdurchführung mit allen Beteiligten
- Sicherstellung der vollständigen Testdokumentation
Evidence Owner
Der Evidence Owner ist verantwortlich für die fristgerechte Bereitstellung und Qualitätssicherung der für einen Resilienztest erforderlichen Nachweise.
- Fristgerechte Bereitstellung angeforderten Testnachweise
- Qualitätssicherung der bereitgestellten Nachweise
- Sicherstellung der Vollständigkeit der Nachweise gemäß Testplan
Finding Owner
Der Finding Owner ist verantwortlich für die Bearbeitung, Behebung und Nachverfolgung eines identifizierten Befundes aus einem Resilienztest.
- Analyse und Bewertung des zugewiesenen Befundes
- Erstellung eines Maßnahmenplans zur Befundbehebung
- Umsetzung der erforderlichen Korrekturmaßnahmen
Management Reviewer
Der Management Reviewer führt die unabhängige Management-Review der Testdurchführung und der Ergebnisse durch und bestätigt die Angemessenheit und Wirksamkeit der Resilienzmaßnahmen.
- Unabhängige Prüfung der Testdurchführung und -ergebnisse
- Bewertung der Angemessenheit von Korrekturmaßnahmen
- Bestätigung der Wirksamkeit von Resilienzmaßnahmen
Testklassen
Drei Testklassen strukturieren das Testprogramm nach Art und Auslöser der Tests.
Reguläre Tests
Zyklisch geplante Tests, die regelmäßig durchgeführt oder deren Nachweise regelmäßig angefordert werden. Diese Tests folgen einem festen Turnus und werden unabhängig von konkreten Anlässen im Rahmen des jährlichen Testplans durchgeführt.
Prozessgetriebene Tests
Tests, die durch Entwicklungs-, Change-, Release-, Beschaffungs- oder Softwareprozesse ausgelöst werden. Diese Tests sind an den Lebenszyklus von IKT-Systemen und -Dienstleistungen gekoppelt und werden bei relevanten Prozessereignissen angestoßen.
Risikoorientierte Tests
Tests, deren Umfang, Tiefe und Frequenz risikoorientiert durch das Resilience Board festgelegt werden. Diese Tests basieren auf der aktuellen IKT-Risikolage und werden individuell geplant und priorisiert.
12 Testtypen im Detail
Alle operativen Testtypen mit Klasse, Frequenz und Umfang.
Vulnerability Assessment & Scan
Identifikation von Schwachstellen in IKT-Systemen durch automatisierte Scans und manuelle Validierung zur proaktiven Risikominderung.
Open Source & Exposure Analysis
Analyse von Open-Source-Komponenten und externer Angriffsfläche zur Identifikation von bekannten Schwachstellen und Fehlkonfigurationen.
Network Security Assessment
Bewertung der Netzwerksicherheit einschließlich Firewall-Konfigurationen, Segmentierung und Zugriffskontrollen.
Gap Analysis & Control Review
Vergleich bestehender Kontrollen mit regulatorischen Anforderungen und Best Practices zur Identifikation von Lücken und Verbesserungsbedarf.
Physical & Environmental Security Review
Bewertung der physischen Sicherheit von Rechenzentren, Bürogebäuden und kritischen Infrastruktureinrichtungen.
Questionnaire & Control Self-Assessment
Standardisierte Fragebögen und Selbstbewertungen zur Erfassung des Controllestatus und der Risikowahrnehmung durch Fachbereiche.
Source Code & Configuration Review
Manuelle Überprüfung von Quellcode und Systemkonfigurationen auf Sicherheitslücken, Qualitätsmängel und Abweichungen von Standards.
Scenario-Based Resilience Test
Simulation von Geschäftsunterbrechungsszenarien und Krisenmanagementübungen zur Validierung von Notfallplänen und Wiederherstellungsfähigkeiten.
Compatibility & Change Resilience Test
Testen der Kompatibilität und Widerstandsfähigkeit gegenüber Änderungen, Updates und Migrationen in IKT-Umgebungen.
Performance, Capacity & Availability Test
Belastungstests zur Validierung von Leistungsfähigkeit, Kapazitätsgrenzen und Verfügbarkeitszusagen unter verschiedener Last.
End-to-End Process & Service Test
Ganzheitliche Tests von Geschäftsprozessen und Dienstleistungen über alle Systemkomponenten hinweg zur Validierung der Gesamtfunktionalität.
Penetration Test & Adversarial Simulation
Simulierte Angriffe durch externe Red Teams zur Identifikation von ausnutzbaren Schwachstellen und Validierung der Verteidigungskräfte.
Scoring-Modell
Risikobasiertes Scoring-Modell zur Bestimmung der Testpriorität von IKT-Assets. Maximale Punktzahl: 295.
Schutzbedarfsfaktor
15 Pkt.Höchster Schutzbedarfswert aus Verfügbarkeit, Vertraulichkeit, Integrität, Nachvollziehbarkeit
Logik: Score = Faktor * 15
kwF-Unterstützungsfaktor
20 Pkt.Asset unterstützt kritische oder wichtige Funktion
Logik: ja = +20, nein = +0
Altsystemfaktor
20 Pkt.IKT-Asset ist ein Altsystem ohne Hersteller-Support
Logik: ja = +20, nein = +0
Expositionsfaktor
20 Pkt.Asset hat externen Zugriff oder Internetexposition
Logik: ja = +20, nein = +0
Vorfallfaktor
40 Pkt.Relevanter IKT-Vorfall im Betrachtungszeitraum
Logik: ja = +40, nein = +0
Überfälligkeitsfaktor
30 Pkt.Testüberfälligkeit für das Asset
Logik: ja = +30, nein = +0
Drittparteienfaktor
25 Pkt.Asset wird durch externen Dienstleister betrieben
Logik: vollständig ausgelagert = +25, teilweise ausgelagert = +15, eigener Betrieb = +0
Risikoprofilfaktor
35 Pkt.Aktuelles Risikoprofil des IKT-Assets
Logik: kritisch = +35, erhöht = +20, normal = +0
Major-Change-Faktor
25 Pkt.Wesentliche Änderung an Architektur, Technologie oder Betriebsmodell
Logik: ja = +25, nein = +0
Offene-Findings-Faktor
20 Pkt.Offene Feststellungen mit hohem oder kritischem Risiko
Logik: ja = +20, nein = +0
Höchste Testpriorität – jährliches Testpaket erforderlich
Score >= 100Erhöhte Testpriorität – 2-Jahres-Testpaket erforderlich
Score >= 60 und < 100Standard-Testpriorität – 3-Jahres-Test erforderlich
Score >= 20 und < 60Niedrige Testpriorität – keine regelmäßige Testaktivität erforderlich
Score < 20 oder AusnahmeregelungDiese Score-Schwellenwerte sind initiale Defaults und müssen institutsspezifisch kalibriert werden. Die Score-Berechnung ist eine Entscheidungshilfe und ersetzt keine risikobasierte Fachentscheidung durch das Resilience Board.
Grundschutz-Validierung (GSV)
Nachweis, dass für besonders relevante IKT-Assets laufende technische Basissicherheitskontrollen bestehen
kwF-Unterstützung ja UND relevante technische Exposition
Quartalsweise Nachweisanforderung über durchgeführte wöchentliche Schwachstellenscans sowie Status kritischer Schwachstellen. Bei ausgelagertem Betrieb: Dienstleisterbericht anfordern.
Keine kwF-Unterstützung
GSV nicht erforderlich, außer risikobasiert durch Resilience Board anders entschieden.
Ausnahmeregelung
GSV nicht erforderlich mit dokumentierter Begründung und Freigabe durch Resilience Board.
Periodischer Resilienz-Test (PRT)
Mehrjährige risikoorientierte Testabdeckung aller relevanten IKT-Assets
Priorität 1 (Score >= 100)
Jährliches Testpaket: Penetrationstest oder Adversarial Simulation (risikobasiert), Schwachstellenscan, Gap Analysis, Management Review.
Priorität 2 (Score >= 60 und < 100)
Alle 2 Jahre Testpaket: Penetrationstest oder Schwachstellenscan, Gap Analysis oder Fragebogen/Software Scan. Bei Dienstleisterbetrieb: Nachweisanforderung.
Priorität 3 (Score >= 20 und < 60)
3-Jahres-Regel: Mindestens Schwachstellenscan oder Gap Analysis oder Self Assessment.
Priorität 4 (Score < 20 oder Ausnahmeregelung)
Keine regelmäßige Testaktivität erforderlich. Eventbasiert bei Major Change, IKT-Vorfall oder Risikoänderung.
Betriebsmodell-Logik
Die Betriebsart eines IKT-Assets bestimmt, ob Tests intern durchgeführt oder Nachweise extern eingeholt werden müssen.
Vollständig eigener Betrieb
Interne Durchführung möglich, interne Evidence, interne Findings, interne Retests
Teilweise ausgelagerter Betrieb
Kombination aus interner Durchführung und Dienstleister-Nachweis. Dienstleisterberichte erforderlich. Verantwortlichkeitsmatrix erforderlich.
Vollständig ausgelagerter Betrieb
Nachweisanforderung an Dienstleister. Bewertung der eingereichten Nachweise und Maßnahmenverfolgung durch Institut. Keine eigenen Tests.
Testumgebungen
Verschiedene Umgebungstypen für die Durchführung von Resilienztests mit spezifischen Risikoprofilen.
Produktivumgebung
Live-Umgebung mit Echtzeitdaten und -transaktionen. Geeignet für aussagekräftige Sicherheitstests, aber mit höchsten Anforderungen an Risikominimierung und Vorbereitung.
Geeignet für: VAS, NSA, PTAS
Testumgebung
Isolierte Umgebung mit replizierten Produktivdaten und -konfigurationen. Bietet sichere Bedingungen für tiefgehende Tests ohne Risiko für die Produktion.
Geeignet für: OSEA, SCCR, CCRT, PCAT, EEPST
Gemischte Umgebung
Kombination aus Produktiv- und Testumgebungen, oft bei szenariobasierten oder End-to-End-Tests erforderlich, bei denen reale Abhängigkeiten abgebildet werden müssen.
Geeignet für: SBRT, PTAS
Dokumentenprüfung
Keine technische Testumgebung erforderlich. Prüfung erfolgt auf Basis von Dokumenten, Fragebögen und Nachweisen.
Geeignet für: GACR, QCSA
Dienstleisterumgebung
Tests, die in der Umgebung oder beim Standort eines IKT-Dienstleisters durchgeführt werden. Erfordert vertragliche Regelung und Zugriffsrechte.
Geeignet für: PESR
Testkalender
Der Testkalender steuert die zeitliche Planung aller Resilienztests auf Basis der Prioritätseinstufung und der Betriebsart eines IKT-Assets.
Höchste Testpriorität – jährliches Testpaket erforderlich
>= 100Erhöhte Testpriorität – 2-Jahres-Testpaket erforderlich
>= 60 und < 100Standard-Testpriorität – 3-Jahres-Test erforderlich
>= 20 und < 60Niedrige Testpriorität – keine regelmäßige Testaktivität erforderlich
< 20 oder AusnahmeregelungZykluslogik
- P1 (jährlich): Assets mit Score ≥ 85 erhalten jährlich ein vollständiges Testpaket (Penetrationstest, Schwachstellenscan, Gap Analysis, Management Review).
- P2 (2-Jahres-Zyklus): Assets mit Score 50–84 werden alle 2 Jahre getestet (Penetrationstest oder Scan + Gap Analysis).
- P3 (3-Jahres-Zyklus): Assets mit Score 15–49 erhalten mindestens einen Schwachstellenscan oder Gap Analysis alle 3 Jahre.
- P4 (eventbasiert): Assets mit Score < 15 haben keine reguläre Testpflicht, werden aber bei Major Changes, Vorfällen oder Risikoänderungen ad-hoc getestet.
Ergebnisanalyse & Reporting
Testergebnisse werden systematisch erfasst, bewertet und für das Management aufbereitet.
Finding-Klassifizierung
- Kritisch: Unmittelbare Gefährdung, sofortige Maßnahmen erforderlich
- Hoch: Signifikantes Risiko, kurzfristige Behebung erforderlich
- Mittel: Moderates Risiko, planmäßige Behebung
- Niedrig: Geringes Risiko, optionale Optimierung
Reporting-Pflichten
- Testergebnisse unverzüglich dem Management berichten (Art. 24 Abs. 4)
- Jährlicher Testplan-Status an das Resilience Board
- Prüffeststellungen und Maßnahmen nachhalten
- Testportfolio-Transparenz gemäß Art. 25 DORA
Risikobehandlung
Aus Testergebnissen abgeleitete Risiken werden nach festgelegten Behandlungsoptionen adressiert.
Vermeidung
Risikoquelle wird beseitigt, z. B. durch Abschaltung nicht benötigter Dienste oder Systeme.
Verminderung
Risiko wird durch technische oder organisatorische Maßnahmen reduziert (Patches, Härtung).
Risikotransfer
Risiko wird auf Dritte übertragen, z. B. durch Versicherung oder vertragliche Regelungen.
Akzeptanz
Risiko wird nach dokumentierter Entscheidung durch das Resilience Board bewusst getragen.
Eventbasierte Trigger & Maßnahmen
Major Change
Wesentliche Änderung an Architektur, Technologie oder Betriebsmodell
Risikobasierte Testentscheidung durch Resilience Board innerhalb von 30 Tagen
IKT-Vorfall
Relevanter Sicherheitsvorfall mit Bezug zum Asset
Ad-hoc Test und Retest-Review der bestehenden Testabdeckung
Kritischer Finding
Offener Finding mit hohem oder kritischem Risiko
Nachtest nach Remediation innerhalb von 90 Tagen
Neuer kritischer Dienstleister
Aufnahme eines neuen Dienstleisters mit kwF-Unterstützung
Einholung von Dienstleister-Nachweisen innerhalb von 90 Tagen
Neue kwF-Unterstützung
Asset erhält neue Klassifizierung als kritische oder wichtige Funktion
Vollständige Testneubewertung innerhalb von 60 Tagen
Regulatory Radar Signal
Aufsichtliche Ankündigung, Prüfungsfeststellung oder neue gesetzliche Anforderung
Risikobewertung und Testanpassung durch Resilience Board
Offene Findings
Kritische oder hohe Findings aus vorherigem Test
Nachtest nach Remediation innerhalb von 90 Tagen; Resilience Board über Status informieren
Dienstleister-Nachweis überfällig
Ausgelagertes Asset: fälliger Nachweis wurde nicht fristgerecht eingereicht
Vertraglich festgelegte Nachweispflicht durchsetzen; Eskalation an Resilience Board; Retest-Deadline setzen
Kritisches Risikoprofil
Aktuelles Risikoprofil des Assets wurde auf kritisch eingestuft
Sofortige Risikobewertung; Testneubewertung innerhalb von 14 Tagen; Resilience Board informieren
Quellen & Prüfungsstatus
Diese Inhalte sind Umsetzungshilfen und ersetzen keine Rechtsberatung oder verbindliche aufsichtsrechtliche Auslegung. Für verbindliche Anforderungen sind die offiziellen Quellen maßgeblich.
Prüfungsstatus: Alle Inhalte befinden sich im Status "reviewed". Die dargestellten Score-Schwellenwerte, Regelvorschläge und Prozesse sind initiale Defaults und müssen institutsspezifisch kalibriert sowie durch das Resilience Board freigegeben werden.