Strategie wyjścia DORA dla usług ICT z kontrolami ISO 27001

O 07:42 w poniedziałek osoba odpowiedzialna za operacje w fintechu otrzymuje wiadomość, której nikt nie chce przeczytać: dostawca chmurowej usługi monitorowania transakcji doświadczył poważnej awarii regionalnej. O 08:15 dyrektor ds. ryzyka pyta, czy dotknięta usługa wspiera funkcję krytyczną lub istotną. O 08:40 dział prawny chce wiedzieć, czy umowa zapewnia firmie wsparcie przejścia, eksport danych, usunięcie danych oraz prawa audytowe. O 09:05 CISO szuka dowodów, że plan wyjścia został przetestowany, a nie tylko opisany.

W innej firmie świadczącej usługi finansowe Sarah, CISO szybko rosnącej platformy fintech, otwiera przed audytem wniosek o informacje do oceny zgodności z DORA. Pytania są znajome, dopóki nie pojawia się sekcja dotycząca zewnętrznych dostawców usług ICT wspierających funkcje krytyczne lub istotne. Audytorzy nie pytają, czy spółka ma politykę dostawców. Pytają o udokumentowane, przetestowane i wykonalne strategie wyjścia.

Jej myśli natychmiast kierują się do głównego dostawcy chmury, który hostuje platformę, a następnie do dostawcy zarządzanych usług bezpieczeństwa monitorującego zagrożenia przez całą dobę. Co, jeśli dostawca chmury doświadczy zakłócenia geopolitycznego? Co, jeśli MSSP zostanie przejęty przez konkurenta? Co, jeśli krytyczny dostawca SaaS stanie się niewypłacalny, zakończy świadczenie usługi albo utraci zaufanie klientów po poważnym incydencie?

Niewygodna odpowiedź w wielu firmach jest taka sama. Istnieje ocena ryzyka dostawcy, plan ciągłości działania, folder z umową, inwentarz usług chmurowych i być może raport z kopii zapasowych. Nie ma jednak jednej, gotowej do audytu strategii wyjścia DORA dla zewnętrznego dostawcy usług ICT, która łączy krytyczność biznesową, prawa umowne, techniczną przenośność, plany ciągłości, dowody dotyczące kopii zapasowych, obowiązki w zakresie prywatności oraz akceptację kierownictwa.

DORA zmienia sposób myślenia o zarządzaniu dostawcami. Zgodnie z Rozporządzeniem (UE) 2022/2554 podmioty finansowe muszą zarządzać ryzykiem związanym z zewnętrznymi dostawcami usług ICT jako częścią ram zarządzania ryzykiem ICT. Pozostają w pełni odpowiedzialne za zgodność, utrzymują rejestr umów dotyczących usług ICT, odróżniają uzgodnienia ICT wspierające funkcje krytyczne lub istotne, oceniają ryzyko koncentracji i podwykonawstwa oraz utrzymują strategie wyjścia dla krytycznych zależności od zewnętrznych dostawców usług ICT. DORA ma zastosowanie od 17 stycznia 2025 r. i ustanawia jednolite wymagania UE dotyczące zarządzania ryzykiem ICT, zgłaszania incydentów, testowania odporności, wymiany informacji oraz zarządzania ryzykiem zewnętrznych dostawców ICT w szerokim zakresie podmiotów finansowych.

Strategia wyjścia DORA nie jest akapitem w umowie z dostawcą. To system kontroli. Musi podlegać nadzorowi, wynikać z oceny ryzyka, być technicznie wykonalna, egzekwowalna umownie, przetestowana, udokumentowana dowodami i stale doskonalona.

Podejście Clarysec łączy Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, szablony polityk dla przedsiębiorstw oraz Zenith Controls: The Cross-Compliance Guide Zenith Controls, aby poniedziałkowe pytanie zamienić w przygotowaną odpowiedź.

Dlaczego strategie wyjścia DORA zawodzą w rzeczywistych audytach

Większość niepowodzeń strategii wyjścia DORA dla ICT ma charakter strukturalny, zanim stanie się problemem technicznym. Organizacja ma właściciela dostawcy, ale nie ma rozliczalnego właściciela ryzyka. Ma zadania tworzenia kopii zapasowych, ale nie ma dowodów odtworzenia. Ma kwestionariusz due diligence dostawcy, ale nie ma udokumentowanej decyzji, czy dostawca wspiera funkcję krytyczną lub istotną. Ma postanowienia dotyczące rozwiązania umowy, ale nie ma okresu przejściowego uzgodnionego z planem ciągłości działania.

DORA łączy te elementy. Article 28 określa ogólne zasady zarządzania ryzykiem związanym z zewnętrznymi dostawcami usług ICT, w tym konieczność zarządzania tym ryzykiem przez cały cykl życia oraz utrzymywania odpowiednich strategii wyjścia. Article 30 ustanawia szczegółowe wymagania umowne dla usług ICT wspierających funkcje krytyczne lub istotne, w tym opisy usług, lokalizacje przetwarzania danych, środki ochrony bezpieczeństwa, prawa dostępu i audytu, wsparcie w razie incydentu, współpracę z właściwymi organami oraz prawa do rozwiązania umowy.

Rozporządzenie jest również proporcjonalne. Articles 4 and 16 pozwalają niektórym mniejszym lub zwolnionym podmiotom stosować uproszczone ramy zarządzania ryzykiem ICT. Uproszczenie nie oznacza jednak braku dokumentacji. Mniejsze podmioty finansowe nadal potrzebują udokumentowanego zarządzania ryzykiem ICT, ciągłego monitorowania, odpornych systemów, szybkiej identyfikacji incydentów ICT, identyfikacji kluczowych zależności od zewnętrznych dostawców usług ICT, tworzenia i odtwarzania kopii zapasowych, ciągłości działania, reagowania i odzyskiwania, testów, wniosków z doświadczeń oraz szkoleń.

Mały fintech nie może powiedzieć: „Jesteśmy za mali na planowanie wyjścia”. Może powiedzieć: „Nasza strategia wyjścia DORA jest skalowana do naszej wielkości, profilu ryzyka i złożoności usług”. Różnicę stanowią dowody.

W przypadku podmiotów objętych również krajowym zakresem NIS2, DORA działa jako sektorowy akt prawny Unii dla nakładających się obowiązków cyberbezpieczeństwa w sektorze finansowym. NIS2 nadal ma znaczenie w szerszym ekosystemie, zwłaszcza dla dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa, dostawców chmury, centrów danych oraz podmiotów infrastruktury cyfrowej. NIS2 Article 21 wzmacnia te same obszary: analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczne nabywanie, ocenę skuteczności, szkolenia, kryptografię, kontrolę dostępu, zarządzanie aktywami oraz uwierzytelnianie.

Organy nadzoru, klienci, audytorzy i rady nadzorcze mogą zadawać pytanie w różny sposób, ale zasadniczy problem pozostaje ten sam: czy można zakończyć korzystanie z krytycznego dostawcy ICT bez utraty kontroli nad ciągłością usługi, danymi, dowodami lub wpływem na klientów?

Włącz strategię wyjścia do SZBI

ISO/IEC 27001:2022 zapewnia podstawę systemu zarządzania dla planowania wyjścia DORA.

Klauzule 4.1–4.4 wymagają, aby organizacja określiła swój kontekst, strony zainteresowane, wymagania prawne, regulacyjne i umowne, zakres SZBI, interfejsy, zależności oraz procesy. To tutaj podmiot finansowy identyfikuje DORA, zobowiązania wobec klientów, oczekiwania dotyczące outsourcingu, zależności od chmury, obowiązki w zakresie prywatności, podwykonawców i usługi ICT w granicach SZBI.

Klauzule 5.1–5.3 wymagają przywództwa, polityki, zasobów, przypisania ról i rozliczalności. Jest to zgodne z modelem ładu zarządczego DORA, w którym organ zarządzający definiuje, zatwierdza, nadzoruje i pozostaje odpowiedzialny za zarządzanie ryzykiem ICT, w tym ciągłość działania ICT, plany reagowania i odzyskiwania, plany audytu ICT, budżety, strategię odporności oraz politykę ryzyka związanego z zewnętrznymi dostawcami usług ICT.

Klauzule 6.1.1–6.1.3 przekształcają planowanie wyjścia w postępowanie z ryzykiem. Organizacja definiuje kryteria ryzyka, przeprowadza powtarzalne oceny ryzyka, identyfikuje ryzyka dla poufności, integralności i dostępności, przypisuje właścicieli ryzyka, ocenia konsekwencje i prawdopodobieństwo, wybiera opcje postępowania, porównuje kontrole z Załącznikiem A, opracowuje Deklarację stosowania, przygotowuje plan postępowania z ryzykiem oraz uzyskuje akceptację właściciela ryzyka i akceptację ryzyka rezydualnego.

Klauzula 8.1 wymaga następnie planowania i kontroli operacyjnej. Organizacja musi planować, wdrażać i kontrolować procesy SZBI, utrzymywać udokumentowane informacje wykazujące, że procesy przeprowadzono zgodnie z planem, zarządzać zmianami oraz kontrolować zewnętrznie dostarczane procesy, produkty lub usługi istotne dla SZBI.

ISO/IEC 27005:2022 wzmacnia to podejście. Klauzula 6.2 zaleca organizacjom identyfikowanie wymagań stron zainteresowanych, w tym kontroli z Załącznika A ISO/IEC 27001:2022, norm sektorowych, regulacji krajowych i międzynarodowych, zasad wewnętrznych, wymagań umownych oraz istniejących kontroli wynikających z wcześniejszego postępowania z ryzykiem. Klauzule 6.4.1–6.4.3 wyjaśniają, że kryteria ryzyka powinny uwzględniać aspekty prawne i regulacyjne, relacje z dostawcami, prywatność, skutki operacyjne, naruszenia umów, działania stron trzecich oraz konsekwencje reputacyjne. Klauzule 8.2–8.6 wspierają bibliotekę kontroli i plan postępowania, które mogą łączyć Załącznik A ISO/IEC 27001:2022 z DORA, NIS2, GDPR, zobowiązaniami wobec klientów oraz politykami wewnętrznymi.

Model operacyjny jest prosty: jeden inwentarz wymagań, jeden rejestr ryzyk dostawców, jedna Deklaracja stosowania, jeden plan postępowania z ryzykiem i jeden pakiet dowodowy dla każdego krytycznego scenariusza wyjścia.

Kontrole ISO/IEC 27001:2022 stanowiące podstawę planowania wyjścia DORA

Strategie wyjścia DORA stają się gotowe do audytu, gdy nadzór nad dostawcami, przenośność chmury, planowanie ciągłości oraz dowody dotyczące kopii zapasowych są traktowane jako jeden powiązany łańcuch kontroli.

Zenith Controls Clarysec mapuje kontrole z Załącznika A ISO/IEC 27001:2022 na atrybuty kontroli, dowody audytowe oraz oczekiwania zgodności przekrojowej. Nie jest to odrębny zestaw ram kontroli. To przewodnik Clarysec po zgodności przekrojowej, pokazujący, jak kontrole ISO/IEC 27001:2022 wspierają wyniki audytowe, regulacyjne i operacyjne.

W przypadku strategii wyjścia DORA dla zewnętrznego dostawcy usług ICT ścieżka audytowa powinna wykazywać, że:

• Dostawca jest sklasyfikowany i powiązany z procesami biznesowymi.
• Usługa została oceniona pod kątem wspierania funkcji krytycznej lub istotnej.
• Ryzyko wyjścia jest zarejestrowane wraz z rozliczalnym właścicielem ryzyka.
• Klauzule umowne wspierają przejście, dostęp, audyt, zwrot danych, usunięcie danych, współpracę i ciągłość.
• Przenośność i interoperacyjność chmury zostały zwalidowane.
• Kopie zapasowe i testy odtwarzania potwierdzają możliwość odzyskania danych.
• Udokumentowano tymczasowe zastąpienie lub alternatywne przetwarzanie.
• Wyniki testów wyjścia zostały przejrzane, objęte działaniami naprawczymi i zaraportowane kierownictwu.

Język umowy jest pierwszą kontrolą ciągłości

Umowa powinna być pierwszą kontrolą ciągłości, a nie barierą dla ciągłości. Jeżeli dostawca może szybko rozwiązać umowę, opóźnić eksport, ograniczyć dostęp do logów, naliczyć niezdefiniowane opłaty przejściowe lub odmówić wsparcia migracji, strategia wyjścia jest krucha.

W Zenith Blueprint, w fazie Kontrole w działaniu, krok 23, kontrola 5.20, wyjaśniono, że umowy z dostawcami powinny obejmować praktyczne wymagania bezpieczeństwa, które umożliwiają wyjście:

Kluczowe obszary zwykle uwzględniane w umowach z dostawcami obejmują:

✓ Obowiązki dotyczące poufności, w tym zakres, czas trwania oraz ograniczenia ujawniania stronom trzecim;

✓ Odpowiedzialności w zakresie kontroli dostępu, takie jak to, kto może uzyskać dostęp do danych, jak zarządzane są dane uwierzytelniające i jakie monitorowanie jest stosowane;

✓ Środki techniczne i organizacyjne dotyczące ochrony danych, szyfrowania, bezpiecznej transmisji, tworzenia kopii zapasowych oraz zobowiązań dostępnościowych;

✓ Terminy i protokoły zgłaszania incydentów, często z określonymi ramami czasowymi;

✓ Prawo do audytu, w tym częstotliwość, zakres oraz dostęp do odpowiednich dowodów;

✓ Kontrole podwykonawców, wymagające od dostawcy przeniesienia równoważnych obowiązków bezpieczeństwa na swoich partnerów niższego szczebla;

✓ Postanowienia końcowe umowy, takie jak zwrot lub zniszczenie danych, odzyskanie aktywów oraz dezaktywacja kont.

Ta lista łączy oczekiwania umowne DORA Article 30 z kontrolą A.5.20 z Załącznika A ISO/IEC 27001:2022.

Język polityk korporacyjnych Clarysec przedstawia tę samą zasadę w sposób operacyjny. W Polityce zarządzania ryzykiem zależności od dostawców Polityka zarządzania ryzykiem zależności od dostawców, w sekcji „Wymagania wdrożeniowe”, klauzula 6.4.3 stanowi:

Techniczne rozwiązania awaryjne: należy zapewnić przenośność i interoperacyjność danych w celu wsparcia przejścia usługi, jeżeli będzie to wymagane (np. regularne kopie zapasowe w standardowych formatach od dostawcy SaaS umożliwiające migrację).

Ta sama polityka, klauzula 6.8.2, wymaga:

Prawa do wsparcia przejścia (klauzula wsparcia wyjścia), gdy wymagana jest zmiana dostawcy, w tym utrzymania świadczenia usługi przez określony okres przejściowy.

Ta klauzula często decyduje, czy strategia wyjścia przejdzie audyt. Zamienia wyjście z nagłego odcięcia w zarządzane przejście.

W przypadku mniejszych podmiotów Polityka bezpieczeństwa dostawców i stron trzecich dla MŚP Polityka bezpieczeństwa dostawców i stron trzecich dla MŚP, sekcja „Wymagania ładu zarządczego”, klauzula 5.3.6, wymaga:

Warunków rozwiązania umowy, w tym bezpiecznego zwrotu lub zniszczenia danych

W środowiskach korporacyjnych Polityka bezpieczeństwa dostawców i stron trzecich Polityka bezpieczeństwa dostawców i stron trzecich, sekcja „Wymagania wdrożeniowe polityki”, klauzula 6.5.1.2 wymaga:

Zwrotu lub certyfikowanego zniszczenia wszystkich informacji będących własnością organizacji

Wymagania polityki powinny mieć bezpośrednie odwzorowanie w klauzulach umownych, procedurach dostawców, podręcznikach operacyjnych wyjścia oraz dowodach audytowych.

Wyjście z chmury: przetestuj przenośność, zanim będzie potrzebna

Usługi chmurowe to obszar, w którym strategie wyjścia DORA często stają się nieprecyzyjne. Firma zakłada, że może wyeksportować dane, ale nikt nie przetestował formatu. Zakłada, że usunięcie nastąpi, lecz model retencji dostawcy obejmuje kopie zapasowe i zreplikowane zasoby pamięci. Zakłada, że alternatywny dostawca może przyjąć dane, ale schematy, integracje tożsamości, klucze szyfrowania, sekrety, logi, interfejsy API i limity liczby żądań sprawiają, że migracja trwa dłużej, niż pozwala tolerancja wpływu.

Kontrola A.5.23 z Załącznika A ISO/IEC 27001:2022 odnosi się do tego problemu cyklu życia, wymagając kontroli bezpieczeństwa informacji dla pozyskiwania, korzystania, zarządzania i wyjścia z usług chmurowych.

Polityka korzystania z chmury obliczeniowej dla MŚP Clarysec Polityka korzystania z chmury obliczeniowej dla MŚP, sekcja „Wymagania wdrożeniowe polityki”, klauzula 6.3.4 wymaga:

Potwierdzenia możliwości eksportu danych przed wdrożeniem usługi (np. w celu uniknięcia uzależnienia od dostawcy)

Klauzula 6.3.5 wymaga:

Potwierdzenia procedur bezpiecznego usuwania przed zamknięciem konta

Te wymagania należą do początku cyklu życia dostawcy. Nie należy czekać do rozwiązania umowy, aby zapytać, czy dane można wyeksportować. Nie należy czekać do zamknięcia konta, aby zapytać, czy istnieją dowody usunięcia.

Praktyczny test wyjścia z chmury w ramach DORA powinien obejmować:

1. Eksport reprezentatywnego zbioru danych w uzgodnionym formacie.
2. Walidację kompletności, integralności, znaczników czasu, metadanych i kontroli dostępu.
3. Import zbioru danych do środowiska testowego lub alternatywnego narzędzia.
4. Potwierdzenie obsługi kluczy szyfrowania i rotacji sekretów.
5. Potwierdzenie eksportu logów i okresu przechowywania ścieżki audytowej.
6. Udokumentowanie procedur usunięcia danych przez dostawcę, w tym retencji kopii zapasowych i certyfikacji usunięcia.
7. Zarejestrowanie problemów, działań naprawczych, właścicieli i terminów.
8. Aktualizację oceny ryzyka dostawcy, Deklaracji stosowania i planu wyjścia.

Przenośność nie jest obietnicą sprzedażową. Jest przetestowaną zdolnością.

Tygodniowy sprint do planu wyjścia DORA gotowego do audytu

Rozważmy instytucję płatniczą korzystającą z dostawcy analityki oszustw w modelu SaaS. Dostawca przyjmuje dane transakcyjne, identyfikatory klientów, dane telemetryczne urządzeń, sygnały behawioralne, reguły fraudowe, wyniki scoringowe oraz notatki dotyczące spraw. Usługa wspiera krytyczny proces wykrywania oszustw. Firma korzysta również z chmurowej hurtowni danych do przechowywania wyeksportowanych wyników analitycznych.

CISO potrzebuje strategii wyjścia DORA dla zewnętrznego dostawcy usług ICT, która przetrwa audyt wewnętrzny i przegląd nadzorczy. Tygodniowy sprint może ujawnić luki i zbudować łańcuch dowodowy.

Dzień 1: sklasyfikuj dostawcę i zdefiniuj scenariusz wyjścia

Korzystając z Zenith Blueprint, fazy Kontrole w działaniu, krok 23, Działania dla kontroli 5.19 do 5.37, zespół rozpoczyna od przeglądu i klasyfikacji portfela dostawców:

Sporządź pełną listę obecnych dostawców i dostawców usług (5.19) oraz sklasyfikuj ich na podstawie dostępu do systemów, danych lub kontroli operacyjnej. Dla każdego sklasyfikowanego dostawcy zweryfikuj, czy oczekiwania bezpieczeństwa są jasno ujęte w umowach (5.20), w tym poufność, dostęp, zgłaszanie incydentów i obowiązki zgodności.

Dostawca jest klasyfikowany jako krytyczny, ponieważ wspiera funkcję krytyczną lub istotną, przetwarza wrażliwe dane operacyjne i wpływa na wyniki monitorowania transakcji.

Zespół definiuje trzy wyzwalacze wyjścia:

• Niewypłacalność dostawcy lub zaprzestanie świadczenia usługi.
• Istotne naruszenie bezpieczeństwa lub utrata zaufania.
• Migracja strategiczna w celu ograniczenia ryzyka koncentracji.

Dzień 2: zbuduj inwentarz wymagań i zapis ryzyka

Zespół tworzy jeden inwentarz wymagań obejmujący ryzyko zewnętrznych dostawców ICT w DORA, kontrole dostawców i chmury w ISO/IEC 27001:2022, obowiązki GDPR dotyczące danych osobowych, zobowiązania umowne wobec klientów oraz wewnętrzny apetyt na ryzyko.

Na gruncie GDPR firma potwierdza, czy identyfikatory transakcji, identyfikatory urządzeń, sygnały lokalizacyjne i analityka behawioralna odnoszą się do zidentyfikowanych lub możliwych do zidentyfikowania osób fizycznych. Zasady GDPR Article 5, w tym integralność, poufność, ograniczenie przechowywania i rozliczalność, stają się częścią wymagań dowodowych dla wyjścia. Jeżeli wyjście obejmuje przekazanie danych nowemu dostawcy, należy udokumentować podstawę prawną, cel, minimalizację, okres przechowywania, warunki dla podmiotu przetwarzającego oraz środki ochrony.

Zapis ryzyka obejmuje następujące elementy:

Dzień 3: usuń luki w umowie

Dział prawny i zakupy porównują umowę z klauzulami dostawców Clarysec. Dodają wsparcie przejścia, kontynuację świadczenia usługi przez określony okres przejściowy, dostęp do audytu i dowodów, powiadamianie o podwykonawcach, format eksportu danych, certyfikację bezpiecznego usunięcia, współpracę przy incydentach oraz zobowiązania dotyczące czasu odtworzenia.

Polityka ciągłości działania i odtwarzania po awarii Polityka ciągłości działania i odtwarzania po awarii, sekcja „Wymagania wdrożeniowe polityki”, klauzula 6.5.1 stanowi:

Umowy z dostawcami krytycznymi powinny obejmować obowiązki w zakresie ciągłości działania oraz zobowiązania dotyczące czasu odtworzenia.

W przypadku MŚP Polityka ciągłości działania i odtwarzania po awarii dla MŚP Polityka ciągłości działania i odtwarzania po awarii dla MŚP, sekcja „Postępowanie z ryzykiem i wyjątki”, klauzula 7.2.1.4 wymaga od zespołów, aby:

dokumentowały plany tymczasowego zastąpienia dostawcy lub partnera

Ta klauzula zamienia „przeprowadzimy migrację” w wykonalne rozwiązanie awaryjne: który dostawca, jakie obejście wewnętrzne, jaki proces ręczny, jaki ekstrakt danych, który właściciel i która ścieżka akceptacji.

Dzień 4: przetestuj przenośność danych i możliwość odzyskania kopii zapasowych

Zespół technologiczny eksportuje reguły fraudowe, dane spraw, wyniki scoringu transakcji, logi, konfigurację, dokumentację API oraz listy kontroli dostępu użytkowników. Testuje, czy dane można odtworzyć lub ponownie wykorzystać w kontrolowanym środowisku.

Polityka tworzenia kopii zapasowych i odtwarzania dla MŚP Polityka tworzenia kopii zapasowych i odtwarzania dla MŚP, sekcja „Wymagania ładu zarządczego”, klauzula 5.3.3 wymaga:

Testy odtwarzania są przeprowadzane co najmniej kwartalnie, a wyniki są dokumentowane w celu weryfikacji możliwości odzyskania danych

Korporacyjna Polityka tworzenia kopii zapasowych i odtwarzania Polityka tworzenia kopii zapasowych i odtwarzania, sekcja „Egzekwowanie i zgodność”, klauzula 8.3.1 dodaje:

Okresowo audytuj logi kopii zapasowych, ustawienia konfiguracyjne i wyniki testów

W Zenith Blueprint, w fazie Kontrole w działaniu, krok 19, kontrola 8.13, Clarysec ostrzega, dlaczego ma to znaczenie:

Testowanie odtwarzania to obszar, w którym większość organizacji nie spełnia oczekiwań. Kopia zapasowa, której nie można odtworzyć na czas lub w ogóle, jest zobowiązaniem, a nie aktywem. Zaplanuj regularne ćwiczenia odtwarzania, nawet częściowe, i dokumentuj wynik.

Zespół odkrywa, że wyeksportowane notatki spraw nie obejmują załączników, a limity liczby żądań API powodują, że pełny eksport jest zbyt wolny dla zdefiniowanego celu odtworzenia. Problem zostaje zarejestrowany, przypisany i usunięty przez aneks do umowy oraz techniczne przeprojektowanie eksportu.

Dzień 5: przeprowadź ćwiczenie tabletop wyjścia i przegląd dowodów

Zespół przeprowadza ćwiczenie scenariuszowe typu tabletop: dostawca ogłasza rozwiązanie umowy w terminie 90 dni po poważnym incydencie. Operacje muszą utrzymać monitorowanie oszustw w trakcie migracji danych.

W Zenith Blueprint, w fazie Kontrole w działaniu, krok 23, kontrola 5.30, Clarysec wyjaśnia standard testu:

Gotowość ICT zaczyna się na długo przed wystąpieniem zakłócenia. Obejmuje identyfikację systemów krytycznych, zrozumienie ich współzależności oraz mapowanie ich na procesy biznesowe.

Ta sama sekcja dodaje:

Docelowe czasy odtworzenia (RTO) i docelowe punkty odtworzenia (RPO) zdefiniowane w planie ciągłości działania muszą mieć odzwierciedlenie w konfiguracjach technicznych, umowach i projekcie infrastruktury.

Pakiet dowodowy obejmuje klasyfikację dostawcy, ocenę ryzyka, klauzule umowne, podręcznik operacyjny wyjścia, wyniki eksportu danych, dowody odtworzenia kopii zapasowej, procedurę usunięcia, ocenę alternatywnego dostawcy, protokół z ćwiczenia tabletop, rejestr działań naprawczych, akceptację kierownictwa oraz decyzję dotyczącą ryzyka rezydualnego.

CISO może teraz odpowiedzieć radzie nadzorczej dowodami, a nie optymizmem.

Zgodność przekrojowa: jeden plan wyjścia, wiele perspektyw audytu

Silna strategia wyjścia DORA ogranicza powielanie prac związanych ze zgodnością w obszarze oczekiwań ładu zarządczego ISO/IEC 27001:2022, NIS2, GDPR, NIST i COBIT 2019.

Istotne nie jest to, że jedne ramy zastępują inne. Wartość polega na tym, że dobrze zbudowany SZBI pozwala organizacji wygenerować dowody raz i inteligentnie wykorzystać je ponownie.

Zenith Controls Clarysec pomaga zespołom przygotować się do tych perspektyw audytu, łącząc kontrole ISO/IEC 27001:2022 z dowodami audytowymi i oczekiwaniami różnych ram.

Częstą przyczyną niepowodzenia audytu jest fragmentacja dowodów. Właściciel dostawcy ma umowę. IT ma logi kopii zapasowych. Dział prawny ma umowę powierzenia przetwarzania danych. Ryzyko ma ocenę. Zgodność ma mapowanie regulacyjne. Nikt nie ma pełnej historii.

Clarysec rozwiązuje ten problem, projektując pakiet dowodowy wokół scenariusza wyjścia. Każdy dokument odpowiada na jedno pytanie audytowe: jaka usługa jest wycofywana, dlaczego jest krytyczna, jakie dane i systemy są objęte wpływem, kto jest właścicielem ryzyka, jakie prawa umowne umożliwiają wyjście, jakie mechanizmy techniczne umożliwiają migrację, jakie ustalenia ciągłości utrzymują działalność, jaki test potwierdza, że plan działa, jakie problemy naprawiono i kto zaakceptował ryzyko rezydualne.

Lista kontrolna strategii wyjścia DORA od Clarysec

Użyj tej listy kontrolnej, aby przekształcić strategię wyjścia DORA dla zewnętrznego dostawcy usług ICT z dokumentu w audytowalny zestaw kontroli.

Zamień planowanie wyjścia w kontrolę odporności gotową dla rady nadzorczej

Jeżeli strategia wyjścia DORA jest tylko klauzulą umowną, nie jest gotowa. Jeżeli kopia zapasowa nigdy nie została odtworzona, nie jest gotowa. Jeżeli dostawca chmury może eksportować dane, ale nikt nie zwalidował kompletności, nie jest gotowa. Jeżeli rada nadzorcza nie widzi decyzji dotyczącej ryzyka rezydualnego, nie jest gotowa.

Clarysec pomaga CISO, menedżerom zgodności, audytorom i właścicielom biznesowym budować strategie wyjścia DORA dla zewnętrznych dostawców usług ICT, które są praktyczne, proporcjonalne i gotowe do audytu. Łączymy Zenith Blueprint Zenith Blueprint do sekwencjonowania wdrożenia, Zenith Controls Zenith Controls do mapowania zgodności przekrojowej oraz szablony polityk, takie jak Polityka zarządzania ryzykiem zależności od dostawców Polityka zarządzania ryzykiem zależności od dostawców, Polityka korzystania z chmury obliczeniowej dla MŚP Polityka korzystania z chmury obliczeniowej dla MŚP, Polityka bezpieczeństwa dostawców i stron trzecich dla MŚP Polityka bezpieczeństwa dostawców i stron trzecich dla MŚP oraz Polityka ciągłości działania i odtwarzania po awarii Polityka ciągłości działania i odtwarzania po awarii, aby stworzyć kompletny łańcuch od kontroli do dowodów.

Następny krok jest prosty i ma wysoką wartość: wybierz w tym tygodniu jednego krytycznego dostawcę ICT. Sklasyfikuj go, przejrzyj jego umowę, przetestuj jeden eksport danych, zweryfikuj jedno odtworzenie, udokumentuj jeden plan zastąpienia i utwórz jeden pakiet dowodowy.

To pojedyncze ćwiczenie pokaże, czy Twoja strategia wyjścia DORA jest rzeczywistą zdolnością odpornościową, czy tylko dokumentem czekającym na porażkę podczas audytu.