Gotowa do audytu ocena ryzyka ISO 27001 dla NIS2 i DORA

Kawa na biurku Sary wystygła.

Jako CISO szybko rosnącego fintechu była przyzwyczajona do presji. Spółka właśnie pozyskała dużego partnera bankowego, a kwestionariusz due diligence widoczny na ekranie powinien być formalnością. Pierwsze pytania były znajome: przedstawić Deklarację stosowania ISO/IEC 27001:2022, udostępnić najnowszy rejestr ryzyk, wyjaśnić metodykę oceny ryzyka.

Potem kwestionariusz zmienił kierunek.

Wykaż, w jaki sposób program zarządzania ryzykiem uwzględnia DORA. Wyjaśnij przygotowanie do dyrektywy NIS2, w tym rozliczalność kierownictwa i środki dotyczące ryzyka w łańcuchu dostaw. Przedstaw dowody, że krytyczni dostawcy ICT są oceniani, monitorowani oraz objęci planami reagowania na incydenty i ciągłości działania.

W poniedziałek rano ten sam temat trafił do porządku obrad komitetu ds. ryzyka rady dyrektorów. Audyt certyfikacyjny ISO 27001 miał się odbyć za osiem tygodni. Klienci z sektora finansowego wywierali presję związaną z DORA. Pytania klasyfikacyjne NIS2 dotyczyły linii usług hostowanych w chmurze i rozwijanych na rynku UE. Zakupy twierdziły, że przeglądy dostawców istnieją, ale dowody były rozproszone między pocztą elektroniczną, folderami umów i arkuszem dostawców. Dział prawny wskazywał, że mapowanie regulacyjne nadal trwa. Zespół inżynierii twierdził, że rejestr ryzyk jest w większości gotowy.

Zarząd zadał jedyne pytanie, które miało znaczenie:

Czy potrafimy wykazać, że nasza ocena ryzyka i plan postępowania z ryzykiem są wystarczające?

To realny problem firm SaaS, fintechów, dostawców usług zarządzanych, dostawców chmury i platform cyfrowych. Nie chodzi o to, czy rejestr ryzyk istnieje. Nie chodzi o to, czy zabezpieczenia z Załącznika A zostały skopiowane do arkusza kalkulacyjnego. Chodzi o to, czy organizacja potrafi wykazać — pod presją audytu i klientów — że jej proces oceny ryzyka ISO 27001 jest powtarzalny, oparty na ryzyku, zatwierdzony przez właścicieli ryzyka, powiązany z działaniami w ramach postępowania z ryzykiem, zmapowany na obowiązki prawne i faktycznie działa operacyjnie.

Dobrze wykonana jedna ocena ryzyka ISO 27001 i jeden plan postępowania z ryzykiem mogą wspierać certyfikację ISO/IEC 27001:2022, środki zarządzania ryzykiem cyberbezpieczeństwa z NIS2 Article 21, wymagania DORA dotyczące zarządzania ryzykiem ICT, rozliczalność GDPR, zapewnienie dostawców, gotowość na incydenty i raportowanie do zarządu.

Źle wykonana staje się arkuszem kalkulacyjnym, który audytorzy rozłożą na czynniki pierwsze w trzydzieści minut.

Ten przewodnik pokazuje, jak Clarysec buduje gotowe do audytu dowody oceny ryzyka ISO 27001 i postępowania z ryzykiem z wykorzystaniem Zenith Blueprint: 30-etapowej mapy drogowej audytora, polityk Clarysec oraz Zenith Controls: przewodnika po zgodności przekrojowej.

Dlaczego ocena ryzyka ISO 27001 jest dziś centrum zgodności

Krajobraz regulacyjny UE zbiega się wokół prostej zasady: ryzyko cyberbezpieczeństwa musi być nadzorowane, udokumentowane, testowane i przypisane właścicielom.

ISO/IEC 27001:2022 już działa w ten sposób. Klauzule 4.1 do 4.4 wymagają, aby organizacja rozumiała swój kontekst, potrzeby i oczekiwania stron zainteresowanych, zakres SZBI oraz interakcje procesów przed oceną ryzyka. Klauzule 6.1.2 i 6.1.3 wymagają zdefiniowanego procesu oceny ryzyka bezpieczeństwa informacji i postępowania z ryzykiem. Klauzule 8.2 i 8.3 wymagają, aby organizacja przeprowadzała oceny ryzyka i wdrażała plan postępowania z ryzykiem, zachowując udokumentowane informacje.

NIS2 i DORA sprawiają, że ta sama logika oparta na ryzyku staje się pilniejsza.

NIS2 Article 20 wymaga, aby organy zarządzające podmiotów kluczowych i ważnych zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie i odbywały szkolenia z zakresu cyberbezpieczeństwa. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych służących zarządzaniu ryzykiem dla sieci i systemów informatycznych. Środki te obejmują analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczny rozwój oprogramowania, obsługę podatności, ocenę skuteczności, cyberhigienę, kryptografię, bezpieczeństwo HR, kontrolę dostępu, zarządzanie aktywami oraz, w stosownych przypadkach, uwierzytelnianie wieloskładnikowe lub zabezpieczoną komunikację.

DORA wywiera podobną presję na podmioty finansowe. Articles 5 i 6 wymagają, aby organ zarządzający definiował, zatwierdzał, nadzorował i pozostawał odpowiedzialny za ustalenia dotyczące zarządzania ryzykiem ICT. DORA oczekuje udokumentowanych ram zarządzania ryzykiem ICT, zintegrowanych z ogólnym zarządzaniem ryzykiem i wspieranych przez polityki, procedury, protokoły, narzędzia, audyt wewnętrzny, działania naprawcze, ciągłość działania, testowanie, zarządzanie incydentami oraz nadzór nad zewnętrznymi dostawcami usług ICT.

Wniosek jest praktyczny i nieunikniony: rejestr ryzyk nie jest już roboczym arkuszem zespołu technicznego. Jest dowodem ładu zarządczego.

Firmowa Polityka zarządzania ryzykiem Clarysec wyraźnie formułuje to oczekiwanie:

Formalny proces zarządzania ryzykiem należy utrzymywać zgodnie z ISO/IEC 27005 i ISO 31000, obejmując identyfikację ryzyka, analizę, ocenę, postępowanie z ryzykiem, monitorowanie i komunikację.

Z firmowej Polityki zarządzania ryzykiem, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.1.

Ta sama polityka definiuje rezultat gotowy do audytu:

Utrzymywanie scentralizowanego, objętego kontrolą wersji rejestru ryzyk i planu postępowania z ryzykiem, odzwierciedlających aktualny status ryzyka, pokrycie zabezpieczeniami i postęp działań ograniczających ryzyko.

Z firmowej Polityki zarządzania ryzykiem, sekcja „Cele”, klauzula polityki 3.3.

Sformułowanie „aktualny status ryzyka, pokrycie zabezpieczeniami i postęp działań ograniczających ryzyko” stanowi różnicę między statycznym plikiem zgodności a możliwym do obrony programem zarządzania ryzykiem.

Zacznij od zakresu, obowiązków i kryteriów ryzyka

Wiele słabych ocen ryzyka ISO 27001 zaczyna się od listy kontrolnej zabezpieczeń. To odwrócona kolejność.

ISO 27001 wymaga, aby organizacja określiła kontekst, wymagania stron zainteresowanych, zakres SZBI, odpowiedzialności kierownictwa i planowanie ryzyka przed wyborem zabezpieczeń. ISO/IEC 27005:2022 wzmacnia to podejście, zalecając organizacjom identyfikację podstawowych wymagań stron zainteresowanych przed oceną ryzyka. Wymagania te mogą wynikać z norm ISO, regulacji sektorowych, przepisów krajowych, umów z klientami, polityk wewnętrznych, wcześniejszych działań w zakresie postępowania z ryzykiem oraz obowiązków wobec dostawców.

W przypadku spółki SaaS lub fintechu działającej na rynku UE proces ryzyka powinien zaczynać się od inwentaryzacji obowiązków zgodności.

Dla MŚP punktem wyjścia jest Polityka zgodności prawnej i regulacyjnej - MŚP Clarysec:

Dyrektor Generalny musi utrzymywać prosty, uporządkowany rejestr zgodności obejmujący:

Z Polityki zgodności prawnej i regulacyjnej dla MŚP, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.1.1.

Taki prosty rejestr stanowi pomost między zgodnością a zarządzaniem ryzykiem. Jeżeli wskazuje, że GDPR ma zastosowanie, ponieważ przetwarzane są dane osobowe z UE, NIS2 może mieć zastosowanie, ponieważ organizacja świadczy usługi cyfrowe lub zarządzane, albo DORA jest istotna ze względu na klientów z sektora finansowego, obowiązki te muszą wpływać na kryteria ryzyka i priorytety postępowania z ryzykiem.

Zenith Blueprint mówi o tym wprost w fazie zarządzania ryzykiem, krok 10, „Ustanawianie kryteriów ryzyka i macierzy wpływu”:

W kryteriach akceptacji należy również uwzględnić wymagania prawne/regulacyjne. Niektóre ryzyka mogą być nieakceptowalne niezależnie od prawdopodobieństwa ze względu na przepisy prawa.

Z Zenith Blueprint, faza zarządzania ryzykiem, krok 10.

Podaje też praktyczną zasadę do warsztatów:

„Każde ryzyko, które mogłoby prowadzić do niezgodności z mającymi zastosowanie przepisami prawa (GDPR itd.), jest nieakceptowalne i musi zostać ograniczone”.

Z Zenith Blueprint, faza zarządzania ryzykiem, krok 10.

Dla fintechu Sary zmienia to model punktacji. Podatność w interfejsie API dostawcy może mieć niskie prawdopodobieństwo, ale jeżeli jej wykorzystanie mogłoby uruchomić poważny incydent związany z ICT według DORA, znaczący incydent NIS2, ocenę naruszenia według GDPR, naruszenie SLA klienta lub eskalację na poziom zarządu, wpływ jest wysoki albo krytyczny. Ekspozycja na zgodność staje się częścią logiki ryzyka, a nie osobnym arkuszem kalkulacyjnym.

Zbuduj rejestr ryzyk, który audytorzy mogą przetestować

Audytorzy nie pytają tylko o najważniejsze ryzyka. Sprawdzają, czy metoda jest zdefiniowana, powtarzalna, identyfikowalna i stosowana.

Zapytają:

• Jak zidentyfikowano te ryzyka?
• Jakie aktywa, usługi, dostawcy, typy danych i procesy były w zakresie?
• Jakich kryteriów użyto dla prawdopodobieństwa i wpływu?
• Kto jest właścicielem każdego ryzyka?
• Jakie istniejące zabezpieczenia ograniczają ryzyko?
• Dlaczego wybrano daną decyzję dotyczącą postępowania z ryzykiem?
• Gdzie są dowody, że działanie w ramach postępowania z ryzykiem zostało wykonane?
• Kto zatwierdził ryzyko szczątkowe?
• Kiedy ryzyko zostanie ponownie ocenione?

Polityka zarządzania ryzykiem - MŚP Clarysec ujmuje minimalny, gotowy do audytu wpis ryzyka:

Każdy wpis ryzyka musi obejmować: opis, prawdopodobieństwo, wpływ, punktację, właściciela i plan postępowania z ryzykiem.

Z Polityki zarządzania ryzykiem dla MŚP, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.1.2.

W programach firmowych Zenith Blueprint, faza zarządzania ryzykiem, krok 11, „Budowanie i dokumentowanie rejestru ryzyk”, rozszerza tę strukturę. Rekomenduje kolumny takie jak identyfikator ryzyka, aktywo, zagrożenie, podatność, opis ryzyka, prawdopodobieństwo, wpływ, poziom ryzyka, obecne zabezpieczenia, właściciel ryzyka, decyzja dotycząca postępowania z ryzykiem, plan postępowania z ryzykiem lub zabezpieczenia oraz status.

Silny wpis ryzyka wygląda następująco:

To zasadniczo różni się od wpisu „ryzyko stron trzecich, wysokie, ograniczyć”. Wersja gotowa do audytu łączy aktywo, zagrożenie, podatność, konsekwencję, obecne zabezpieczenia, właściciela, regulację, dowody i ład zarządczy.

Przekształć postępowanie z ryzykiem w plan dowodowy

Plan postępowania z ryzykiem musi odpowiadać na cztery pytania operacyjne:

1. Co zrobimy?
2. Kto jest właścicielem działania?
3. Kiedy zostanie ono wykonane?
4. Jak wykażemy, że ograniczyło ryzyko?

ISO/IEC 27001:2022 Klauzula 6.1.3 wymaga, aby organizacja wybrała opcje postępowania z ryzykiem, określiła niezbędne zabezpieczenia, porównała je z Załącznikiem A w celu uniknięcia pominięć, sporządziła Deklarację stosowania, sformułowała plan postępowania z ryzykiem oraz uzyskała zatwierdzenie planu i ryzyk szczątkowych przez właścicieli ryzyka. Klauzula 8.3 wymaga następnie wdrożenia planu postępowania z ryzykiem i zachowania udokumentowanych informacji o wynikach.

Firmowa Polityka zarządzania ryzykiem ujmuje to praktycznie:

Menedżer ryzyka zapewnia, aby działania w ramach postępowania z ryzykiem były realistyczne, ograniczone w czasie i powiązane z zabezpieczeniami z ISO/IEC 27001 Załącznik A.

Z firmowej Polityki zarządzania ryzykiem, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.4.2.

Polityka dla MŚP wyjaśnia również, że akceptacja nie jest skrótem:

Akceptacja: uzasadnić, dlaczego dalsze działanie nie jest wymagane, i zarejestrować ryzyko szczątkowe.

Z Polityki zarządzania ryzykiem dla MŚP, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.

Akceptacja musi być uzasadniona względem kryteriów, zatwierdzona przez właściwego właściciela i monitorowana. W ramach NIS2 i DORA niezatwierdzone ryzyko szczątkowe może stać się nieskutecznością ładu zarządczego.

Kompletny plan postępowania z ryzykiem powinien zawierać następujące pola:

Dla R-042 Sary plan postępowania z ryzykiem staje się listą działań zgodności przekrojowej.

Ten plan jest skuteczny, ponieważ tworzy bezpośrednie powiązanie między jednym scenariuszem ryzyka a zabezpieczeniami ISO 27001, obowiązkami NIS2, artykułami DORA, właścicielami i dowodami.

Wykorzystaj Deklarację stosowania intensywniej

Deklaracja stosowania jest często traktowana jako artefakt certyfikacyjny. Powinna być czymś więcej.

ISO/IEC 27001:2022 Klauzula 6.1.3 wymaga, aby SoA obejmowała niezbędne zabezpieczenia, uzasadnienie ich włączenia, status wdrożenia oraz uzasadnienie wyłączeń. Wytyczne ISO/IEC 27005:2022 wzmacniają potrzebę porównania wybranych zabezpieczeń z ISO/IEC 27001 Załącznik A, aby uniknąć pominięć.

W programie gotowym do audytu SoA staje się pomostem między postępowaniem z ryzykiem a dowodami zgodności przekrojowej. Jeżeli plan postępowania z ryzykiem wymaga MFA, rejestrowania, monitorowania dostawcy, odtwarzania kopii zapasowych, bezpiecznego rozwoju oprogramowania, eskalacji incydentu lub planowania wyjścia z chmury, SoA powinna pokazywać, że właściwe zabezpieczenia z Załącznika A są uwzględnione, uzasadnione, wdrożone lub zaplanowane oraz potwierdzone dowodami.

Pomaga to również uniknąć częstej niezgodności audytowej: rejestr ryzyk mówi jedno, plan postępowania z ryzykiem mówi drugie, a SoA milczy. Gdy te artefakty są niespójne, audytorzy szybko tracą zaufanie.

Mapowanie postępowania z ryzykiem ISO 27001 na NIS2, DORA i GDPR

ISO 27001 nie zastępuje NIS2, DORA ani GDPR. Daje natomiast uporządkowany mechanizm wytwarzania dowodów dla tych wymagań.

Kluczowe jest wbudowanie mapowania w proces ryzyka, zamiast dokładania go później.

Mapowanie to jest szczególnie ważne tam, gdzie regulacje się nakładają. DORA jest sektorowym reżimem odporności ICT dla wielu podmiotów finansowych, podczas gdy NIS2 może pozostawać bezpośrednio istotna dla określonych dostawców, koordynacji lub podmiotów poza zakresem DORA. Fintech może potrzebować DORA jako podstawowych ram odporności ICT, natomiast dostawca usług zarządzanych wspierający ten fintech może podlegać bezpośrednim obowiązkom NIS2.

Rejestr ryzyk musi potrafić pokazać obie strony tej zależności.

Użyj Zenith Controls jako kompasu zgodności przekrojowej

Clarysec wykorzystuje Zenith Controls jako przewodnik po zgodności przekrojowej, aby zapobiec częstej nieskuteczności, w której zabezpieczenia ISO, artykuły regulacyjne i pytania audytowe funkcjonują w odrębnych światach. Nie tworzy on osobnych ram kontroli. Mapuje obszary zabezpieczeń ISO/IEC 27001:2022 i ISO/IEC 27002:2022 na inne normy, oczekiwania audytowe i perspektywy zgodności.

Dla oceny ryzyka i postępowania z ryzykiem ISO 27001 szczególnie ważne są następujące odniesienia:

Wniosek z perspektywy zgodności przekrojowej jest prosty. Jeśli obowiązki prawne nie są ujęte w metodzie oceny ryzyka, punktacja jest niepełna. Jeśli punktacja jest niepełna, priorytety postępowania z ryzykiem mogą być błędne. Jeśli priorytety są błędne, SoA i raportowanie do zarządu stają się niewiarygodne.

Zenith Blueprint podkreśla to samo w fazie zarządzania ryzykiem, krok 14, „Polityki postępowania z ryzykiem i regulacyjne odniesienia krzyżowe”. Zaleca organizacjom utworzenie tabeli mapowania obejmującej kluczowe regulacyjne wymagania bezpieczeństwa oraz odpowiadające im zabezpieczenia lub polityki w SZBI. Nie jest to obowiązkowe dla certyfikacji ISO 27001, ale jest bardzo przydatne do wykazania, że bezpieczeństwo jest zarządzane w kontekście prawnym i umownym.

O co zapytają różni audytorzy

Audytor certyfikujący, recenzent zorientowany na NIS2, klient patrzący przez pryzmat DORA, recenzent GDPR, asesor NIST albo audytor COBIT/ISACA mogą badać te same dowody, ale zadawać inne pytania.

Dlatego architektura dowodów ma znaczenie. Ten sam wpis ryzyka powinien być możliwy do prześledzenia od celu biznesowego do aktywa, zagrożenia, podatności, zabezpieczenia, właściciela, czynnika regulacyjnego, działania w ramach postępowania z ryzykiem, wyniku testu i decyzji kierownictwa.

Polityki Clarysec są projektowane tak, aby wspierać taką architekturę. Firmowa Polityka zarządzania ryzykiem stanowi w sekcji „Normy i ramy odniesienia”:

Article 5: Wymaga udokumentowanych ram zarządzania ryzykiem ICT, w pełni pokrytych strukturą tej polityki, w tym mapowaniem SoA i KRI.

To przekształca politykę ze statycznego dokumentu w dowód audytowy pokazujący, że ład zarządczy ryzyka ICT został zaprojektowany celowo z uwzględnieniem DORA.

Częste ustalenia, które osłabiają programy ryzyka

Gdy Clarysec przegląda dowody oceny ryzyka ISO 27001 i postępowania z ryzykiem, te same ustalenia powtarzają się regularnie.

Po pierwsze, kryteria ryzyka ignorują wpływ prawny, regulacyjny, umowny, dostawczy i prywatnościowy. Powoduje to słabą punktację. Naruszenie ochrony danych osobowych lub awaria krytycznego dostawcy mogą zostać ocenione jako średnie, ponieważ prawdopodobieństwo jest niskie, mimo że wpływ na GDPR, NIS2, DORA lub klienta powinien uczynić je wysokimi albo krytycznymi.

Po drugie, właściciele ryzyka są generyczni. „IT” nie jest właścicielem ryzyka. Właścicielem ryzyka powinna być rola lub osoba rozliczalna za decyzje dotyczące postępowania z ryzykiem, budżet, terminy i ryzyko szczątkowe.

Po trzecie, plany postępowania z ryzykiem nie są ograniczone w czasie. „Usprawnić monitorowanie” nie jest planem. „Wdrożyć alerty sesji uprzywilejowanych w SIEM dla kont administratorów produkcyjnych do 30 czerwca, z właścicielem w osobie kierownika centrum operacji bezpieczeństwa (SOC), przetestowane przez symulowane logowanie administratora, z dołączonym dowodem alertu” — to jest plan.

Po czwarte, SoA jest odłączona od postępowania z ryzykiem. Jeżeli plan postępowania z ryzykiem wymaga monitorowania dostawcy, testowania kopii zapasowych, eskalacji incydentu, MFA lub rejestrowania, SoA powinna odzwierciedlać właściwe zabezpieczenia i status wdrożenia.

Po piąte, ryzyko szczątkowe nie jest zatwierdzone. ISO 27001 wymaga zatwierdzenia planu postępowania z ryzykiem i ryzyk szczątkowych przez właściciela ryzyka. NIS2 i DORA czynią to jeszcze ważniejszym, ponieważ rozliczalność kierownictwa jest wyraźna.

Po szóste, ryzyko dostawców jest traktowane jak administracja zakupowa. Zgodnie z NIS2 Article 21(2)(d) oraz DORA Articles 28 i 30 ryzyko dostawców i zewnętrznych dostawców usług ICT musi być częścią zarządzania ryzykiem, a nie corocznym kwestionariuszem przechowywanym w izolacji.

Po siódme, brak dowodów skuteczności. ISO 27001 Klauzula 6.1.1 wymaga, aby zaplanowane działania były oceniane pod kątem skuteczności. NIS2 obejmuje ocenę skuteczności w Article 21(2)(f). DORA oczekuje testowania i działań naprawczych. Zabezpieczenie, które istnieje, ale nigdy nie jest testowane, stanowi słaby dowód.

Polityka zarządzania ryzykiem - MŚP ujmuje oczekiwanie jasno:

Dyrektor Generalny i Koordynator ds. ryzyka muszą zapewnić, aby działania zarządzania ryzykiem były gotowe do audytu. Rejestr ryzyk i powiązane działania podlegają audytowi wewnętrznemu i zewnętrznemu.

Z Polityki zarządzania ryzykiem dla MŚP, sekcja „Egzekwowanie i zgodność”, klauzula polityki 8.2.1.

Raportowanie do zarządu bez przeciążania kadry kierowniczej

NIS2, DORA i ISO 27001 wskazują na rozliczalność kierownictwa, ale zarządy nie potrzebują każdego wiersza ryzyka. Potrzebują raportowania użytecznego decyzyjnie.

Dobry pakiet ryzyka dla zarządu powinien pokazywać:

• Ryzyka wysokie i krytyczne według domeny
• Przeterminowane działania w ramach postępowania z ryzykiem
• Ryzyka regulacyjne obejmujące NIS2, DORA, GDPR lub umowy
• Ryzyka dostawców wpływające na usługi krytyczne lub ważne
• Trendy incydentów i zdarzeń potencjalnie incydentowych
• Ryzyka szczątkowe oczekujące na akceptację
• Wyniki testów skuteczności zabezpieczeń
• Istotne zmiany zakresu, dostawców, technologii lub prawa
• Ustalenia audytu wewnętrznego i działania korygujące

Clarysec zwykle rekomenduje miesięczne operacyjne przeglądy ryzyka i kwartalne przeglądy zarządzania. Przeglądy miesięczne koncentrują się na realizacji działań w ramach postępowania z ryzykiem. Przeglądy kwartalne koncentrują się na akceptacji, finansowaniu, priorytetyzacji, ekspozycji regulacyjnej i strategicznych decyzjach dotyczących ryzyka.

Taki rytm wspiera również ciągłe doskonalenie. Oceny ryzyka powinny być aktualizowane po wystąpieniu incydentów, pojawieniu się podatności, wprowadzeniu nowych aktywów, zmianach technologicznych, zmianach dostawców, zmianach prawa, zmianach obowiązków wobec klientów lub zmianach apetytu na ryzyko.

Ścieżka wdrożenia Clarysec

Ujednolicony program ryzyka pozwala uniknąć rozłącznych arkuszy ISO, NIS2, DORA, GDPR i zapewnienia dla klientów. Praktyczna ścieżka wygląda następująco:

1. Potwierdź zakres SZBI, usługi, aktywa, dostawców, jurysdykcje i zobowiązania wobec klientów.
2. Zbuduj lub zaktualizuj rejestr zgodności, korzystając w razie potrzeby z Polityki zgodności prawnej i regulacyjnej - MŚP.
3. Zdefiniuj metodykę ryzyka, kryteria akceptacji, skale prawdopodobieństwa, skale wpływu i zasady uwzględniania wpływu regulacyjnego.
4. Zbuduj rejestr ryzyk, korzystając z fazy zarządzania ryzykiem w Zenith Blueprint oraz podejścia Clarysec do kreatora rejestru ryzyk i SoA.
5. Zidentyfikuj ryzyka oparte na aktywach i scenariuszach, w tym scenariusze dostawców, chmury, prywatności, ciągłości działania, incydentów, podatności, bezpiecznego rozwoju oprogramowania i dostępu.
6. Oceń ryzyka według kryteriów obejmujących wpływ prawny, regulacyjny, umowny, operacyjny, prywatnościowy, dostawczy i finansowy.
7. Wybierz opcje postępowania z ryzykiem: ograniczenie, unikanie, transfer albo akceptacja.
8. Zmapuj niezbędne zabezpieczenia na ISO/IEC 27001:2022 Załącznik A i wytyczne ISO/IEC 27002:2022.
9. Utwórz lub zaktualizuj Deklarację stosowania.
10. Zmapuj działania w ramach postępowania z ryzykiem na NIS2 Article 21, zarządzanie ryzykiem ICT DORA i oczekiwania wobec stron trzecich, rozliczalność GDPR oraz zobowiązania umowne wobec klientów.
11. Zbierz dowody, zwaliduj skuteczność zabezpieczeń i uzyskaj zatwierdzenie ryzyka szczątkowego.
12. Przygotuj pakiet audytowy uporządkowany według ryzyka, zabezpieczenia, regulacji i artefaktu dowodowego.
13. Wprowadź wyniki do przeglądu zarządzania, audytu wewnętrznego, działań korygujących i ciągłego doskonalenia.

To nie jest dokumentacja dla samej dokumentacji. To system operacyjny możliwego do obrony ładu cyberbezpieczeństwa.

Zbuduj gotowy do audytu pakiet postępowania z ryzykiem

Historia Sary kończy się dobrze, ponieważ przestała traktować ISO 27001, NIS2 i DORA jako odrębne projekty zgodności. Wykorzystała ocenę ryzyka ISO 27001 jako centralny mechanizm, wbudowała obowiązki regulacyjne w kryteria ryzyka, zmapowała działania w ramach postępowania z ryzykiem na Załącznik A i wymagania UE oraz zebrała dowody zrozumiałe dla klientów, audytorów i zarządu.

Twoja organizacja może zrobić to samo.

Użyj Zenith Blueprint: 30-etapowej mapy drogowej audytora, aby zdefiniować kryteria ryzyka, zbudować rejestr ryzyk, utworzyć plan postępowania z ryzykiem i powiązać wymagania regulacyjne odniesieniami krzyżowymi.

Użyj Zenith Controls: przewodnika po zgodności przekrojowej, aby połączyć obszary zabezpieczeń ISO/IEC 27001:2022 Załącznik A z perspektywami ładu zarządczego, zgodności prawnej, zapewnienia i audytu.

Użyj Polityki zarządzania ryzykiem, Polityki zarządzania ryzykiem - MŚP oraz Polityki zgodności prawnej i regulacyjnej - MŚP Clarysec, aby ustandaryzować własność, rejestry, decyzje dotyczące postępowania z ryzykiem i dowody gotowe do audytu.

Najszybszym praktycznym krokiem jest wzięcie dziesięciu najważniejszych ryzyk i sprawdzenie ich względem pięciu pytań:

1. Czy wpływ regulacyjny jest widoczny?
2. Czy plan postępowania z ryzykiem jest ograniczony w czasie i ma właściciela?
3. Czy każde działanie w ramach postępowania z ryzykiem jest zmapowane na Załącznik A i SoA?
4. Czy znaczenie dla NIS2, DORA, GDPR lub klienta jest udokumentowane tam, gdzie ma zastosowanie?
5. Czy istnieją dowody, że zabezpieczenie działa?

Jeśli odpowiedź brzmi „nie”, Clarysec może pomóc przekształcić rejestr ryzyk w możliwy do obrony, przekrojowy program postępowania z ryzykiem, któremu mogą zaufać audytorzy, organy regulacyjne, klienci i zarządy.