ISO 27001 jako szkielet dowodowy dla NIS2 i DORA

Poniedziałkowe zderzenie wymagań zgodności
O 08:12 w poniedziałek Maria, CISO europejskiego operatora płatności, otrzymuje trzy wiadomości, które na pierwszy rzut oka nie mają ze sobą związku.
Menedżer audytu wewnętrznego prosi o dowód, że Deklaracja stosowania ISO 27001:2022 jest aktualna. Zespół prawny przekazuje kwestionariusz od partnera bankowego dotyczący nadzoru nad ryzykiem stron trzecich ICT w DORA. Dyrektor operacyjny pyta, czy ten sam podręcznik postępowania na wypadek incydentów może wspierać oczekiwania NIS2 dotyczące powiadamiania dla nowo przejętej jednostki biznesowej w UE.
Do 09:00 tablica w biurze Marii jest pokryta akronimami: ISO 27001, NIS2, DORA, GDPR, NIST, COBIT 2019. Jej organizacja ma środki kontrolne. Ma zarządzanie dostępem, kopie zapasowe, kwestionariusze dostawców, szyfrowanie, reagowanie na incydenty, zatwierdzenia polityk, przeglądy zarządzania i zapisy ukończenia szkoleń. Nie ma natomiast jednego gotowego do audytu szkieletu dowodowego, który wyjaśnia, dlaczego te środki kontrolne istnieją, jakie ryzyka ograniczają, które regulacje wspierają, kto za nie odpowiada i gdzie znajduje się dowód.
Ten problem staje się w Europie powszechny. NIS2 wzmacnia zarządzanie ryzykiem cyberbezpieczeństwa, ład zarządczy, obsługę incydentów i odporność łańcucha dostaw. DORA dodaje szczegółowe wymagania dotyczące zarządzania ryzykiem ICT, testowania odporności, zgłaszania incydentów oraz nadzoru nad stronami trzecimi ICT dla podmiotów finansowych. GDPR nadal wymaga rozliczalności, bezpieczeństwa przetwarzania, nadzoru nad podmiotami przetwarzającymi oraz oceny naruszeń ochrony danych osobowych.
Błędną reakcją jest budowanie trzech równoległych programów zgodności. Prowadzi to do dublowania środków kontrolnych, niespójnych dowodów i przeciążenia zespołów.
Lepszym podejściem jest wykorzystanie ISO 27001:2022 jako szkieletu środków kontrolnych. Nie jako certyfikatu na ścianie, lecz jako systemu operacyjnego dla ryzyka, polityk, nadzoru nad dostawcami, reagowania na incydenty, mapowania zgodności i dowodów audytowych.
Praktyczny model Clarysec jest prosty: użyj SZBI ISO 27001:2022 jako systemu porządkującego, Deklaracji stosowania jako pomostu, polityk jako egzekwowalnych reguł operacyjnych oraz Zenith Controls: The Cross-Compliance Guide jako kompasu dla zintegrowanej zgodności. Zbuduj raz, mapuj starannie, wykazuj zgodność stale.
Dlaczego ISO 27001:2022 działa jako szkielet zgodności
NIS2 i DORA mają różne zakresy, mechanizmy prawne i modele nadzoru. NIS2 ma zastosowanie do podmiotów kluczowych i ważnych w różnych sektorach. DORA dotyczy podmiotów finansowych i ustanawia szczegółowe wymagania w zakresie cyfrowej odporności operacyjnej. GDPR koncentruje się na przetwarzaniu danych osobowych i rozliczalności.
Mimo to pytania operacyjne stojące za tymi ramami znacząco się pokrywają:
- Czy cyberbezpieczeństwo jest zarządzane przez polityki zatwierdzone przez kierownictwo?
- Czy ryzyka bezpieczeństwa informacji i ICT są identyfikowane, oceniane i poddawane postępowaniu z ryzykiem?
- Czy środki kontrolne są dobierane na podstawie ryzyka, kontekstu biznesowego i obowiązków prawnych?
- Czy dostawcy są nadzorowani poprzez due diligence, umowy, monitorowanie i kontrole wyjścia?
- Czy personel potrafi wcześnie rozpoznać i zgłosić zdarzenia bezpieczeństwa informacji?
- Czy incydenty mogą być poddane triage, eskalowane, badane i oceniane pod kątem obowiązku zgłoszenia regulacyjnego?
- Czy organizacja może szybko pozyskać dowody podczas audytu, przeglądu klienta lub zapytania organu nadzorczego?
ISO 27001:2022 daje kierownictwu system zarządzania pozwalający odpowiadać na te pytania w sposób spójny. ISO/IEC 27007:2022 traktuje Deklarację stosowania jako podlegający audytowi wykaz wybranych środków kontrolnych bezpieczeństwa informacji, obejmujący środki kontrolne z ISO 27001:2022 Załącznik A, innych norm lub środków specyficznych dla organizacji, wraz z udokumentowanym uzasadnieniem włączenia lub wyłączenia. ISO/IEC 27006-1:2024 wzmacnia podejście, zgodnie z którym SoA i powiązana dokumentacja SZBI tworzą podstawową bazę dowodową do wykazania, które środki kontrolne są wymagane, jak przypisano odpowiedzialności oraz jak polityki są wdrażane i komunikowane.
To sprawia, że SoA jest czymś znacznie ważniejszym niż arkusz kalkulacyjny. Staje się uzgodnionym mechanizmem kontroli między ryzykiem, zgodnością, operacjami, działem prawnym, zakupami, audytem i zarządem.
[P01] Polityka bezpieczeństwa informacji Clarysec zakotwicza to wymaganie ładu zarządczego:
Organizacja musi wdrożyć i utrzymywać System Zarządzania Bezpieczeństwem Informacji (SZBI) zgodnie z klauzulami 4–10 ISO/IEC 27001:2022.
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.
Ma to znaczenie, ponieważ wnioski o dowody na potrzeby NIS2 i DORA rzadko są formułowane językiem ISO. Organ regulacyjny, klient lub komitet zarządu może poprosić o potwierdzenie zarządzania ryzykiem cyberbezpieczeństwa, ładu ICT, nadzoru nad zależnościami od stron trzecich, eskalacji incydentów lub testowania odporności operacyjnej. SZBI ISO 27001:2022 nadaje tym odpowiedziom strukturę.
SoA jest pomostem, a nie ćwiczeniem dokumentacyjnym
W Zenith Blueprint: An Auditor’s 30-Step Roadmap, w fazie zarządzania ryzykiem, krok 13, Clarysec opisuje SoA jako kluczowy mechanizm identyfikowalności między postępowaniem z ryzykiem a wdrożonymi środkami kontrolnymi:
SoA jest w praktyce dokumentem pomostowym: łączy ocenę ryzyka/postępowanie z ryzykiem z rzeczywistymi środkami kontrolnymi, które posiadasz.
To zdanie stanowi sedno zintegrowanej zgodności. Środek kontrolny bez identyfikowalności staje się luźnym artefaktem. Środek kontrolny powiązany z ryzykiem, obowiązkiem prawnym, polityką, właścicielem, zapisem dowodowym i wynikiem testu staje się gotowy do audytu.
Krok 13 zaleca również dodawanie odniesień do środków kontrolnych w scenariuszach ryzyka, na przykład powiązanie scenariusza naruszenia bazy danych klientów z kontrolą dostępu, kryptografią, zarządzaniem podatnościami, reagowaniem na incydenty i środkami kontrolnymi dotyczącymi dostawców. Zaleca także odnotowanie, kiedy środki kontrolne wspierają wymagania zewnętrzne, takie jak GDPR, NIS2 lub DORA.
[P06] Polityka zarządzania ryzykiem Clarysec jednoznacznie określa tę regułę operacyjną:
Decyzje dotyczące środków kontrolnych wynikające z procesu postępowania z ryzykiem muszą być odzwierciedlone w SoA.
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.5.1.
Dla mniejszych organizacji Polityka zarządzania ryzykiem dla MŚP stosuje tę samą logikę:
Zapewnia, że zarządzanie ryzykiem jest aktywnym elementem planowania, realizacji projektów, wyboru dostawców i reagowania na incydenty, zgodnie z ISO 27001, ISO 31000 oraz mającymi zastosowanie wymaganiami regulacyjnymi.
Z sekcji „Cel”, klauzula polityki 1.2.
Jeżeli postępowanie z ryzykiem strony trzeciej w DORA, środek obsługi incydentów w NIS2 albo wymaganie bezpieczeństwa podmiotu przetwarzającego w GDPR nie znajduje odzwierciedlenia w SoA lub powiązanym rejestrze zgodności, organizacja może nadal wykonywać właściwe działania. Będzie jednak mieć trudność z ich spójnym wykazaniem.
Praktyczne mapowanie ISO 27001:2022 na NIS2 i DORA
Poniższe mapowanie nie stanowi porady prawnej. Jest praktycznym modelem dowodowym dla CISO, liderów zgodności, audytorów wewnętrznych i właścicieli biznesowych, którzy muszą powiązać dowody ISO 27001:2022 z oczekiwaniami NIS2 i DORA.
ENISA, we współpracy z Komisją Europejską i Grupą Współpracy NIS, udostępniła doradcze wytyczne referencyjne, które pomagają uzgadniać wymagania cyberbezpieczeństwa UE z normami międzynarodowymi i krajowymi, w tym ISO 27001. Wytyczne te nie są prawnie wiążące i muszą być uzupełnione instrukcjami organów krajowych, zasadami sektorowymi oraz przeglądem prawnym. Wspierają jednak możliwe do obrony podejście do mapowania.
| Pytanie dotyczące zgodności | Dowody szkieletowe ISO 27001:2022 | Znaczenie dla NIS2 | Znaczenie dla DORA | Artefakt dowodowy Clarysec |
|---|---|---|---|---|
| Czy cyberbezpieczeństwo jest zarządzane przez polityki zatwierdzone przez kierownictwo? | Polityka bezpieczeństwa informacji, zakres SZBI, role, zapisy z przeglądów zarządzania, SoA | Oczekiwania dotyczące zarządzania ryzykiem cyberbezpieczeństwa i ładu zarządczego | Ład ICT i ramy zarządzania ryzykiem ICT | Polityka bezpieczeństwa informacji, SoA, pakiet przeglądu zarządzania |
| Czy ryzyka są oceniane i poddawane postępowaniu? | Rejestr ryzyk, plan postępowania z ryzykiem, uzasadnienia SoA, akceptacje ryzyka szczątkowego | Środki cyberbezpieczeństwa oparte na ryzyku zgodnie z Article 21 | Identyfikacja ryzyka ICT, ochrona, zapobieganie, wykrywanie, reagowanie i odzyskiwanie | Rejestr ryzyk, Plan postępowania z ryzykiem, SoA_Builder.xlsx |
| Czy dostawcy są kontrolowani? | Polityka dostawców, zapisy due diligence, umowy, prawo do audytu, klauzule zgłaszania naruszeń | Cyberbezpieczeństwo łańcucha dostaw zgodnie z Article 21(2)(d) | Zarządzanie ryzykiem stron trzecich ICT zgodnie z Articles 28 to 30 | Polityka bezpieczeństwa dostawców i stron trzecich, rejestr dostawców |
| Czy incydenty są wykrywane, eskalowane i zgłaszane? | Plan reagowania na incydenty, kanał zgłaszania, zapisy triage, ćwiczenia tabletop, wnioski po incydencie | Obsługa i zgłaszanie istotnych incydentów zgodnie z Article 23 | Zarządzanie incydentami związanymi z ICT i ich zgłaszanie zgodnie z Articles 17 to 19 | Polityka reagowania na incydenty, zgłoszenia incydentów, raport z ćwiczenia |
| Czy dowody są scentralizowane i możliwe do audytu? | Program audytu wewnętrznego, repozytorium materiału dowodowego, rejestr zgodności, działania korygujące | Gotowość do przedstawienia dowodów nadzorczych | Gotowość do inspekcji regulacyjnych i nadzorczych | Polityka audytu i monitorowania zgodności, centralny folder audytowy |
Mapowanie działa, ponieważ nie tworzy odrębnych środków kontrolnych dla każdej regulacji. Wykorzystuje ISO 27001:2022 jako szkielet środków kontrolnych i dodaje oznaczenia regulacyjne, właścicielstwo oraz oczekiwania dowodowe.
Trzy środki kontrolne ISO 27001:2022, które uruchamiają szkielet
Dla NIS2 i DORA znaczenie ma wiele środków kontrolnych, ale trzy środki kontrolne ISO/IEC 27002:2022 często stają się kręgosłupem modelu dowodowego: 5.1, 5.19 i 5.24. Czwarty środek kontrolny, 6.8, często decyduje o tym, czy zgłaszanie incydentów działa w praktyce.
| Środek kontrolny ISO/IEC 27002:2022 | Dlaczego ma znaczenie | Wartość dla zintegrowanej zgodności |
|---|---|---|
| 5.1 Polityki bezpieczeństwa informacji | Ustanawia zatwierdzony przez kierownictwo kierunek bezpieczeństwa i rozliczalność | Wspiera ład NIS2, ład ICT w DORA, rozliczalność GDPR oraz dowody polityk ISO 27001 |
| 5.19 Bezpieczeństwo informacji w relacjach z dostawcami | Definiuje oczekiwania bezpieczeństwa wobec dostawców w ramach onboardingu, monitorowania i zarządzania relacją | Wspiera cyberbezpieczeństwo łańcucha dostaw NIS2, ryzyko stron trzecich ICT w DORA oraz nadzór nad podmiotami przetwarzającymi w GDPR |
| 5.24 Planowanie i przygotowanie zarządzania incydentami bezpieczeństwa informacji | Tworzy ramy zarządzania incydentami, role, ścieżki eskalacji i działania gotowościowe | Wspiera obsługę incydentów w NIS2, zgłaszanie incydentów związanych z ICT w DORA oraz ocenę naruszeń w GDPR |
| 6.8 Zgłaszanie zdarzeń bezpieczeństwa informacji | Zapewnia, że personel może szybko zgłaszać podejrzane zdarzenia jasnymi kanałami | Wspiera wczesne wykrywanie, eskalację, ocenę obowiązku powiadomienia i jakość dowodów incydentowych |
W Zenith Controls środek kontrolny ISO/IEC 27002:2022 5.1, Polityki bezpieczeństwa informacji, jest scharakteryzowany jako kontrola zapobiegawcza wspierająca poufność, integralność i dostępność, z ładem zarządczym oraz zarządzaniem politykami jako kluczowymi zdolnościami operacyjnymi. Mapowanie krzyżowe wyjaśnia, że GDPR Articles 5(2), 24 i 32 wymagają rozliczalności, odpowiedzialności i bezpieczeństwa przetwarzania. Mapuje również ten sam środek kontrolny na oczekiwania NIS2 dotyczące zarządzania ryzykiem cyberbezpieczeństwa i ładu zarządczego oraz na wymagania DORA w zakresie ładu ICT i ram zarządzania ryzykiem.
Dlatego Polityka bezpieczeństwa informacji nie jest po prostu kolejną polityką. Asesor NIS2 może potraktować ją jako dowód ładu zarządczego. Organ nadzorczy DORA może potraktować ją jako dowód ram ryzyka ICT. Recenzent GDPR może potraktować ją jako dowód rozliczalności. Audytor ISO 27001:2022 może potraktować ją jako część struktury polityk SZBI.
Środek kontrolny 5.19, Bezpieczeństwo informacji w relacjach z dostawcami, to punkt styku zakupów, prawa, bezpieczeństwa, prywatności i odporności. Zenith Controls mapuje go na obowiązki podmiotu przetwarzającego w GDPR, cyberbezpieczeństwo łańcucha dostaw w NIS2 oraz zarządzanie ryzykiem stron trzecich ICT w DORA. W przypadku DORA dowody te stają się jeszcze mocniejsze, gdy są wspierane przez środki kontrolne 5.20, Uwzględnianie bezpieczeństwa informacji w umowach z dostawcami, 5.21, Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT, oraz 5.23, Bezpieczeństwo informacji przy korzystaniu z usług w chmurze obliczeniowej.
Środek kontrolny 5.24, Planowanie i przygotowanie zarządzania incydentami bezpieczeństwa informacji, jest operacyjnym silnikiem gotowości incydentowej. Zenith Controls mapuje go na obsługę incydentów i powiadamianie w NIS2, zgłoszenie naruszenia ochrony danych osobowych w GDPR oraz zarządzanie incydentami związanymi z ICT i ich zgłaszanie w DORA. Dowodem nie jest tylko polityka reagowania na incydenty. Obejmuje on kanały zgłaszania, kryteria triage, zapisy eskalacji, oceny prawne dotyczące powiadomień, ćwiczenia tabletop, zgłoszenia incydentów i wnioski po incydencie.
Środek kontrolny 6.8, Zgłaszanie zdarzeń bezpieczeństwa informacji, zamyka lukę między pisemnym planem a zachowaniem ludzi. Jeżeli personel nie wie, jak zgłosić podejrzenie phishingu, wycieku danych, niedostępności dostawcy lub podejrzanej aktywności systemowej, organizacja może stracić krytyczny czas, zanim w ogóle rozpocznie się ocena prawna lub regulacyjna dotycząca obowiązku zgłoszenia.
Jeden incydent u dostawcy, jeden skoordynowany łańcuch dowodowy
Wyobraźmy sobie, że dostawca analityki chmurowej wykorzystywany przez operatora płatności Marii wykrywa nieuprawniony dostęp do portalu wsparcia. Dostawca hostuje spseudonimizowane dane o korzystaniu z usług przez klientów i wspiera krytyczny biznesowo proces raportowania. Incydent może dotyczyć danych osobowych, regulowanej odporności ICT i dostępności usługi.
Rozdrobniony program zgodności uruchamia trzy osobne strumienie pracy: ocenę naruszenia GDPR, przegląd incydentu ICT DORA i zgłoszenie dostawcy w ISO 27001. Każdy zespół prosi o podobne dowody w innym formacie. Zakupy szukają umowy. Dział prawny pyta, czy dostawca jest podmiotem przetwarzającym. Bezpieczeństwo pyta, czy incydent spełnia progi raportowania. Zgodność otwiera nowy arkusz kalkulacyjny.
Dojrzały szkielet ISO 27001:2022 uruchamia jeden skoordynowany łańcuch dowodowy.
Po pierwsze, zdarzenie jest rejestrowane w ramach procesu reagowania na incydenty. Zgłaszający używa zdefiniowanego kanału, zespół bezpieczeństwa przeprowadza triage zdarzenia, a dział prawny ocenia obowiązki powiadomienia. [P30] Polityka reagowania na incydenty Clarysec wymaga, aby incydenty dotyczące danych regulowanych były oceniane przez dział prawny i DPO:
Jeżeli incydent skutkuje potwierdzonym lub prawdopodobnym ujawnieniem danych osobowych lub innych danych regulowanych, dział prawny i DPO muszą ocenić zastosowanie:
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.4.1.
Dla mniejszych organizacji Polityka reagowania na incydenty dla MŚP przypisuje ten sam praktyczny punkt decyzyjny:
Jeżeli sprawa dotyczy danych klientów, Dyrektor Generalny musi ocenić prawne obowiązki powiadomienia na podstawie zastosowania GDPR, NIS2 lub DORA.
Z sekcji „Postępowanie z ryzykiem i wyjątki”, klauzula polityki 7.4.1.
Po drugie, przeglądana jest relacja z dostawcą. Czy dostawca został sklasyfikowany jako krytyczny? Czy umowa zawierała obowiązki zgłaszania naruszeń, prawo do audytu, odpowiedzialności w zakresie ochrony danych, oczekiwania dotyczące ciągłości świadczenia usług i postanowienia dotyczące wyjścia? Polityka bezpieczeństwa dostawców i stron trzecich Clarysec ustanawia takie oczekiwanie:
Włączaj ustandaryzowane wymagania bezpieczeństwa do wszystkich umów z dostawcami, w tym obowiązki zgłaszania naruszeń, prawo do audytu oraz odpowiedzialności w zakresie ochrony danych.
Z sekcji „Cele”, klauzula polityki 3.2.
Dla MŚP Polityka bezpieczeństwa dostawców i stron trzecich dla MŚP jasno określa cel zintegrowanej zgodności:
Wspierać zgodność z obowiązkami ISO/IEC 27001:2022, GDPR, NIS2 i DORA dotyczącymi nadzoru nad dostawcami.
Z sekcji „Cele”, klauzula polityki 3.6.
Po trzecie, rejestr ryzyk, plan postępowania z ryzykiem i SoA są aktualizowane, jeżeli incydent ujawnia lukę. Być może umowa z dostawcą nie zawiera konkretnego terminu powiadomienia regulacyjnego. Być może częstotliwość monitorowania dostawcy jest zbyt niska dla krytycznego dostawcy ICT. Być może plan reagowania na incydenty nie rozróżnia wystarczająco jasno kryteriów naruszenia ochrony danych osobowych od kryteriów zakłócenia usługi ICT.
Celem nie jest tworzenie nowego świata zgodności. Celem jest aktualizacja jednego zintegrowanego łańcucha dowodowego, tak aby te same zapisy odpowiadały na wiele pytań audytowych.
Przekształcenie SoA w mapę dowodową NIS2 i DORA
Standardowa SoA często dobrze odpowiada na pytania ISO: które środki kontrolne mają zastosowanie, dlaczego zostały wybrane i czy zostały wdrożone. Aby uczynić z niej praktyczną mapę dowodową NIS2 i DORA, należy wzbogacić ją o pola regulacyjne i operacyjne.
Otwórz SoA_Builder.xlsx z Audit Ready Toolkit wskazanego w Zenith Blueprint, w fazie audytu, przeglądu i doskonalenia, krok 24. Krok 24 wyjaśnia, że audytorzy często wybiorą próbkę środka kontrolnego z SoA i zapytają, dlaczego został wdrożony. Kolumna uzasadnienia oraz powiązane ryzyko lub wymaganie powinny odpowiadać na to pytanie.
Dodaj następujące kolumny:
| Nowa kolumna SoA | Cel | Przykładowy wpis |
|---|---|---|
| Przesłanka regulacyjna | Pokazuje, czy środek kontrolny wspiera NIS2, DORA, GDPR, umowy z klientami lub odporność | NIS2, DORA, GDPR |
| Zmapowany identyfikator ryzyka | Łączy środek kontrolny z rejestrem ryzyk | R-017 Niedostępność dostawcy wpływająca na raportowanie regulowane |
| Właściciel dowodu | Wskazuje, kto utrzymuje dowód | Kierownik operacji bezpieczeństwa |
| Dowód podstawowy | Określa artefakt, który audytorzy powinni sprawdzić w pierwszej kolejności | Plan reagowania na incydenty i rejestr zgłoszeń incydentów |
| Dowód operacyjny | Pokazuje, że środek kontrolny działa w czasie | Raport z ćwiczenia tabletop, test powiadomienia o naruszeniu przez dostawcę |
| Status audytu | Śledzi gotowość | Przetestowane, luka otwarta, termin działania korygującego |
Następnie zastosuj to do podstawowego zestawu środków kontrolnych.
| Środek kontrolny ISO/IEC 27002:2022 | Przesłanka regulacyjna | Dowód podstawowy | Dowód operacyjny | Wniosek audytora |
|---|---|---|---|---|
| 5.1 Polityki bezpieczeństwa informacji | NIS2, DORA, GDPR | Zatwierdzona Polityka bezpieczeństwa informacji, zakres SZBI, przypisania ról | Zapis przeglądu polityki, potwierdzenie szkolenia, protokoły z przeglądów zarządzania | Ład zarządczy istnieje, kierownictwo zatwierdziło kierunek, rozliczalność jest udokumentowana |
| 5.19 Bezpieczeństwo informacji w relacjach z dostawcami | NIS2, DORA, GDPR | Polityka dostawców, rejestr dostawców, klasyfikacja dostawców | Przeglądy due diligence, oceny krytyczności, przeglądy umów, dowody prawa do audytu | Ryzyko stron trzecich jest nadzorowane przez onboarding, kontraktowanie, monitorowanie i wyjście |
| 5.20 Uwzględnianie bezpieczeństwa informacji w umowach z dostawcami | NIS2, DORA, GDPR | Standardowe klauzule umowne, załącznik bezpieczeństwa, warunki przetwarzania danych | Próba umów, zatwierdzenia odstępstw od klauzul, zapisy przeglądu prawnego | Wymagania bezpieczeństwa są wbudowane w umowy z dostawcami |
| 5.23 Bezpieczeństwo informacji przy korzystaniu z usług w chmurze obliczeniowej | DORA, NIS2, GDPR | Standard bezpieczeństwa chmury obliczeniowej, ocena ryzyka chmury, zatwierdzenie architektury | Przegląd dostawcy usług chmurowych, przegląd ryzyka koncentracji, test incydentu chmurowego | Ryzyko usług chmurowych jest identyfikowane, nadzorowane, monitorowane i testowane |
| 5.24 Planowanie i przygotowanie zarządzania incydentami bezpieczeństwa informacji | NIS2, DORA, GDPR | Polityka reagowania na incydenty, macierz eskalacji, drzewo decyzyjne powiadomień | Zgłoszenia incydentów, raporty tabletop, wnioski po incydencie, oceny powiadomień | Incydenty mogą być wykrywane, poddawane triage, eskalowane i oceniane pod kątem raportowania regulacyjnego |
| 6.8 Zgłaszanie zdarzeń bezpieczeństwa informacji | NIS2, DORA, GDPR | Kanał zgłaszania, materiały świadomościowe, procedura zgłaszania zdarzeń | Zgłoszenia phishingu, logi infolinii, zapisy symulacji, rozmowy z personelem | Personel wie, jak szybko zgłaszać podejrzane zdarzenia bezpieczeństwa |
Następnie wykonaj przykładowe prześledzenie. Wybierz jeden incydent dostawcy z ostatniego roku i przejdź od zgłoszenia incydentu do umowy z dostawcą, od klasyfikacji dostawcy do rejestru ryzyk, od postępowania z ryzykiem do SoA oraz od SoA do przeglądu zarządzania.
Jeżeli łańcuch się urywa, nie jest to porażka. To precyzyjne działanie korygujące, które należy wykonać, zanim lukę znajdzie audytor, klient, regulator lub komitet zarządu.
Scentralizowane dowody są niedocenianym akceleratorem
Wiele organizacji ma wystarczające środki kontrolne, ale słabe pozyskiwanie dowodów. Dowody są rozproszone w poczcie elektronicznej, systemach zgłoszeniowych, folderach SharePoint, repozytoriach umów, platformach HR, narzędziach GRC i portalach dostawców. W sezonie audytowym zespół zgodności przez tygodnie zbiera zrzuty ekranu.
To nie jest gotowość do audytu. To odzyskiwanie dowodów na potrzeby audytu.
[P33S] Polityka audytu i monitorowania zgodności dla MŚP Clarysec stanowi:
Wszystkie dowody muszą być przechowywane w scentralizowanym folderze audytowym.
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.1.
Scentralizowany folder audytowy nie oznacza niekontrolowanego miejsca zrzutu plików. Oznacza uporządkowane repozytorium dostosowane do SZBI, SoA, rejestru ryzyk, planu audytów i rejestru zgodności.
| Folder | Zawartość | Zastosowanie dla zintegrowanej zgodności |
|---|---|---|
| 01 Ład zarządczy | Zakres SZBI, Polityka bezpieczeństwa informacji, przypisania ról, protokoły z przeglądów zarządzania | Ład NIS2, ład ICT DORA, rozliczalność GDPR |
| 02 Ryzyko i SoA | Rejestr ryzyk, plan postępowania z ryzykiem, SoA, akceptacje ryzyka szczątkowego | Zarządzanie ryzykiem NIS2, zarządzanie ryzykiem ICT DORA |
| 03 Dostawcy | Rejestr dostawców, due diligence, umowy, oceny krytyczności, zapisy z przeglądów | Łańcuch dostaw NIS2, ryzyko stron trzecich ICT w DORA, podmioty przetwarzające GDPR |
| 04 Incydenty | Zgłoszenia incydentów, oceny naruszeń, decyzje o powiadomieniach, ćwiczenia tabletop | Raportowanie NIS2, zarządzanie incydentami DORA, zgłoszenie naruszenia GDPR |
| 05 Audyt i doskonalenie | Raporty audytu wewnętrznego, działania korygujące, próbkowanie dowodów, działania następcze kierownictwa | Gotowość do audytu ISO 27001:2022, gotowość nadzorcza |
Polityka zgodności prawnej i regulacyjnej dla MŚP Clarysec odnosi się bezpośrednio do problemu mapowania:
Jeżeli regulacja ma zastosowanie w wielu obszarach (np. GDPR dotyczy okresu przechowywania, bezpieczeństwa i prywatności), musi to być jasno zmapowane w Rejestrze zgodności i materiałach szkoleniowych.
Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.2.2.
Dokładnie w ten sposób ISO 27001:2022 staje się szkieletem środków kontrolnych dla NIS2 i DORA. Nie polegasz na wiedzy nieformalnej. Mapujesz regulacje na procesy, polityki, środki kontrolne, dowody i szkolenia.
Zgłaszanie incydentów zaczyna się od ludzi, nie od portali
Częsta słabość audytowa pojawia się wtedy, gdy plan reagowania na incydenty wygląda solidnie, ale pracownicy nie wiedzą, kiedy ani jak zgłaszać zdarzenia. Jest to niebezpieczne dla NIS2, DORA i GDPR, ponieważ terminy ocen regulacyjnych zależą od wykrycia, eskalacji i klasyfikacji.
W Zenith Blueprint, w fazie Kontrole w działaniu, krok 16, Clarysec podkreśla zgłaszanie incydentów przez personel w ramach środka kontrolnego ISO/IEC 27002:2022 6.8. Wytyczne wskazują, że reagowanie na incydenty zaczyna się od ludzi. Organizacje powinny utworzyć jasny, prosty i dostępny kanał zgłaszania, taki jak monitorowany adres e-mail, portal wewnętrzny, infolinia lub kategoria w systemie zgłoszeniowym. Zalecają również szkolenie świadomościowe, kulturę zgłaszania bez obwiniania, poufność, niski próg zgłoszenia i okresowe symulacje.
Wpływ na zintegrowaną zgodność jest bezpośredni. Zenith Blueprint łączy tę zdolność zgłaszania przez personel z GDPR Article 33, NIS2 Article 23 i DORA Article 17. Jeżeli pracownicy wahają się przed zgłoszeniem podejrzanej aktywności, organizacja może stracić krytyczny czas, zanim zespoły prawne, bezpieczeństwa lub regulacyjne ocenią obowiązki powiadomienia.
Praktyczny test środka kontrolnego jest prosty:
- Zapytaj pięciu pracowników, jak zgłosić podejrzaną wiadomość phishingową.
- Sprawdź, czy kanał zgłaszania jest monitorowany.
- Potwierdź, czy system zgłoszeniowy ma kategorię incydentu bezpieczeństwa.
- Przejrzyj ostatnią symulację lub ćwiczenie tabletop.
- Zweryfikuj, czy wnioski po incydencie zostały omówione podczas przeglądu zarządzania.
Jeżeli którakolwiek odpowiedź jest niejasna, zaktualizuj instrukcję zgłaszania incydentów, materiały szkoleniowe, kanał zgłaszania i odniesienie dowodowe w SoA.
Jak różni audytorzy sprawdzają ten sam szkielet
Dowody zintegrowanej zgodności muszą wytrzymać różne perspektywy audytowe. Ten sam środek kontrolny może być testowany inaczej w zależności od mandatu osoby dokonującej przeglądu.
| Perspektywa audytora | Prawdopodobne pytanie | Oczekiwane dowody | Typowa nieskuteczność |
|---|---|---|---|
| Audytor ISO 27001:2022 | Dlaczego ten środek kontrolny ma zastosowanie i czy działa zgodnie z opisem? | Uzasadnienie SoA, powiązanie z postępowaniem z ryzykiem, polityka, zapisy operacyjne, wyniki audytu wewnętrznego | Środek kontrolny istnieje, ale uzasadnienie SoA jest ogólne lub nieaktualne |
| Asesor zorientowany na NIS2 | Czy możesz wykazać środki cyberbezpieczeństwa oparte na ryzyku i koordynację incydentów? | Rejestr ryzyk, polityka ładu zarządczego, plan incydentowy, proces raportowania, dowody ryzyka dostawców | Mapowanie NIS2 istnieje w prezentacji, ale nie w dowodach operacyjnych |
| Organ nadzorczy zorientowany na DORA | Czy możesz wykazać zarządzanie ryzykiem ICT, klasyfikację incydentów, testowanie i nadzór nad stronami trzecimi? | Rejestr ryzyka ICT, krytyczność dostawców, klasyfikacja incydentów, testy odporności, klauzule umowne | Zapisy dostawców nie odróżniają krytycznych dostawców ICT od zwykłych dostawców |
| Recenzent zorientowany na GDPR | Czy możesz wykazać rozliczalność, bezpieczeństwo przetwarzania, kontrole podmiotów przetwarzających i ocenę naruszeń? | Mapowanie ochrony danych, klauzule podmiotów przetwarzających, zapisy oceny naruszeń, dowody dostępu i szyfrowania | Środki bezpieczeństwa są wdrożone, ale nie są powiązane z ryzykami dotyczącymi danych osobowych |
| Audytor zorientowany na NIST | Czy możesz pokazać ład zarządczy, identyfikację ryzyka, ochronę, wykrywanie, reagowanie i odzyskiwanie? | Ład polityk, zapisy aktywów i ryzyk, logi wykrywania, dowody incydentów i odzyskiwania | Dowody techniczne istnieją, ale właścicielstwo w ramach ładu zarządczego jest słabe |
| Audytor COBIT 2019 lub w stylu ISACA | Czy cele ładu zarządczego, odpowiedzialności, monitorowanie wyników i działania zapewniające są zdefiniowane? | RACI, właścicielstwo środków kontrolnych, raportowanie zarządcze, plan audytów, metryki, działania korygujące | Środki kontrolne są techniczne, ale nie są zarządzane poprzez mierzalną rozliczalność |
W tym miejscu Zenith Controls wnosi wartość wykraczającą poza prostą tabelę mapowania. Pomaga przełożyć środki kontrolne ISO/IEC 27002:2022 na perspektywy istotne audytowo, w tym atrybuty środków kontrolnych, relacje regulacyjne i oczekiwania dowodowe. Dla środka kontrolnego 5.1 atrybuty wspierają ład zarządczy, zarządzanie politykami, rozliczalność i cele bezpieczeństwa. Dla środka kontrolnego 5.24 atrybuty wspierają koncepcje reagowania i odzyskiwania, gotowość incydentową oraz działania korygujące. Dla środka kontrolnego 5.19 atrybuty relacji z dostawcami łączą ład zarządczy, ryzyko ekosystemu, ochronę i nadzór nad stronami trzecimi.
Co powinien zobaczyć zarząd
Zarząd nie potrzebuje każdej pozycji SoA. Potrzebuje jednak historii, którą opowiada SoA.
Solidny pakiet dla zarządu dotyczący dostosowania ISO 27001:2022, NIS2 i DORA powinien obejmować:
- Zakres SZBI i objęte nim usługi biznesowe.
- Najważniejsze ryzyka bezpieczeństwa informacji i ICT.
- Podsumowanie mających zastosowanie środków kontrolnych według domen.
- Status mapowania NIS2, DORA i GDPR.
- Krytycznych dostawców i ryzyka koncentracji.
- Metryki zgłaszania incydentów i wyniki ćwiczeń tabletop.
- Otwarte działania korygujące i zaległe działania postępowania z ryzykiem.
- Decyzje wymagane w zakresie akceptacji ryzyka, budżetu, właścicielstwa i zasobów.
To przekształca zgodność w dowód ładu zarządczego. Jest to również zgodne z celem środka kontrolnego 5.1 w Zenith Controls, w którym polityki bezpieczeństwa informacji wspierają kierunek na poziomie kierownictwa wykonawczego, rozliczalność i cele bezpieczeństwa.
Typowe błędy, których należy unikać
Pierwszym błędem jest założenie, że certyfikacja ISO 27001:2022 automatycznie potwierdza zgodność z NIS2 lub DORA. Nie potwierdza. ISO 27001:2022 daje silny system zarządzania i szkielet środków kontrolnych, ale nadal potrzebne są określenie zakresu regulacyjnego, analiza prawna, interpretacja sektorowa, procesy powiadamiania oraz znajomość oczekiwań organów krajowych.
Drugim błędem jest traktowanie SoA jako dokumentu statycznego. SoA musi ewoluować, gdy pojawiają się nowi dostawcy, systemy, incydenty, regulacje, usługi lub ryzyka. Zenith Blueprint, krok 24, zaleca krzyżową weryfikację SoA z rejestrem ryzyk i planem postępowania z ryzykiem oraz zapewnienie, że każdy wybrany środek kontrolny ma uzasadnienie oparte na zmapowanym ryzyku, wymaganiu prawnym lub potrzebie biznesowej.
Trzecim błędem jest mapowanie na zbyt wysokim poziomie. Slajd mówiący „ISO 27001 mapuje się na DORA” nie jest dowodem audytowym. Konkretna pozycja SoA, która łączy bezpieczeństwo relacji z dostawcą z ryzykiem krytycznego dostawcy ICT, klauzulą umowną, zapisem przeglądu dostawcy i oczekiwaniem DORA dotyczącym nadzoru nad stroną trzecią, jest znacznie mocniejsza.
Czwartym błędem jest brak centralizacji dowodów. Jeżeli menedżer zgodności spędza dwa tygodnie na zbieraniu zrzutów ekranu przed każdym audytem, organizacja ma problem z pozyskiwaniem dowodów.
Piątym błędem jest ignorowanie zabezpieczeń osobowych. Zgłaszanie incydentów, onboarding dostawcy, przeglądy dostępu, akceptacja polityki i eskalacja zależą od zachowania ludzi. Dopracowany proces, którego nikt nie stosuje, załamie się pod próbkowaniem audytowym.
Model operacyjny Clarysec dla zintegrowanej zgodności
Metoda Clarysec łączy historię zgodności od strategii do dowodów:
- W Zenith Blueprint, faza zarządzania ryzykiem, krok 13, mapujesz środki kontrolne na ryzyka i budujesz SoA jako dokument pomostowy.
- W Zenith Blueprint, faza zarządzania ryzykiem, krok 14, tworzysz odniesienia krzyżowe wymagań GDPR, NIS2 i DORA do polityk i środków kontrolnych.
- W Zenith Blueprint, faza Kontrole w działaniu, krok 16, operacjonalizujesz zgłaszanie incydentów przez personel, aby eskalacja zaczynała się wcześnie.
- W Zenith Blueprint, faza audytu, przeglądu i doskonalenia, krok 24, finalizujesz i testujesz SoA, weryfikujesz ją krzyżowo z planem postępowania z ryzykiem i przygotowujesz jako jeden z pierwszych dokumentów, o które poprosi audytor.
Metodę tę wspierają polityki Clarysec, które przekładają zasady na reguły operacyjne: ład bezpieczeństwa informacji, postępowanie z ryzykiem, bezpieczeństwo dostawców, reagowanie na incydenty, mapowanie prawne i regulacyjne oraz przechowywanie dowodów.
Rezultatem nie jest tylko gotowość do ISO 27001:2022. Jest nim wielokrotnego użytku system dowodowy zgodności dla NIS2, DORA, GDPR, zapewnienia dla klientów, audytu wewnętrznego i nadzoru zarządu.
Następne kroki: zbuduj raz, wykazuj wielokrotnie
Jeżeli Twoja organizacja mierzy się z NIS2, DORA, GDPR, audytami klientów lub presją certyfikacji ISO 27001:2022, zacznij od szkieletu.
- Przejrzyj SoA i dodaj kolumny przesłanek regulacyjnych dla NIS2, DORA i GDPR.
- Zweryfikuj SoA względem rejestru ryzyk i planu postępowania z ryzykiem.
- Zmapuj krytycznych dostawców na środki kontrolne bezpieczeństwa dostawców, klauzule umowne i dowody monitorowania.
- Przetestuj proces zgłaszania incydentów przy użyciu ćwiczenia tabletop.
- Scentralizuj dowody audytowe według środka kontrolnego, regulacji, właściciela i statusu testu.
- Użyj Zenith Controls, aby przełożyć środki kontrolne ISO/IEC 27002:2022 na dowody zintegrowanej zgodności.
- Użyj Zenith Blueprint, aby przejść od postępowania z ryzykiem do gotowej do audytu walidacji SoA.
- Wdróż zestaw polityk Clarysec, w tym Politykę bezpieczeństwa informacji, Politykę zarządzania ryzykiem, Politykę bezpieczeństwa dostawców i stron trzecich oraz Politykę reagowania na incydenty, aby przyspieszyć wdrożenie.
Najszybszą drogą nie są kolejne rozłączone listy kontrolne. Jest nią jeden zintegrowany SZBI, jedna identyfikowalna SoA, jeden scentralizowany model dowodowy i jeden rytm operacyjny zintegrowanej zgodności.
Clarysec może pomóc przekształcić ISO 27001:2022 z projektu certyfikacyjnego w praktyczny szkielet środków kontrolnych dla NIS2 i DORA. Pobierz Zenith Blueprint, poznaj Zenith Controls albo umów ocenę Clarysec, aby zbudować gotowy do audytu model dowodowy, zanim następny regulator, klient lub komitet zarządu poprosi o dowody.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


