Przewodnik 2026: rejestr obowiązków zgodności w cyberbezpieczeństwie

Maria, dyrektor ds. bezpieczeństwa informacji w szybko rosnącej platformie fintech, miała dwadzieścia minut do zamknięcia kwartalnego pakietu materiałów dla zarządu. Wiadomość od CEO była krótka i niewygodna:

„Maria, potrzebuję jednego slajdu pokazującego, że mamy pod kontrolą nasze obowiązki prawne w obszarze cyberbezpieczeństwa na 2026 r. Nie tylko ISO 27001. Mam na myśli wszystko: NIS2, DORA, GDPR, nasze umowy z klientami. Czy jesteśmy zgodni? Gdzie są dowody? Kto za to odpowiada?”

O 08:15 pojawiły się trzy kolejne zapytania. Dział prawny chciał wiedzieć, czy spółka jest podmiotem ważnym zgodnie z krajowymi przepisami transponującymi NIS2 w jednym z państw członkowskich. Inspektor ochrony danych chciał ustalić, czy podejrzany eksport bazy danych należy obsłużyć jako naruszenie ochrony danych osobowych w rozumieniu GDPR, poważny incydent związany z ICT w rozumieniu DORA, jedno i drugie, czy żadne z nich. Dział zakupów oczekiwał akceptacji dostawcy analityki fraudowej, który miał przetwarzać dane osobowe z UE, wspierać usługę krytyczną i korzystać z podwykonawcy usług chmurowych spoza UE.

Żadne z tych pytań nie jest w 2026 r. nietypowe. Niebezpieczna sytuacja pojawia się wtedy, gdy organizacja nie potrafi odpowiedzieć na nie na podstawie jednego utrzymywanego źródła prawdy.

Większość firm ma polityki. Wiele ma rejestry ryzyk, teczki dostawców, rejestry prywatności, procedury reagowania na incydenty i Deklarację stosowania. Luka ujawnia się jednak wtedy, gdy członek zarządu, audytor, regulator albo kluczowy klient zada proste pytanie:

„Pokażcie każdy mający zastosowanie obowiązek prawny, regulacyjny i umowny w obszarze cyberbezpieczeństwa, wskażcie, kto jest jego właścicielem, jak często jest przeglądany, jakie zabezpieczenie go realizuje, jakie dowody to potwierdzają i jak wyjątki trafiają do kierownictwa.”

Tym właśnie jest rejestr obowiązków zgodności w cyberbezpieczeństwie.

Dla CISO, menedżerów zgodności, audytorów i właścicieli biznesowych taki rejestr nie jest już administracyjnym arkuszem kalkulacyjnym. Jest mechanizmem operacyjnym, który łączy krajowe obowiązki wynikające z NIS2, oczekiwania nadzorcze DORA, rozliczalność GDPR, wymagania ISO/IEC 27001:2022, umowy z klientami i polityki wewnętrzne w działający system ładu zarządczego.

Clarysec traktuje rejestr jako żywy artefakt SZBI, a nie załącznik prawny. W Polityce zgodności prawnej i regulacyjnej funkcja zgodności:

„Utrzymuje Rejestr obowiązków zgodności, obejmujący wszystkie mające zastosowanie przepisy, normy, certyfikacje i klauzule umowne.”
Z Polityki zgodności prawnej i regulacyjnej, Role i odpowiedzialności, klauzula 4.2.1.

Kluczowe słowo to „utrzymuje”. Rejestr utworzony na potrzeby certyfikacji i ignorowany do kolejnego audytu nie jest mechanizmem zgodności. Jest dowodem historycznego optymizmu.

Co musi robić rejestr obowiązków zgodności w cyberbezpieczeństwie w 2026 r.

Użyteczny rejestr obowiązków realizuje pięć zadań.

Po pierwsze, identyfikuje obowiązki. Obejmują one przepisy prawa, regulacje, normy, certyfikacje i klauzule umowne. W 2026 r. typowe źródła obejmują NIS2 dla podmiotów kluczowych i ważnych, DORA dla objętych nią podmiotów finansowych oraz zewnętrznych dostawców usług ICT, GDPR dla administratorów i podmiotów przetwarzających dane osobowe z UE, wymagania ISO/IEC 27001:2022 dla SZBI, zobowiązania dotyczące bezpieczeństwa chmury obliczeniowej, klauzule powiadamiania o naruszeniach w umowach z klientami, zasady outsourcingu oraz wymagania bezpieczeństwa dostawców.

Po drugie, klasyfikuje zastosowanie. NIS2 może mieć zastosowanie, ponieważ organizacja działa w sektorze z załącznika I lub załącznika II, dostarcza infrastrukturę cyfrową, działa jako dostawca usług zarządzanych, świadczy usługi chmury obliczeniowej albo należy do kategorii niezależnej od wielkości, takiej jak DNS, TLD lub usługi zaufania. DORA może mieć zastosowanie, ponieważ organizacja jest podmiotem finansowym albo zewnętrznym dostawcą usług ICT wspierającym podmioty finansowe. GDPR może mieć zastosowanie, ponieważ organizacja przetwarza dane osobowe z UE, oferuje usługi osobom fizycznym w UE albo monitoruje zachowanie osób w UE.

Po trzecie, mapuje obowiązki na wewnętrzne zabezpieczenia, polityki, procesy i systemy. To w tym miejscu rejestr staje się operacyjny. Środki zarządzania ryzykiem z NIS2 Article 21 mapują się na ocenę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczny rozwój oprogramowania, przeglądy skuteczności zabezpieczeń, szkolenia, kryptografię, kontrolę dostępu, zarządzanie aktywami i MFA tam, gdzie jest to właściwe. DORA mapuje się na rozliczalność organu zarządzającego, zarządzanie ryzykiem ICT, klasyfikację incydentów, testowanie odporności, rejestry stron trzecich i strategie wyjścia. GDPR mapuje się na rejestry czynności przetwarzania, podstawę prawną, minimalizację danych, okres przechowywania, bezpieczeństwo przetwarzania, ocenę naruszeń i dowody rozliczalności.

Po czwarte, przypisuje właścicieli i cykl przeglądu. Bez własności zgodność pozostaje tematem spotkań. Z własnością staje się zarządzanym procesem.

Po piąte, definiuje dowody. Rejestr powinien odpowiadać na pytanie, jaki artefakt potwierdza, że dany obowiązek jest spełniony dzisiaj. Dowody mogą obejmować protokoły zarządu, zapisy oceny ryzyka, zgłoszenia incydentów, due diligence dostawców, klauzule umowne, konfiguracje szyfrowania, raporty podatności, przeglądy uprawnień dostępu, zapisy testów kopii zapasowych, klauzule informacyjne, DPIA, oceny naruszeń i ustalenia audytu wewnętrznego.

Polityka Clarysec wskazuje tę identyfikowalność wprost:

„Wszystkie obowiązki prawne i regulacyjne muszą być mapowane na konkretne polityki, środki kontrolne i właścicieli w ramach Systemu Zarządzania Bezpieczeństwem Informacji (SZBI).”
Z Polityki zgodności prawnej i regulacyjnej, Wymagania dotyczące wdrożenia polityki, klauzula 6.2.1.

Definiuje również dowody jako element tego samego mechanizmu:

„Wymagane artefakty lub zapisy służące wykazaniu zgodności (np. logi audytowe, ustawienia szyfrowania, dokumentacja zgód)”
Z Polityki zgodności prawnej i regulacyjnej, Wymagania dotyczące wdrożenia polityki, klauzula 6.2.2.3.

To różnica między świadomością zgodności a zapewnieniem zgodności.

Dlaczego ISO/IEC 27001:2022 jest kręgosłupem

ISO/IEC 27001:2022 bywa traktowana jako cel certyfikacyjny, ale w zarządzaniu obowiązkami jej wartość jest większa. Nadaje rejestrowi miejsce w systemie zarządzania.

Klauzule 4.1 do 4.4 wymagają od organizacji zrozumienia kwestii wewnętrznych i zewnętrznych, identyfikacji zainteresowanych stron oraz określenia wymagań prawnych, regulacyjnych i umownych istotnych dla SZBI. Klauzule 5.1 do 5.3 wymagają zaangażowania przywództwa, spójności polityk, zasobów i przypisanych odpowiedzialności. Klauzule 6.1 do 6.2 wymagają oceny ryzyka, postępowania z ryzykiem, Deklaracji stosowania i mierzalnych celów uwzględniających mające zastosowanie wymagania. Klauzule 8, 9 i 10 tworzą cykl operacyjny: wdrożenie zabezpieczeń, ponowna ocena ryzyk, monitorowanie wyników, prowadzenie audytów wewnętrznych, przegląd na poziomie kierownictwa i korygowanie niezgodności.

W Zenith Blueprint: 30-krokowej mapie drogowej audytora Clarysec umieszcza ten element na wczesnym etapie fazy podstaw i przywództwa SZBI, w kroku 2: potrzeby interesariuszy i zakres SZBI. Blueprint zaleca zespołom identyfikowanie wymagań interesariuszy poprzez przegląd wymagań prawnych i regulacyjnych, wyodrębnianie umownych klauzul bezpieczeństwa, rozmowy z interesariuszami oraz uwzględnianie norm branżowych oczekiwanych przez partnerów.

„Klauzula 4.2 nie wymaga konkretnego dokumentu, ale w praktyce warto utworzyć tabelę analizy interesariuszy. Może to być prosta tabela z kolumnami: Zainteresowana strona, Potrzeby/Oczekiwania, Jak na nie odpowiadamy.”
Z Zenith Blueprint, faza podstaw i przywództwa SZBI, krok 2.

Ta analiza interesariuszy staje się wejściem źródłowym do rejestru obowiązków. Następnie rejestr staje się pomostem do postępowania z ryzykiem.

W fazie zarządzania ryzykiem, w kroku 13, Zenith Blueprint wskazuje zespołom, aby mapowały zabezpieczenia na ryzyka, klauzule i regulacje zewnętrzne:

„Odwołania krzyżowe do regulacji: jeśli określone środki kontrolne są wdrażane konkretnie w celu spełnienia GDPR, NIS2 lub DORA, można odnotować to albo w Rejestrze ryzyk (jako element uzasadnienia wpływu ryzyka), albo w uwagach SoA.”
Z Zenith Blueprint, faza zarządzania ryzykiem, krok 13: Planowanie postępowania z ryzykiem i Deklaracja stosowania.

To właśnie tej identyfikowalności oczekują audytorzy. Jeśli GDPR uzasadnia zabezpieczenia dotyczące szyfrowania, okresu przechowywania i oceny naruszeń, należy to wskazać. Jeśli NIS2 uzasadnia eskalację zgłaszania incydentów i zabezpieczenia bezpieczeństwa dostawców, należy to wskazać. Jeśli DORA uzasadnia rejestry ryzyka zewnętrznych dostawców ICT i testowanie wyjścia, należy to wskazać.

Trzy kluczowe zabezpieczenia ISO/IEC 27002:2022

Centralnym zabezpieczeniem ISO/IEC 27002:2022 dla zarządzania obowiązkami jest 5.31, wymagania prawne, ustawowe, regulacyjne i umowne. Clarysec w Zenith Controls: przewodniku po cross-compliance klasyfikuje 5.31 jako zabezpieczenie zapobiegawcze powiązane z poufnością, integralnością i dostępnością, dostosowane do funkcji Identify w cyberbezpieczeństwie i działające w obszarze zdolności prawnej oraz zgodności w domenach ładu zarządczego, ekosystemu i ochrony.

Narracja Zenith Controls jest bezpośrednia:

„Bezpieczeństwo nie istnieje w próżni. Działa w sieci obowiązków — część z nich wynika z prawa, część z umów, a część z regulacji sektorowych.”
Z Zenith Controls, omówienie zabezpieczenia ISO/IEC 27002:2022 5.31.

Zabezpieczenie 5.31 nie działa samodzielnie. Niezbędne są dwa zabezpieczenia wspierające.

Zabezpieczenie 5.2, role i odpowiedzialności w zakresie bezpieczeństwa informacji, zapewnia, że obowiązki nie są przypisywane abstrakcyjnie do „biznesu” albo „IT”. Mapowanie Zenith Controls wiąże 5.2 z własnością polityk, monitorowaniem zgodności, zarządzaniem incydentami, świadomością, niezależnym przeglądem, postępowaniem z materiałem dowodowym i nadzorem nad dostępem uprzywilejowanym.

Zabezpieczenie 5.36, zgodność z politykami, zasadami i normami bezpieczeństwa informacji, domyka pętlę. Zapewnia, że udokumentowane wymagania są przestrzegane, monitorowane, raportowane i korygowane. Mapowanie Zenith Controls łączy 5.36 z politykami bezpieczeństwa informacji, procesem dyscyplinarnym, niezależnym przeglądem, rolami i odpowiedzialnościami, oceną zdarzeń, rejestrowaniem, monitorowaniem i chronionymi zapisami.

Łącznie te zabezpieczenia odpowiadają na podstawowe pytania audytora.

W mniejszych organizacjach ta sama struktura może być lżejsza. Clarysec w Polityce zgodności prawnej i regulacyjnej - SME stanowi:

„GM musi utrzymywać prosty, uporządkowany Rejestr zgodności obejmujący:”
Z Polityki zgodności prawnej i regulacyjnej - SME, Wymagania dotyczące ładu zarządczego, klauzula 5.1.1.

Wymaga również rutynowego przeglądu:

„Rejestr zgodności musi być przeglądany kwartalnie i aktualizowany, gdy:”
Z Polityki zgodności prawnej i regulacyjnej - SME, Wymagania dotyczące ładu zarządczego, klauzula 5.1.2.

W przypadku MŚP rejestr może zacząć się od prostej formy. Nadal wymaga jednak własności, cyklu przeglądu i dowodów.

Buduj rejestr wokół obowiązków, a nie frameworków

Najczęstszym błędem jest tworzenie jednego rejestru śledzenia dla NIS2, drugiego dla DORA, trzeciego dla GDPR, kolejnego dla ISO/IEC 27001:2022 i jeszcze jednego dla umów z klientami. Powoduje to powielone żądania dowodów, sprzeczne przypisania właścicieli i przeciążenie zespołów.

Lepszym podejściem jest mapowanie obowiązku na zabezpieczenie. Jedna zdolność bezpieczeństwa może spełniać wiele wymagań prawnych, jeśli rejestr zachowuje różnice dotyczące przesłanki, zakresu, terminu i organu właściwego.

Na przykład reagowanie na incydenty wspiera zgłaszanie znaczących incydentów zgodnie z NIS2, zgłaszanie poważnych incydentów związanych z ICT zgodnie z DORA oraz ocenę naruszenia ochrony danych osobowych zgodnie z GDPR. Due diligence dostawców wspiera bezpieczeństwo łańcucha dostaw w NIS2, ryzyko zewnętrznych dostawców ICT w DORA oraz nadzór nad podmiotami przetwarzającymi w GDPR. Rejestrowanie i monitorowanie wspierają wykrywanie incydentów, skuteczność zabezpieczeń i rozliczalność. Inwentarze aktywów i danych wspierają ocenę ryzyka w NIS2, DORA, GDPR i ISO/IEC 27001:2022.

Celem nie jest ukrywanie różnic prawnych. Celem jest uniknięcie trzykrotnego wdrażania tej samej zdolności.

Praktyczny model rejestru, który można wdrożyć w tym tygodniu

Rejestr obowiązków w stylu Clarysec powinien być na tyle prosty, aby dało się go utrzymywać, i na tyle szczegółowy, aby przetrwał próbkowanie audytowe. Minimalne pola to:

1. ID obowiązku.
2. Źródło, takie jak NIS2, DORA, GDPR, ISO/IEC 27001:2022, umowa z klientem albo polityka wewnętrzna.
3. Konkretny artykuł, klauzula albo odniesienie umowne.
4. Podsumowanie wymagania.
5. Uzasadnienie zastosowania.
6. Proces biznesowy albo usługa, których dotyczy obowiązek.
7. Scenariusz ryzyka w przypadku niespełnienia.
8. Mapowanie zabezpieczeń, w tym zabezpieczenia ISO/IEC 27002:2022 i odniesienia do polityk wewnętrznych.
9. Właściciel zabezpieczenia.
10. Właściciel dowodów.
11. Cykl przeglądu.
12. Lokalizacja dowodów.
13. Wyjątki albo otwarte luki.
14. Flaga eskalacji do przeglądu zarządzania.
15. Data ostatniego przeglądu i data następnego przeglądu.
16. Status.

Poniżej znajduje się praktyczny przykład dla dostawcy fintech SaaS działającego w UE.

| ID obowiązku | Źródło i wymaganie | Mapowanie wewnętrzne | Właściciel | Cykl przeglądu | Dowody | |—|—|—|—|—| | OBL-001 | Zastosowanie NIS2 i klasyfikacja podmiotu dla infrastruktury cyfrowej albo działalności usług zarządzanych | Polityka zgodności prawnej i regulacyjnej, zabezpieczenie 5.31, zakres SZBI | Menedżer zgodności | Kwartalnie i przy zmianie usługi | Notatka dotycząca zastosowania, dane rejestracyjne podmiotu, briefing dla zarządu | | OBL-002 | Zarządzanie ryzykiem zewnętrznych dostawców ICT zgodnie z DORA dla krytycznych albo ważnych usług ICT | Procedura bezpieczeństwa dostawców, zabezpieczenia 5.19 do 5.23, rejestr dostawców DORA | Właściciel ryzyka dostawców | Kwartalnie i przed wyborem nowego dostawcy krytycznego | Rejestr dostawców, due diligence, klauzule umowne, test wyjścia | | OBL-003 | Ocena naruszenia ochrony danych osobowych i rozliczalność zgodnie z GDPR | Plan reagowania na incydenty, procedura prywatności, zabezpieczenia 5.24 do 5.28 i 5.34 | DPO i menedżer incydentu | Dla każdego incydentu, kwartalny przegląd trendów | Ocena naruszenia, zgłoszenie incydentu, decyzja dotycząca powiadomienia, wyciągnięte wnioski | | OBL-004 | Monitorowanie, audyt wewnętrzny i przegląd zarządzania zgodnie z ISO/IEC 27001:2022 | Proces audytu i monitorowania zgodności, zabezpieczenie 5.36 | Menedżer systemu zarządzania bezpieczeństwem informacji | Roczny plan audytów, kwartalne monitorowanie | Raport audytu wewnętrznego, pulpit KPI, rejestr działań korygujących | | OBL-005 | Umowa z klientem wymaga powiadomienia o incydencie bezpieczeństwa w ciągu 24 godzin | Rejestr umów, procedura komunikacji incydentowej | Zespół ds. sukcesu klienta i dział prawny | Przy zmianie umowy i dla każdego incydentu | Wyciąg z klauzuli umownej, zapis komunikacji incydentowej |

Warto zwrócić uwagę, że każdy wiersz jest wykonalny. Nie mówi wyłącznie „zapewnić zgodność z DORA”. Określa wymaganie, mapowanie wewnętrzne, właściciela, rytm przeglądu i dowody.

Clarysec w Polityce ról i odpowiedzialności w ramach ładu zarządczego - SME wzmacnia tę dyscyplinę własności:

„Odpowiedzialności w ramach ładu zarządczego (np. przegląd polityk, zatwierdzanie wyjątków, nadzór nad dostawcami) muszą być przypisane do konkretnych osób lub ról.”
Z Polityki ról i odpowiedzialności w ramach ładu zarządczego - SME, Wymagania dotyczące ładu zarządczego, klauzula 5.3.

W środowiskach korporacyjnych ta sama koncepcja powinna być odzwierciedlona w macierzy RACI, rejestrze własności zabezpieczeń i pakiecie raportowania zarządczego.

Przykład zgłaszania incydentów: jedna procedura, wiele obowiązków

Dostawca SaaS ustala, że może mieścić się w zakresie NIS2, ponieważ świadczy w UE usługi chmurowe albo usługi zarządzane i spełnia odpowiednie kryteria wielkości lub sektora. Organizacja ma już Plan reagowania na incydenty, ale nie zmapowała zgłaszania NIS2 do procedur eskalacji.

Wpis w rejestrze powinien precyzyjnie ująć obowiązek:

• Źródło: NIS2 Article 23.
• Wymaganie: bez zbędnej zwłoki powiadomić CSIRT albo właściwy organ o znaczących incydentach, z wczesnym ostrzeżeniem w ciągu 24 godzin, zgłoszeniem w ciągu 72 godzin i raportem końcowym w ciągu jednego miesiąca.
• Zastosowanie: potencjalnie ma zastosowanie ze względu na kategorię usługi i działalność w państwach członkowskich.
• Ryzyko w przypadku niespełnienia: naruszenie regulacyjne, opóźnione powiadomienie interesariuszy, utrata zaufania klienta.

Następnie należy zmapować obowiązek na zabezpieczenia. Zabezpieczenia ISO/IEC 27002:2022 5.24 do 5.28 obejmują planowanie zarządzania incydentami, ocenę, reakcję, wyciąganie wniosków i zabezpieczanie materiału dowodowego. Zabezpieczenie 5.31 obejmuje śledzenie obowiązków prawnych. Zabezpieczenie 5.2 obejmuje przypisanie ról. Zabezpieczenie 5.36 obejmuje monitorowanie, czy proces jest przestrzegany.

Własność powinna być wyraźna. Menedżer incydentu odpowiada za klasyfikację i eskalację. Dział prawny albo funkcja zgodności odpowiada za interpretację regulacyjną i autoryzację powiadomienia. Komunikacja odpowiada za komunikację z klientami. Właściciel dowodów utrzymuje akta incydentu.

Dowody powinny obejmować zapis klasyfikacji incydentu, oś czasu, czas uzyskania świadomości, czas triage, czas eskalacji, decyzję o powiadomieniu, zgłoszenie do regulatora, jeśli ma zastosowanie, decyzję dotyczącą komunikacji z klientem, wyciągnięte wnioski i działania korygujące.

Ćwiczenie typu tabletop sprawia następnie, że rejestr staje się realny. Użyj scenariusza, w którym błędna konfiguracja chmury obliczeniowej powoduje potencjalne ujawnienie danych klientów i zakłócenie usługi. Sprawdź, czy zespół potrafi zidentyfikować 24-godzinny zegar NIS2, ustalić, czy wymagana jest ocena naruszenia zgodnie z GDPR, sklasyfikować potencjalny wpływ DORA, jeśli dotyczy usług finansowych, i przygotować kompletny plik dowodowy.

W ten sposób rejestr obowiązków staje się zabezpieczeniem. Zmienia zachowanie operacyjne.

Zarządzanie dowodami to miejsce, w którym audyty często się nie udają

Wiele organizacji potrafi pokazać rejestr. Mniej potrafi wykazać, że dowody są kompletne, aktualne, chronione i powiązane.

Clarysec w Polityce audytu i monitorowania zgodności - SME podaje podstawowe wymaganie:

„Wszystkie dowody muszą być przechowywane w scentralizowanym folderze audytowym.”
Z Polityki audytu i monitorowania zgodności - SME, Wymagania dotyczące wdrożenia polityki, klauzula 6.2.1.

To zdanie rozwiązuje typową przyczynę niepowodzeń audytowych. Dowody rozproszone po poczcie elektronicznej, zgłoszeniach Jira, folderach SharePoint, portalach dostawców i prywatnych dyskach nie są gotowe do audytu. Scentralizowany folder nie musi oznaczać jednego dosłownego folderu dla każdego pliku, ale musi istnieć kontrolowane repozytorium dowodów albo indeks wskazujący audytorowi, gdzie znajduje się autorytatywny artefakt.

Dla każdego obowiązku dowody powinny być nazywane spójnie, mapowane na ID obowiązku i ID zabezpieczenia, przypisane do wskazanej osoby lub roli, chronione przed nieuprawnioną modyfikacją, przechowywane zgodnie z wymaganiami prawnymi i umownymi, przeglądane w określonym cyklu oraz powiązane z wyjątkami i działaniami korygującymi.

Omówienie zabezpieczenia 5.31 w Zenith Controls łączy wymagania prawne z okresem przechowywania zapisów poprzez zabezpieczenie 5.33, prywatnością i ochroną danych osobowych umożliwiających identyfikację osoby (PII) poprzez zabezpieczenie 5.34, niezależnym przeglądem poprzez zabezpieczenie 5.35 oraz wewnętrzną zgodnością poprzez zabezpieczenie 5.36. Ma to znaczenie, ponieważ same dowody mogą zawierać informacje regulowane, takie jak dane osobowe, wskaźniki kryminalistyczne, logi dostępu uprzywilejowanego albo poufne dane klienta.

Perspektywa audytu: jak różni weryfikatorzy będą testować rejestr

Silny rejestr wytrzymuje różne perspektywy audytowe.

Audytor ISO/IEC 27001:2022 rozpocznie od kontekstu, zainteresowanych stron, zakresu, postępowania z ryzykiem, Deklaracji stosowania, monitorowania, audytu wewnętrznego i przeglądu zarządzania. Dla zabezpieczenia 5.31 audytor będzie oczekiwać, że mające zastosowanie wymagania prawne i umowne są zidentyfikowane, aktualizowane i odzwierciedlone w zabezpieczeniach. Dla zabezpieczenia 5.2 sprawdzi, czy odpowiedzialności są przypisane i rozumiane. Dla zabezpieczenia 5.36 będzie szukać monitorowania, niezgodności i działań korygujących.

Asesor działający zgodnie z NIST skoncentruje się na wynikach ładu zarządczego. NIST Cybersecurity Framework 2.0 GOVERN obejmuje GV.OC-03, który oczekuje, że wymagania prawne, regulacyjne i umowne dotyczące cyberbezpieczeństwa, w tym obowiązki w zakresie prywatności i swobód obywatelskich, są rozumiane i zarządzane. Asesor może poprosić o profil organizacyjny, analizę luk i priorytetowy plan działań, a następnie sprawdzić na próbie, czy obowiązki przekładają się na zarządzanie aktywami, kontrolę dostępu, ochronę danych, rejestrowanie, reagowanie i odtwarzanie.

Audytor COBIT 2019 albo ISACA spojrzy przez pryzmat celów ładu zarządczego i zarządzania. Szczególnie istotny jest MEA03, zarządzana zgodność z wymaganiami zewnętrznymi. Audytor może sprawdzić, czy wymagania zewnętrzne są identyfikowane poprzez MEA03.01, czy odpowiedzi są optymalizowane poprzez MEA03.02, czy zgodność jest potwierdzana poprzez MEA03.03 oraz czy uzyskiwane jest zapewnienie poprzez MEA03.04.

Audytor oparty na ISACA ITAF będzie akcentował wystarczające i odpowiednie dowody. Może wybrać wymaganie zgłoszenia naruszenia zgodnie z GDPR, wymaganie rejestru dostawców zgodnie z DORA i wymaganie zgłaszania incydentów zgodnie z NIS2, a następnie poprosić o pełną ścieżkę dowodową od początku do końca.

Asesor techniczny może zweryfikować zabezpieczenie 5.36 na podstawie dowodów konfiguracyjnych. Jeśli rejestr wskazuje, że NIS2 i umowy z klientami wymagają MFA dla dostępu uprzywilejowanego, może sprawdzić ustawienia dostawcy tożsamości. Jeśli wskazuje, że GDPR i umowy wymagają szyfrowania, może przeanalizować szyfrowanie baz danych, zapisy zarządzania kluczami i diagramy przepływu danych. Jeśli DORA wymaga monitorowania usług zewnętrznych dostawców ICT, może przejrzeć przeglądy usług, raporty SLA i zapisy testów wyjścia.

Rejestr potrzebuje dowodów ładu zarządczego i dowodów technicznych.

Przegląd zarządzania domyka pętlę rozliczalności

Rejestr obowiązków zgodności nie powinien być po cichu własnością funkcji zgodności. Musi trafiać do przeglądu zarządzania, ponieważ NIS2, DORA, GDPR i ISO/IEC 27001:2022 opierają się na rozliczalności.

NIS2 wymaga od organów zarządzających zatwierdzania środków zarządzania ryzykiem cyberbezpieczeństwa oraz nadzorowania ich wdrożenia. DORA nakłada ostateczną rozliczalność za zarządzanie ryzykiem ICT na organ zarządzający. GDPR wymaga od administratorów wykazania zgodności. ISO/IEC 27001:2022 wymaga, aby przegląd zarządzania uwzględniał zmiany kontekstu, potrzeby zainteresowanych stron, wyniki audytów, wyniki monitorowania, wyniki oceny ryzyka, status postępowania z ryzykiem i możliwości doskonalenia.

Clarysec w Polityce bezpieczeństwa informacji dostosowuje się do tego oczekiwania:

„Działania przeglądu zarządzania (zgodnie z ISO/IEC 27001 Clause 9.3) powinny być prowadzone co najmniej raz w roku i powinny obejmować:”
Z Polityki bezpieczeństwa informacji, Wymagania dotyczące ładu zarządczego, klauzula 5.3.

Polityka audytu dla SME dodaje powiązanie operacyjne:

„Ustalenia z audytu i aktualizacje statusu muszą być uwzględniane w procesie przeglądu zarządzania SZBI.”
Z Polityki audytu i monitorowania zgodności - SME, Wymagania dotyczące ładu zarządczego, klauzula 5.4.3.

Przegląd zarządzania nie potrzebuje każdego wiersza. Potrzebuje trendów, decyzji dotyczących ryzyka, wyjątków, zasobów i rozliczalności.

To przekształca rejestr z pliku zgodności w narzędzie przywódcze.

Typowe wzorce niepowodzeń i jak ich uniknąć

Pierwszy wzorzec niepowodzenia polega na tym, że dział prawny jest właścicielem prawa, bezpieczeństwo jest właścicielem zabezpieczeń, a nikt nie jest właścicielem mapowania. Clarysec zapobiega temu, wymagając mapowania obowiązków na polityki, zabezpieczenia i właścicieli w SZBI.

Drugi to śledzenie frameworków zamiast obowiązków. Wpis w rejestrze mówiący „DORA” nie jest wykonalny. Wpis mówiący „DORA Article 28 zarządzanie ryzykiem zewnętrznych dostawców ICT wymaga due diligence, postanowień umownych, monitorowania i strategii wyjścia” jest wykonalny.

Trzeci to brak cyklu przeglądu. Kwartalny przegląd jest praktyczną bazą dla wielu organizacji, z aktualizacjami wyzwalanymi zdarzeniami, takimi jak nowe usługi, nowe kraje, nowi dostawcy, incydenty, audyty i zmiany umów.

Czwarty to dowody, które istnieją, ale nie można ich znaleźć. Zasada scentralizowanego folderu audytowego odpowiada na ten problem bezpośrednio.

Piąty to nieformalne wyjątki. Jeśli zabezpieczenie tymczasowo nie może spełnić obowiązku, wyjątek musi być udokumentowany, oceniony pod kątem ryzyka, zatwierdzony, ograniczony czasowo i przeglądany.

Szósty to ceremonialny przegląd zarządzania. Rejestr powinien wpływać na decyzje dotyczące budżetu, obsady, remediacji dostawców, negocjacji umów, akceptacji ryzyka i działań korygujących.

Jak Clarysec przekształca rejestr w mechanizm operacyjny

30-krokowe podejście Clarysec sprawia, że zarządzanie obowiązkami jest praktyczne.

W Zenith Blueprint krok 2 identyfikuje potrzeby interesariuszy i mające zastosowanie wymagania. Krok 13 mapuje zabezpieczenia na ryzyka, klauzule i Deklarację stosowania. Krok 23 dotyczy zabezpieczeń organizacyjnych, w tym wymagania zbudowania i utrzymywania rejestru wymagań prawnych i regulacyjnych.

Blueprint stanowi:

„Współpracuj z działem prawnym, funkcją zgodności albo zewnętrznym doradcą prawnym, aby zbudować rejestr mających zastosowanie przepisów, regulacji i obowiązków umownych związanych z bezpieczeństwem informacji (5.31). Powinien on obejmować przepisy o ochronie danych (np. GDPR), wymagania sektorowe i wymogi certyfikacyjne. Upewnij się, że zespół SZBI wie, gdzie odwoływać się do tego rejestru, oraz że zmiany są przeglądane co najmniej kwartalnie.”
Z Zenith Blueprint, faza Zabezpieczenia w działaniu, krok 23.

Polityki Clarysec zapewniają zasady ładu zarządczego: utrzymywanie rejestru, przypisywanie odpowiedzialności, centralizowanie dowodów, przegląd ustaleń i uwzględnianie statusu w przeglądzie zarządzania.

Zenith Controls zapewnia kompas cross-compliance. Dla zabezpieczenia 5.31 mapuje zarządzanie obowiązkami na rozliczalność GDPR, obowiązki cyberbezpieczeństwa NIS2, zarządzanie ryzykiem ICT DORA, ład zarządczy NIST CSF, zarządzanie programem i ciągłe monitorowanie NIST SP 800-53 oraz monitorowanie zgodności zewnętrznej COBIT 2019. Dla zabezpieczenia 5.2 łączy rozliczalność ról z GDPR, NIS2, DORA, NIST i COBIT. Dla zabezpieczenia 5.36 łączy monitorowanie zgodności z politykami z rozliczalnością GDPR, oczekiwaniami NIS2 dotyczącymi cyberhigieny i kontroli dostępu, odpornością operacyjną DORA, ciągłym monitorowaniem NIST i monitorowaniem zgodności COBIT.

Wartość jest prosta: jeden rejestr, jedna architektura zabezpieczeń, wiele rezultatów zgodności.

Następne kroki: przygotuj rejestr obowiązków do audytu

Organizacje, które dobrze poradzą sobie ze zgodnością w 2026 r., nie będą tymi z największą liczbą arkuszy kalkulacyjnych. Będą to organizacje z identyfikowalnością: od obowiązku do właściciela, od właściciela do zabezpieczenia, od zabezpieczenia do dowodu, od dowodu do przeglądu, od przeglądu do doskonalenia.

Zacznij od tych działań:

1. Utwórz albo odśwież rejestr obowiązków zgodności w cyberbezpieczeństwie.
2. Dodaj NIS2, DORA, GDPR, ISO/IEC 27001:2022 oraz kluczowe obowiązki umowne klientów.
3. Zmapuj każdy obowiązek na polityki, zabezpieczenia ISO/IEC 27002:2022, właścicieli, cykl przeglądu i dowody.
4. Zidentyfikuj luki, wyjątki i wygasłe dowody.
5. Dodaj status rejestru do najbliższego przeglądu zarządzania SZBI.
6. Użyj Zenith Blueprint Clarysec, aby umieścić rejestr w 30-krokowej mapie drogowej SZBI.
7. Użyj Zenith Controls, aby krzyżowo mapować obowiązki na oczekiwania ISO, NIST, COBIT, GDPR, NIS2 i DORA.
8. Użyj Polityki zgodności prawnej i regulacyjnej, Polityki zgodności prawnej i regulacyjnej - SME, Polityki ról i odpowiedzialności w ramach ładu zarządczego - SME, Polityki audytu i monitorowania zgodności - SME oraz Polityki bezpieczeństwa informacji, aby sformalizować własność, przegląd, przechowywanie dowodów i rozliczalność kierownictwa.

Clarysec może pomóc zbudować tę identyfikowalność w Twoim SZBI, zanim poprosi o nią audytor, regulator, członek zarządu albo klient. Pobierz odpowiednie szablony polityk Clarysec, zmapuj pierwszych dziesięć obowiązków w tym tygodniu i przekształć zgodność z działań reaktywnych w system operacyjny.