DORA Kapitel IV · operative Testplanung

DORA-Testkalender

Arbeitsstruktur für ein risikobasiertes, nachweisfähiges Programm zum Testen der digitalen operationalen Resilienz.

Arbeitsmodus

Diese öffentliche Seite erläutert die Planungslogik. Verbindliche Termine, Verantwortlichkeiten und Nachweise werden mandantenbezogen im Testing Portal geführt.

Zum geschützten Arbeitsraum Testprogramm

Management-Zusammenfassung

DORA verlangt ein solides, umfassendes und risikobasiertes Programm zum Testen der digitalen operationalen Resilienz.
Alle IKT-Systeme und -Anwendungen, die kritische oder wichtige Funktionen unterstützen, sind mindestens jährlich angemessen zu testen.
Art. 25 Abs. 1 nennt zwölf mögliche Testverfahren; Auswahl, Tiefe und Frequenz folgen dem Risikoprofil.
Interne Prioritätsklassen oder kürzere Zyklen sind Steuerungsentscheidungen des Instituts und keine unmittelbar aus DORA abgeleiteten Pauschalfristen.

Planungsgrundlage

Regulatorische Mindestanker

Arbeitsstrom	Rechtsanker	Verantwortung	Planungsregel
Testprogramm	Art. 24 Abs. 1 und 2	IKT-Risikomanagement	laufend pflegen und risikobasiert überprüfen
Systeme für kritische oder wichtige Funktionen	Art. 24 Abs. 3	Service- und Funktionsverantwortliche	mindestens jährlich angemessen testen
TLPT	Art. 26	TLPT-Control-Team	für bestimmte Institute grundsätzlich alle 3 Jahre
Ereignisbasierte Neubewertung	Risikobasierte Programmsteuerung	Testprogramm-Verantwortliche	bei wesentlicher Änderung, Vorfall oder relevantem Finding
Findings und Retests	Art. 24 Abs. 5	Finding Owner	frist- und risikogesteuert

DORA Art. 25 Abs. 1

Zwölf Testverfahren für den risikobasierten Testmix

Die Aufzählung ist kein pauschaler Pflichtkatalog je Asset. Das Institut dokumentiert Auswahl und Nichtauswahl nachvollziehbar.

Schwachstellenbewertungen und -scans

Evidence: Scope, Scanbericht, validierte Befunde, Maßnahmen und Retest

Open-Source-Analysen

Evidence: Quellen, Suchumfang, Bewertung und dokumentierte Folgemaßnahmen

Netzwerksicherheitsbewertungen

Evidence: Netzplan, Prüfparameter, Ergebnisse und Freigabe

Lückenanalysen

Evidence: Soll-Ist-Kriterien, Abweichungen, Verantwortliche und Fristen

Überprüfungen der physischen Sicherheit

Evidence: Prüfobjekte, Feststellungen, Maßnahmen und Nachprüfung

Fragebögen und Software-Scanning-Lösungen

Evidence: Fragebogenstand, Plausibilisierung, Scanexport und Bewertung

Quellcodeprüfungen, soweit durchführbar

Evidence: Repository-Scope, Methode, Befunde und Remediation-Nachweis

Szenariobasierte Tests

Evidence: Szenario, Annahmen, Teilnehmer, Beobachtungen und Lessons Learned

Kompatibilitätstests

Evidence: Komponentenmatrix, Testfälle, Ergebnisse und Abweichungen

Leistungstests

Evidence: Lastprofil, Grenzwerte, Messdaten und Bewertung

End-to-End-Tests

Evidence: Prozesskette, abhängige Systeme, Ergebnis und Restrestrisiken

Penetrationstests

Evidence: Rules of Engagement, Bericht, Findings, Maßnahmen und Retest

End-to-End-Workflow

Fünf Gates bis zum geschlossenen Nachweis

Gate 1

Scope festlegen

Kritische oder wichtige Funktionen, unterstützende IKT-Systeme, Prozesse, Daten und Drittdienstleister vollständig zuordnen.

Gate 2

Risiko bewerten

Kritikalität, Bedrohungslage, Änderungen, Vorfälle, offene Findings und letzte Testergebnisse nachvollziehbar bewerten.

Gate 3

Testmix bestimmen

Geeignete Verfahren aus Art. 25 Abs. 1 auswählen; Frequenz und Tiefe proportional und institutsspezifisch begründen.

Gate 4

Durchführung steuern

Owner, unabhängige Durchführung, Termin, Abhängigkeiten, Dienstleisterbeiträge und Abnahmekriterien festlegen.

Gate 5

Evidence schließen

Ergebnisse, Findings, Maßnahmen, Retests, Risikoakzeptanzen und Management-Entscheidungen revisionsfähig verknüpfen.

Datenqualität

Mindestdaten eines belastbaren Kalendereintrags

Ein Termin allein ist kein steuerungsfähiger Testplan. Diese Felder verbinden Planung, Durchführung, Befundbehandlung und Nachweis.

Testobjekt und Scope

Kritische oder wichtige Funktion, Asset, Prozess, Daten und Abhängigkeiten eindeutig abgrenzen.

Testziel und Verfahren

Risiko, Kontrollziel, gewähltes Verfahren nach Art. 25 und Auswahlbegründung dokumentieren.

Termin und Verantwortung

Planstart, Planende, Owner, unabhängige Durchführung und erforderliche Mitwirkung festlegen.

Abnahmekriterien

Erwartetes Ergebnis, Toleranzen, Abbruchkriterien und Freigabeinstanz vor Durchführung definieren.

Ergebnis und Findings

Durchführung, Ergebnisstatus, Abweichungen, Befunde und Risikoentscheidung nachvollziehbar verknüpfen.

Retest und Evidence

Maßnahmenfrist, Retesttermin, Nachweisartefakte, Reviewstatus und Abschlussentscheidung führen.

Governance-Kadenz

Kontrollzyklus für das Testjahr

Die konkrete Frequenz richtet sich nach Institutsprofil und Risiko. Der Zyklus strukturiert die erforderlichen Entscheidungen.

Phase	Kadenz	Steuerungsentscheidung
Planen	vor Jahresbeginn	Testuniversum, risikobasierter Testmix, Kapazität und Abhängigkeiten bestätigen.
Freigeben	jährlich und bei Änderung	Programm, Ausnahmen, Priorisierung und Restrisiken durch zuständige Rolle genehmigen.
Steuern	mindestens quartalsweise	Terminlage, Überfälligkeiten, Coverage, Findings und Dienstleisterbeiträge überwachen.
Neu bewerten	ereignisbezogen	Nach Vorfall, wesentlicher Änderung oder neuem Risiko zusätzliche Tests auslösen.
Abschließen	nach Test und Retest	Evidence prüfen, Findings behandeln und Abschluss oder Risikoakzeptanz dokumentieren.

Rollierende Planung

Planungshorizont 2026–2029

Jedes Jahr wird neu bewertet. Termine entstehen erst aus realen Assets, Funktionen, Risiken und genehmigten Testprogrammen.

2026 Steuerungsjahr

Programm und Scope überprüfen
Fällige Tests und Retests einplanen
Abweichungen und Entscheidungen dokumentieren

2027 Vorschau

Programm und Scope überprüfen
Fällige Tests und Retests einplanen
Abweichungen und Entscheidungen dokumentieren

2028 Vorschau

Programm und Scope überprüfen
Fällige Tests und Retests einplanen
Abweichungen und Entscheidungen dokumentieren

2029 Vorschau

Programm und Scope überprüfen
Fällige Tests und Retests einplanen
Abweichungen und Entscheidungen dokumentieren

Musterexport oder operative Steuerung?

Die öffentlichen Dateien demonstrieren Format und Struktur. Mandantenspezifische Kalender werden ausschließlich im geschützten Arbeitsraum erzeugt und gepflegt.

Muster ICS Muster CSV Muster PDF

Hinweis zur Anwendung: Testfrequenzen über die ausdrücklich genannten Mindestanker hinaus sind institutsspezifisch festzulegen. Die Arbeitsstruktur ersetzt weder fachliche Freigabe noch Rechtsberatung oder eine verbindliche Auslegung der Aufsicht.