Ciągłe monitorowanie zgodności z NIS2 i DORA

Piątkowe popołudniowe pytanie, na które każdy CISO musi dziś umieć odpowiedzieć

W piątek o 16:40 CISO platformy płatności działającej w chmurze otrzymuje w ciągu dziesięciu minut trzy wiadomości.

Pierwsza pochodzi od dyrektora finansowego: „Nasz partner bankowy oczekuje aktualnych dowodów, że spełniamy wymagania DORA dotyczące ryzyka ICT związanego z zewnętrznymi dostawcami oraz zgłaszania incydentów”.

Druga pochodzi od radcy prawnego: „Nasza usługa zarządzanego bezpieczeństwa może objąć nas zakresem krajowej implementacji NIS2. Czy możemy wykazać nadzór kierownictwa i skuteczność kontroli?”.

Trzecia pochodzi od dyrektora ds. inżynierii: „Wdrożyliśmy poprawkę dla krytycznej podatności, ale backlog pokazuje 38 przeterminowanych ustaleń o średniej istotności. Czy musimy eskalować?”.

To jest moment, w którym roczna zgodność przestaje działać.

PDF z polityką, rejestr ryzyk ostatnio zaktualizowany przed poprzednim audytem i folder ze zrzutami ekranu nie wystarczą dla NIS2 i DORA. Te regulacje wymagają żywego ładu zarządczego, nadzoru kierownictwa, ścieżek obsługi incydentów, widoczności dostawców, testowania odporności, działań korygujących oraz możliwej do wykazania skuteczności kontroli.

Dla wielu CISO presja nie jest teoretyczna. Transpozycja NIS2 w państwach członkowskich UE przeniosła cyberbezpieczeństwo z programu technicznego do obszaru rozliczalności kierownictwa. DORA obowiązuje od 17 stycznia 2025 r. i wprowadza dla podmiotów finansowych sektorowy zestaw zasad odporności operacyjnej obejmujący ryzyko ICT, zgłaszanie incydentów, testowanie i ryzyko związane z zewnętrznymi dostawcami. Dostawcy chmury, SaaS, usług zarządzanych, zarządzanego bezpieczeństwa, centrów danych, dostarczania treści, usług zaufania oraz publicznej łączności elektronicznej mogą również podlegać bezpośrednim lub pośrednim obowiązkom w zależności od zakresu, wielkości, sektora, klasyfikacji krajowej i umów z klientami.

Praktyczne pytanie nie brzmi już: „Czy mamy kontrolę?”.

Brzmi ono: „Kto jest właścicielem kontroli, który wskaźnik potwierdza, że kontrola działa, jak często gromadzimy dowody i co dzieje się, gdy wskaźnik nie spełnia progu?”.

To jest sedno ciągłego monitorowania zgodności z NIS2 i DORA. We wdrożeniach Clarysec wykorzystujemy ISO/IEC 27001:2022 jako fundament systemu zarządzania, ISO/IEC 27002:2022 jako język kontroli, Zenith Blueprint: 30-etapowa mapa drogowa audytora jako sekwencję wdrożenia oraz Zenith Controls: przewodnik po zgodności międzyramowej jako kompas zgodności międzyramowej, który łączy dowody ISO/IEC 27001:2022 z NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 i oczekiwaniami audytowymi.

Dlaczego NIS2 i DORA sprawiają, że okresowa zgodność nie wystarcza

NIS2 i DORA różnią się strukturą prawną, modelem nadzorczym i zakresem, ale tworzą tę samą presję operacyjną. Cyberbezpieczeństwem i odpornością ICT trzeba zarządzać w sposób ciągły.

NIS2 wymaga od podmiotów kluczowych i ważnych stosowania odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych w podejściu uwzględniającym wszystkie zagrożenia. Środki te obejmują analizę ryzyka, polityki bezpieczeństwa systemów informatycznych, obsługę incydentów, ciągłość działania, zarządzanie kryzysowe, bezpieczeństwo łańcucha dostaw, bezpieczne nabywanie i rozwój, obsługę podatności, ocenę skuteczności, cyberhigienę, szkolenia, kryptografię, bezpieczeństwo HR, kontrolę dostępu, zarządzanie aktywami oraz uwierzytelnianie wieloskładnikowe tam, gdzie jest to właściwe. Organy zarządzające muszą zatwierdzać środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorować ich wdrożenie i odbywać szkolenia.

DORA ujmuje to jeszcze wyraźniej w odniesieniu do podmiotów finansowych. Wymaga wewnętrznych ustaleń w zakresie ładu zarządczego i kontroli ryzyka ICT, udokumentowanych ram zarządzania ryzykiem ICT, odpowiedzialności organu zarządzającego, zarządzania incydentami związanymi z ICT i ich zgłaszania, testowania cyfrowej odporności operacyjnej, zarządzania ryzykiem związanym z zewnętrznymi dostawcami usług ICT, działań następczych po audytach, szkoleń oraz ustaleń komunikacyjnych. DORA jasno wskazuje również, że podmioty finansowe pozostają odpowiedzialne za zgodność, gdy korzystają z zewnętrznych dostawców usług ICT.

Tworzy to nową rzeczywistość zgodności. CISO nie może czekać do miesiąca audytu, aby odkryć, że:

• przeglądy dostępu uprzywilejowanego zostały pominięte przez dwa kwartały;
• plany wyjścia od dostawców zostały udokumentowane, ale nigdy ich nie przetestowano;
• kryteria istotności incydentu nie mapują się na progi raportowania regulacyjnego;
• kopie zapasowe są skonfigurowane, ale brakuje dowodów odtwarzania;
• kierownictwo nigdy nie przejrzało przeterminowanych działań w zakresie postępowania z ryzykiem;
• umowy chmurowe nie zawierają prawa do audytu, widoczności podwykonawców ani klauzul powiadamiania o incydentach.

Stary model projektowy tworzy cykle paniki. Zespoły mobilizują się przed audytem, zbierają zrzuty ekranu, aktualizują daty polityk i liczą, że dowody opowiedzą spójną historię. NIS2 i DORA zaprojektowano tak, aby takie podejście zawodziło. Koncentrują się na rozliczalności, proporcjonalności, odporności i dowodach działania.

ISO/IEC 27001:2022 zapewnia system operacyjny dla tego problemu. Jej klauzule wymagają od organizacji zrozumienia kontekstu, stron zainteresowanych, wymagań prawnych i umownych, zakresu, przywództwa, ról, oceny ryzyka, postępowania z ryzykiem, Deklaracji stosowania, planowania operacyjnego, oceny wyników, audytu wewnętrznego, przeglądu zarządzania, obsługi niezgodności i ciągłego doskonalenia. Ta struktura doskonale nadaje się do połączenia NIS2, DORA, GDPR, zapewnienia dla klientów i ryzyka wewnętrznego w jeden model ciągłego monitorowania.

Ciągłe monitorowanie zgodności to nie większa liczba pulpitów. To nadzorowany cykl gromadzenia dowodów.

Zbuduj mechanizm zgodności na ISO/IEC 27001:2022

Wiele organizacji błędnie traktuje ISO/IEC 27001:2022 wyłącznie jako ramy certyfikacyjne. W praktyce jest to system zarządzania ryzykiem, który sprawia, że ład bezpieczeństwa jest powtarzalny, mierzalny i możliwy do prześledzenia w audycie.

Ma to znaczenie, ponieważ NIS2 i DORA nie są odizolowanymi listami kontrolnymi. Wymagają modelu operacyjnego, który potrafi przyjmować wymogi prawne, przekładać je na kontrole, przypisywać właścicielstwo, monitorować wyniki i doskonalić się, gdy zostaną wykryte luki.

Podstawowe klauzule ISO/IEC 27001:2022 zapewniają ten model:

Dla FinTechu, dostawcy SaaS, usługi zarządzanego bezpieczeństwa lub dostawcy ICT dla podmiotów finansowych ta struktura zapobiega powielaniu projektów zgodności. Jeden SZBI może raz zmapować obowiązki na kontrole, a następnie ponownie wykorzystywać dowody w NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019, certyfikacji ISO/IEC 27001:2022 i przeglądach zapewnienia dla klientów.

Zacznij od właścicielstwa kontroli, nie od narzędzi

Pierwszy wzorzec porażki w ciągłym monitorowaniu zgodności to wdrożenie zaczynające się od narzędzi. Firma kupuje platformę GRC, importuje setki wymagań, przypisuje wszystko do „Security” i nazywa to ciągłym monitorowaniem. Sześć miesięcy później pulpit świeci się na czerwono, inżynieria kwestionuje dowody dotyczące podatności, dział prawny twierdzi, że dokumenty dostawców są niekompletne, a kierownictwo nie widzi jasno ryzyka szczątkowego.

ISO/IEC 27001:2022 zapobiega temu, wymagając przypisania i zakomunikowania odpowiedzialności oraz uprawnień. NIS2 i DORA wzmacniają to samo oczekiwanie przez rozliczalność kierownictwa, zdefiniowane role i nadzór.

Polityka ról i odpowiedzialności w ramach ładu zarządczego - MŚP Clarysec stanowi:

Każda rola z odpowiedzialnością za bezpieczeństwo musi być zapisana w centralnym rejestrze i potwierdzona na piśmie.

Ta klauzula jest ważniejsza niż większość pulpitów. Jeśli testowanie kopii zapasowych, usuwanie podatności, due diligence dostawców, klasyfikacja incydentów i przegląd dostępu uprzywilejowanego nie mają imiennie wskazanych właścicieli, nie ma wiarygodnego cyklu gromadzenia dowodów.

Polityka bezpieczeństwa informacji operacjonalizuje to w środowiskach korporacyjnych:

Gromadź i przechowuj dowody audytowe na potrzeby audytów i przeglądów kontroli.

Wymaga również od właścicieli kontroli, aby:

Raportowali wyniki kontroli oraz wszelkie luki lub problemy do Menedżera SZBI.

W Zenith Controls temat ten mapuje się bezpośrednio na kontrole ISO/IEC 27002:2022: 5.2 Role i odpowiedzialności w bezpieczeństwie informacji, 5.35 Niezależny przegląd bezpieczeństwa informacji oraz 5.36 Zgodność z politykami, zasadami i normami bezpieczeństwa informacji.

Zenith Blueprint daje praktyczny punkt wyjścia w fazie ISMS Foundation & Leadership, krok 4: Role and Responsibilities in the ISMS. Rekomenduje formalne powołanie, aktualizacje opisów stanowisk, powiązanie z KPI, komunikację w całej organizacji oraz odpowiedzialność na poziomie działów.

Typowy zapis powołania może brzmieć:

„Ze skutkiem natychmiastowym zostaje Pan/Pani powołany(-a) na stanowisko Oficera bezpieczeństwa informacji z odpowiedzialnością za nadzór i koordynację SZBI, w tym zarządzanie ryzykiem, wdrożenie kontroli i monitorowanie zgodności”.

Takie powołanie nie jest biurokracją. To dowód audytowy dla przywództwa i przypisania ról w ISO/IEC 27001:2022. Wspiera również nadzór kierownictwa w NIS2 i ład zarządczy DORA. Regulatorzy, audytorzy certyfikacyjni i klienci bankowi chcą widzieć, że odpowiedzialność nie jest domniemana. Jest przypisana, potwierdzona, wyposażona w zasoby i monitorowana.

Praktyczny rejestr właścicielstwa kontroli powinien zawierać następujące pola:

Ten rejestr staje się pomostem między polityką a dowodem.

Zdefiniuj KPI i KRI, które potwierdzają skuteczność kontroli

Gdy właściciele są przypisani, muszą wiedzieć, co oznacza „dobrze”. Ciągłe monitorowanie zgodności opiera się na znaczących wskaźnikach, a nie ogólnych intencjach.

„Poprawić wdrażanie poprawek” nie jest KPI. „Regularnie przeglądać dostawców” nie jest dowodem. „Utrzymywać odporność” nie jest mierzalną kontrolą.

Clarysec wyraźnie rozróżnia dwa typy wskaźników:

• KPI, czyli kluczowy wskaźnik efektywności, mierzy, czy proces działa zgodnie z oczekiwaniami.
• KRI, czyli kluczowy wskaźnik ryzyka, sygnalizuje wzrost ryzyka lub przekroczenie progu wymagające eskalacji.

Korporacyjna Polityka zarządzania ryzykiem stanowi:

KRI (kluczowe wskaźniki ryzyka) i metryki bezpieczeństwa należy definiować dla ryzyk krytycznych i monitorować miesięcznie.

Wymaga również logiki eskalacji:

Wyzwalacze eskalacji należy wbudować w logikę monitorowania (np. gdy ryzyko szczątkowe wzrasta o więcej niż jeden poziom lub terminy postępowania z ryzykiem nie są dotrzymywane).

Dla mniejszych organizacji Polityka zarządzania ryzykiem - MŚP Clarysec przyjmuje podejście proporcjonalne:

Postęp w ograniczaniu ryzyka musi być przeglądany kwartalnie.

Dopuszcza również lekkie metryki:

Można śledzić nieformalne metryki (np. liczbę otwartych ryzyk, przeterminowanych działań, nowych incydentów).

Ta proporcjonalność ma znaczenie. Międzynarodowy bank i 60-osobowy dostawca FinTech nie potrzebują identycznej telemetrii, ale oba podmioty potrzebują przypisanego właścicielstwa, powtarzalnego pomiaru, progów eskalacji i dowodów działań korygujących.

Praktyczny model KPI i KRI dla NIS2 i DORA wygląda następująco:

Te metryki wspierają więcej niż certyfikację ISO/IEC 27001:2022. Wspierają również środki zarządzania ryzykiem cyberbezpieczeństwa NIS2, gotowość do zgłaszania incydentów NIS2, zarządzanie ryzykiem ICT w DORA, ryzyko związane z zewnętrznymi dostawcami w DORA, rozliczalność GDPR, wyniki ładu zarządczego NIST CSF 2.0 oraz zarządzanie wynikami w stylu COBIT.

Ustal cykl gromadzenia dowodów, zanim poprosi o nie audyt

Wiele organizacji gromadzi dowody przypadkowo. Zrzut ekranu pojawia się na kanale Teams. Zgłoszenie Jira jest podlinkowane w e-mailu. Kwestionariusz dostawcy znajduje się w zakupach. Test kopii zapasowej jest opisany ustnie. W tygodniu audytu Menedżer SZBI staje się śledczym informatyki śledczej.

Ciągłe monitorowanie zgodności wymaga zaplanowanego cyklu i właściwej higieny dowodów.

Polityka audytu i monitorowania zgodności - MŚP Clarysec stanowi:

Każdy audyt musi obejmować zdefiniowany zakres, cele, odpowiedzialny personel i wymagane dowody.

Wskazuje również:

Dowody muszą być przechowywane przez co najmniej dwa lata albo dłużej, jeśli wymagają tego certyfikacja lub porozumienia z klientami.

Dla organizacji korporacyjnych Polityka audytu i monitorowania zgodności dodaje oczekiwania dotyczące automatyzacji:

Należy wdrożyć zautomatyzowane narzędzia do monitorowania zgodności konfiguracji, zarządzania podatnościami, statusu poprawek i dostępu uprzywilejowanego.

Automatyzacja powinna być ukierunkowana. Kontrole wysokiego ryzyka i wysokiej częstotliwości nie powinny zależeć od ręcznych zrzutów ekranu. Najlepszy model dowodowy łączy zautomatyzowaną telemetrię, poświadczenia właścicieli, rejestry wyjątków, zapisy systemu zgłoszeniowego, wyniki testów i protokoły z przeglądów zarządzania.

Konwencja nazewnictwa również ma znaczenie. Dowody powinny być łatwe do odnalezienia bez nadzwyczajnego wysiłku. Na przykład:

• tygodniowy raport podatności: YYYY-MM-DD_Vulnerability-SLA_ControlOwner
• miesięczny przegląd dostępu uprzywilejowanego: YYYY-MM_IAM-Privileged-Review_Attestation
• kwartalny przegląd dostawców: YYYY-QX_Critical-Supplier-Review
• pakiet incydentu: INC-YYYY-###_Timeline-Classification-RCA-CAPA

W tym miejscu polityka staje się operacyjna. Przechowywanie dowodów nie jest zadaniem archiwalnym. Jest częścią kontroli.

Mapuj jeden dowód na wiele obowiązków

Ciągłe monitorowanie zgodności nabiera mocy, gdy jeden dowód spełnia wymagania wielu ram. Dlatego Zenith Controls jest centralnym elementem podejścia Clarysec do zgodności międzyramowej.

Rozważmy obsługę incydentów. W NIS2 istotne incydenty wymagają etapowego raportowania, w tym wczesnego ostrzeżenia w ciągu 24 godzin od uzyskania wiedzy, powiadomienia w ciągu 72 godzin oraz raportu końcowego w ciągu jednego miesiąca, z zastrzeżeniem krajowej implementacji i faktów dotyczących incydentu. DORA wymaga od podmiotów finansowych zarządzania, klasyfikowania, eskalowania i zgłaszania poważnych incydentów związanych z ICT z wykorzystaniem wymaganych procesów i szablonów. GDPR wymaga od administratorów oceny i obsługi naruszeń ochrony danych osobowych, gdy naruszona jest poufność, integralność lub dostępność danych osobowych.

Jeden pakiet dowodów incydentu może wspierać wszystkie trzy regulacje, jeśli obejmuje:

• oś czasu incydentu i czas uzyskania wiedzy;
• uzasadnienie klasyfikacji;
• dotknięte usługi i jurysdykcje;
• wpływ na klienta, transakcję lub użytkownika;
• ocenę wpływu na dane osobowe;
• analizę przyczyny źródłowej;
• działania ograniczające i odtworzeniowe;
• komunikację i powiadomienia;
• zapis eskalacji do kierownictwa;
• wpis działania korygującego.

Ta sama logika zgodności międzyramowej dotyczy ryzyka dostawców. NIS2 wymaga bezpieczeństwa łańcucha dostaw oraz uwzględnienia bezpośrednich relacji z dostawcami i usługodawcami. DORA wymaga strategii zarządzania ryzykiem związanym z zewnętrznymi dostawcami usług ICT, rejestrów, due diligence przed zawarciem umowy, klauzul umownych, prawa do audytu, poziomów usług, strategii wyjścia i monitorowania ryzyka koncentracji. NIST CSF 2.0 traktuje ryzyko łańcucha dostaw jako dyscyplinę ładu zarządczego w całym cyklu życia. ISO/IEC 27001:2022 wiąże te wymagania z zakresem, wymaganiami stron zainteresowanych, postępowaniem z ryzykiem i kontrolą operacyjną procesów dostarczanych zewnętrznie.

Praktyczna macierz dowodów pomaga właścicielom kontroli zrozumieć, dlaczego dowody mają znaczenie:

To podejście zapobiega powielaniu pracy związanej ze zgodnością. Organizacja gromadzi jeden solidny zestaw dowodów, a następnie mapuje go na wiele obowiązków.

Model monitorowania Clarysec: od obowiązku przez właściciela do dowodu

Solidny model monitorowania opiera się na prostej sekwencji.

Po pierwsze, zdefiniuj obowiązek. Na przykład DORA wymaga zarządzania ryzykiem związanym z zewnętrznymi dostawcami usług ICT jako częścią zarządzania ryzykiem ICT, z rejestrami, due diligence, wymogami umownymi, prawami do audytu i strategiami wyjścia dla funkcji krytycznych lub ważnych. NIS2 wymaga bezpieczeństwa łańcucha dostaw i odpowiednich działań korygujących.

Po drugie, przełóż obowiązek na wymagania SZBI według ISO/IEC 27001:2022. Obejmuje to wymagania stron zainteresowanych, zakres, ocenę ryzyka, postępowanie z ryzykiem, Deklarację stosowania, kontrolę operacyjną, monitorowanie, audyt wewnętrzny, przegląd zarządzania i doskonalenie.

Po trzecie, wybierz kontrole operacyjne. W Zenith Controls podstawowe kontrole ładu zarządczego dla ciągłego monitorowania zgodności obejmują kontrole ISO/IEC 27002:2022 5.2, 5.35 i 5.36. Kontrole wspierające często obejmują 5.19 Bezpieczeństwo informacji w relacjach z dostawcami, 5.21 Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT, 5.22 Monitorowanie, przegląd i zarządzanie zmianami usług dostawców, 5.23 Bezpieczeństwo informacji przy korzystaniu z usług chmurowych, 5.24 Planowanie i przygotowanie zarządzania incydentami bezpieczeństwa informacji, 5.26 Reagowanie na incydenty bezpieczeństwa informacji, 5.30 Gotowość ICT dla ciągłości działania, 5.31 Wymagania prawne, ustawowe, regulacyjne i umowne, 8.8 Zarządzanie podatnościami technicznymi, 8.13 Kopie zapasowe informacji, 8.15 Rejestrowanie, 8.16 Działania monitorujące oraz 8.9 Zarządzanie konfiguracją.

Po czwarte, przypisz właściciela i cykl. Ryzyko dostawcy może angażować zakupy, dział prawny, bezpieczeństwo i właściciela usługi biznesowej, ale jeden rozliczalny właściciel musi utrzymywać rejestr i raportować wyjątki.

Po piąte, zdefiniuj KPI, KRI i dowody. KPI dostawców mogą obejmować odsetek krytycznych dostawców ICT z ukończonym due diligence, odsetek z zatwierdzonymi klauzulami umownymi, liczbę dostawców bez przetestowanych planów wyjścia oraz liczbę przeterminowanych przeglądów dostawców. KRI mogą obejmować nierozwiązane ustalenia wysokiego ryzyka dotyczące dostawców, ryzyko koncentracji powyżej tolerancji lub brak praw do audytu dla usługi wspierającej funkcję krytyczną lub ważną.

Po szóste, raportuj i eskaluj. Miesięczne pulpity SZBI nie powinny jedynie pokazywać zielonego statusu. Powinny identyfikować przeterminowane dowody, zmiany poziomu ryzyka, niedotrzymane terminy postępowania z ryzykiem i wymagane decyzje kierownictwa.

Po siódme, audytuj i doskonal. Luki dowodowe stają się działaniami korygującymi, a nie wymówkami.

Jest to zgodne z fazą Audit, Review & Improvement w Zenith Blueprint. Krok 25, Internal Audit Program, rekomenduje objęcie właściwych procesów i kontroli SZBI cyklem audytowym, z corocznym audytem pełnego zakresu oraz mniejszymi kwartalnymi kontrolami wyrywkowymi dla obszarów wysokiego ryzyka, gdy jest to właściwe. Krok 28, Management Review, wymaga danych wejściowych takich jak zmiany wymagań, wyniki monitorowania i pomiarów, wyniki audytów, incydenty, niezgodności, możliwości doskonalenia i potrzeby zasobowe. Krok 29, Continual Improvement, wykorzystuje rejestr CAPA do rejestrowania opisu problemu, przyczyny źródłowej, działania korygującego, odpowiedzialnego właściciela, terminu docelowego i statusu.

Tak wygląda ciągłe monitorowanie zgodności w praktyce.

Praktyczny scenariusz: krytyczna podatność w publicznym API

O 02:15 uruchamia się alert SIEM. Skan podatności zidentyfikował krytyczną podatność zdalnego wykonania kodu w publicznie dostępnej bramie API wspierającej regulowaną usługę płatniczą.

Model ciągłego monitorowania powinien zadziałać bez czekania na spotkanie.

Po pierwsze, inwentarz aktywów klasyfikuje bramę jako krytyczną. Zegar KPI zarządzania podatnościami zaczyna biec. KRI dla niezałatanych podatności krytycznych wzrasta. Jeśli aktywo jest dostępne z Internetu, a exploit jest aktywny, próg eskalacji uruchamia się natychmiast.

Po drugie, zgłoszenie trafia do dyżurnego zespołu DevOps. Dyrektor ds. DevOps, jako właściciel kontroli zarządzania podatnościami, otrzymuje automatyczne powiadomienie. Kierownik SOC śledzi, czy istnieją wskaźniki wykorzystania podatności. Menedżer SZBI monitoruje, czy spełniono kryteria incydentu.

Po trzecie, dowody są gromadzone jako produkt uboczny przepływu pracy. Alert SIEM, skan podatności, klasyfikacja aktywa, znaczniki czasu zgłoszenia, czat reakcji, zapis wdrożenia poprawki, skan walidacyjny i akceptacja zamknięcia są dołączane do pakietu dowodowego.

Po czwarte, zespół ocenia, czy zdarzenie jest tylko podatnością, zdarzeniem bezpieczeństwa czy incydentem. Jeśli występuje wpływ na usługę, wskaźniki naruszenia, wpływ na klienta lub ekspozycja danych osobowych, przepływ obsługi incydentu uruchamia oceny raportowania według NIS2, DORA, GDPR i umów.

Po piąte, kierownictwo otrzymuje zwięzły raport. Jeśli podatność została usunięta w ciągu czterech godzin, dowody wspierają skuteczność kontroli. Jeśli SLA zostało przekroczone, rejestr CAPA odnotowuje przyczynę źródłową, działanie korygujące, właściciela, termin docelowy i status.

To pojedyncze zdarzenie generuje użyteczne dowody dla zarządzania podatnościami, gotowości incydentowej, monitorowania, dostępu do aktywów krytycznych, przeglądu zarządzania i ciągłego doskonalenia.

Jak audytorzy i regulatorzy będą testować ten sam model monitorowania

Dojrzały program ciągłego monitorowania zgodności musi przetrwać różne perspektywy audytowe. Dowody się nie zmieniają, ale pytania tak.

Dla kontroli ISO/IEC 27002:2022 5.35 Niezależny przegląd bezpieczeństwa informacji audytor ISO/IEC 27001:2022 skupi się na planie audytu wewnętrznego, zakresie, kompetencjach, ustaleniach i działaniach korygujących. Regulator NIS2 lub DORA skupi się na tym, czy kierownictwo zrozumiało ustalenia, sfinansowało remediację i ograniczyło ryzyko systemowe. Asesor NIST CSF 2.0 może zmapować przegląd do funkcji GOVERN, w tym nadzoru i korekty wyników.

Ten sam zestaw dowodów służy wszystkim, jeśli jest kompletny, aktualny i powiązany z właścicielstwem.

Typowe pułapki osłabiające ciągłe monitorowanie zgodności

Pierwsza pułapka to traktowanie NIS2 i DORA jako odrębnych projektów. Tworzy to powielone rejestry, sprzeczne metryki i przeciążonych właścicieli kontroli. Wykorzystaj ISO/IEC 27001:2022 jako fundament SZBI i mapuj obowiązki przez jedną bibliotekę kontroli.

Druga pułapka to przypisywanie kontroli zespołom zamiast osobom. „IT odpowiada za kopie zapasowe” nie wystarcza. Imiennie wskazany właściciel musi poświadczać, raportować wyjątki i eskalować ryzyko.

Trzecia pułapka to gromadzenie dowodów bez oceny skuteczności. Zrzut ekranu z sukcesem kopii zapasowej nie potwierdza możliwości odzyskania danych. Potwierdza ją test odtwarzania. Kwestionariusz dostawcy nie potwierdza odporności strony trzeciej. Klauzule umowne, prawa do audytu, postanowienia dotyczące powiadamiania o incydentach, raporty wyników i planowanie wyjścia tworzą silniejsze dowody.

Czwarta pułapka to mierzenie aktywności zamiast ryzyka. Liczenie podatności jest użyteczne. Śledzenie przeterminowanych krytycznych podatności w systemach dostępnych z Internetu jest lepsze. Liczenie dostawców jest użyteczne. Śledzenie krytycznych dostawców bez planów wyjścia jest lepsze.

Piąta pułapka to słaba dyscyplina działań korygujących. Krok 29 w Zenith Blueprint jasno wskazuje, że ustalenia wymagają opisu problemu, przyczyny źródłowej, działania korygującego, odpowiedzialnego właściciela, terminu docelowego i statusu. Jeśli rejestr CAPA nie jest przeglądany, ciągłe monitorowanie zgodności staje się ciągłym gromadzeniem znanych słabości.

Co kierownictwo powinno widzieć co miesiąc

Organy zarządzające w ramach NIS2 i DORA nie potrzebują surowych eksportów ze skanerów. Potrzebują obrazu ryzyka cyber i ICT o jakości umożliwiającej podejmowanie decyzji.

Miesięczny pulpit dla zarządu lub kierownictwa powinien obejmować:

• najważniejsze ryzyka cyber i ICT wraz ze zmianą ryzyka szczątkowego;
• przeterminowane działania w zakresie postępowania z ryzykiem i niedotrzymane terminy;
• istotne incydenty, kandydatów na poważne incydenty związane z ICT oraz wnioski z doświadczeń;
• wyjątki dotyczące ryzyka krytycznych dostawców;
• wyniki SLA podatności dla aktywów krytycznych;
• status testów kopii zapasowych i odzyskiwania;
• wyjątki z przeglądu dostępu uprzywilejowanego;
• wskaźnik kompletności dowodów zgodności;
• ustalenia audytowe i status CAPA;
• wymagane decyzje zasobowe.

Bezpośrednio wspiera to przegląd zarządzania ISO/IEC 27001:2022 oraz oczekiwania ładu zarządczego NIS2 i DORA. Jest również zgodne z NIST CSF 2.0, gdzie najwyższe kierownictwo wyznacza priorytety, rozliczalność, zasoby i apetyt na ryzyko, a menedżerowie przekładają te priorytety na profile docelowe i plany działań.

Zbuduj rytm dowodowy NIS2 i DORA w tym tygodniu

Nie musisz od razu obejmować wszystkiego naraz, aby zacząć. Użyteczny pierwszy tydzień może być prosty.

Dzień 1: utwórz rejestr właścicieli kontroli dla pięciu domen: ład zarządczy i zarządzanie ryzykiem, zarządzanie incydentami i raportowanie, zarządzanie podatnościami i poprawkami, ryzyko dostawców i chmury oraz ciągłość działania i odzyskiwanie.

Dzień 2: zdefiniuj po jednym KPI i jednym KRI dla każdej domeny. Niech będą konkretne, mierzalne i powiązane z apetytem na ryzyko.

Dzień 3: zmapuj każdy dowód na wartość dla NIS2, DORA, ISO/IEC 27001:2022, GDPR i zapewnienia dla klientów.

Dzień 4: ustal cykl gromadzenia dowodów, lokalizację przechowywania, konwencję nazewnictwa, zasadę okresu przechowywania i osobę przeprowadzającą przegląd.

Dzień 5: przeprowadź ćwiczenie tabletop eskalacji. Użyj scenariusza awarii chmury lub krytycznej podatności. Potwierdź klasyfikację, ocenę raportowania regulacyjnego, komunikację z klientem, przechowywanie dowodów i utworzenie CAPA.

Jeśli Twoja organizacja nadal zarządza NIS2 i DORA za pomocą arkuszy kalkulacyjnych, corocznych warsztatów i rozproszonych folderów dowodowych, teraz jest czas, aby przejść na monitorowany rytm operacyjny.

Zacznij od trzech działań:

1. Zbuduj rejestr właścicieli kontroli dla domen o najwyższym ryzyku.
2. Zdefiniuj jeden KPI, jeden KRI, jeden dowód i jeden cykl dla każdej kontroli.
3. Przeprowadź 30-minutowy przegląd dowodów i otwórz pozycje CAPA dla wszystkiego, czego brakuje.

Clarysec może pomóc przyspieszyć tę zmianę dzięki Zenith Blueprint do sekwencjonowania wdrożenia, Zenith Controls do mapowania zgodności międzyramowej oraz bibliotece polityk Clarysec, w tym Polityce bezpieczeństwa informacji, Polityce zarządzania ryzykiem, Polityce audytu i monitorowania zgodności, Polityce ról i odpowiedzialności w ramach ładu zarządczego - MŚP, Polityce zarządzania ryzykiem - MŚP oraz Polityce audytu i monitorowania zgodności - MŚP.

Celem nie jest większa liczba dokumentów zgodności. Celem jest odpowiedzieć na piątkowe popołudniowe pytanie z pewnością:

„Tak, wiemy, kto jest właścicielem kontroli, znamy KPI, mamy dowody, znamy wyjątki, a kierownictwo przejrzało ryzyko”.

Skontaktuj się z Clarysec, aby zbudować model ciągłego monitorowania zgodności, który jest gotowy na audyt, gotowy dla zarządu i wystarczająco odporny na NIS2, DORA oraz kolejną regulację, która nadejdzie.