So planen Sie DORA-Resilienztests mit KI

Überblick

Sie erfahren, wie Sie mithilfe von KI ein Programm für digitale operationale Resilienztests entwerfen und implementieren, das die DORA-Artikel 24–27 erfüllt. Dieser Leitfaden deckt das allgemeine Testprogramm (Schwachstellenbewertungen, Penetrationstests, szenariobasierte Tests), die Anforderungen an fortgeschrittene bedrohungsorientierte Penetrationstests (TLPT), Testumfang und -häufigkeit, die Berichterstattung der Ergebnisse an Ihr Leitungsorgan sowie die Integration der Tests in Ihren IKT-Risikomanagementrahmen ab, einschließlich spezifischer ISMS Copilot-Prompts für jede Komponente.

Für wen dieser Leitfaden ist

Dieser Leitfaden richtet sich an:

• CISOs und Sicherheitsmanager, die für den Entwurf und die Ü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 Finanzunternehmen bei der Vorbereitung auf TLPT oder allgemeine Resilienztests unterstützen

Bevor Sie beginnen

Sie benötigen:

• Ein ISMS Copilot-Konto (kostenlose Testversion verfügbar)

• Ihren IKT-Risikomanagementrahmen und Ihr IKT-Asset-Inventar aus „So erstellen Sie einen DORA IKT-Risikomanagementrahmen mit KI“

• Ihre Verfahren zur Klassifizierung und Reaktion auf Vorfälle aus „So implementieren Sie die DORA-Vorfallsberichterstattung mit KI“

• Verständnis Ihrer aktuellen Testaktivitäten (Schwachstellen-Scans, Penetrationstests, DR-Tests)

• Kenntnis darüber, ob Ihr Unternehmen von Ihrer zuständigen Behörde für TLPT benannt wurde

• Budgetfreigabe für externe Testdienstleistungen (insbesondere für TLPT)

Verständnis der DORA-Anforderungen an Resilienztests

Aufschlüsselung Artikel für Artikel

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

Artikel

Titel

Hauptanforderungen

Anwendbarkeit

Art. 24

Allgemeine Anforderungen an das Testen der digitalen operationalen Resilienz

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

Alle Finanzunternehmen (proportional)

Art. 25

Testen von IKT-Tools und -Systemen

Spezifische Testarten: Schwachstellenbewertungen, Penetrationstests, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, Quellcodeprüfungen

Alle Finanzunternehmen (proportional)

Art. 26

Fortgeschrittene Tests mittels TLPT

Bedrohungsorientierte Penetrationstests basierend auf dem TIBER-EU-Rahmenwerk, alle 3 Jahre

Nur benannte Unternehmen

Art. 27

Anforderungen an Tester

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

Alle Unternehmen, 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:

Aspekt

Allgemeine Tests (Art. 24–25)

TLPT (Art. 26–27)

Hauptunterschied

Wer

Alle Finanzunternehmen

Nur benannte Unternehmen

Die zuständige Behörde benennt TLPT-Unternehmen

Häufigkeit

Risikobasiert; kritische Systeme mindestens jährlich

Mindestens alle 3 Jahre

TLPT ist seltener, aber weitaus intensiver

Umfang

Alle IKT-Systeme (proportional)

Kritische und wichtige Funktionen, Live-Produktionssysteme

TLPT testet Live-Systeme, nicht nur Testumgebungen

Methodik

Verschiedene (Schwachstellen-Scans, Penetrationstests, Szenariotests)

TIBER-EU-Rahmenwerk, basierend auf Threat Intelligence

TLPT simuliert reale Taktiken von Angreifern

Tester

Intern oder extern (mit Unabhängigkeitsanforderungen)

Externe Tester erforderlich (mit wenigen Ausnahmen)

TLPT erfordert ein zertifiziertes externes Red Team

Berichterstattung

Intern (Leitungsorgan, IKT-Risikofunktion)

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

TLPT-Ergebnisse gehen an den Regulator

Schritt 1: Entwurf Ihres allgemeinen Testprogramms (Artikel 24–25)

Rahmenwerk für das Testprogramm

Artikel 24 erfordert ein Testprogramm, das fester Bestandteil Ihres IKT-Risikomanagementrahmens ist, einem risikobasierten Ansatz folgt und proportional zur Größe und zum Risikoprofil Ihres Unternehmens ist.

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

2. Erzeugen Sie das Dokument zum Testprogramm:

   „Erstelle ein Programm für digitale operationale Resilienztests für ein [Unternehmenstyp], das die DORA-Artikel 24–25 erfüllt. Enthalten sein sollen: Zweck und Ziele des Programms, Governance (Aufsicht durch das Leitungsorgan, Programmeigentümer, Rollen und Verantwortlichkeiten), risikobasierter Ansatz für die Testplanung (wie Risiken bestimmen, was wie oft getestet wird), Testumfang (zugeordnet zum IKT-Asset-Inventar und zu kritischen/wichtigen Funktionen), durchzuführende Testarten (Schwachstellenbewertungen, Netzwerksicherheitstests, Penetrationstests, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, Quellcodeprüfungen, Open-Source-Softwaretests, End-to-End-Tests), Testhäufigkeit nach Asset-Kritikalität und Testart, Anforderungen an interne vs. externe Tester, Unabhängigkeitsanforderungen gemäß Artikel 27, Berichterstattung der Ergebnisse und Kommunikation mit dem Leitungsorgan, Prozess zur Verfolgung der Mängelbehebung, Integration in Aktualisierungen des IKT-Risikomanagementrahmens, Vorlage für einen jährlichen Testkalender sowie Budget- und Ressourcenplanung. Wende Proportionalität für eine [Unternehmensgröße] Organisation an.“

3. Definieren Sie die risikobasierte Testmethodik:

   „Erstelle eine risikobasierte Testmethodik für DORA-Resilienztests. Definiere, wie wir Folgendes bestimmen: welche Systeme und Funktionen getestet werden sollen (basierend auf IKT-Asset-Kritikalität, Geschäftsauswirkung, Bedrohungslandschaft, früheren Vorfällen), welche Art von Tests anzuwenden ist (Schwachstellenscan vs. Penetrationstest vs. szenariobasierter Test), Testtiefe und -intensität (Basis, Standard, Fortgeschritten), Testhäufigkeit (vierteljährlich, halbjährlich, jährlich) und Testpriorität bei Ressourcenknappheit. Erstelle eine Matrix für die Testpriorisierung, die Asset-Kritikalität und Bedrohungsniveau der Testart und Häufigkeit zuordnet. Füge Beispiele für ein [Unternehmenstyp] hinzu.“

Testarten und ihre Anwendung

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

1. Programm für Schwachstellenbewertungen:

   „Erstelle ein Programm für Schwachstellenbewertungen zur DORA-Konformität gemäß Artikel 25. Enthalten sein sollen: Scan-Umfang (alle IKT-Assets nach Kritikalitätsstufe), Scan-Tools und -Methodik, Scan-Häufigkeit (mindestens vierteljährlich für kritische Assets, monatlich empfohlen), Schwachstellenklassifizierung abgestimmt auf CVSS-Scoring, Zeitrahmen für die Behebung nach Schweregrad (kritisch: 48 Stunden, hoch: 7 Tage, mittel: 30 Tage, niedrig: 90 Tage), Ausnahmeverwaltungsprozess für Schwachstellen, die nicht sofort behoben werden können, Berichtsformat (technischer Bericht und Management-Zusammenfassung), Methodik der Trendanalyse und Integration in Patch-Management-Verfahren. Erstelle einen Workflow für das Schwachstellenmanagement.“

2. Programm für Penetrationstests:

   „Erstelle ein Programm für Penetrationstests zur DORA-Konformität gemäß 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 Einsatzregeln (Umfang, Zeitplan, Eskalation, verbotene Handlungen), Anforderungen an die Qualifikation der Tester gemäß DORA-Artikel 27 (Unabhängigkeit, Kompetenz, Versicherung), Verfahren vor dem Test (Autorisierung, Bestätigung des Umfangs, Kommunikation), Berichtsanforderungen (Executive Summary, technische Ergebnisse, Risikobewertungen, Empfehlungen zur Behebung), Verfahren nach dem Test (Verifizierung der Behebung, Nachtests) und Berichtsformat für das Leitungsorgan. Erstelle eine Beispielvorlage für die Einsatzregeln (Rules of Engagement).“

3. Programm für szenariobasierte Tests:

   „Entwirf ein szenariobasiertes Resilienztestprogramm für DORA-Artikel 25. Erstelle Test-Szenarien zu: Ransomware-Angriff auf Kernbanken-/Zahlungssysteme, Ausfall eines großen Cloud-Anbieters mit Auswirkungen auf kritische Dienste, DDoS-Angriff während Spitzenzeiten bei Transaktionen, Insider-Bedrohung, die sensible Daten kompromittiert, Lieferkettenangriff über einen kritischen Drittanbieter von IKT-Diensten, gleichzeitiger Ausfall von Primär- und Backup-Systemen, Verlust von wichtigem IKT-Personal während eines Vorfalls, regulatorische Datenschutzverletzung, die eine Benachrichtigung der Kunden erfordert. Definiere für jedes Szenario: Testziele, Umfang und beteiligte Systeme, Szenario-Handlung mit einem Zeitplan für Ereignisse (Injects), Erfolgskriterien, Teilnehmer und Rollen, Testausführungsverfahren, erwartete Ergebnisse, Bewertungskriterien und Berichtsvorlage. Berücksichtige sowohl Tabletop-Formate als auch simulierte Übungen.“

Schritt 2: Anforderungen an Tester festlegen (Artikel 27)

Unabhängigkeit und Qualifikation der Tester

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

„Erstelle eine Richtlinie für Anforderungen und Qualifikationen von Testern gemäß DORA-Artikel 27. Berücksichtige: interne Tester (Unabhängigkeit von den zu testenden Bereichen, relevante Zertifizierungen wie OSCP/CREST/GPEN, Aufrechterhaltung der Kompetenz, Rotationsanforderungen), externe Tester (berufliche Zertifizierungen und Akkreditierungen, relevante Erfahrung mit Tests im Finanzsektor, Berufshaftpflichtversicherung, Überprüfung der Unabhängigkeit, Prüfung von Referenzen), Management von Interessenkonflikten, Verfahren zur Überprüfung und Sicherheitsprüfung von Testern, Geheimhaltungs- und Vertraulichkeitsanforderungen sowie Bewertungskriterien für die Testerleistung. Erstelle eine Checkliste für die Qualifikation von Testern für sowohl interne als auch externe Tester sowie eine Beispiel-Leistungsbeschreibung für externe Testaufträge.“

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

Verständnis der TLPT-Anforderungen

Bedrohungsorientierte Penetrationstests (TLPT) unter DORA basieren auf dem TIBER-EU-Rahmenwerk und stellen die intensivste Testanforderung dar. Selbst wenn Sie nicht für TLPT benannt wurden, ist das Verständnis der Anforderungen wertvoll für die Vorbereitung.

1. Bewertung der TLPT-Anwendbarkeit:

   „Bewerte, ob unser [Unternehmenstyp] mit [Größe, systemischer Bedeutung, IKT-Risikoprofil] wahrscheinlich für DORA-TLPT gemäß Artikel 26 benannt wird. Berücksichtige: unsere systemische Bedeutung im Finanzsektor, die Kritikalität der von uns angebotenen Dienstleistungen, unser IKT-Risikoprofil und dessen Komplexität sowie die Benennungskriterien der zuständigen Behörde aus veröffentlichten Leitlinien. Falls eine Benennung wahrscheinlich ist, erstelle eine TLPT-Bereitschaftsbewertung und einen Vorbereitungszeitplan. Falls unwahrscheinlich, empfiehl vorbereitende Maßnahmen, die wir dennoch ergreifen sollten.“

2. Erzeugung des TLPT-Rahmenwerks:

   „Erstelle ein Rahmenwerk für die Vorbereitung und Durchführung von TLPT gemäß DORA-Artikel 26, abgestimmt auf die TIBER-EU-Methodik. Enthalten sein sollen: Phase 1 – Vorbereitung: Umfangsdefinition (kritische und wichtige Funktionen, die auf Live-Produktionssystemen getestet werden sollen), 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), Genehmigungen durch die interne Governance. Phase 2 – Threat Intelligence: Threat-Intelligence-Bericht (zielgerichtete Analyse der Bedrohungslandschaft), Bedrohungsszenarien basierend auf aktuellen Bedrohungsakteuren und Techniken, Analyse der Angriffsoberfläche und Überprüfung der Bedrohungsszenarien durch die zuständige Behörde. Phase 3 – Red-Team-Tests: Red-Team-Einsatz (simulierte Angriffe auf Live-Produktionssysteme), Testausfü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 Reaktion des Blue Teams, Erstellung eines Behebungsplans, Briefing des Leitungsorgans, Attestierungsprozess der zuständigen Behörde. Gib Schätzungen für den Zeitplan und den Ressourcenbedarf für jede Phase an.“

Auswahl des TLPT-Anbieters

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

„Erstelle ein Rahmenwerk zur Auswahl von TLPT-Anbietern gemäß DORA-Artikel 26-27. Für den Threat-Intelligence-Anbieter: erforderliche Qualifikationen (sektorspezifische Finanzbedrohungsexpertise, anerkannte Zertifizierungen), Bewertungskriterien (Qualität früherer Bedrohungsberichte, Verständnis der Bedrohungen im EU-Finanzsektor, Datenquellen und Erfassungsfähigkeiten) und Auswahl-Checkliste. 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), Unabhängigkeitsprüfung (keine aktuelle Beratungsbeziehung zum Unternehmen), Versicherungsanforderungen und Auswahl-Checkliste. Erstelle eine Ausschreibungsvorlage (RFP) für beide Anbietertypen.“

Festlegung des TLPT-Umfangs

Die richtige Festlegung des Umfangs ist entscheidend für ein erfolgreiches TLPT. Nutzen Sie ISMS Copilot, um den Testumfang zu definieren:

„Hilf uns dabei, den Umfang für unsere DORA-TLPT-Übung zu definieren. Unsere kritischen und wichtigen Funktionen umfassen: [Liste der Funktionen]. Identifiziere für jede kritische Funktion: die unterstützenden IKT-Systeme und die Infrastruktur, die zum Umfang gehören sollten, Datenflüsse und Integrationen, die Angriffspfade sein könnten, Drittanbieter von IKT-Diensten, 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 ausdrücklich ausgeschlossen werden sollten. Erstelle ein Dokument zum TLPT-Umfang, das für die Überprüfung durch die zuständige Behörde geeignet ist.“

Schritt 4: Berichterstattung der Ergebnisse und Verfolgung der Mängelbehebung

Berichterstattung der Testergebnisse an das Management

DORA schreibt vor, dass Testergebnisse an das Leitungsorgan gemeldet und zur Aktualisierung des IKT-Risikomanagementrahmens verwendet werden:

1. Erzeugen Sie Vorlagen für Berichte über Testergebnisse:

   „Erstelle eine Berichtsvorlage für Resilienztestergebnisse zur Berichterstattung an das Leitungsorgan gemäß DORA-Artikel 24. Enthalten sein sollen: Executive Summary (allgemeine Resilienzlage, Hauptergebnisse, Trendvergleich), Zusammenfassung der Durchführung des Testprogramms (durchgeführte Tests, Umfang, Zeitplan), Ergebnisse nach Schweregrad (kritisch, hoch, mittel, niedrig) mit Kontext zur Geschäftsauswirkung, Vergleich mit früheren Testzyklen (Verbesserung oder Verschlechterung), Status der Behebung früher identifizierter Schwachstellen, neue Empfehlungen zur Behebung mit risikobasierter Priorisierung, Bewertung der Wirksamkeit des Testprogramms, Budget- und Ressourcenauslastung 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 bieten.“

2. Erstellen Sie Unterlagen für die TLPT-Bestätigung:

   „Erstelle ein Paket mit Bestätigungsunterlagen für TLPT 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 (kritisch und hoher Schweregrad), Behebungsplan mit Zeitplan und Status, Anerkennung und Genehmigung durch das Leitungsorgan, organisatorische Lerneffekte sowie etwaige Anträge auf gegenseitige Anerkennung durch andere zuständige Behörden. Folge den Formatvorgaben der [zuständigen Behörde] und dem TIBER-EU-Rahmenwerk.“

Verfolgung der Mängelbehebung

Tests sind nur dann wertvoll, wenn die Ergebnisse zu Verbesserungen führen. Etablieren Sie eine robuste Nachverfolgung der Behebung:

„Erstelle ein Verfahren zur Verfolgung der Behebung von Mängeln aus Resilienztests zur DORA-Konformität. 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 von Verantwortlichen für die Behebung, Fortschrittsüberwachung und Eskalation bei überfälligen Behebungen, Verifizierungstests (Bestätigung, dass Korrekturen wirksam sind), Ausnahmeprozess für Ergebnisse, die nicht behoben werden können (kompensierende Kontrollen, Risikoakzeptanz mit Genehmigung des Leitungsorgans), Integration in das IKT-Risikoregister (Aktualisierung von Risikobewertungen basierend auf Testergebnissen) und Rhythmus der Berichterstattung an das Leitungsorgan. Erstelle eine Vorlage für ein Register zur Verfolgung der Mängelbehebung.“

Schritt 5: Integration der Tests in Ihren IKT-Risikomanagementrahmen

Einpflegen der Ergebnisse in das Risikomanagement

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

„Definiere, wie Resilienztestergebnisse in unseren DORA IKT-Risikomanagementrahmen integriert werden. Enthalten sein sollen: wie Testergebnisse das IKT-Risikoregister aktualisieren (neue Risiken identifiziert, Risikobewertungen angepasst, Wirksamkeit von Kontrollen neu bewertet), wie Testergebnisse die jährliche Überprüfung des IKT-Risikomanagementrahmens gemäß Artikel 6(5) informieren, wie TLPT-Ergebnisse unsere IKT-Risikostrategie und den Risikoappetit beeinflussen, wie Ergebnisse aus szenariobasierten Tests 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 aus Vorfallssimulationen unsere Verfahren zur Klassifizierung und Berichterstattung von Vorfällen validieren oder infrage stellen. Erstelle ein Prozessdiagramm, das die Rückkopplungsschleife zwischen Tests und Risikomanagement zeigt.“

Kontinuierliche Verbesserung der Tests

Ihr Testprogramm selbst sollte sich auf der Grundlage der Ergebnisse und sich ändernder Bedrohungen weiterentwickeln:

„Erstelle einen Prozess zur jährlichen Überprüfung des Testprogramms zur DORA-Konformität. Die Überprüfung sollte bewerten: Testabdeckung (haben wir alle kritischen Systeme und Funktionen wie geplant getestet?), Testwirksamkeit (haben die Tests echte Schwachstellen identifiziert? wie schneiden die Ergebnisse im Vergleich zu tatsächlichen Vorfällen ab?), Testeffizienz (nutzen wir Ressourcen effektiv? gibt es überschneidende oder redundante Tests?), Änderungen der Bedrohungslandschaft (spiegeln unsere Test-Szenarien aktuelle Bedrohungen wider?), seit der letzten Überprüfung hinzugefügte neue Systeme oder Dienste (sind sie im Testumfang enthalten?), regulatorisches Feedback oder Leitlinien zu Testerwartungen sowie empfohlene Programmanpassungen für den nächsten Zyklus. Erstelle eine Berichtsvorlage für die jährliche Überprüfung des Testprogramms zur Genehmigung durch das Leitungsorgan.“

Schritt 6: Verwaltung der Testlogistik und Governance

Testkalender und Koordination

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

„Erstelle einen jährlichen Resilienztestkalender für unser [Unternehmenstyp]. Ordne alle erforderlichen Testaktivitäten über das Jahr zu: Schwachstellen-Scans (vierteljährlich für kritische Systeme, monatlich für Systeme mit Internetzugriff), Penetrationstests (jährlich extern, jährlich intern, jährlich Anwendung), szenariobasierte Übungen (halbjährlich Tabletop, jährlich Simulation), Business-Continuity-Tests (jährliches Failover, jährliche Backup-Wiederherstellung) und TLPT-Vorbereitungsaktivitäten (falls zutreffend). Enthalten sein sollen: Ressourcenbedarf für jede Aktivität, Koordinationsanforderungen (Change-Freeze-Fenster, Einbeziehung von Geschäftseinheiten), Abhängigkeiten zwischen Testaktivitäten, Budgetzuweisung nach Quartalen und Meilensteine für die Berichterstattung an das Leitungsorgan. Formatiere dies als Kalenderansicht mit Gantt-Chart-Struktur.“

Tests bei Drittanbietern von IKT-Diensten

Artikel 26(3) befasst sich mit Tests, die IKT-Drittdienstleister einbeziehen. Koordinieren Sie die Testanforderungen mit Ihren Anbietern:

„Erstelle Verfahren zur Koordination von Resilienztests mit IKT-Drittanbietern unter DORA. Enthalten sein sollen: vertragliche Anforderungen für die Teilnahme des Anbieters an Tests (Link zu Vertragsklauseln gemäß Artikel 28), Benachrichtigungs- und Koordinationsverfahren für Anbieter, Tests bei geteilter Verantwortung (was wir testen vs. was der Anbieter testet), Umgang mit der Weigerung des Anbieters, an Tests teilzunehmen, alternative Testansätze, wenn direkte Tests beim Anbieter nicht möglich sind (synthetische Tests, vom Anbieter bereitgestellte Testberichte), TLPT unter Einbeziehung von Systemen von Drittanbietern (Sammeltestvereinbarungen gemäß Artikel 26(3)) sowie Sammlung von Nachweisen aus Testaktivitäten des Anbieters. Berücksichtige Szenarien für Cloud-Anbieter, Managed-Service-Provider und Anbieter kritischer Infrastrukturen.“

Nächste Schritte

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

• Rahmenwerk für das Testprogramm mit risikobasierter Methodik

• Detaillierte Pläne für Schwachstellenbewertungen, Penetrationstests und szenariobasierte Tests

• Anforderungen an die Qualifikation und Unabhängigkeit der Tester

• TLPT-Vorbereitungsrahmenwerk (falls benannt oder eine Benennung wahrscheinlich ist)

• Vorlagen für die Ergebnisberichterstattung an das Leitungsorgan und die zuständige Behörde

• Verfahren zur Verfolgung der Mängelbehebung

• Integration in den IKT-Risikomanagementrahmen

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

• „So verwalten Sie DORA-IKT-Drittanbieterrisiken mit KI“ – 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 „Erste Schritte bei der DORA-Implementierung mit KI“. Zum IKT-Risikorahmenwerk siehe „So erstellen Sie einen DORA IKT-Risikomanagementrahmen mit KI“. Zur Integration der Vorfallsberichterstattung siehe „So implementieren Sie die DORA-Vorfallsberichterstattung mit KI“.

Gebrauchsfertige Prompts finden Sie in der DORA Compliance Prompt Library. Einen vollständigen regulatorischen Überblick finden Sie im 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 Test-Szenarien zu erstellen, die spezifisch für Ihren Unternehmenstyp und Ihre IKT-Umgebung sind.

• Vorhandene Testberichte hochladen: Erhalten Sie eine Gap-Analyse, indem Sie frühere Penetrationstests oder Schwachstellenbewertungsberichte hochladen, um sie mit den DORA-Anforderungen abzugleichen.

• TLPT-Vorbereitung: Nutzen Sie ISMS Copilot, um Ihr Dokument zum TLPT-Umfang und die Kriterien zur Anbieterauswahl zu entwickeln, bevor Sie mit Ihrer zuständigen Behörde in Kontakt treten.

• Ergebnisse validieren: Überprüfen Sie alle Testpläne vor der Genehmigung durch das Leitungsorgan gegen die DORA-Artikel 24–27, relevante RTS und das TIBER-EU-Rahmenwerk.