Rejestry kontaktów regulacyjnych NIS2 i DORA jako dowód dla ISO 27001

Incydent o 02:17: gdy lista kontaktów staje się środkiem kontrolnym

O 02:17 we wtorek analityk SOC widzi wzorzec, którego nikt nie chce zobaczyć. Uprzywilejowane konto serwisowe uwierzytelniło się z nietypowej lokalizacji geograficznej, rejestry klientów były odpytywane sekwencyjnie, a dostawca zarządzanej detekcji utworzył zgłoszenie o wysokim priorytecie. W ciągu kilku minut dowódca incydentu potwierdza obawy: wskaźniki ransomware rozprzestrzeniają się ruchem lateralnym, krytyczna usługa produkcyjna działa w trybie zdegradowanym, a sprawa może dotyczyć danych klientów.

Reakcja techniczna rusza szybko. Punkty końcowe są izolowane, pobierane są logi tożsamości, zabezpieczane są migawki w chmurze obliczeniowej, a dostawca zarządzanych usług bezpieczeństwa dołącza do połączenia koordynacyjnego. Następnie zaczyna się chłodniejsza panika.

CISO pyta: „Kogo powiadamiamy?”

Dział prawny wskazuje, że może być konieczne zaangażowanie organu ochrony danych. DPO pyta, czy jest to naruszenie ochrony danych osobowych. COO twierdzi, że dostawca usług chmurowych musi zostać objęty eskalacją zgodnie z klauzulą wsparcia korporacyjnego. Kierownik ds. zgodności pyta, czy podmiot jest podmiotem ważnym w rozumieniu NIS2 albo czy zastosowanie ma DORA, ponieważ usługa wspiera regulowany podmiot finansowy. Zarząd chce wiedzieć, co musi wydarzyć się w pierwszych 24 godzinach.

Nikt nie kwestionuje potrzeby komunikacji. Problem polega na tym, że dane kontaktowe, ścieżka zatwierdzenia, przesłanki prawne i wymagania dowodowe są rozproszone między starym arkuszem ciągłości działania, umowami z dostawcami, wątkami e-mail, nieaktualną wiki zgodności i telefonem jednej osoby.

To nie jest tylko niedogodność operacyjna. W 2026 roku jest to luka zgodności.

NIS2 uczyniła etapowe powiadamianie o incydentach obowiązkiem ładu zarządczego, obejmującym wczesne ostrzeżenie w ciągu 24 godzin, powiadomienie w ciągu 72 godzin oraz raport końcowy w ciągu miesiąca dla istotnych incydentów. DORA ustanowiła odrębny reżim cyfrowej odporności operacyjnej dla podmiotów finansowych, obejmujący zarządzanie incydentami związanymi z ICT, klasyfikację, raportowanie nadzorcze, ryzyko stron trzecich ICT oraz komunikację kryzysową. GDPR pozostaje istotne zawsze, gdy w grę wchodzą dane osobowe. ISO/IEC 27001:2022 przekształca te obowiązki w podlegające audytowi dowody systemu zarządzania.

Rejestr kontaktów regulacyjnych brzmi administracyjnie. Nie jest nim. To tkanka łączna między reagowaniem na incydenty, powiadomieniem prawnym, ciągłością działania, koordynacją dostawców, rozliczalnością kierownictwa i dowodami audytowymi.

Clarysec traktuje to jako problem dowodowy, a nie ćwiczenie dokumentacyjne. W Zenith Blueprint: 30-etapowa mapa drogowa audytora Zenith Blueprint, krok 22 w fazie „Środki kontrolne w działaniu” wyjaśnia, dlaczego kontakt z organami musi być z góry zdefiniowany:

Środek kontrolny 5.5 zapewnia, że organizacja jest przygotowana do kontaktu z organami zewnętrznymi wtedy, gdy jest to potrzebne — nie reaktywnie ani w panice, lecz przez wcześniej zdefiniowane, uporządkowane i dobrze zrozumiane kanały.

To jest prawdziwa lekcja z incydentu o 02:17. Czas na znalezienie portalu zgłoszeniowego regulatora, telefonu dyżurnego CSIRT, zapasowego kontaktu DPO, kanału zgłoszeniowego nadzorcy finansowego i ścieżki eskalacji dostawcy jest przed incydentem, a nie wtedy, gdy termin zgłoszenia już biegnie.

Dlaczego rejestry kontaktów regulacyjnych stały się priorytetem zgodności w 2026 roku

Wiele organizacji ma już listy kontaktów awaryjnych. Problem polega na tym, że NIS2 i DORA wymagają czegoś bardziej zdyscyplinowanego niż lista nazwisk i numerów telefonów. Wymagają precyzyjnego, opartego na rolach i gotowego dowodowo nadzoru nad kontaktami, powiązanego z przesłankami prawnymi, uprawnieniami eskalacyjnymi, terminami raportowania oraz zależnościami od dostawców.

NIS2 ma zastosowanie do szerokiego zbioru podmiotów kluczowych i ważnych w sektorach takich jak energia, transport, bankowość, infrastruktura rynków finansowych, ochrona zdrowia, woda pitna, ścieki, infrastruktura cyfrowa, zarządzanie usługami ICT, administracja publiczna i przestrzeń kosmiczna. Obejmuje również wielu dostawców cyfrowych, w tym usługi chmury obliczeniowej, usługi centrów danych, sieci dostarczania treści, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa, internetowe platformy handlowe, wyszukiwarki internetowe i platformy społecznościowe. Państwa członkowskie miały obowiązek ustanowić wykazy podmiotów kluczowych i ważnych do 17 kwietnia 2025 r. oraz aktualizować je co najmniej co dwa lata. Dla wielu dostawców usług chmurowych, SaaS, usług zarządzanych i platform cyfrowych ekspozycja regulacyjna przeszła z poziomu teoretycznego na operacyjny.

DORA ma zastosowanie od 17 stycznia 2025 r. do podmiotów finansowych, takich jak instytucje kredytowe, instytucje płatnicze, instytucje pieniądza elektronicznego, firmy inwestycyjne, dostawcy usług w zakresie kryptoaktywów, systemy obrotu, centralne depozyty papierów wartościowych, kontrahenci centralni, zakłady ubezpieczeń i reasekuracji oraz inne objęte nią organizacje sektora finansowego. DORA jest również głęboko istotna dla ekosystemu stron trzecich ICT, ponieważ podmioty finansowe muszą zarządzać dostawcami wspierającymi funkcje krytyczne lub istotne. DORA Article 17 wymaga procesu zarządzania incydentami związanymi z ICT, Article 18 określa oczekiwania klasyfikacyjne, a Article 19 reguluje zgłaszanie poważnych incydentów związanych z ICT do właściwego organu.

GDPR dodaje wymiar prywatności. Incydent cyberbezpieczeństwa może stać się naruszeniem ochrony danych osobowych, jeżeli obejmuje przypadkowe lub niezgodne z prawem zniszczenie, utratę, zmianę, nieuprawnione ujawnienie lub dostęp do danych osobowych. Administrator musi być w stanie wykazać rozliczalność, ocenić ryzyko dla osób fizycznych oraz, gdy jest to wymagane, powiadomić organ nadzorczy i potencjalnie osoby, których dane dotyczą.

Dojrzały rejestr kontaktów regulacyjnych musi zatem pod presją odpowiadać na pięć pytań:

• Który CSIRT, właściwy organ, nadzorca finansowy, organ ochrony danych i kontakt do organów ścigania mają zastosowanie do tej osoby prawnej, jurysdykcji i usługi?
• Która rola wewnętrzna jest upoważniona do zainicjowania kontaktu, zatwierdzenia treści i złożenia powiadomień?
• Z którymi dostawcami należy skontaktować się w celu powstrzymania incydentu, pozyskania logów, odtworzenia, zabezpieczenia materiału dowodowego lub raportowania umownego?
• Która ścieżka komunikacji z klientem, kontrahentem lub opinią publiczną jest uruchamiana na każdym poziomie wagi?
• Jak udowodnimy, że rejestr został przejrzany, przetestowany i użyty prawidłowo?

Odpowiedź nie może znajdować się wyłącznie w skrzynce działu prawnego albo w pamięci CISO. Musi to być kontrolowany zapis SZBI.

Co zawiera gotowy dowodowo rejestr kontaktów NIS2 i DORA

Rejestr kontaktów regulacyjnych powinien być zaprojektowany do użycia podczas rzeczywistego incydentu. Jeżeli dowódca incydentu musi podjąć pierwszą decyzję eskalacyjną w ciągu kilku minut, rejestr nie może być niejasną listą stron internetowych. Musi być uporządkowany, zweryfikowany i powiązany z podręcznikiem reagowania na incydenty.

Kompletny rejestr powinien obejmować co najmniej sześć rodzin kontaktów.

Po pierwsze, oficjalne organy cyberbezpieczeństwa: krajowe CSIRT, właściwe organy, pojedyncze punkty kontaktowe tam, gdzie mają zastosowanie, oraz sektorowe agencje cyberbezpieczeństwa.

Po drugie, nadzorcy finansowi dla DORA: właściwe organy i kanały raportowania wykorzystywane do wstępnego, pośredniego i końcowego zgłaszania poważnych incydentów związanych z ICT.

Po trzecie, organy ds. prywatności: organy ochrony danych, logika wiodącego organu nadzorczego dla przetwarzania transgranicznego oraz ścieżki eskalacji DPO.

Po czwarte, organy ścigania: jednostki ds. cyberprzestępczości, jednostki ds. oszustw oraz kontakty awaryjne dla wymuszeń, ransomware, nieuprawnionego dostępu i zabezpieczenia materiału dowodowego.

Po piąte, dostawcy i strony trzecie ICT: dostawcy usług chmurowych, dostawcy zarządzanych usług bezpieczeństwa, dostawcy usług zarządzanych, platformy tożsamości, operatorzy płatności, dostawcy informatyki śledczej i doradca prawny.

Po szóste, wewnętrzne role eskalacyjne: dowódca incydentu, CISO, DPO, doradca prawny, osoba odpowiedzialna za komunikację, osoba odpowiedzialna za ciągłość działania, osoba zatwierdzająca po stronie kierownictwa, łącznik z zarządem i właściciel usługi.

Rejestr powinien również obejmować grupy specjalnego zainteresowania tam, gdzie są istotne, takie jak ISAC lub sektorowe społeczności wymiany informacji. Nie są to regulatorzy, ale mogą stać się ważnymi kanałami informacji o zagrożeniach i skoordynowanej reakcji.

Zenith Blueprint przekłada to na praktykę w kroku 22:

Utwórz lub zaktualizuj procedury kontaktu z organami podczas zdarzeń bezpieczeństwa (5.5), obejmujące dane kontaktowe lokalnych CERT, regulatorów i organów ścigania. Utrzymuj podobną listę kontaktów na potrzeby udziału w forach bezpieczeństwa lub grupach sektorowych (5.6). Przechowuj te informacje w lokalizacji dostępnej, ale objętej kontrolą dostępu, i uwzględnij je w podręczniku reagowania na incydenty.

To ostatnie zdanie ma znaczenie. Jeżeli rejestr nie znajduje się w podręczniku reagowania na incydenty, prawdopodobnie nie zostanie użyty wtedy, gdy presja będzie realna.

Przykładowa struktura rejestru kontaktów dla dostawcy FinTech lub SaaS

Wyobraźmy sobie dostawcę fintech SaaS, który wspiera analitykę płatności dla klientów z UE. Korzysta z dostawcy usług chmurowych, dostawcy zarządzanej detekcji, platformy tożsamości, platformy obsługi klienta i zewnętrznego doradcy prawnego. W zależności od swojej roli może być podmiotem finansowym, zewnętrznym dostawcą usług ICT, dostawcą cyfrowym objętym zakresem NIS2 albo podmiotem przetwarzającym dane osobowe na gruncie GDPR.

Praktyczny rejestr mógłby zaczynać się tak:

Wpisy nie powinny zawierać zbędnych danych osobowych. Tam, gdzie to możliwe, należy używać kontaktów opartych na rolach, chronić wrażliwe dane kontaktowe i zapewnić dostępność offline podczas poważnej awarii. Rejestr dostępny wyłącznie z tych samych systemów, których dotyczy incydent ransomware, nie jest odporny.

Mapowanie rejestru na dowody ISO/IEC 27001:2022

Audytorzy rzadko stwierdzają niezgodność dlatego, że organizacja nie ma arkusza kalkulacyjnego. Stwierdzają ją dlatego, że organizacja nie potrafi udowodnić, iż arkusz jest kompletny, aktualny, zatwierdzony, chroniony, przetestowany i powiązany z rzeczywistymi procesami.

ISO/IEC 27001:2022 zaczyna od kontekstu organizacji. Klauzule 4.1 do 4.4 wymagają, aby organizacja rozumiała kwestie wewnętrzne i zewnętrzne, identyfikowała zainteresowane strony oraz ich wymagania, definiowała zakres SZBI i rozumiała interfejsy oraz zależności. Rejestr kontaktów regulacyjnych jest silnym dowodem, że wymagania prawne, regulacyjne, umowne i wymagania interesariuszy zostały przełożone na relacje operacyjne.

Następnie pojawia się przywództwo. Klauzule 5.1 do 5.3 wymagają od najwyższego kierownictwa wykazania przywództwa, przypisania odpowiedzialności, zapewnienia komunikacji i wspierania SZBI. Jeżeli rejestr wskazuje, kto jest upoważniony do powiadomienia CSIRT, nadzorcy lub organu ochrony danych, kto zatwierdza komunikację zewnętrzną oraz kto raportuje status incydentu do najwyższego kierownictwa, wspiera to dowody dotyczące przywództwa.

Planowanie ryzyka przekształca następnie obowiązki w działania. Klauzule 6.1.1 do 6.1.3 wymagają procesu oceny ryzyka i postępowania z ryzykiem, porównania z załącznikiem A, Deklaracji stosowania, planu postępowania z ryzykiem i akceptacji ryzyka rezydualnego. Rejestr powinien pojawić się w planie postępowania z ryzykiem dla ryzyk takich jak nieskuteczne powiadomienie prawne, opóźniona eskalacja incydentu, nieskuteczna reakcja dostawcy, błąd powiadomienia transgranicznego i załamanie komunikacji w ciągłości działania.

Punkty odniesienia ze środków kontrolnych załącznika A są jasne:

W Zenith Controls: przewodnik po zgodności między ramami Zenith Controls kontakt z organami jest traktowany jako środek kontrolny 5.5 o charakterze zapobiegawczym i korygującym. Wspiera poufność, integralność i dostępność oraz łączy się z funkcjami cyberbezpieczeństwa Identify, Protect, Respond i Recover. Zenith Controls wiąże go z planowaniem incydentów, zgłaszaniem zdarzeń, informacjami o zagrożeniach, grupami specjalnego zainteresowania i reagowaniem na incydenty. Wyjaśnia również, dlaczego wcześniej ustanowione kontakty z regulatorami, organami ścigania, krajowymi CERT lub organami ochrony danych umożliwiają szybszą eskalację i uzyskanie wskazówek podczas zdarzeń takich jak istotne naruszenia lub ataki ransomware.

Ten środek kontrolny nie jest odizolowany. Zenith Controls mapuje również środek kontrolny 6.8, zgłaszanie zdarzeń bezpieczeństwa informacji, jako kontrolę detekcyjną powiązaną z planowaniem incydentów, oceną zdarzeń, reakcją, wnioskami, świadomością, monitorowaniem i procesem dyscyplinarnym. Środek kontrolny 5.24, planowanie i przygotowanie zarządzania incydentami bezpieczeństwa informacji, łączy się z oceną zdarzeń, wnioskami, logowaniem, monitorowaniem, bezpieczeństwem podczas zakłóceń, ciągłością oraz kontaktem z organami. Historia audytowa staje się silniejsza, gdy zdarzenia są zgłaszane, oceniane, eskalowane, komunikowane, udokumentowane dowodowo i doskonalone.

NIS2, DORA i GDPR: jeden rejestr, różne zegary prawne

Jeden incydent może uruchomić kilka ścieżek prawnych. Nieuprawniony dostęp u dostawcy SaaS może być istotnym incydentem NIS2, naruszeniem ochrony danych osobowych GDPR i zdarzeniem wymagającym umownego powiadomienia klienta. Niedostępność u podmiotu finansowego może być poważnym incydentem związanym z ICT w rozumieniu DORA, a jednocześnie wymagać analizy GDPR i koordynacji z dostawcą.

NIS2 wymaga, aby podmioty kluczowe i ważne bez zbędnej zwłoki powiadamiały swój CSIRT lub właściwy organ o istotnych incydentach wpływających na świadczenie usług. Etapowy model raportowania obejmuje wczesne ostrzeżenie bez zbędnej zwłoki i w ciągu 24 godzin od uzyskania świadomości, powiadomienie o incydencie bez zbędnej zwłoki i w ciągu 72 godzin, pośrednie raporty statusowe na żądanie oraz raport końcowy w ciągu miesiąca od powiadomienia o incydencie. Jeżeli incydent nadal trwa, może być również wymagane raportowanie postępów.

DORA wymaga od podmiotów finansowych utrzymywania procesu zarządzania incydentami związanymi z ICT, który wykrywa, obsługuje i zgłasza incydenty, rejestruje incydenty i istotne cyberzagrożenia, klasyfikuje wagę i krytyczność, przypisuje role, definiuje eskalację i komunikację, raportuje poważne incydenty do kierownictwa wyższego szczebla oraz wspiera terminowe odzyskiwanie. Zgłaszanie poważnych incydentów związanych z ICT opiera się na logice raportowania wstępnego, pośredniego i końcowego, a klasyfikacja uwzględnia takie czynniki jak dotknięci klienci, czas trwania, zasięg geograficzny, utrata danych, krytyczność usług i wpływ ekonomiczny.

GDPR dodaje ocenę naruszenia ochrony danych osobowych. Rejestr kontaktów samodzielnie nie przesądza o obowiązku zgłoszenia. Zapewnia, że właściwe osoby mogą szybko podjąć decyzję, korzystając z aktualnych kanałów i udokumentowanych kryteriów.

Biblioteka polityk Clarysec przekłada to na działania operacyjne. W polityce SME Incident Response Policy Polityka reagowania na incydenty — SME, klauzula 5.1.1 stanowi:

Dyrektor Generalny (GM) odpowiada za autoryzację wszystkich decyzji dotyczących eskalacji incydentów, powiadomień regulacyjnych oraz komunikacji zewnętrznej.

Ta sama polityka SME, klauzula 7.4.1, dodaje:

Jeżeli sprawa dotyczy danych klientów, Dyrektor Generalny musi ocenić obowiązki prawnego powiadomienia na podstawie stosowalności GDPR, NIS2 lub DORA.

Dla środowisk korporacyjnych Incident Response Policy Polityka reagowania na incydenty, klauzula 5.5, ustanawia ramy komunikacji:

Cała komunikacja związana z incydentem musi przebiegać zgodnie z Macierzą komunikacji i eskalacji, zapewniając:

Klauzula 6.4.2 dodaje wymaganie dowodowe:

Wszystkie zgłoszenia naruszeń muszą być udokumentowane i zatwierdzone przed złożeniem, a ich kopie muszą być przechowywane w SZBI.

W tym miejscu rejestr staje się dowodem ISO. Nie chodzi wyłącznie o wiedzę, do kogo zadzwonić. Chodzi o wykazanie, kto był upoważniony, co zostało ocenione, co zatwierdzono, co złożono i gdzie znajduje się zachowana kopia.

Model dowodowy Clarysec: cztery artefakty działające razem

Silna zdolność obsługi kontaktów regulacyjnych wymaga czterech artefaktów działających jako jeden łańcuch dowodowy.

Rejestr kontaktów regulacyjnych identyfikuje kontakty, kanały, przesłanki i właścicieli. Macierz komunikacji i eskalacji definiuje, kto wykonuje jakie działania. Dziennik decyzji rejestruje klasyfikację, ocenę obowiązku zgłoszenia, przegląd prawny i zatwierdzenie. Pakiet dowodowy powiadomień zachowuje złożone zawiadomienia, potwierdzenia z portali, wiadomości e-mail, notatki z rozmów, informacje zwrotne od regulatora, odpowiedzi dostawców i raporty końcowe.

Legal and Regulatory Compliance Policy Clarysec Polityka zgodności prawnej i regulacyjnej — SME czyni koncepcję rejestru wyraźną. Klauzula 5.5.2 stanowi:

Kluczowe warunki zgodności, np. terminy zgłaszania naruszeń i klauzule dotyczące postępowania z danymi, muszą zostać wyodrębnione i śledzone w Rejestrze zgodności.

Rejestr zgodności powinien zasilać rejestr kontaktów regulacyjnych. Wymaganie prawne może brzmieć „wczesne ostrzeżenie NIS2 w ciągu 24 godzin”, podczas gdy rejestr kontaktów wskazuje krajowy portal CSIRT, zapasowy numer dyżurny, upoważnioną osobę składającą zgłoszenie, osobę dokonującą przeglądu prawnego, wymagane dowody i ścieżkę przechowywania.

Polityki ciągłości działania wzmacniają to samo oczekiwanie. Polityka SME Business Continuity Policy and Disaster Recovery Policy Polityka ciągłości działania i odtwarzania po awarii — SME, klauzula 5.2.1.1, odnosi się do:

list kontaktowych i alternatywnych planów komunikacji

Korporacyjna Business Continuity Policy and Disaster Recovery Policy Polityka ciągłości działania i odtwarzania po awarii, klauzula 5.3.3, wymaga, aby ustalenia dotyczące ciągłości były:

Wspierane przez aktualne listy kontaktów i przepływy eskalacji

Nadzór nad dostawcami również należy do tego modelu. W polityce SME Third-Party and Supplier Security Policy Polityka bezpieczeństwa dostawców i stron trzecich — SME, klauzula 5.4.3 wymaga:

Przypisanej osoby kontaktowej

Dla NIS2 i DORA taki kontakt nie może być ogólny. Jeżeli krytyczny dostawca usług chmurowych, dostawca zarządzanych usług bezpieczeństwa, dostawca tożsamości lub operator płatności wspiera usługę regulowaną, rejestr powinien identyfikować kontakt operacyjny, kontakt ds. incydentów bezpieczeństwa, kanał powiadomień umownych i ścieżkę eskalacji dla wniosków dowodowych.

Zbuduj rejestr podczas jednej sesji roboczej

Użyteczny rejestr można zbudować szybko, jeżeli w spotkaniu uczestniczą właściwe osoby. Zaplanuj dwugodzinną sesję z CISO, DPO, doradcą prawnym, menedżerem dostawców, osobą odpowiedzialną za ciągłość działania, dowódcą incydentu i właścicielem zgodności.

Zacznij od Rejestru zgodności. Wyodrębnij obowiązki raportowe wynikające z NIS2, DORA, GDPR, umów i wymagań sektorowych. Zapisz terminy, kryteria obowiązku zgłoszenia i wymagania dowodowe.

Otwórz podręcznik reagowania na incydenty. Dla każdej kategorii incydentu, takiej jak ransomware, nieuprawniony dostęp, niedostępność usługi, eksfiltracja danych, incydent dostawcy i awaria regionu chmurowego, wskaż wymagane kontakty zewnętrzne.

Uzupełnij rejestr kontaktów regulacyjnych o organ, jurysdykcję, przesłankę, kanał główny, kanał zapasowy, właściciela, zatwierdzającego, wymagane dowody, datę ostatniej walidacji i lokalizację przechowywania.

Powiąż kontakty dostawców. Dla każdej funkcji krytycznej lub istotnej wskaż kontakt dostawcy ds. incydentów bezpieczeństwa, kanał powiadomień umownych, kontakt audytowy i awaryjną ścieżkę eskalacji.

Przejrzyj zgodność z politykami. Potwierdź, że uprawnienia eskalacyjne odpowiadają Polityce reagowania na incydenty, dowody powiadomień są przechowywane w SZBI, listy kontaktów ciągłości działania są spójne, a kontakty dostawców mają przypisanych właścicieli.

Przetestuj jeden scenariusz. Użyj ukierunkowanego ćwiczenia typu tabletop: „Ekspozycja danych klientów wykryta o 02:17, dotycząca klientów z UE i potencjalnie spowodowana naruszonymi danymi uwierzytelniającymi dostawcy tożsamości”. Poproś zespół o wskazanie, czy mogą być wymagane powiadomienia CSIRT, organu ochrony danych, nadzorcy finansowego, dostawcy i klientów. Celem ćwiczenia nie jest wymuszenie ostatecznej konkluzji prawnej. Celem jest udowodnienie, gdzie znajdują się kontakty, kto zatwierdza kontakt, jakie dowody są potrzebne i gdzie rejestrowane są decyzje.

Utwórz pakiet dowodowy. Zachowaj wersję rejestru, uczestników spotkania, zatwierdzenia, notatki scenariuszowe, dziennik decyzji, działania do wykonania i zaktualizowane odniesienie do podręcznika.

W tym miejscu praktyczny staje się krok 23 Zenith Blueprint:

Upewnij się, że masz aktualny plan reagowania na incydenty (5.24), obejmujący przygotowanie, eskalację, reakcję i komunikację. Zdefiniuj, co stanowi podlegające zgłoszeniu zdarzenie bezpieczeństwa (5.25) oraz jak uruchamiany i dokumentowany jest proces decyzyjny. Wybierz niedawne zdarzenie albo przeprowadź ćwiczenie typu tabletop, aby zwalidować plan.

Ćwiczenie nie musi być rozbudowane. Musi udowodnić gotowość.

Mapowanie zgodności między ramami: jeden rejestr, wiele frameworków

Wartość rejestru kontaktów regulacyjnych polega na tym, że ogranicza zduplikowany wysiłek związany ze zgodnością. Jeden gotowy dowodowo artefakt może wspierać oczekiwania dotyczące ładu zarządczego w ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.

NIST CSF 2.0 jest szczególnie użyteczny jako warstwa integracyjna. Jego funkcja GOVERN oczekuje, że organizacje rozumieją interesariuszy, obowiązki prawne i regulacyjne, usługi krytyczne, zależności, apetyt na ryzyko, role, polityki, nadzór i ryzyko dostawców. Profile CSF pomagają organizacjom udokumentować profil bieżący, zdefiniować profil docelowy, przeanalizować luki i utworzyć priorytetyzowany plan działań. Rejestr kontaktów regulacyjnych może być konkretnym dowodem zamykającym lukę między obecnym i docelowym ładem zarządczym nad incydentami.

W zakresie łańcucha dostaw NIST CSF 2.0 oczekuje, że dostawcy, klienci i partnerzy mają zdefiniowane role i odpowiedzialności w cyberbezpieczeństwie, znana jest krytyczność dostawców, wymagania cyberbezpieczeństwa są wbudowane w umowy, ryzyka dostawców są oceniane, a istotni dostawcy są uwzględniani w planowaniu incydentów, reakcji i odzyskiwaniu. To mapuje się bezpośrednio na ryzyko stron trzecich ICT w DORA i oczekiwania NIS2 dotyczące łańcucha dostaw.

Jak audytorzy i nadzorcy będą testować ten sam rejestr

Dobrze utrzymany rejestr będzie analizowany różnie w zależności od perspektywy osoby dokonującej przeglądu.

Audytor ISO/IEC 27001:2022 zacznie od zakresu i zainteresowanych stron. Zapyta, w jaki sposób organizacja zidentyfikowała właściwe organy, obowiązki prawne, umowne obowiązki powiadamiania i zależności outsourcingowe. Następnie prześledzi rejestr do Deklaracji stosowania, planu reagowania na incydenty, planu ciągłości działania i przechowywania dowodów. Może wybrać próbkę jednego kontaktu i poprosić o dowód ostatniej walidacji.

Oceniający NIS2 skupi się na tym, czy podmiot zidentyfikował właściwy CSIRT lub właściwy organ oraz czy progi istotnych incydentów zostały zoperacjonalizowane. Będzie szukać procesu zdolnego do wsparcia wczesnego ostrzeżenia w ciągu 24 godzin, powiadomienia w ciągu 72 godzin i raportu końcowego. Zwróci również uwagę na nadzór organu zarządzającego, ponieważ NIS2 Article 20 czyni ład cyberbezpieczeństwa odpowiedzialnością kierownictwa.

Nadzorca DORA lub zespół audytu wewnętrznego sprawdzi, czy rejestr wspiera zarządzanie incydentami, klasyfikację, raportowanie poważnych incydentów związanych z ICT, komunikację kryzysową, raportowanie do kierownictwa wyższego szczebla, koordynację dostawców i odzyskiwanie operacyjne. Może zapytać, czy istnieją kontakty do zewnętrznych dostawców usług ICT wspierających funkcje krytyczne lub istotne oraz czy obowiązki komunikacyjne znajdują odzwierciedlenie w umowach.

Audytor GDPR lub przegląd DPO skupi się na ocenie naruszenia ochrony danych osobowych. Zapyta, czy DPO i kontakty prawne ds. prywatności są angażowane wcześnie, czy role administratora i podmiotu przetwarzającego są jasne, czy zidentyfikowano właściwy organ nadzorczy oraz czy decyzje dotyczące komunikacji z osobami, których dane dotyczą, są rejestrowane.

Oceniający NIST CSF potraktuje rejestr jako dowód dla wyników GOVERN: oczekiwań interesariuszy, obowiązków prawnych, ról, polityk, nadzoru i ryzyka łańcucha dostaw. Audytor COBIT 2019 lub audytor w podejściu ISACA sprawdzi, czy potrzeby interesariuszy zostały przełożone na praktyki ładu i zarządzania, czy odpowiedzialności są przypisane oraz czy wyniki procesów są monitorowane.

Ten sam artefakt musi przetrwać wszystkie te pytania. Dlatego rejestr powinien być kontrolowany, mieć właściciela, być przeglądany, objęty kontrolą dostępu i testowany.

Typowe wzorce nieskuteczności nadzoru nad kontaktami

Organizacje rzadko ponoszą porażkę dlatego, że nie mają żadnych kontaktów. Ponoszą ją dlatego, że podczas rzeczywistego incydentu kontaktom nie można zaufać.

Każdy problem tworzy przewidywalne ustalenie z audytu. Działanie naprawcze jest równie przewidywalne: dopasować rejestr do polityki, zintegrować go z reagowaniem na incydenty, zwalidować kontakty, przetestować przepływ pracy i zachować dowody.

Rozliczalność zarządu i kierownictwa

NIS2 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie i odbywały szkolenia. DORA Article 5 czyni organ zarządzający odpowiedzialnym za definiowanie, zatwierdzanie, nadzorowanie i ponoszenie odpowiedzialności za ustalenia dotyczące ryzyka ICT, w tym polityki, role, ciągłość działania ICT, plany reakcji i odzyskiwania, politykę stron trzecich ICT, świadomość i szkolenia. ISO/IEC 27001:2022 wymaga od kierownictwa dostosowania SZBI do kierunku strategicznego, zapewnienia zasobów, przypisania odpowiedzialności i wspierania ciągłego doskonalenia.

Zarząd nie musi znać na pamięć numeru telefonu CSIRT. Musi jednak mieć zapewnienie, że gotowość do powiadamiania istnieje, ma właściciela, jest testowana i przeglądana.

Kwartalny pakiet zarządczy powinien obejmować:

• status przeglądu rejestru kontaktów regulacyjnych,
• zmiany we właściwych organach, nadzorcach lub jurysdykcjach,
• otwarte luki w kontaktach incydentowych dostawców,
• wyniki ćwiczeń typu tabletop i wnioski,
• dowody testowania ścieżki zatwierdzania powiadomień,
• metryki czasu od wykrycia do decyzji eskalacyjnej,
• aktualizacje obowiązków raportowych wynikających z NIS2, DORA, GDPR i umów,
• ryzyka rezydualne wymagające akceptacji kierownictwa.

To przesuwa rejestr z operacyjnego arkusza kalkulacyjnego do środka kontrolnego ładu zarządczego.

Jak Clarysec pomaga zbudować gotowy do audytu nadzór nad kontaktami

Clarysec łączy tekst polityk, sekwencjonowanie wdrożenia i mapowanie środków kontrolnych między ramami w jedną ścieżkę dowodową.

Biblioteka polityk definiuje rozliczalność i wymagane zapisy. Polityka reagowania na incydenty ustanawia oczekiwania dotyczące eskalacji, zatwierdzania powiadomień i przechowywania. Polityka zgodności prawnej i regulacyjnej wymaga śledzenia warunków zgodności, takich jak terminy zgłaszania naruszeń. Polityka ciągłości działania i odtwarzania po awarii wymaga aktualnych list kontaktów i alternatywnych planów komunikacji. Polityka bezpieczeństwa dostawców i stron trzecich wymaga przypisanych kontaktów dostawców.

Zenith Blueprint zapewnia sekwencjonowanie wdrożenia. Krok 5 w fazie „Podstawy SZBI i przywództwo” obejmuje komunikację, świadomość i kompetencje, w tym zewnętrznych interesariuszy, terminy, role komunikujące i plany komunikacji. Krok 22 wbudowuje kontakty z organami i grupami specjalnego zainteresowania w zabezpieczenia organizacyjne. Krok 23 waliduje zarządzanie incydentami, decyzje dotyczące zdarzeń podlegających zgłoszeniu, zabezpieczenie dowodów kryminalistycznych i wnioski.

Przewodnik Zenith Controls dostarcza kompas zgodności między ramami. Pokazuje, jak kontakt z organami łączy się z planowaniem incydentów, zgłaszaniem zdarzeń, informacjami o zagrożeniach, grupami specjalnego zainteresowania i reagowaniem na incydenty. Pokazuje również, dlaczego zgłaszanie zdarzeń bezpieczeństwa informacji i przygotowanie do incydentów są niezbędnymi elementami towarzyszącymi. Rejestr kontaktów jest skuteczny tylko wtedy, gdy zdarzenia są zgłaszane i oceniane wystarczająco wcześnie, aby go uruchomić.

Dla MŚP oznacza to odchudzony, ale możliwy do obrony rejestr, jasną rozliczalność i dowody zgodne z zasadą proporcjonalności. Dla przedsiębiorstw oznacza to integrację między jurysdykcjami, osobami prawnymi, jednostkami biznesowymi, dostawcami, regulatorami, nadzorcami, CSIRT i raportowaniem do zarządu.

Następne kroki: zbuduj rejestr, zanim ruszy zegar

Jeżeli Twoja organizacja przygotowuje się do NIS2, DORA, gotowości do zgłaszania naruszeń GDPR lub certyfikacji ISO/IEC 27001:2022, nie czekaj na incydent produkcyjny, aby odkryć, czy nadzór nad kontaktami działa.

Zacznij w tym tygodniu od czterech działań:

1. Utwórz lub odśwież rejestr kontaktów regulacyjnych dla CSIRT, właściwych organów, nadzorców finansowych, organów ochrony danych, organów ścigania, krytycznych dostawców i wewnętrznych ról eskalacyjnych.
2. Zmapuj każdy kontakt na przesłankę, właściciela, ścieżkę zatwierdzenia, wymaganie dowodowe i lokalizację przechowywania.
3. Przeprowadź jedno ćwiczenie typu tabletop skoncentrowane na decyzjach powiadomieniowych, kontakcie z organem, koordynacji z dostawcami i przechowywaniu dowodów.
4. Zaktualizuj zapisy SZBI, w tym Rejestr zgodności, podręcznik reagowania na incydenty, listy kontaktów ciągłości działania i zapisy kontaktów dostawców.

Clarysec może pomóc we wdrożeniu tego szybko przy użyciu Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls oraz naszych bibliotek polityk dla MŚP i przedsiębiorstw, w tym Polityki reagowania na incydenty Polityka reagowania na incydenty, Polityki zgodności prawnej i regulacyjnej Polityka zgodności prawnej i regulacyjnej — SME, Polityki ciągłości działania i odtwarzania po awarii Polityka ciągłości działania i odtwarzania po awarii oraz Polityki bezpieczeństwa dostawców i stron trzecich Polityka bezpieczeństwa dostawców i stron trzecich — SME.

Zegar 24-godzinny nie zatrzyma się, gdy Twój zespół będzie szukał właściwego kontaktu. Zbuduj rejestr teraz, przetestuj go i włącz do dowodów ISO, zanim następny incydent narzuci Ci oś czasu.