Jak zaplanować testy odporności DORA z wykorzystaniem AI

Przegląd

Dowiesz się, jak zaprojektować i wdrożyć program testów odporności operacyjnej w cyfrowym środowisku, który spełnia wymogi artykułów 24-27 DORA z wykorzystaniem AI. Przewodnik obejmuje ogólny program testowy (oceny podatności, testy penetracyjne, testy scenariuszowe), zaawansowane wymagania dotyczące testów penetracyjnych prowadzonych przez zagrożenia (TLPT), zakres i częstotliwość testów, raportowanie wyników do organu zarządzającego, a także integrację testów z ramami zarządzania ryzykiem ICT, wraz z konkretnymi promptami ISMS Copilot do generowania każdego komponentu.

Dla kogo jest ten przewodnik

Ten przewodnik jest przeznaczony dla:

• Dyrektorów ds. bezpieczeństwa informacji (CISO) i menedżerów ds. bezpieczeństwa odpowiedzialnych za projektowanie i nadzorowanie programów testów odporności
• Menedżerów ds. ryzyka IT integrujących wyniki testów z ocenami ryzyka ICT
• Koordynatorów testów penetracyjnych zarządzających wewnętrznymi i zewnętrznymi działaniami testowymi
• Oficerów ds. zgodności zapewniających, że programy testowe spełniają oczekiwania regulacyjne
• Konsultantów pomagających podmiotom finansowym przygotować się do TLPT lub ogólnych testów odporności

Zanim zaczniesz

Będziesz potrzebować:

• Konta w ISMS Copilot (dostępna darmowa wersja próbna)
• Ram zarządzania ryzykiem ICT oraz inwentarz aktywów ICT z Jak zbudować ramy zarządzania ryzykiem ICT DORA z wykorzystaniem AI
• Procedur klasyfikacji i reagowania na incydenty z Jak wdrożyć raportowanie incydentów DORA z wykorzystaniem AI
• Zrozumienia obecnych działań testowych (skanowanie podatności, testy penetracyjne, testy odtwarzania po awarii)
• Wiedzy, czy Twój podmiot został wyznaczony do TLPT przez właściwy organ nadzoru
• Autoryzacji budżetowej na zewnętrzne usługi testowe (szczególnie w przypadku TLPT)

Zrozumienie wymogów DORA dotyczących testów odporności

Omówienie artykuł po artykule

Rozdział IV DORA (Artykuły 24-27) ustanawia ustrukturyzowane podejście do testów odporności operacyjnej w cyfrowym środowisku:

Article

Title

Key requirements

Applicability

Art 24

Ogólne wymagania dotyczące testów odporności operacyjnej w cyfrowym środowisku

Ustanowienie programu testowego jako części zarządzania ryzykiem ICT, podejście oparte na ryzyku

Wszystkie podmioty finansowe (proporcjonalnie)

Art 25

Testowanie narzędzi i systemów ICT

Konkretne typy testów: oceny podatności, testy penetracyjne, testy scenariuszowe, testy kompatybilności, testy wydajności, przeglądy kodu źródłowego

Wszystkie podmioty finansowe (proporcjonalnie)

Art 26

Zaawansowane testy poprzez TLPT

Testy penetracyjne prowadzone przez zagrożenia oparte na frameworku TIBER-EU, co 3 lata

Tylko wyznaczone podmioty

Art 27

Wymagania dla testerów

Kwalifikacje, niezależność i standardy dla testerów (wewnętrznych i zewnętrznych)

Wszystkie podmioty przeprowadzające testy

Ogólne testy vs. TLPT

Zrozumienie różnicy między ogólnymi testami a TLPT jest kluczowe dla określenia zakresu programu:

Aspect

Ogólne testy (Art 24-25)

TLPT (Art 26-27)

Key difference

Kto

Wszystkie podmioty finansowe

Tylko wyznaczone podmioty

Właściwy organ nadzoru wyznacza podmioty do TLPT

Częstotliwość

Opiera się na ryzyku; krytyczne systemy co najmniej raz w roku

Co najmniej co 3 lata

TLPT jest rzadsze, ale znacznie bardziej intensywne

Zakres

Wszystkie systemy ICT (proporcjonalnie)

Krytyczne i ważne funkcje, systemy produkcyjne

TLPT testuje systemy produkcyjne, a nie tylko środowiska testowe

Metodologia

Różne (skanowanie podatności, testy penetracyjne, testy scenariuszowe)

Framework TIBER-EU, prowadzone przez analizę zagrożeń

TLPT symuluje taktyki rzeczywistych przeciwników

Testerzy

Wewnętrzni lub zewnętrzni (z wymogami niezależności)

Wymagani zewnętrzni testerzy (z ograniczonymi wyjątkami)

TLPT wymaga certyfikowanego zewnętrznego zespołu czerwonego

Raportowanie

Wewnętrzne (organ zarządzający, funkcja ryzyka ICT)

Do właściwego organu nadzoru, z poświadczeniem

Wyniki TLPT trafiają do regulatora

Krok 1: Zaprojektuj ogólny program testowy (Artykuły 24-25)

Ramy programu testowego

Artykuł 24 wymaga programu testowego, który jest integralną częścią ram zarządzania ryzykiem ICT, opiera się na podejściu opartym na ryzyku i jest proporcjonalny do wielkości oraz profilu ryzyka podmiotu.

1. Otwórz swoją przestrzeń roboczą DORA w ISMS Copilot

2. Wygeneruj dokument programu testowego:

   "Utwórz Program Testów Odporności Operacyjnej w Cyfrowym Środowisku dla [typ podmiotu] spełniający wymogi Artykułów 24-25 DORA. Zawrzyj: cel i założenia programu, nadzór organu zarządzającego, właściciela programu, role i odpowiedzialności, podejście oparte na ryzyku do planowania testów (jak ryzyka determinują, co jest testowane i jak często), zakres testów (zmapowany do inwentarza aktywów ICT oraz krytycznych/ważnych funkcji), typy testów do przeprowadzenia (oceny podatności, testy bezpieczeństwa sieci, testy penetracyjne, testy scenariuszowe, testy kompatybilności, testy wydajności, przeglądy kodu źródłowego, testy oprogramowania open source, testy end-to-end), częstotliwość testów w zależności od krytyczności aktywów i typu testu, wymagania dotyczące testerów wewnętrznych vs. zewnętrznych, wymogi niezależności zgodnie z Artykułem 27, raportowanie wyników i komunikacja z organem zarządzającym, proces śledzenia napraw, integracja z aktualizacjami ram zarządzania ryzykiem ICT, szablon rocznego kalendarza testów oraz planowanie budżetu i zasobów. Zastosuj proporcjonalność dla organizacji [rozmiar podmiotu]."

3. Zdefiniuj metodologię testów opartą na ryzyku:

   "Utwórz metodologię testów opartą na ryzyku dla testów odporności DORA. Określ, jak ustalamy: które systemy i funkcje testować (na podstawie krytyczności aktywów ICT, wpływu na biznes, krajobrazu zagrożeń, wcześniejszych incydentów), jaki typ testów zastosować (skanowanie podatności vs. test penetracyjny vs. test scenariuszowy), głębokość i intensywność testów (podstawowa, standardowa, zaawansowana), częstotliwość testów (kwartalna, półroczna, roczna) oraz priorytety testów przy ograniczonych zasobach. Dostarcz macierz priorytetów testów, która mapuje krytyczność aktywów i poziom zagrożenia na typ i częstotliwość testów. Dołącz przykłady dla [typ podmiotu]."

Typy testów i ich zastosowanie

Artykuł 25 określa wiele typów testów. Użyj ISMS Copilot, aby opracować szczegółowe plany dla każdego z nich:

1. Program oceny podatności:

   "Utwórz program oceny podatności dla zgodności z Artykułem 25 DORA. Zawrzyj: zakres skanowania (wszystkie aktywa ICT według poziomu krytyczności), narzędzia i metodologię skanowania, częstotliwość skanowania (co najmniej kwartalnie dla krytycznych aktywów, zalecane miesięcznie), klasyfikację podatności zgodną z oceną CVSS, terminy naprawy według poziomu ważności (krytyczne: 48 godzin, wysokie: 7 dni, średnie: 30 dni, niskie: 90 dni), proces zarządzania wyjątkami dla podatności, których nie można natychmiast naprawić, format raportowania (raport techniczny i podsumowanie dla zarządu), metodologię analizy trendów oraz integrację z procedurami zarządzania łatkami. Dostarcz schemat przepływu pracy zarządzania podatnościami."

2. Program testów penetracyjnych:

   "Utwórz program testów penetracyjnych dla zgodności z Artykułem 25 DORA. Zawrzyj: zakres testów (perymetr zewnętrzny, sieć wewnętrzna, aplikacje webowe, aplikacje mobilne, bezpieczeństwo API, inżynieria społeczna), częstotliwość testów (co najmniej rocznie dla systemów krytycznych, częściej dla obszarów wysokiego ryzyka), metodologię testów (OWASP, PTES lub równoważna), szablon zasad zaangażowania (zakres, czas, eskalacja, zabronione działania), wymagania dotyczące kwalifikacji testerów zgodnie z Artykułem 27 DORA (niezależność, kompetencje, ubezpieczenie), procedury przed testem (autoryzacja, potwierdzenie zakresu, komunikacja), wymagania dotyczące raportowania (podsumowanie dla zarządu, wyniki techniczne, oceny ryzyka, zalecenia dotyczące napraw), procedury po teście (weryfikacja napraw, ponowne testy) oraz format raportowania dla organu zarządzającego. Dostarcz przykładowy szablon zasad zaangażowania."

3. Program testów scenariuszowych:

   "Zaprojektuj program testów odporności scenariuszowych dla zgodności z Artykułem 25 DORA. Utwórz scenariusze testowe obejmujące: atak ransomware na podstawowe systemy bankowe/płatnicze, awarię głównego dostawcy chmury wpływającą na krytyczne usługi, atak DDoS podczas szczytowych okresów transakcyjnych, zagrożenie wewnętrzne kompromitujące poufne dane, atak na łańcuch dostaw poprzez krytycznego dostawcę ICT, jednoczesną awarię systemów podstawowych i zapasowych, utratę kluczowego personelu ICT podczas incydentu, naruszenie danych regulacyjnych wymagające powiadomienia klientów. Dla każdego scenariusza zdefiniuj: cele testu, zakres i zaangażowane systemy, narrację scenariusza i harmonogram wprowadzania zdarzeń, kryteria sukcesu, uczestników i role, procedury wykonania testu, oczekiwane wyniki, kryteria oceny oraz szablon raportowania. Uwzględnij zarówno formaty ćwiczeń typu tabletop, jak i symulacji."

Krok 2: Ustal wymagania dla testerów (Artykuł 27)

Niezależność i kwalifikacje testerów

Artykuł 27 określa wymagania dla testerów przeprowadzających testy odporności. Dotyczą one zarówno testerów wewnętrznych, jak i zewnętrznych:

"Utwórz politykę wymagań i kwalifikacji testerów dla zgodności z Artykułem 27 DORA. Uwzględnij: testerów wewnętrznych (niezależność od obszarów testowanych, odpowiednie certyfikaty takie jak OSCP/CREST/GPEN, utrzymywanie kompetencji, wymogi rotacji), testerów zewnętrznych (profesjonalne certyfikaty i akredytacje, odpowiednie doświadczenie w testach sektora finansowego, ubezpieczenie od odpowiedzialności cywilnej zawodowej, weryfikacja niezależności, sprawdzanie referencji), zarządzanie konfliktem interesów, procedury weryfikacji i sprawdzania bezpieczeństwa testerów, wymogi dotyczące poufności i niedyskrecji oraz kryteria oceny wydajności testerów. Dostarcz checklistę kwalifikacji testerów zarówno dla wewnętrznych, jak i zewnętrznych testerów oraz przykładowe zapytanie ofertowe (SOW) dla zewnętrznych zaangażowań testowych."

Krok 3: Zaplanuj TLPT (Artykuły 26-27)

Zrozumienie wymogów TLPT

Testy penetracyjne prowadzone przez zagrożenia (TLPT) w ramach DORA oparte są na frameworku TIBER-EU i stanowią najbardziej intensywne wymaganie testowe. Nawet jeśli nie zostałeś wyznaczony do TLPT, zrozumienie wymogów jest cenne dla przygotowań.

1. Oceń stosowalność TLPT:

   "Oceń, czy nasz [typ podmiotu] o [rozmiarze, znaczeniu systemowym, profilu ryzyka ICT] prawdopodobnie zostanie wyznaczony do TLPT DORA zgodnie z Artykułem 26. Weź pod uwagę: nasze znaczenie systemowe w sektorze finansowym, krytyczność świadczonych usług, nasz profil ryzyka ICT i złożoność, kryteria wyznaczania przez właściwy organ nadzoru z opublikowanych wytycznych. Jeśli prawdopodobne jest wyznaczenie, dostarcz ocenę gotowości do TLPT i harmonogram przygotowań. Jeśli jest to mało prawdopodobne, zalec środki przygotowawcze, które powinniśmy podjąć mimo wszystko."

2. Wygeneruj framework TLPT:

   "Utwórz framework przygotowania i realizacji TLPT dla zgodności z Artykułem 26 DORA, zgodny z metodologią TIBER-EU. Zawrzyj: Faza 1 - Przygotowanie: definicja zakresu (krytyczne i ważne funkcje do testowania na żywych systemach produkcyjnych), zaangażowanie i powiadomienie właściwego organu nadzoru, wybór dostawcy analizy zagrożeń, wybór dostawcy zespołu czerwonego, utworzenie zespołu białego (wewnętrzny zespół świadomy testu), zatwierdzenia wewnętrzne. Faza 2 - Analiza zagrożeń: raport z analizy zagrożeń (analiza ukierunkowanego krajobrazu zagrożeń), scenariusze zagrożeń oparte na aktualnych aktorach i technikach zagrożeń, analiza powierzchni ataku oraz przegląd scenariuszy zagrożeń przez właściwy organ nadzoru. Faza 3 - Testy zespołu czerwonego: zaangażowanie zespołu czerwonego (symulowane ataki na żywe systemy produkcyjne), wykonanie testu przez [typowy czas trwania: 8-12 tygodni], kontrolowane testy z mechanizmami bezpieczeństwa, działania zespołu fioletowego (jeśli uzgodniono) oraz dokumentacja wyników. Faza 4 - Zamknięcie: raport zespołu czerwonego z wynikami i dowodami, ocena reakcji zespołu niebieskiego, opracowanie planu naprawczego, briefing dla organu zarządzającego, proces poświadczania przez właściwy organ nadzoru. Dostarcz szacunkowe terminy i wymagania dotyczące zasobów dla każdej fazy."

Wybór dostawców TLPT

TLPT wymaga zarówno dostawcy analizy zagrożeń, jak i dostawcy zespołu czerwonego. Użyj ISMS Copilot, aby opracować kryteria wyboru:

"Utwórz framework wyboru dostawców TLPT dla zgodności z Artykułami 26-27 DORA. Dla dostawcy analizy zagrożeń: wymagane kwalifikacje (ekspertyza w zakresie zagrożeń specyficznych dla sektora finansowego, uznane certyfikaty), kryteria oceny (jakość wcześniejszych raportów o zagrożeniach, zrozumienie zagrożeń dla sektora finansowego UE, źródła danych i możliwości zbierania informacji) oraz checklistę wyboru. Dla dostawcy zespołu czerwonego: wymagane kwalifikacje (akredytacja CREST, CBEST lub równoważna, doświadczenie w testach TIBER-EU, doświadczenie w sektorze finansowym), kryteria oceny (możliwości techniczne, metodologia, skład zespołu, historia bezpieczeństwa), weryfikacja niezależności (brak obecnej relacji doradczej z podmiotem), wymogi ubezpieczeniowe oraz checklistę wyboru. Dostarcz szablon zapytania ofertowego (RFP) dla obu typów dostawców."

Zakres TLPT

Odpowiednie określenie zakresu jest kluczowe dla sukcesu TLPT. Użyj ISMS Copilot, aby zdefiniować zakres testów:

"Pomóż nam zdefiniować zakres naszego ćwiczenia TLPT DORA. Nasze krytyczne i ważne funkcje obejmują: [lista funkcji]. Dla każdej krytycznej funkcji określ: wspierające systemy i infrastrukturę ICT, które powinny być w zakresie, przepływy danych i integracje, które mogą być ścieżkami ataku, dostawców ICT wspierających funkcję (i czy powinni być włączeni do testów zgodnie z Artykułem 26(3)), potencjalne powierzchnie ataku (zewnętrzne, wewnętrzne, fizyczne, inżynieria społeczna) oraz systemy, które powinny być wyraźnie wyłączone ze względów bezpieczeństwa. Przygotuj dokument zakresu TLPT odpowiedni do przeglądu przez właściwy organ nadzoru."

Krok 4: Raportowanie wyników i śledzenie napraw

Raportowanie wyników testów do zarządu

DORA wymaga, aby wyniki testów były raportowane do organu zarządzającego i wykorzystywane do aktualizacji ram zarządzania ryzykiem ICT:

1. Wygeneruj szablony raportów z wyników testów:

   "Utwórz szablon raportu z wyników testów odporności do raportowania organowi zarządzającemu zgodnie z Artykułem 24 DORA. Zawrzyj: podsumowanie wykonawcze (ogólna postawa odporności, kluczowe wyniki, porównanie trendów), podsumowanie wykonania programu testowego (przeprowadzone testy, zakres, czas), wyniki według poziomu ważności (krytyczne, wysokie, średnie, niskie) z kontekstem wpływu na biznes, porównanie z poprzednimi cyklami testowymi (poprawa lub pogorszenie), status naprawy wcześniej zidentyfikowanych podatności, nowe zalecenia naprawcze z priorytetyzacją opartą na ryzyku, ocena skuteczności programu testowego, wykorzystanie budżetu i zasobów oraz zalecenia dotyczące dostosowań programu testowego. Raport powinien być odpowiedni dla członków zarządu nietechnicznych, zachowując jednocześnie wystarczający poziom szczegółowości dla nadzoru ryzyka."

2. Utwórz dokumentację poświadczającą TLPT:

   "Utwórz pakiet dokumentacji poświadczającej TLPT do przedłożenia właściwemu organowi nadzoru zgodnie z Artykułem 26(6) DORA. Zawrzyj: podsumowanie TLPT (zakres, metodologia, harmonogram), zanonimizowane wyniki zespołu czerwonego (krytyczne i wysokie poziomy ważności), plan naprawczy z harmonogramem i statusem, potwierdzenie i zatwierdzenie przez organ zarządzający, wnioski organizacyjne oraz wszelkie wnioski o wzajemne uznanie z innymi właściwymi organami nadzoru. Postępuj zgodnie z wytycznymi dotyczącymi formatu od [właściwy organ nadzoru] oraz frameworku TIBER-EU."

Śledzenie napraw

Testy mają wartość tylko wtedy, gdy ich wyniki prowadzą do poprawy. Ustanów solidne śledzenie napraw:

"Utwórz procedurę śledzenia napraw wyników testów odporności dla zgodności z DORA. Zawrzyj: jak wyniki są przekładane na działania naprawcze, metodologię priorytetyzacji (krytyczne: naprawić w ciągu 30 dni, wysokie: 60 dni, średnie: 90 dni, niskie: w następnym cyklu testowym), przypisanie właściciela naprawy i odpowiedzialność, śledzenie postępów i eskalację w przypadku opóźnionych napraw, testy weryfikacyjne (potwierdzające skuteczność poprawek), proces wyjątków dla wyników, których nie można naprawić (kompensacyjne środki kontroli, akceptacja ryzyka z zatwierdzeniem przez organ zarządzający), integrację z rejestrem ryzyka ICT (aktualizacja ocen ryzyka na podstawie wyników testów) oraz częstotliwość raportowania do organu zarządzającego. Dostarcz szablon rejestru śledzenia napraw."

Krok 5: Zintegruj testy z ramami zarządzania ryzykiem ICT

Przekazywanie wyników do zarządzania ryzykiem

DORA wymaga, aby wyniki testów informowały i aktualizowały ramy zarządzania ryzykiem ICT. Użyj ISMS Copilot, aby sformalizować tę integrację:

"Zdefiniuj, jak wyniki testów odporności integrują się z naszymi ramami zarządzania ryzykiem ICT DORA. Zawrzyj: jak wyniki testów aktualizują rejestr ryzyka ICT (nowe zidentyfikowane ryzyka, dostosowane oceny ryzyka, ponowna ocena skuteczności kontroli), jak wyniki testów wpływają na roczny przegląd ram zarządzania ryzykiem ICT zgodnie z Artykułem 6(5), jak wyniki TLPT wpływają na naszą strategię ryzyka ICT i apetyt na ryzyko, jak wyniki testów scenariuszowych aktualizują nasze plany ciągłości działania i odtwarzania po awarii, jak trendy z ocen podatności wpływają na nasze środki ochrony i zapobiegania zgodnie z Artykułem 9 oraz jak wyniki symulacji incydentów walidują lub podważają nasze procedury klasyfikacji i raportowania incydentów. Dostarcz schemat procesu pokazujący pętlę sprzężenia zwrotnego między testami a zarządzaniem ryzykiem."

Ciągłe doskonalenie testów

Twój program testowy powinien ewoluować na podstawie wyników i zmieniających się zagrożeń:

"Utwórz proces rocznego przeglądu programu testowego dla zgodności z DORA. Przegląd powinien oceniać: pokrycie testami (czy przetestowaliśmy wszystkie krytyczne systemy i funkcje zgodnie z planem?), skuteczność testów (czy testy zidentyfikowały rzeczywiste podatności? jak wyniki odnoszą się do faktycznych incydentów?), efektywność testów (czy efektywnie wykorzystujemy zasoby? czy występują nakładające się lub zbędne testy?), zmiany w krajobrazie zagrożeń (czy nasze scenariusze testowe odzwierciedlają aktualne zagrożenia?), nowe systemy lub usługi dodane od ostatniego przeglądu (czy są uwzględnione w zakresie testów?), opinie regulacyjne lub wytyczne dotyczące oczekiwań testowych oraz zalecane dostosowania programu na kolejny cykl. Przygotuj szablon rocznego raportu przeglądu programu testowego do zatwierdzenia przez organ zarządzający."

Krok 6: Zarządzaj logistyką i nadzorem testów

Kalendarz testów i koordynacja

Ustal ustrukturyzowany roczny kalendarz testów, aby zapewnić, że wszystkie działania testowe są zaplanowane, mają przydzielone zasoby i są skoordynowane:

"Utwórz roczny kalendarz testów odporności dla naszego [typ podmiotu]. Zmapuj wszystkie wymagane działania testowe w ciągu roku: skanowanie podatności (kwartalne dla krytycznych, miesięczne dla systemów dostępnych z internetu), testy penetracyjne (roczne zewnętrzne, roczne wewnętrzne, roczne aplikacji), ćwiczenia scenariuszowe (półroczne typu tabletop, roczne symulacje), testy ciągłości działania (roczne przełączenie awaryjne, roczne odtwarzanie kopii zapasowych) oraz działania przygotowawcze do TLPT (jeśli dotyczy). Zawrzyj: wymagania dotyczące zasobów dla każdej aktywności, wymagania koordynacyjne (okna zamrożenia zmian, zaangażowanie jednostek biznesowych), zależności między działaniami testowymi, alokację budżetu według kwartału oraz kamienie milowe raportowania do organu zarządzającego. Sformatuj jako widok kalendarza z strukturą wykresu Gantta."

Testowanie dostawców ICT zewnętrznych

Artykuł 26(3) dotyczy testów obejmujących zewnętrznych dostawców usług ICT. Koordynuj wymagania testowe z dostawcami:

"Utwórz procedury koordynacji testów odporności z zewnętrznymi dostawcami ICT zgodnie z DORA. Zawrzyj: wymagania kontraktowe dotyczące udziału dostawcy w testach (odnośnik do klauzul kontraktowych Artykułu 28), procedury powiadamiania i koordynacji z dostawcą, testowanie podzielonej odpowiedzialności (co testujemy my, a co dostawca), postępowanie w przypadku odmowy udziału w testach przez dostawcę, alternatywne podejścia do testów, gdy bezpośrednie testowanie dostawcy nie jest możliwe (testy syntetyczne, raporty testowe dostarczone przez dostawcę), TLPT obejmujące systemy dostawcy zewnętrznego (Artykuł 26(3) - ustalenia dotyczące testów grupowych) oraz zbieranie dowodów z działań testowych dostawcy. Uwzględnij scenariusze dla dostawców chmury, dostawców usług zarządzanych oraz dostawców krytycznej infrastruktury."

Następne kroki

Masz teraz kompleksowy program testów odporności operacyjnej w cyfrowym środowisku:

• Ramy programu testowego z metodologią opartą na ryzyku
• Szczegółowe plany oceny podatności, testów penetracyjnych i testów scenariuszowych
• Wymagania dotyczące kwalifikacji i niezależności testerów
• Framework przygotowania do TLPT (jeśli jesteś wyznaczony lub prawdopodobnie zostaniesz wyznaczony)
• Szablony raportowania wyników dla organu zarządzającego i właściwego organu nadzoru
• Procedury śledzenia napraw
• Integrację z ramami zarządzania ryzykiem ICT

Kontynuuj ostatnim przewodnikiem z tej serii DORA:

• Jak zarządzać ryzykiem ICT od stron trzecich w DORA z wykorzystaniem AI -- Upewnij się, że Twoi dostawcy zewnętrzni są uwzględnieni w programie testowym i że kontrakty wspierają Twoje obowiązki testowe

Aby uzyskać podstawową konfigurację, zobacz Jak rozpocząć wdrażanie DORA z wykorzystaniem AI. W przypadku ram zarządzania ryzykiem ICT, zobacz Jak zbudować ramy zarządzania ryzykiem ICT DORA z wykorzystaniem AI. W celu integracji raportowania incydentów, zobacz Jak wdrożyć raportowanie incydentów DORA z wykorzystaniem AI.

Aby uzyskać gotowe do użycia prompty, zobacz DORA Compliance Prompt Library. Pełny przegląd regulacyjny znajdziesz w DORA Compliance Guide for Financial Entities.

Uzyskanie pomocy

Aby uzyskać dodatkowe wsparcie w planowaniu programu testów odporności:

• Zapytaj ISMS Copilot: Użyj swojej przestrzeni roboczej DORA, aby wygenerować scenariusze testowe specyficzne dla typu Twojego podmiotu i środowiska ICT
• Prześlij istniejące raporty testowe: Uzyskaj analizę luk poprzez przesłanie poprzednich raportów z testów penetracyjnych lub ocen podatności w celu porównania z wymogami DORA
• Przygotowanie do TLPT: Użyj ISMS Copilot, aby opracować dokument zakresu TLPT i kryteria wyboru dostawców przed kontaktem z właściwym organem nadzoru
• Weryfikuj wyniki: Przejrzyj wszystkie plany testowe pod kątem zgodności z Artykułami 24-27 DORA, odpowiednimi RTS oraz frameworkiem TIBER-EU przed zatwierdzeniem przez organ zarządzający