ISO 27001 SoA jako przygotowanie do NIS2 i DORA

Jest poniedziałek, godzina 08:30. Elena, dyrektorka ds. bezpieczeństwa informacji u szybko rosnącego dostawcy B2B FinTech SaaS, otwiera pilne zapytanie od zarządu. Spółka właśnie uzyskała certyfikację ISO/IEC 27001:2022, ale duży potencjalny klient bankowy z UE zadaje pytania trudniejsze niż standardowy kwestionariusz bezpieczeństwa.

Nie pyta wyłącznie o to, czy spółka szyfruje dane, stosuje uwierzytelnianie wieloskładnikowe albo posiada raport z testów penetracyjnych. Chce wiedzieć, czy platforma SaaS wspiera jego obowiązki wynikające z DORA, czy dostawca może znajdować się w zakresie NIS2 jako usługa ICT lub zależność infrastruktury cyfrowej, oraz czy Deklaracja stosowania ISO 27001 może uzasadnić każde włączone zabezpieczenie, każde wyłączone zabezpieczenie i każdy dowód.

Zarząd zadaje pytanie, które coraz częściej słyszy każdy CISO, menedżer ds. zgodności i założyciel firmy SaaS:

Czy nasza ISO 27001 SoA może wykazać gotowość do NIS2 i DORA?

Elena wie, że błędną odpowiedzią byłoby uruchomienie trzech odrębnych programów zgodności: jednego dla ISO 27001, drugiego dla NIS2 i trzeciego dla DORA. Doprowadziłoby to do dublowania dowodów, sprzecznych właścicieli zabezpieczeń oraz stałej presji przed każdą oceną klienta. Lepszą odpowiedzią jest wykorzystanie istniejącego SZBI jako operacyjnego systemu zgodności, z Deklaracją stosowania, czyli SoA, jako głównym dokumentem zapewniającym identyfikowalność.

SoA nie jest tylko arkuszem kalkulacyjnym na potrzeby certyfikacji ISO. W środowisku cyberbezpieczeństwa i odporności operacyjnej UE jest miejscem, w którym organizacja wykazuje, dlaczego zabezpieczenia istnieją, dlaczego wyłączenia są możliwe do obrony, kto odpowiada za każde zabezpieczenie, jakie dowody potwierdzają wdrożenie oraz w jaki sposób zestaw zabezpieczeń odpowiada na NIS2, DORA, GDPR, umowy z klientami i wewnętrzne postępowanie z ryzykiem.

Firmowa Polityka bezpieczeństwa informacji Clarysec Polityka bezpieczeństwa informacji stanowi:

SZBI musi obejmować zdefiniowane granice zakresu, metodykę oceny ryzyka, mierzalne cele oraz udokumentowane zabezpieczenia uzasadnione w Deklaracji stosowania (SoA).

To wymaganie, wynikające z klauzuli 6.1.2 w Polityce bezpieczeństwa informacji, stanowi podstawę podejścia gotowego do audytu. SoA powinna stać się pomostem między obowiązkami, ryzykami, zabezpieczeniami, dowodami i decyzjami kierownictwa.

Dlaczego NIS2 i DORA zmieniły znaczenie sformułowania „ma zastosowanie”

Tradycyjna SoA ISO/IEC 27001:2022 często zaczyna się od prostego pytania: „Które zabezpieczenia z Załącznika A mają zastosowanie do naszego planu postępowania z ryzykiem?”. To nadal prawidłowe pytanie, ale nie jest już wystarczające dla dostawców SaaS, chmury obliczeniowej, usług zarządzanych, fintech, technologii finansowych oraz krytycznych dostawców w łańcuchu dostaw.

NIS2 podnosi bazowy poziom zarządzania ryzykiem cyberbezpieczeństwa dla podmiotów kluczowych i ważnych w UE. Obejmuje sektory takie jak infrastruktura cyfrowa, dostawcy usług chmurowych, dostawcy usług centrów danych, sieci dostarczania treści, dostawcy usług zarządzanych, dostawcy zarządzanych usług bezpieczeństwa, bankowość oraz infrastruktura rynków finansowych. Państwa członkowskie muszą identyfikować podmioty kluczowe i ważne oraz dostawców usług rejestracji nazw domen, a wielu dostawców technologii, którzy wcześniej traktowali regulacje cyberbezpieczeństwa jako problem klienta, obecnie albo znajduje się bezpośrednio w zakresie, albo jest objętych wymaganiami przenoszonymi umownie w dół łańcucha.

NIS2 Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych w obszarach analizy ryzyka, polityk bezpieczeństwa, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego nabywania, rozwoju i utrzymania, oceny skuteczności zabezpieczeń, cyberhigieny, szkoleń, kryptografii, bezpieczeństwa HR, kontroli dostępu, zarządzania aktywami oraz uwierzytelniania tam, gdzie ma to zastosowanie. NIS2 Article 23 dodaje etapowe oczekiwania dotyczące zgłaszania incydentów, w tym wczesne ostrzeżenie, powiadomienie, aktualizacje oraz raport końcowy dla istotnych incydentów.

DORA, Digital Operational Resilience Act, ma zastosowanie od 17 stycznia 2025 r. i koncentruje się na podmiotach finansowych oraz ich ekosystemie ryzyka ICT. Obejmuje zarządzanie ryzykiem ICT, zgłaszanie incydentów związanych z ICT, zgłaszanie incydentów operacyjnych lub bezpieczeństwa dotyczących płatności w odniesieniu do określonych podmiotów, testowanie cyfrowej odporności operacyjnej, wymianę informacji o cyberzagrożeniach, zarządzanie ryzykiem ze strony zewnętrznych dostawców usług ICT, ustalenia umowne oraz nadzór nad krytycznymi zewnętrznymi dostawcami usług ICT.

Dla podmiotów finansowych, które są również podmiotami kluczowymi lub ważnymi w rozumieniu NIS2, DORA działa jako sektorowy reżim dla równoważnych obowiązków zarządzania ryzykiem ICT i zgłaszania incydentów. Natomiast dla dostawców SaaS, dostawców chmury, MSP i dostawców MDR obsługujących klientów finansowych praktyczna rzeczywistość jest taka, że oczekiwania DORA pojawiają się w procesie zakupowym, umowach, prawach do audytu, obowiązkach wsparcia incydentowego, planowaniu wyjścia, przejrzystości podwykonawców oraz dowodach odporności.

To zmienia rozmowę o SoA. Pytanie nie brzmi już: „Czy Załącznik A zawiera to zabezpieczenie?”. Lepsze pytanie brzmi:

Czy potrafimy wykazać, że dobór zabezpieczeń jest oparty na ryzyku, uwzględnia obowiązki, jest proporcjonalny, ma właściciela, został wdrożony, jest monitorowany, udokumentowany dowodami i zatwierdzony?

ISO 27001 jako uniwersalny tłumacz NIS2 i DORA

ISO/IEC 27001:2022 jest wartościowe, ponieważ jest normą systemu zarządzania, a nie wąską listą kontrolną. Wymaga, aby SZBI był zintegrowany z procesami organizacji i skalowany do jej potrzeb. Dzięki temu skutecznie przekłada nakładające się wymagania zgodności na jeden model zarządzania.

Klauzule 4.1 do 4.4 wymagają, aby organizacja rozumiała swój kontekst, identyfikowała strony zainteresowane, określała istotne wymagania i definiowała zakres SZBI. W przypadku dostawcy FinTech SaaS, takiego jak spółka Eleny, wymagania stron zainteresowanych mogą obejmować klientów z UE, klientów finansowych objętych DORA, ekspozycję sektorową NIS2, obowiązki administratora i podmiotu przetwarzającego wynikające z GDPR, zależności od usług chmurowych realizowanych w outsourcingu, interfejsy dostawców oraz oczekiwania zarządu.

Klauzule 6.1.1 do 6.1.3 wymagają planowania ryzyk i szans, powtarzalnego procesu oceny ryzyka bezpieczeństwa informacji, procesu postępowania z ryzykiem, porównania z Załącznikiem A oraz Deklaracji stosowania, która identyfikuje włączone zabezpieczenia, status wdrożenia i uzasadnienia wyłączeń.

W tym miejscu SoA staje się zapisem decyzji dotyczących zabezpieczeń. Zabezpieczenie może zostać włączone, ponieważ odpowiada na ryzyko, spełnia wymóg prawny, realizuje umowę z klientem, wspiera cel biznesowy albo stanowi bazową praktykę higieny bezpieczeństwa. Zabezpieczenie może zostać wyłączone dopiero po świadomej ocenie przez organizację, stwierdzeniu jego braku związku z zakresem SZBI, udokumentowaniu uzasadnienia i uzyskaniu właściwego zatwierdzenia.

Firmowa Polityka zarządzania ryzykiem Clarysec Polityka zarządzania ryzykiem stanowi:

Deklaracja stosowania (SoA) musi odzwierciedlać wszystkie decyzje dotyczące postępowania z ryzykiem i musi być aktualizowana zawsze, gdy zmienia się pokrycie zabezpieczeniami.

To wymaganie, wynikające z klauzuli 5.4 w Polityce zarządzania ryzykiem, ma krytyczne znaczenie dla gotowości do NIS2 i DORA. Nowy klient regulowany, nowa zależność chmurowa, nowy obowiązek zgłaszania incydentów albo nowe ryzyko koncentracji u dostawcy mogą zmienić zastosowanie zabezpieczeń.

Zacznij od rejestru zgodności, nie od listy zabezpieczeń

Słaba SoA zaczyna od Załącznika A i pyta: „Które zabezpieczenia już mamy?”. Mocna SoA zaczyna od operacyjnej rzeczywistości organizacji i pyta: „Jakie obowiązki, usługi, ryzyka, dane, dostawców i klientów musi obejmować SZBI?”.

ISO/IEC 27005:2022 wspiera takie podejście, podkreślając wymagania stron zainteresowanych, kryteria ryzyka oraz potrzebę uwzględnienia norm, zasad wewnętrznych, ustaw, regulacji, umów i istniejących zabezpieczeń. Wskazuje również, że brak zastosowania lub brak zgodności powinny być wyjaśnione i uzasadnione.

Polityka zgodności prawnej i regulacyjnej dla MŚP Clarysec Polityka zgodności prawnej i regulacyjnej dla MŚP ujmuje tę samą zasadę operacyjną:

GM musi utrzymywać prosty, ustrukturyzowany Rejestr zgodności zawierający:

To wymaganie pochodzi z klauzuli 5.1.1 Polityki zgodności prawnej i regulacyjnej dla MŚP. W mniejszej organizacji rejestr może być prosty. W przedsiębiorstwie powinien być bardziej szczegółowy. Logika jest taka sama: obowiązki muszą być widoczne, zanim będzie można je zmapować.

Firmowa Polityka zgodności prawnej i regulacyjnej Clarysec Polityka zgodności prawnej i regulacyjnej jest jednoznaczna:

Wszystkie obowiązki prawne i regulacyjne muszą być zmapowane na konkretne polityki, zabezpieczenia i właścicieli w ramach Systemu Zarządzania Bezpieczeństwem Informacji (SZBI).

To klauzula 6.2.1 w Polityce zgodności prawnej i regulacyjnej. Jest to kręgosłup ładu dla wykorzystania Deklaracji stosowania ISO 27001 w przygotowaniu do zgodności z NIS2 i DORA.

Zbuduj kryteria ryzyka uwzględniające odporność, prywatność, dostawców i regulacje

Wiele uzasadnień w SoA zawodzi, ponieważ model punktacji ryzyka jest zbyt wąski. Mierzy techniczne prawdopodobieństwo i wpływ, ale nie obejmuje ekspozycji regulacyjnej, krytyczności usługi, szkody po stronie klienta, zależności od dostawcy, wpływu na prywatność ani systemowych zakłóceń operacyjnych.

NIS2 nie dotyczy wyłącznie poufności. Koncentruje się na zapobieganiu wpływowi incydentów na usługi i odbiorców usług oraz minimalizowaniu tego wpływu. DORA definiuje funkcje krytyczne lub ważne na podstawie tego, czy zakłócenie istotnie pogorszyłoby wyniki finansowe, ciągłość świadczenia usług lub zgodność regulacyjną. GDPR dodaje rozliczalność, integralność, poufność, gotowość na naruszenia oraz szkodę po stronie osoby, której dane dotyczą.

Polityka zarządzania ryzykiem dla MŚP Clarysec Polityka zarządzania ryzykiem dla MŚP wskazuje praktyczne minimum:

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

To klauzula 5.1.2 Polityki zarządzania ryzykiem dla MŚP. Dla gotowości do NIS2 i DORA Clarysec rozszerza to minimum o pola takie jak źródło obowiązku, usługa objęta wpływem, kategoria danych, zależność od dostawcy, właściciel biznesowy, wpływ regulacyjny, ryzyko szczątkowe, status postępowania oraz źródło dowodów.

Zwróć uwagę na język. Mocne uzasadnienie nie mówi tylko „wdrożono”. Wyjaśnia, dlaczego zabezpieczenie ma zastosowanie w kontekście biznesowym, regulacyjnym i ryzyka organizacji.

Mapuj domeny NIS2 i DORA na zabezpieczenia ISO 27001:2022

Po ustanowieniu rejestru zgodności i kryteriów ryzyka praktyczna praca polega na mapowaniu domen regulacyjnych na zabezpieczenia z Załącznika A. Samo mapowanie nie dowodzi zgodności, ale daje audytorom i klientom czytelny indeks do testowania dowodów.

Dla Eleny to mapowanie zmieniło rozmowę z zarządem. Zamiast przedstawiać NIS2 i DORA jako odrębne projekty, mogła pokazać wspólny zakres: ład, zarządzanie ryzykiem, incydenty, ciągłość działania, dostawców, testowanie, kontrolę dostępu i kryptografię.

Trzy zabezpieczenia ISO, od których zależy każda SoA dla NIS2 i DORA

W Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec traktuje trzy zabezpieczenia ISO/IEC 27002:2022 jako kluczowe dla gotowego do audytu ładu SoA w kontekście NIS2 i DORA. Są to zabezpieczenia ISO wzbogacone o atrybuty zgodności przekrojowej w przewodniku Zenith Controls.

Te zabezpieczenia nie są odizolowane. Łączą się bezpośrednio z zabezpieczeniami relacji z dostawcami A.5.19 do A.5.23, zabezpieczeniami zarządzania incydentami A.5.24 do A.5.28, zabezpieczeniami ciągłości działania A.5.29 i A.5.30, ochroną prywatności A.5.34, zarządzaniem podatnościami A.8.8, zarządzaniem konfiguracją A.8.9, kopiami zapasowymi informacji A.8.13, rejestrowaniem A.8.15, działaniami monitorującymi A.8.16, kryptografią A.8.24, zabezpieczeniami bezpiecznego rozwoju A.8.25 do A.8.29 oraz zarządzaniem zmianami A.8.32.

Wartość Zenith Controls polega na tym, że pomaga zespołom uniknąć traktowania SoA jako artefaktu jednej normy. Zabezpieczenie 5.31 wspiera mapowanie prawne i umowne. Zabezpieczenie 5.35 wspiera audyt wewnętrzny, niezależny przegląd i zapewnienie dla kierownictwa. Zabezpieczenie 5.36 wspiera operacyjną zgodność z politykami, procedurami, normami i wymaganiami zabezpieczeń.

Wykorzystaj Zenith Blueprint do zbudowania, przetestowania i obrony SoA

W Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint Clarysec umieszcza budowę SoA w fazie zarządzania ryzykiem, w kroku 13: planowanie postępowania z ryzykiem i Deklaracja stosowania. Blueprint nakazuje organizacjom użycie arkusza SoA w szablonie „Risk Register and SoA Builder.xlsx”, podjęcie decyzji, czy każde z 93 zabezpieczeń Załącznika A ma zastosowanie, oraz oparcie decyzji na postępowaniu z ryzykiem, wymaganiach prawnych i umownych, istotności dla zakresu oraz kontekście organizacji.

Blueprint stwierdza:

SoA jest w praktyce dokumentem pomostowym: łączy ocenę i postępowanie z ryzykiem z rzeczywistymi zabezpieczeniami, które posiadasz.

To zdanie oddaje model operacyjny. SoA łączy obowiązki, ryzyka, polityki, zabezpieczenia, dowody i wnioski audytowe.

Zenith Blueprint nakazuje również zespołom umieszczanie odniesień do regulacji w notatkach SoA tam, gdzie jest to właściwe. Jeżeli zabezpieczenie jest wdrożone dla GDPR, NIS2 lub DORA, powinno to znaleźć się w rejestrze ryzyk albo w notatkach SoA. Następnie, w kroku 24, Blueprint poleca organizacjom aktualizację SoA po wdrożeniu i krzyżową weryfikację z planem postępowania z ryzykiem. W kroku 30, Przygotowanie do certyfikacji, przegląd końcowy i audyt próbny, Blueprint kieruje zespoły do potwierdzenia, że każde mające zastosowanie zabezpieczenie z Załącznika A posiada dowody, takie jak polityka, procedura, raport, plan albo zapis wdrożenia.

Ta sekwencja czyni SoA żywym instrumentem zgodności:

1. Krok 13 buduje ją na podstawie postępowania z ryzykiem i obowiązków.
2. Krok 24 testuje ją względem rzeczywistego wdrożenia.
3. Krok 30 broni jej poprzez końcowy przegląd dowodów i audyt próbny.

Jak pisać uzasadnienia włączenia zrozumiałe dla audytorów

Zabezpieczenie powinno zostać włączone, gdy istnieje co najmniej jeden możliwy do obrony czynnik: postępowanie z ryzykiem, wymóg prawny, wymóg umowny, istotność dla zakresu, bazowa higiena bezpieczeństwa, oczekiwanie klienta w zakresie zapewnienia albo zatwierdzony przez kierownictwo cel odpornościowy.

Przydatna formuła brzmi:

Ma zastosowanie, ponieważ [ryzyko lub obowiązek] wpływa na [usługę, aktywo, dane lub proces], a to zabezpieczenie zapewnia [rezultat zapobiegawczy, detekcyjny, korygujący lub odpornościowy], potwierdzony przez [politykę, zapis, test, raport lub wynik systemowy].

W przypadku dostawcy fintech SaaS jeden wiersz SoA może wyglądać następująco:

To jest gotowe do audytu, ponieważ łączy zabezpieczenie z kontekstem, ryzykiem, obowiązkiem, wdrożeniem, właścicielem i dowodami.

Jak uzasadniać wyłączenia bez tworzenia ekspozycji audytowej

Wyłączenia nie są porażką. Porażką są źle uzasadnione wyłączenia.

ISO/IEC 27001:2022 wymaga, aby SoA uzasadniała wyłączone zabezpieczenia z Załącznika A. ISO/IEC 27005:2022 wzmacnia zasadę, że brak zastosowania powinien być wyjaśniony i uzasadniony. Firmowa Polityka bezpieczeństwa informacji Clarysec stanowi:

Bazowy zestaw może zostać dostosowany; jednak wyłączenia muszą być udokumentowane wraz z formalnym zatwierdzeniem i uzasadnieniem w SoA.

To klauzula 7.2.2 Polityki bezpieczeństwa informacji.

Polityka bezpieczeństwa informacji dla MŚP Clarysec Polityka bezpieczeństwa informacji dla MŚP stanowi:

Każde odstępstwo od tej polityki musi być udokumentowane i jasno wyjaśniać, dlaczego odstępstwo jest konieczne, jakie alternatywne środki ochrony obowiązują oraz jaka data została określona dla ponownej oceny.

To wymaganie pochodzi z klauzuli 7.2.1 Polityki bezpieczeństwa informacji dla MŚP.

W kontekście NIS2 i DORA wyłączenia wymagają szczególnej ostrożności. Spółka SaaS rzadko powinna wyłączać rejestrowanie, monitorowanie, kopie zapasowe, zarządzanie incydentami, kontrolę dostępu, bezpieczeństwo dostawców albo zarządzanie podatnościami. Nawet gdy zabezpieczenie nie jest powiązane z jednym konkretnym ryzykiem, może nadal być konieczne jako bazowa praktyka bezpieczeństwa, zapewnienie dla klienta, oczekiwanie umowne albo obowiązek prawny.

Polityka zarządzania ryzykiem dla MŚP Clarysec przypomina również, jak należy obsługiwać zaakceptowane ryzyko:

Akceptuj: Uzasadnij, dlaczego dalsze działanie nie jest wymagane, i odnotuj ryzyko szczątkowe.

Ta klauzula, 6.1.1 w Polityce zarządzania ryzykiem dla MŚP, dokładnie oddaje sposób myślenia potrzebny przy wyłączeniach i decyzjach dotyczących ryzyka szczątkowego.

Zgłaszanie incydentów: wykaż proces, nie samo istnienie polityki

NIS2 Article 23 wymaga etapowego zgłaszania istotnych incydentów, w tym wczesnego ostrzeżenia w ciągu 24 godzin od uzyskania świadomości, powiadomienia w ciągu 72 godzin, aktualizacji na żądanie oraz raportu końcowego w ciągu miesiąca od 72-godzinnego powiadomienia. DORA wymaga od podmiotów finansowych wykrywania, zarządzania, klasyfikowania, eskalowania, komunikowania i zgłaszania poważnych incydentów związanych z ICT, informowania dotkniętych klientów tam, gdzie jest to wymagane, przeprowadzania analizy przyczyny źródłowej oraz doskonalenia zabezpieczeń.

Dostawca SaaS nie zawsze raportuje bezpośrednio do organu właściwego dla DORA, ale może być zobowiązany do wspierania terminów raportowania swoich klientów finansowych. To czyni zabezpieczenia dotyczące incydentów bardzo istotnymi w SoA.

Słaba SoA mówi: „Istnieje polityka reagowania na incydenty”.

Mocna SoA mówi: „Ma zastosowanie, ponieważ organizacja musi wykrywać, oceniać, klasyfikować, eskalować, komunikować, zabezpieczać dowody, wspierać terminy raportowania regulacyjnego, powiadamiać klientów dotkniętych incydentem tam, gdzie wymagają tego umowy, oraz wyciągać wnioski z incydentów wpływających na usługi, dane lub klientów regulowanych”.

Dowody powinny obejmować:

• Plan reagowania na incydenty i macierz eskalacji.
• Kryteria klasyfikacji wagi.
• Proces powiadamiania klientów.
• Drzewo decyzyjne powiadomień regulacyjnych, gdy ma zastosowanie.
• Zgłoszenia incydentów i osie czasu.
• Logi i alerty monitorowania.
• Zapisy ćwiczeń typu tabletop.
• Przegląd po incydencie i działania korygujące.
• Procedury zabezpieczania materiału dowodowego.

Firmowa Polityka audytu i monitorowania zgodności Clarysec Polityka audytu i monitorowania zgodności wyjaśnia, dlaczego ma to znaczenie:

Generowanie możliwych do obrony dowodów i ścieżki audytowej na potrzeby zapytań regulacyjnych, postępowań sądowych lub wniosków klientów o zapewnienie.

Ten cel pochodzi z klauzuli 3.4 w Polityce audytu i monitorowania zgodności.

W mniejszych organizacjach okres przechowywania dowodów również musi być jednoznaczny. Polityka audytu i monitorowania zgodności dla MŚP Clarysec Polityka audytu i monitorowania zgodności dla MŚP stanowi:

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

To klauzula 6.2.4 w Polityce audytu i monitorowania zgodności dla MŚP.

Jedna SoA, wiele rozmów audytowych

Najlepsza SoA nie dubluje ram. Tworzy identyfikowalną narrację o zabezpieczeniach, którą potrafią zrozumieć różni audytorzy.

Audytor ISO 27001 zwykle zaczyna od logiki klauzul: zakresu, stron zainteresowanych, oceny ryzyka, postępowania z ryzykiem, SoA, celów, audytu wewnętrznego, przeglądu zarządzania i doskonalenia. Recenzent z perspektywy NIS2 koncentruje się na proporcjonalności, rozliczalności kierownictwa, szkoleniach, łańcuchu dostaw, terminach incydentów i wpływie na usługę. Asesor klienta z perspektywy DORA koncentruje się na ryzyku ICT, funkcjach krytycznych lub ważnych, poważnych incydentach ICT, testowaniu odporności, klauzulach umownych, prawach do audytu, planach wyjścia, podwykonawstwie i ryzyku koncentracji. Recenzent prywatności koncentruje się na rozliczalności GDPR i gotowości na naruszenia. Audytor w stylu COBIT 2019 lub ISACA testuje ład, wskaźniki, własność, zapewnienie i działania korygujące.

Dlatego SoA nie może być utrzymywana wyłącznie przez zespół bezpieczeństwa. Wymaga własności ze strony działu prawnego, prywatności, zakupów, inżynierii, operacji, HR i kierownictwa wykonawczego.

Typowe błędy SoA w projektach przygotowania do NIS2 i DORA

Clarysec regularnie identyfikuje te same problemy w projektach przygotowawczych:

1. SoA oznacza zabezpieczenia jako mające zastosowanie, ale nie odnotowuje ryzyka, obowiązku ani uzasadnienia biznesowego.
2. NIS2 i DORA są wspomniane w politykach, ale nie są zmapowane na zabezpieczenia, właścicieli ani dowody.
3. Zabezpieczenia dostawców są oznaczone jako wdrożone, ale nie istnieje rejestr dostawców, ocena krytyczności, przegląd umów ani plan wyjścia.
4. Zabezpieczenia dotyczące incydentów istnieją, ale proces nie wspiera raportowania w terminach 24-godzinnym i 72-godzinnym, raportowania do klientów ani raportowania końcowego.
5. Zatwierdzenie przez kierownictwo jest domniemane, ale nie ma zapisu akceptacji ryzyka, zatwierdzenia SoA ani decyzji dotyczącej ryzyka szczątkowego.
6. Wyłączenia są skopiowane z szablonu i nie odpowiadają faktycznemu modelowi operacyjnemu chmury, pracy zdalnej, SaaS lub fintech.
7. Dowody istnieją w różnych narzędziach, ale żadna ścieżka audytowa nie łączy ich z SoA.
8. Przetwarzanie danych osobowych według GDPR nie jest powiązane z zabezpieczeniami, reakcją na naruszenie, umowami z dostawcami ani okresem przechowywania.
9. Audyt wewnętrzny sprawdza dokumenty, ale nie testuje, czy SoA odzwierciedla rzeczywiste wdrożenie.
10. SoA jest aktualizowana tylko przed certyfikacją, a nie po nowych klientach, dostawcach, incydentach, ustaleniach z audytu lub zmianach regulacyjnych.

To nie są problemy papierowe. To problemy ładu.

Praktyczna lista kontrolna dla gotowej do audytu ISO 27001 SoA

Użyj tej listy kontrolnej przed audytem certyfikacyjnym ISO 27001, przeglądem gotowości do NIS2, oceną klienta pod kątem DORA, posiedzeniem zarządu albo procesem due diligence inwestora.

Przekształć SoA w możliwy do obrony pomost zgodności

Prezentacja Eleny dla zarządu zakończyła się sukcesem, ponieważ nie przedstawiła trzech niepowiązanych projektów zgodności. Przedstawiła jeden kontrolowany, oparty na dowodach model operacyjny zbudowany na ISO/IEC 27001:2022, z SoA jako pomostem między regulacjami, ryzykiem, wdrożeniem zabezpieczeń, dowodami i nadzorem kierownictwa.

NIS2 i DORA nie czynią ISO 27001 przestarzałym. Sprawiają, że dobrze zbudowana Deklaracja stosowania ISO 27001 staje się bardziej wartościowa. SoA może stać się jednym miejscem, w którym organizacja wyjaśnia, dlaczego zabezpieczenia istnieją, dlaczego wyłączenia są możliwe do obrony, jak przechowywane są dowody, jak nadzorowani są dostawcy, jak eskalowane są incydenty oraz skąd kierownictwo wie, że SZBI działa.

Twoje natychmiastowe działanie jest proste:

1. Otwórz aktualną SoA.
2. Wybierz pięć zabezpieczeń oznaczonych jako mające zastosowanie i zapytaj: „Jakie ryzyko, obowiązek lub umowa to uzasadnia?”.
3. Wybierz pięć wyłączeń i zapytaj: „Czy nadal miałoby to sens dla audytora NIS2, DORA, GDPR lub ISO/IEC 27001:2022?”.
4. Sprawdź, czy każde mające zastosowanie zabezpieczenie ma aktualne dowody.
5. Potwierdź, że kierownictwo zatwierdziło ryzyka szczątkowe i decyzje SoA.
6. Aktualizuj rejestr zgodności, rejestr ryzyk i SoA zawsze, gdy zmieniają się usługi, dostawcy, klienci, regulacje lub incydenty.

Clarysec pomaga organizacjom robić to poprzez Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, zestawy polityk dla przedsiębiorstw i MŚP, narzędzia rejestru ryzyk, szablony SoA, przygotowanie do audytu oraz mapowanie zgodności przekrojowej dla NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 i zapewnienia dla klientów.

Jeżeli Twoja SoA nie potrafi odpowiedzieć, dlaczego zabezpieczenie istnieje, kto jest jego właścicielem, jakie dowody go potwierdzają i jaki obowiązek wspiera, nie jest jeszcze gotowa. Wykorzystaj Clarysec, aby przekształcić ją w gotowy do audytu pomost zgodności, zanim regulator, audytor lub klient zada te pytania jako pierwszy.