Wie Sie DORA-Resilienztests mit KI planen

Übersicht

Sie erfahren, wie Sie ein Programm für digitale operationelle Resilienztests entwerfen und implementieren, das die DORA-Artikel 24-27 mithilfe von KI erfüllt. Dieser Leitfaden behandelt das allgemeine Testprogramm (Schwachstellenbewertungen, Penetrationstests, szenariobasierte Tests), die erweiterten Anforderungen für Threat-Led Penetration Testing (TLPT), Testumfang und -häufigkeit, die Berichterstattung der Ergebnisse an Ihr Leitungsorgan, und die Integration der Tests in Ihr IKT-Risikomanagement-Framework, mit spezifischen ISMS-Copilot-Prompts zur Generierung jeder Komponente.

Zielgruppe

Dieser Leitfaden richtet sich an:

• CISOs und Sicherheitsmanager, die für die Gestaltung und Überwachung von Resilienztestprogrammen verantwortlich sind
• IT-Risikomanager, die Testergebnisse in IKT-Risikobewertungen integrieren
• Koordinatoren für Penetrationstests, die interne und externe Testaktivitäten verwalten
• Compliance-Beauftragte, die sicherstellen, dass Testprogramme regulatorische Erwartungen erfüllen
• Berater, die Finanzinstitute bei der Vorbereitung auf TLPT oder allgemeine Resilienztests unterstützen

Vorbereitung

Sie benötigen:

• Ein ISMS-Copilot-Konto (kostenlose Testversion verfügbar)
• Ihr IKT-Risikomanagement-Framework und IKT-Asset-Inventar aus How to build a DORA ICT risk management framework using AI
• Ihre Incident-Klassifizierungs- und Reaktionsverfahren aus How to implement DORA incident reporting using AI
• Kenntnis Ihrer aktuellen Testaktivitäten (Schwachstellenscans, Penetrationstests, DR-Tests)
• Wissen, ob Ihr Institut von Ihrer zuständigen Behörde für TLPT designiert wurde
• Budgetfreigabe für externe Testdienstleistungen (insbesondere für TLPT)

Verständnis der DORA-Anforderungen für Resilienztests

Artikelweise Aufschlüsselung

DORA-Kapitel IV (Artikel 24-27) legt einen strukturierten Ansatz für digitale operationelle Resilienztests fest:

Article

Title

Key requirements

Applicability

Art 24

Allgemeine Anforderungen an digitale operationelle Resilienztests

Einrichtung eines Testprogramms als Teil des IKT-Risikomanagements, risikobasierter Ansatz

Alle Finanzinstitute (verhältnismäßig)

Art 25

Tests von IKT-Tools und -Systemen

Spezifische Testarten: Schwachstellenbewertungen, Penetrationstests, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, Quellcode-Überprüfungen

Alle Finanzinstitute (verhältnismäßig)

Art 26

Erweiterte Tests durch TLPT

Threat-led Penetration Testing basierend auf dem TIBER-EU-Framework, alle 3 Jahre

Nur designierte Institute

Art 27

Anforderungen an Tester

Qualifikationen, Unabhängigkeit und Standards für Tester (intern und extern)

Alle Institute, die Tests durchführen

Allgemeine Tests vs. TLPT

Das Verständnis des Unterschieds zwischen allgemeinen Tests und TLPT ist entscheidend für die Festlegung des Umfangs Ihres Programms:

Aspect

Allgemeine Tests (Art. 24-25)

TLPT (Art. 26-27)

Key difference

Wer

Alle Finanzinstitute

Nur designierte Institute

Zuständige Behörde designiert TLPT-Institute

Häufigkeit

Risikobasiert; kritische Systeme mindestens jährlich

Mindestens alle 3 Jahre

TLPT ist seltener, aber weitaus intensiver

Umfang

Alle IKT-Systeme (verhältnismäßig)

Kritische und wichtige Funktionen, Live-Produktionssysteme

TLPT testet Live-Systeme, nicht nur Testumgebungen

Methodik

Verschiedene (Schwachstellenscans, Pen-Tests, Szenario-Tests)

TIBER-EU-Framework, Threat-Intelligence-gesteuert

TLPT simuliert reale Angreifertaktiken

Tester

Intern oder extern (mit Unabhängigkeitsanforderungen)

Externe Tester erforderlich (mit begrenzten Ausnahmen)

TLPT erfordert zertifizierte externe Red Teams

Berichterstattung

Intern (Leitungsorgan, IKT-Risikofunktion)

An zuständige Behörde, mit Bestätigung

TLPT-Ergebnisse gehen an die Aufsichtsbehörde

Schritt 1: Gestaltung Ihres allgemeinen Testprogramms (Artikel 24-25)

Testprogramm-Framework

Artikel 24 verlangt ein Testprogramm, das integraler Bestandteil Ihres IKT-Risikomanagement-Frameworks ist, einem risikobasierten Ansatz folgt und der Größe und dem Risikoprofil Ihres Instituts angemessen ist.

1. Öffnen Sie Ihren DORA-Arbeitsbereich in ISMS Copilot

2. Generieren Sie das Testprogramm-Dokument:

   "Erstellen Sie ein Programm für digitale operationelle Resilienztests für ein [Institutsart], das die DORA-Artikel 24-25 erfüllt. Enthalten sein sollen: Zweck und Ziele des Programms, Governance (Aufsicht durch das Leitungsorgan, Programmverantwortlicher, Rollen und Verantwortlichkeiten), risikobasierter Ansatz für die Testplanung (wie Risiken bestimmen, was und wie oft getestet wird), Testumfang (abgestimmt auf das IKT-Asset-Inventar und kritische/wichtige Funktionen), durchzuführende Testarten (Schwachstellenbewertungen, Netzwerksicherheitstests, Penetrationstests, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, Quellcode-Überprüfungen, Tests von Open-Source-Software, End-to-End-Tests), Testhäufigkeit nach Kritikalität der Assets und Testart, Anforderungen an interne vs. externe Tester, Unabhängigkeitsanforderungen gemäß Artikel 27, Berichterstattung der Ergebnisse und Kommunikation mit dem Leitungsorgan, Prozess zur Nachverfolgung von Behebungen, Integration mit Aktualisierungen des IKT-Risikomanagement-Frameworks, Vorlage für einen jährlichen Testkalender sowie Budget- und Ressourcenplanung. Berücksichtigen Sie die Verhältnismäßigkeit für ein [Institutsgröße] Unternehmen."

3. Definieren Sie die risikobasierte Testmethodik:

   "Erstellen Sie eine risikobasierte Testmethodik für DORA-Resilienztests. Definieren Sie, wie wir bestimmen: welche Systeme und Funktionen getestet werden sollen (basierend auf der Kritikalität der IKT-Assets, Geschäftsauswirkungen, Bedrohungslandschaft, früheren Vorfällen), welche Testart angewendet werden soll (Schwachstellenscan vs. Penetrationstest vs. szenariobasierter Test), Testtiefe und -intensität (grundlegend, standard, erweitert), Testhäufigkeit (vierteljährlich, halbjährlich, jährlich) und Testpriorisierung bei begrenzten Ressourcen. Stellen Sie eine Testpriorisierungsmatrix bereit, die die Kritikalität der Assets und das Bedrohungsniveau der Testart und -häufigkeit zuordnet. Fügen Sie Beispiele für ein [Institutsart] bei."

Testarten und ihre Anwendung

Artikel 25 spezifiziert mehrere Testarten. Nutzen Sie ISMS Copilot, um detaillierte Pläne für jede Testart zu entwickeln:

1. Programm für Schwachstellenbewertungen:

   "Erstellen Sie ein Programm für Schwachstellenbewertungen zur Einhaltung von DORA Artikel 25. Enthalten sein sollen: Umfang der Scans (alle IKT-Assets nach Kritikalitätsstufe), Scan-Tools und Methodik, Scan-Häufigkeit (mindestens vierteljährlich für kritische Assets, monatlich empfohlen), Schwachstellenklassifizierung gemäß CVSS-Bewertung, Behebungsfristen nach Schweregrad (kritisch: 48 Stunden, hoch: 7 Tage, mittel: 30 Tage, niedrig: 90 Tage), Ausnahmeprozess für Schwachstellen, die nicht sofort behoben werden können, Berichtsformat (technischer Bericht und Management-Zusammenfassung), Trendanalyse-Methodik und Integration in die Patch-Management-Verfahren. Stellen Sie einen Workflow für das Schwachstellenmanagement bereit."

2. Programm für Penetrationstests:

   "Erstellen Sie ein Programm für Penetrationstests zur Einhaltung von DORA Artikel 25. Enthalten sein sollen: Testumfang (externer Perimeter, internes Netzwerk, Webanwendungen, mobile Anwendungen, API-Sicherheit, Social Engineering), Testhäufigkeit (mindestens jährlich für kritische Systeme, häufiger für Hochrisikobereiche), Testmethodik (OWASP, PTES oder gleichwertig), Vorlage für Regeln of Engagement (Umfang, Zeitplan, Eskalation, verbotene Aktionen), Qualifikationsanforderungen an Tester gemäß DORA Artikel 27 (Unabhängigkeit, Kompetenz, Versicherung), Vorab-Verfahren (Genehmigung, Umfangbestätigung, Kommunikation), Berichtsanforderungen (Zusammenfassung für die Geschäftsführung, technische Ergebnisse, Risikobewertungen, Empfehlungen zur Behebung), Nachtest-Verfahren (Überprüfung der Behebungen, erneute Tests) und Berichtsformat für das Leitungsorgan. Stellen Sie eine Beispielvorlage für Regeln of Engagement bereit."

3. Programm für szenariobasierte Tests:

   "Gestalten Sie ein Programm für szenariobasierte Resilienztests gemäß DORA Artikel 25. Erstellen Sie Testszenarien, die Folgendes abdecken: Ransomware-Angriff auf Kernbanking-/Zahlungssysteme, Ausfall eines großen Cloud-Anbieters mit Auswirkungen auf kritische Dienstleistungen, DDoS-Angriff während Spitzenzeiten im Transaktionsverkehr, Insider-Bedrohung mit Kompromittierung sensibler Daten, Supply-Chain-Angriff über einen kritischen Drittanbieter von IKT-Dienstleistungen, gleichzeitiger Ausfall von Primär- und Backupsystemen, Verlust von Schlüssel-IKT-Personal während eines Vorfalls, regulatorische Datenpanne mit Benachrichtigungspflicht gegenüber Kunden. Für jedes Szenario definieren Sie: Testziele, Umfang und beteiligte Systeme, Szenario-Narrativ und Zeitplan für Injektionen, Erfolgskriterien, Teilnehmer und Rollen, Testdurchführungsverfahren, erwartete Ergebnisse, Bewertungskriterien und Berichtsvorlage. Berücksichtigen Sie sowohl Tabletop- als auch Simulationsübungsformate."

Schritt 2: Festlegung der Tester-Anforderungen (Artikel 27)

Unabhängigkeit und Qualifikationen der Tester

Artikel 27 legt Anforderungen für Tester fest, die Resilienztests durchführen. Diese gelten sowohl für interne als auch externe Tester:

"Erstellen Sie eine Richtlinie für Tester-Anforderungen und Qualifikationen gemäß DORA Artikel 27. Behandeln Sie: interne Tester (Unabhängigkeit von den zu testenden Bereichen, relevante Zertifizierungen wie OSCP/CREST/GPEN, fortlaufende Kompetenz, Rotationsanforderungen), externe Tester (berufliche Zertifizierungen und Akkreditierungen, relevante Erfahrung in der Prüfung des Finanzsektors, Berufshaftpflichtversicherung, Überprüfung der Unabhängigkeit, Referenzprüfung), Management von Interessenkonflikten, Verfahren zur Überprüfung und Sicherheitsfreigabe von Testern, Anforderungen an Vertraulichkeit und Geheimhaltung sowie Kriterien zur Leistungsbewertung von Testern. Stellen Sie eine Checkliste für die Qualifikationen interner und externer Tester sowie eine Beispielvorlage für eine Leistungsbeschreibung (Statement of Work) für externe Testaufträge bereit."

Schritt 3: Planung für TLPT (Artikel 26-27)

Verständnis der TLPT-Anforderungen

Threat-Led Penetration Testing (TLPT) gemäß DORA basiert auf dem TIBER-EU-Framework und stellt die intensivste Testanforderung dar. Selbst wenn Sie nicht für TLPT designiert wurden, ist das Verständnis der Anforderungen wertvoll für die Vorbereitung.

1. Bewertung der TLPT-Anwendbarkeit:

   "Bewerten Sie, ob unser [Institutsart] mit [Größe, systemischer Bedeutung, IKT-Risikoprofil] wahrscheinlich für DORA TLPT gemäß Artikel 26 designiert wird. Berücksichtigen Sie: unsere systemische Bedeutung im Finanzsektor, Kritikalität der von uns erbrachten Dienstleistungen, unser IKT-Risikoprofil und Komplexität, Designationskriterien der zuständigen Behörde aus veröffentlichten Leitlinien. Falls eine Designation wahrscheinlich ist, stellen Sie eine TLPT-Bereitschaftsbewertung und einen Vorbereitungszeitplan bereit. Falls unwahrscheinlich, empfehlen Sie vorbereitende Maßnahmen, die wir dennoch ergreifen sollten."

2. Generieren Sie das TLPT-Framework:

   "Erstellen Sie ein Framework für die Vorbereitung und Durchführung von TLPT gemäß DORA Artikel 26, ausgerichtet auf die TIBER-EU-Methodik. Enthalten sein sollen: Phase 1 - Vorbereitung: Definition des Umfangs (kritische und wichtige Funktionen, die an Live-Produktionssystemen getestet werden), Einbindung und Benachrichtigung der zuständigen Behörde, Auswahl des Threat-Intelligence-Anbieters, Auswahl des Red-Team-Anbieters, Bildung des White Teams (internes Team, das über den Test informiert ist), interne Genehmigungen der Governance. Phase 2 - Threat Intelligence: Threat-Intelligence-Bericht (gezielte Analyse der Bedrohungslandschaft), Bedrohungsszenarien basierend auf aktuellen Bedrohungsakteuren und -techniken, Angriffsoberflächenanalyse und Überprüfung der Bedrohungsszenarien durch die zuständige Behörde. Phase 3 - Red-Team-Testing: Red-Team-Einsatz (simulierte Angriffe auf Live-Produktionssysteme), Testdurchführung über [typische Dauer: 8-12 Wochen], kontrollierte Tests mit Sicherheitsmechanismen, Purple-Team-Aktivitäten (falls vereinbart) und Dokumentation der Ergebnisse. Phase 4 - Abschluss: Red-Team-Bericht mit Ergebnissen und Beweisen, Bewertung der Blue-Team-Reaktion, Entwicklung eines Behebungsplans, Briefing des Leitungsorgans, Bestätigungsprozess durch die zuständige Behörde. Geben Sie Zeit- und Ressourcenschätzungen für jede Phase an."

Auswahl der TLPT-Anbieter

TLPT erfordert sowohl einen Threat-Intelligence-Anbieter als auch einen Red-Team-Anbieter. Nutzen Sie ISMS Copilot, um Auswahlkriterien zu entwickeln:

"Erstellen Sie ein Framework für die Auswahl von TLPT-Anbietern gemäß DORA Artikel 26-27. Für den Threat-Intelligence-Anbieter: erforderliche Qualifikationen (branchen-spezifische Expertise für Finanzbedrohungen, anerkannte Zertifizierungen), Bewertungskriterien (Qualität früherer Bedrohungsberichte, Verständnis von Bedrohungen im EU-Finanzsektor, Datenquellen und Erfassungsmöglichkeiten) und Auswahlcheckliste. Für den Red-Team-Anbieter: erforderliche Qualifikationen (CREST, CBEST oder gleichwertige Akkreditierung, Erfahrung mit TIBER-EU-Tests, Erfahrung im Finanzsektor), Bewertungskriterien (technische Fähigkeiten, Methodik, Teamzusammensetzung, Sicherheitsbilanz), Überprüfung der Unabhängigkeit (keine aktuelle Beratungsbeziehung zum Institut), Versicherungsanforderungen und Auswahlcheckliste. Stellen Sie eine RFP-Vorlage für beide Anbietertypen bereit."

TLPT-Umfangsdefinition

Eine korrekte Umfangsdefinition ist entscheidend für einen erfolgreichen TLPT. Nutzen Sie ISMS Copilot, um den Testumfang zu definieren:

"Helfen Sie uns, den Umfang für unsere DORA-TLPT-Übung zu definieren. Unsere kritischen und wichtigen Funktionen umfassen: [Funktionen auflisten]. Für jede kritische Funktion identifizieren Sie: die unterstützenden IKT-Systeme und -Infrastrukturen, die im Umfang enthalten sein sollten, Datenflüsse und Integrationen, die als Angriffswege dienen könnten, Drittanbieter von IKT-Dienstleistungen, die die Funktion unterstützen (und ob sie gemäß Artikel 26(3) in die Tests einbezogen werden sollten), potenzielle Angriffsoberflächen (extern, intern, physisch, Social Engineering) und Systeme, die aus Sicherheitsgründen explizit ausgeschlossen werden sollten. Erstellen Sie ein TLPT-Umfangsdokument, das für die Überprüfung durch die zuständige Behörde geeignet ist."

Schritt 4: Berichterstattung der Ergebnisse und Nachverfolgung von Behebungen

Berichterstattung der Testergebnisse an die Geschäftsführung

DORA verlangt, dass Testergebnisse dem Leitungsorgan berichtet und zur Aktualisierung des IKT-Risikomanagement-Frameworks verwendet werden:

1. Generieren Sie Vorlagen für Testergebnisberichte:

   "Erstellen Sie eine Vorlage für einen Bericht über Resilienztestergebnisse zur Berichterstattung an das Leitungsorgan gemäß DORA Artikel 24. Enthalten sein sollen: Zusammenfassung für die Geschäftsführung (allgemeine Resilienzlage, wichtige Ergebnisse, Trendvergleich), Zusammenfassung der Testprogrammdurchführung (durchgeführte Tests, Umfang, Zeitplan), Ergebnisse nach Schweregrad (kritisch, hoch, mittel, niedrig) mit Kontext der Geschäftsauswirkungen, Vergleich mit vorherigen Testzyklen (Verbesserung oder Verschlechterung), Status der Behebung zuvor identifizierter Schwachstellen, neue Empfehlungen zur Behebung mit risikobasierter Priorisierung, Bewertung der Wirksamkeit des Testprogramms, Budget- und Ressourcennutzung sowie Empfehlungen für Anpassungen des Testprogramms. Der Bericht sollte für nicht-technische Vorstandsmitglieder geeignet sein und gleichzeitig ausreichend Details für die Risikoaufsicht enthalten."

2. Erstellen Sie TLPT-Bestätigungsdokumentation:

   "Erstellen Sie ein Paket mit TLPT-Bestätigungsdokumenten zur Einreichung bei unserer zuständigen Behörde gemäß DORA Artikel 26(6). Enthalten sein sollen: TLPT-Zusammenfassungsbericht (Umfang, Methodik, Zeitplan), anonymisierte Red-Team-Ergebnisse (kritische und hochgradige Schwachstellen), Behebungsplan mit Zeitplan und Status, Bestätigung und Genehmigung durch das Leitungsorgan, organisatorische Lessons Learned sowie etwaige Anträge auf gegenseitige Anerkennung mit anderen zuständigen Behörden. Befolgen Sie das Format gemäß den Leitlinien von [zuständige Behörde] und dem TIBER-EU-Framework."

Nachverfolgung von Behebungen

Tests sind nur wertvoll, wenn die Ergebnisse zu Verbesserungen führen. Richten Sie eine robuste Nachverfolgung von Behebungen ein:

"Erstellen Sie ein Verfahren zur Nachverfolgung von Behebungen aus Resilienztests zur Einhaltung von DORA. Enthalten sein sollen: wie Ergebnisse in Behebungsmaßnahmen umgesetzt werden, Priorisierungsmethodik (kritisch: Behebung innerhalb von 30 Tagen, hoch: 60 Tage, mittel: 90 Tage, niedrig: nächster Testzyklus), Zuweisung und Verantwortlichkeit von Behebungsverantwortlichen, Fortschrittsverfolgung und Eskalation bei überfälligen Behebungen, Überprüfungstests (Bestätigung der Wirksamkeit von Korrekturen), Ausnahmeprozess für Ergebnisse, die nicht behoben werden können (kompensierende Kontrollen, Risikoakzeptanz mit Genehmigung des Leitungsorgans), Integration in das IKT-Risikoregister (Aktualisierung der Risikobewertungen basierend auf Testergebnissen) und Berichtsrhythmus an das Leitungsorgan. Stellen Sie eine Vorlage für ein Register zur Nachverfolgung von Behebungen bereit."

Schritt 5: Integration der Tests in Ihr IKT-Risikomanagement-Framework

Einbindung der Ergebnisse in das Risikomanagement

DORA verlangt, dass Testergebnisse Ihr IKT-Risikomanagement-Framework informieren und aktualisieren. Nutzen Sie ISMS Copilot, um diese Integration zu formalisieren:

"Definieren Sie, wie die Ergebnisse von Resilienztests in unser DORA-IKT-Risikomanagement-Framework integriert werden. Enthalten sein sollen: wie Testergebnisse das IKT-Risikoregister aktualisieren (neu identifizierte Risiken, angepasste Risikobewertungen, Neubewertung der Kontrollwirksamkeit), wie Testergebnisse die jährliche Überprüfung des IKT-Risikomanagement-Frameworks gemäß Artikel 6(5) beeinflussen, wie TLPT-Ergebnisse unsere IKT-Risikostrategie und Risikobereitschaft beeinflussen, wie szenariobasierte Testergebnisse unsere Business-Continuity- und Disaster-Recovery-Pläne aktualisieren, wie Trends aus Schwachstellenbewertungen unsere Schutz- und Präventionsmaßnahmen gemäß Artikel 9 informieren und wie Ergebnisse von Incident-Simulationen unsere Incident-Klassifizierungs- und Meldeverfahren validieren oder infrage stellen. Stellen Sie einen Prozessfluss bereit, der die Feedback-Schleife zwischen Tests und Risikomanagement zeigt."

Kontinuierliche Verbesserung der Tests

Ihr Testprogramm selbst sollte sich basierend auf Ergebnissen und sich ändernden Bedrohungen weiterentwickeln:

"Erstellen Sie einen jährlichen Überprüfungsprozess für das Testprogramm zur Einhaltung von DORA. Die Überprüfung sollte bewerten: Testabdeckung (haben wir alle geplanten kritischen Systeme und Funktionen getestet?), Wirksamkeit der Tests (haben die Tests echte Schwachstellen identifiziert? Wie verhalten sich die Ergebnisse im Vergleich zu tatsächlichen Vorfällen?), Effizienz der Tests (nutzen wir Ressourcen effektiv? Gibt es überlappende oder redundante Tests?), Änderungen der Bedrohungslandschaft (spiegeln unsere Testszenarien aktuelle Bedrohungen wider?), neue Systeme oder Dienstleistungen, die seit der letzten Überprüfung hinzugekommen sind (sind sie im Testumfang enthalten?), regulatorisches Feedback oder Leitlinien zu Testanforderungen sowie empfohlene Anpassungen des Programms für den nächsten Zyklus. Erstellen Sie eine Vorlage für einen jährlichen Überprüfungsbericht des Testprogramms zur Genehmigung durch das Leitungsorgan."

Schritt 6: Verwaltung der Testlogistik und Governance

Testkalender und Koordination

Richten Sie einen strukturierten jährlichen Testkalender ein, um sicherzustellen, dass alle Testaktivitäten geplant, mit Ressourcen ausgestattet und koordiniert werden:

"Erstellen Sie einen jährlichen Kalender für Resilienztests für unser [Institutsart]. Tragen Sie alle erforderlichen Testaktivitäten über das Jahr ein: Schwachstellenscans (vierteljährlich für kritische, monatlich für internetseitige Systeme), Penetrationstests (jährlich extern, jährlich intern, jährlich für Anwendungen), szenariobasierte Übungen (halbjährlich Tabletop, jährlich Simulation), Business-Continuity-Tests (jährlich Failover, jährlich Backup-Wiederherstellung) und TLPT-Vorbereitungsaktivitäten (falls zutreffend). Enthalten sein sollen: Ressourcenanforderungen für jede Aktivität, Koordinationsanforderungen (Change-Freeze-Zeitfenster, Einbindung von Fachabteilungen), Abhängigkeiten zwischen Testaktivitäten, Budgetzuweisung nach Quartal und Meilensteine für die Berichterstattung an das Leitungsorgan. Formatieren Sie dies als Kalenderansicht mit Gantt-Chart-Struktur."

Tests von Drittanbietern für IKT-Dienstleistungen

Artikel 26(3) behandelt Tests, die IKT-Drittanbieter von Dienstleistungen einbeziehen. Koordinieren Sie die Testanforderungen mit Ihren Anbietern:

"Erstellen Sie Verfahren zur Koordination von Resilienztests mit IKT-Drittanbietern gemäß DORA. Enthalten sein sollen: vertragliche Anforderungen an die Teilnahme der Anbieter an Tests (Verweis auf Artikel-28-Vertragsklauseln), Verfahren zur Benachrichtigung und Koordination mit Anbietern, Tests der gemeinsamen Verantwortung (was wir testen vs. was der Anbieter testet), Umgang mit der Weigerung eines Anbieters, an Tests teilzunehmen, alternative Testansätze, wenn direkte Anbietertests nicht möglich sind (synthetische Tests, vom Anbieter bereitgestellte Testberichte), TLPT mit Einbeziehung von Anbietersystemen (Artikel 26(3) Pooled-Testing-Vereinbarungen) und Sammlung von Nachweisen aus Anbietertestaktivitäten. Behandeln Sie Szenarien für Cloud-Anbieter, Managed-Service-Anbieter und Anbieter kritischer Infrastrukturen."

Nächste Schritte

Sie verfügen nun über ein umfassendes Programm für digitale operationelle Resilienztests:

• Testprogramm-Framework mit risikobasierter Methodik
• Detaillierte Pläne für Schwachstellenbewertungen, Penetrationstests und szenariobasierte Tests
• Qualifikations- und Unabhängigkeitsanforderungen für Tester
• TLPT-Vorbereitungsframework (falls designiert oder wahrscheinlich designiert)
• Berichtsvorlagen für das Leitungsorgan und die zuständige Behörde
• Verfahren zur Nachverfolgung von Behebungen
• Integration in das IKT-Risikomanagement-Framework

Fahren Sie mit dem letzten Leitfaden dieser DORA-Reihe fort:

• How to manage DORA third-party ICT risk using AI -- Stellen Sie sicher, dass Ihre Drittanbieter in Ihr Testprogramm einbezogen werden und dass Verträge Ihre Testverpflichtungen unterstützen

Für die grundlegende Einrichtung siehe How to get started with DORA implementation using AI. Für das IKT-Risikomanagement-Framework siehe How to build a DORA ICT risk management framework using AI. Für die Integration der Incident-Berichterstattung siehe How to implement DORA incident reporting using AI.

Für gebrauchsfertige Prompts siehe die DORA Compliance Prompt Library. Für den vollständigen regulatorischen Überblick verweisen Sie auf den DORA Compliance Guide for Financial Entities.

Hilfe erhalten

Für zusätzliche Unterstützung bei der Planung Ihres Resilienztestprogramms:

• Fragen Sie ISMS Copilot: Nutzen Sie Ihren DORA-Arbeitsbereich, um Testszenarien zu generieren, die auf Ihre Institutsart und IKT-Umgebung zugeschnitten sind
• Laden Sie bestehende Testberichte hoch: Erhalten Sie eine Gap-Analyse, indem Sie frühere Penetrationstest- oder Schwachstellenbewertungsberichte hochladen, um sie mit den DORA-Anforderungen zu vergleichen
• TLPT-Vorbereitung: Nutzen Sie ISMS Copilot, um Ihr TLPT-Umfangsdokument und Kriterien für die Anbieterauswahl zu entwickeln, bevor Sie mit Ihrer zuständigen Behörde in Kontakt treten
• Validieren Sie Ausgaben: Überprüfen Sie alle Testpläne anhand von DORA-Artikeln 24-27, relevanten RTS und dem TIBER-EU-Framework vor der Genehmigung durch das Leitungsorgan