Nie Sprzedaję Zgodności W Paczce. Po Co Są Szablony Dokumentacji NIS2 I ISO 27001? - Security Bez Tabu

Nie Sprzedaję Zgodności W Paczce. Po Co Są Szablony Dokumentacji NIS2 I ISO 27001?

Co znajdziesz w tym artykule?

Zacznijmy od rzeczy, którą warto powiedzieć od razu.

Jeżeli ktoś mówi Ci, że kupisz paczkę dokumentów i od tego momentu Twoja organizacja jest zgodna z NIS2 albo ISO 27001, to powinieneś bardzo uważać.

To tak nie działa.

Dokumenty same w sobie nie dają zgodności. Nie wdrażają zabezpieczeń. Nie robią analizy ryzyka. Nie testują kopii zapasowych. Nie szkolą zarządu. Nie obsługują incydentów. Nie podejmują decyzji za właścicieli procesów. Nie są też certyfikatem, audytem, opinią prawną ani indywidualnym wdrożeniem w konkretnej organizacji.

Ale z drugiej strony — to nie znaczy, że dokumentacja jest niepotrzebna.

Problemem nie jest dokumentacja.

Problemem jest dokumentacja, która nie opisuje rzeczywistości.

I właśnie o tym jest ten tekst.

O różnicy między papierową zgodnością a dokumentacją procesów. O tym, po co są szablony dokumentacji NIS2 i ISO 27001. O tym, komu mogą pomóc, komu nie pomogą i dlaczego największą wartością takiego pakietu nie jest „posiadanie dokumentów”, tylko to, że nie zaczynasz od pustej kartki.

Mit papierowej zgodności

W cyberbezpieczeństwie i compliance bardzo często pojawia się zarzut tak zwanej papierowej zgodności.

Czyli sytuacji, w której organizacja ma dużo dokumentów, polityk, procedur i rejestrów, ale te dokumenty nie mają żadnego związku z realnym działaniem firmy.

Na papierze wszystko wygląda dobrze.

Jest polityka bezpieczeństwa.
Jest procedura obsługi incydentów.
Jest rejestr ryzyka.
Jest polityka kopii zapasowych.
Jest procedura zarządzania dostępami.
Jest nawet arkusz z dostawcami.

Tylko potem przychodzi realne pytanie:

Kto ostatnio testował backup?

Cisza.

Kto zatwierdził akceptację ryzyka?

Cisza.

Kiedy ostatnio sprawdziliśmy dostawców?

Cisza.

Kto podejmuje decyzję, czy incydent jest istotny?

Cisza.

Gdzie są dowody, że ta procedura była wykonana?

Cisza.

I wtedy wychodzi na jaw, że dokumentacja nie była opisem procesu. Była dekoracją.

Tego nie bronię. Tego nie sprzedaję. I tego nie warto kupować.

Dokumentacja procesu, a nie dokument dla dokumentu

Dobra dokumentacja bezpieczeństwa nie polega na tym, że organizacja ma plik o nazwie Polityka_Bezpieczenstwa_v1_FINAL_FINAL.docx.

Dobra dokumentacja odpowiada na bardzo praktyczne pytania:

  • kto jest właścicielem procesu;
  • kiedy proces się uruchamia;
  • kto wykonuje konkretne czynności;
  • kto zatwierdza decyzje;
  • gdzie zapisujemy dowody;
  • jak często robimy przegląd;
  • co robimy, kiedy proces nie działa;
  • jakie narzędzia wspierają proces;
  • jakie ryzyka ten proces zmniejsza;
  • jakie wymagania organizacyjne, regulacyjne albo kontraktowe ten proces wspiera.

To jest różnica między dokumentem a dokumentacją procesu.

Weźmy prosty przykład: obsługa incydentu.

Słaba dokumentacja mówi:

Incydenty bezpieczeństwa są obsługiwane zgodnie z procedurą.

Dobra dokumentacja opisuje:

  • co uznajemy za incydent;
  • kto może zgłosić incydent;
  • gdzie go zgłasza;
  • kto robi triage;
  • kto klasyfikuje incydent;
  • kiedy następuje eskalacja;
  • kto komunikuje się z zarządem;
  • kto komunikuje się z klientem;
  • gdzie trafiają logi, artefakty i timeline;
  • kto zamyka incydent;
  • kiedy robimy post-incident review;
  • jakie działania korygujące trafiają do rejestru.

To jest proces. Dokument ma go opisać, a nie udawać, że proces istnieje.

Dlaczego temat wraca przy NIS2 i ISO 27001?

Bo zarówno NIS2, jak i ISO 27001 dotykają rzeczy, których nie da się utrzymać wyłącznie „w głowie administratora”.

NIS2 wprowadza wspólne ramy cyberbezpieczeństwa dla krytycznych sektorów w Unii Europejskiej, a Komisja Europejska opisuje ją jako ramę obejmującą 18 sektorów krytycznych. Dyrektywa mówi między innymi o zarządzaniu ryzykiem, obsłudze incydentów, ciągłości działania, kopiach zapasowych, bezpieczeństwie łańcucha dostaw, cyberhigienie, szkoleniach, kryptografii, kontroli dostępu, zarządzaniu aktywami i stosowaniu MFA tam, gdzie jest to właściwe.

ISO/IEC 27001 dotyczy systemu zarządzania bezpieczeństwem informacji, czyli ISMS. ISO opisuje tę normę jako wymagania dla systemu, który organizacja ustanawia, wdraża, utrzymuje i doskonali.

To są różne porządki!

NIS2 to regulacyjne wymagania dotyczące cyberbezpieczeństwa określonych typów podmiotów. ISO 27001 to norma systemu zarządzania bezpieczeństwem informacji. One się zazębiają, ale nie są tym samym.

W Polsce dodatkowo trzeba brać pod uwagę krajowe przepisy dotyczące Krajowego Systemu Cyberbezpieczeństwa. Nowelizacja ustawy o KSC została podpisana w lutym 2026 r., a Prezydent RP jednocześnie skierował ją do kontroli następczej przez Trybunał Konstytucyjny. Ministerstwo Cyfryzacji wskazywało przy tej nowelizacji między innymi rozszerzenie katalogu podmiotów KSC, nowe zespoły CSIRT, obowiązki techniczne i organizacyjne oraz dopasowanie środków do wielkości podmiotu i charakteru usług.

I teraz ważne: niezależnie od tego, czy patrzysz na temat od strony NIS2, KSC, ISO 27001 czy wymagań klientów, cały czas wracasz do tego samego problemu operacyjnego.

Ktoś musi opisać procesy.

Nie „napisać papier”.

Opisać procesy.

Czym są szablony dokumentacji procesów bezpieczeństwa?

Szablony dokumentacji nie są magicznym wdrożeniem.

To baza do pracy.

Ich wartość polega na tym, że pokazują strukturę, język, typowe sekcje, układ dokumentów i powiązania między obszarami bezpieczeństwa.

Dobry szablon pomaga odpowiedzieć na pytania:

  • jakie dokumenty mogą być potrzebne;
  • jak rozdzielić politykę od procedury;
  • co powinno trafić do rejestru;
  • gdzie wpisać właściciela procesu;
  • jak opisać odpowiedzialności;
  • jak powiązać proces z ryzykiem;
  • jak odróżnić deklarację od dowodu działania;
  • jakie elementy trzeba dostosować do skali organizacji.

To nie jest produkt typu: „kup, zmień logo, jesteś gotowy”.

To jest raczej:

„Masz bazę. Teraz sprawdź, co pasuje do Twojej organizacji, co trzeba usunąć, co trzeba uprościć, co trzeba rozbudować i kto realnie będzie za to odpowiadał”.

W małym zespole to potrafi być ogromna różnica.

Bo zamiast zaczynać od pustej kartki, zaczynasz od dokumentu, który nadaje kierunek.

Co takie szablony mogą realnie przyspieszyć?

Najwięcej czasu zwykle nie znika na samo pisanie zdań.

Najwięcej czasu znika na chaos.

Na zastanawianie się:

  • jak nazwać dokument;
  • od czego zacząć;
  • co powinno być polityką, a co procedurą;
  • jak nie zrobić dokumentu na 60 stron, którego nikt nie będzie utrzymywał;
  • jak opisać odpowiedzialność zarządu;
  • jak powiązać ryzyka z zabezpieczeniami;
  • jak udokumentować test backupu;
  • jak przygotować rejestr incydentów;
  • jak opisać dostawców;
  • jak napisać procedurę, która nie będzie fikcją.

I tu pojawia się największa wartość szablonów.

Nie to, że „masz dokumenty”.

Tylko to, że nie zaczynasz od zera.

W zależności od skali organizacji, poziomu dojrzałości i zakresu pracy, taka baza może oszczędzić godziny, dni, a czasami nawet tygodnie pracy.

Nie dlatego, że eliminuje pracę.

Dlatego, że eliminuje część błądzenia.

Przykład: polityka backupu bez procesu to tylko deklaracja

Wyobraź sobie dokument, w którym jest zapis:

Kopie zapasowe systemów krytycznych są wykonywane codziennie, a odtwarzanie danych jest testowane cyklicznie.

Brzmi dobrze.

Ale teraz sprawdźmy, czy to jest proces, czy papier.

Pytania kontrolne

Kto zdefiniował systemy krytyczne?

Gdzie jest lista tych systemów?

Jakie jest RPO i RTO?

Kto monitoruje powodzenie backupu?

Gdzie są alerty z nieudanych zadań?

Kiedy był ostatni test odtworzenia?

Kto zatwierdził wynik testu?

Co robimy, kiedy test się nie uda?

Gdzie jest dowód?

I teraz nagle widać, że jeden akapit w polityce może wymagać kilku realnych elementów:

  • listy systemów;
  • harmonogramu backupu;
  • logów z narzędzia backupowego;
  • raportu z testu odtworzenia;
  • ticketu z wynikiem testu;
  • decyzji właściciela systemu;
  • ewentualnych działań korygujących.

Przykładowy dowód operacyjny

To może być wpis w systemie ticketowym:

TICKET: BCP-2026-05-014
Temat: Test odtworzenia bazy CRM z kopii zapasowej
System: CRM-PROD
Data testu: 2026-05-14
RPO wymagane: 24h
RTO wymagane: 4h
Wynik: pozytywny
Czas odtworzenia: 1h 35m
Zakres testu: odtworzenie bazy do środowiska testowego, walidacja integralności danych
Właściciel systemu: Head of Sales
Wykonawca: Administrator IT
Akceptacja: CISO / IT Manager
Uwagi: brak

Może to być też fragment logu z narzędzia backupowego:

2026-05-14 02:00:01 BACKUP JOB STARTED crm-prod-db
2026-05-14 02:37:44 BACKUP JOB COMPLETED crm-prod-db STATUS=SUCCESS
2026-05-14 10:15:11 RESTORE TEST STARTED crm-prod-db restore-target=crm-test
2026-05-14 11:50:03 RESTORE TEST COMPLETED STATUS=SUCCESS checksum=OK

Albo prosta komenda administracyjna użyta do weryfikacji usługi po odtworzeniu:

systemctl status postgresql
pg_isready -h crm-test.local -p 5432

I teraz widzimy różnicę.

Dokument nie jest końcem.

Dokument wskazuje, co trzeba robić i jakie dowody powinny istnieć.

Przykład: procedura incydentowa bez ról nie zadziała

Drugi przykład: incydenty.

Słaba procedura mówi:

Incydenty bezpieczeństwa są zgłaszane do działu IT.

Tylko że w realnej sytuacji to nie wystarczy.

Bo przy incydencie zaczynają się pytania:

Kto odbiera zgłoszenie?

Czy helpdesk może eskalować incydent bezpieczeństwa poza normalnym SLA?

Kto decyduje o odłączeniu hosta od sieci?

Kto może zatrzymać usługę?

Kto komunikuje się z klientami?

Kto ocenia wpływ na dane osobowe?

Kto analizuje, czy trzeba zgłaszać incydent do właściwego organu?

Kto zabezpiecza logi?

Kto prowadzi timeline?

Kto zamyka działania korygujące?

Przykładowy minimalny timeline incydentu

INC-2026-05-021

09:12 - Alert EDR: suspicious PowerShell execution on WS-143
09:16 - Helpdesk przekazuje alert do administratora dyżurnego
09:23 - Administrator izoluje host w EDR
09:35 - Security owner rozpoczyna analizę
10:10 - Potwierdzono uruchomienie skryptu z katalogu TEMP
10:25 - Zabezpieczono artefakty: event logs, EDR telemetry, PowerShell history
11:20 - Brak potwierdzenia lateral movement
12:10 - Decyzja: incydent średni, bez wpływu na usługę krytyczną
14:40 - Host przeinstalowany, konto użytkownika zresetowane
16:00 - Działanie korygujące: reguła blokująca podobny skrypt

Przykładowe komendy pomocnicze

wevtutil epl Security C:\IR\WS-143\Security.evtx
wevtutil epl "Windows PowerShell" C:\IR\WS-143\PowerShell.evtx

Na Linuxie:

journalctl --since "2026-05-21 09:00" --until "2026-05-21 12:00" > incident-journal.log
last -a > last-logins.txt
ss -tulpn > listening-services.txt

To nadal nie jest „zgodność”.

To jest praktyka.

Ale dobra dokumentacja pomaga sprawić, że ta praktyka nie zależy wyłącznie od jednej osoby, która „wie, co robić”.

Przykład: zarządzanie dostępami bez rejestru kończy się chaosem

Dostępy to klasyczny obszar, w którym organizacje mają dokument, ale nie mają procesu.

Polityka mówi:

Dostępy są nadawane zgodnie z zasadą najmniejszych uprawnień.

Świetnie.

Tylko teraz pytania:

Kto zatwierdza dostęp?

Czy dostęp jest czasowy?

Czy dostęp uprzywilejowany wymaga osobnej akceptacji?

Czy mamy przeglądy dostępów?

Jak obsługujemy odejście pracownika?

Czy konto dostawcy ma datę ważności?

Czy wiemy, kto ma dostęp do systemów krytycznych?

Przykładowy wpis w rejestrze dostępów

user,system,role,access_type,approved_by,valid_until,last_review
jkowalski,CRM,Sales Manager,standard,Head of Sales,2026-12-31,2026-05-10
admin.vendor1,VPN,Support Vendor,privileged,IT Manager,2026-06-30,2026-05-10
anowak,ERP,Finance ReadOnly,standard,CFO,2026-12-31,2026-05-10

Przykładowy test rzeczywistości

grep -Ei "Accepted publickey|Accepted password|Failed password" /var/log/auth.log | tail -50

W środowisku Microsoft 365 może to być eksport aktywnych użytkowników, ról administracyjnych i stanu MFA.

W środowisku Google Workspace — przegląd kont superadminów i aplikacji OAuth.

W środowisku lokalnym — lista kont w grupach uprzywilejowanych.

Dokumentacja procesu zarządzania dostępami powinna mówić nie tylko „stosujemy least privilege”, ale też:

  • kto zatwierdza;
  • kto nadaje;
  • kto odbiera;
  • kto przegląda;
  • jak często;
  • gdzie jest ślad;
  • co robimy z wyjątkami.

Bez tego „least privilege” jest hasłem, nie procesem.

Czego szablony dokumentacji nie robią?

Tu trzeba być brutalnie uczciwym.

Szablony dokumentacji nie są:

  • certyfikatem ISO 27001;
  • audytem;
  • gwarancją pozytywnego wyniku audytu;
  • indywidualną opinią prawną;
  • analizą Twojej organizacji;
  • wdrożeniem ISMS;
  • dowodem działania procesu;
  • zamiennikiem decyzji zarządu;
  • zamiennikiem analizy ryzyka;
  • zamiennikiem testów technicznych;
  • zamiennikiem przeglądu dostawców;
  • zamiennikiem obsługi incydentów;
  • zamiennikiem utrzymania dokumentacji.

Jeżeli ktoś kupuje szablony tylko po to, żeby zmienić logo i wrzucić dokumenty do folderu, to robi dokładnie to, czego później wszyscy nienawidzą w compliance.

Tworzy papierową zgodność.

A papierowa zgodność zwykle rozsypuje się przy pierwszym poważniejszym pytaniu.

Dla kogo takie pakiety mają sens?

Najbardziej dla organizacji, które są w jednym z tych miejsc:

Mały zespół, dużo obowiązków

Jedna osoba odpowiada za IT, bezpieczeństwo, dostawców, helpdesk, backupy, dostęp do systemów i jeszcze ma „ogarnąć NIS2”.

W takim układzie największym problemem często nie jest brak dobrej woli.

Problemem jest brak czasu i struktury.

Szablon nie zdejmie odpowiedzialności, ale może pomóc przejść od chaosu do pierwszej wersji dokumentacji.

Firma, która nie wie, od czego zacząć

Ktoś słyszy:

NIS2, KSC, ISO 27001, analiza ryzyka, incydenty, dostawcy, polityki, procedury, rejestry, MFA, backup, BCP, DRP, audyt, zarząd, odpowiedzialność.

I robi się ściana.

Dobry pakiet szablonów działa wtedy jak mapa.

Nie zastępuje drogi, ale pokazuje kierunek.

Zespół techniczny, który musi rozmawiać z zarządem

Administrator może wiedzieć, że backup działa.

Ale zarząd potrzebuje innego języka:

  • jakie mamy ryzyko;
  • kto odpowiada;
  • jaki jest wpływ biznesowy;
  • jakie są decyzje;
  • jakie są wyjątki;
  • co wymaga finansowania;
  • co wymaga akceptacji.

Dokumentacja procesów pomaga przełożyć techniczne bezpieczeństwo na zarządzanie.

Organizacja przed rozmową z konsultantem lub audytorem

Nie każda firma zaczyna od dużego projektu doradczego.

Czasami sensowniej jest najpierw uporządkować podstawy:

  • listę dokumentów;
  • właścicieli procesów;
  • rejestry;
  • dowody;
  • ryzyka;
  • statusy;
  • braki.

Dzięki temu rozmowa z konsultantem albo audytorem jest konkretniejsza.

Dla kogo takie pakiety nie są?

Nie są dla osób, które chcą kupić zgodność i nic więcej nie robić.

Nie są dla osób, które oczekują, że dokumenty same wdrożą bezpieczeństwo.

Nie są dla organizacji, które potrzebują pełnego, indywidualnego projektu wdrożeniowego, ale próbują zastąpić go paczką plików.

Nie są dla osób, które oczekują opinii prawnej.

Nie są dla osób, które oczekują gwarancji certyfikacji ISO 27001.

Nie są dla osób, które oczekują gwarancji pozytywnego wyniku audytu.

Nie są dla osób, które chcą mieć alibi zamiast procesu.

To jest bardzo proste.

Jeżeli chcesz kupić fikcję — to nie jest ten produkt.

Jeżeli chcesz bazę do pracy — wtedy ma to sens.

Dlaczego to ma znaczenie

Bo w realnym incydencie nie pomaga dokument, którego nikt nie stosuje.

Pomaga proces.

Pomaga to, że ktoś wie, kogo obudzić o 2:00 w nocy.

Pomaga to, że wiadomo, kto może odłączyć system.

Pomaga to, że kopie zapasowe były testowane.

Pomaga to, że dostawca ma określone wymagania bezpieczeństwa.

Pomaga to, że dostęp administracyjny nie jest nadawany „bo ktoś poprosił na Teamsie”.

Pomaga to, że zarząd nie dowiaduje się o swojej odpowiedzialności dopiero wtedy, kiedy coś wybuchło.

Dokumentacja ma znaczenie wtedy, kiedy:

  • porządkuje odpowiedzialności;
  • zmniejsza zależność od pojedynczych osób;
  • pozwala powtarzać proces;
  • tworzy ślad decyzji;
  • pomaga szkolić nowych ludzi;
  • ułatwia audyt;
  • wspiera analizę ryzyka;
  • pozwala wykazać, co faktycznie robimy;
  • pokazuje luki, których wcześniej nie było widać.

Bez dokumentacji wiele organizacji zarządza bezpieczeństwem „z pamięci”.

A pamięć nie skaluje się dobrze.

Nie działa dobrze przy rotacji pracowników.

Nie działa dobrze przy incydencie.

Nie działa dobrze przy audycie.

Nie działa dobrze, kiedy zarząd pyta: „czy my to naprawdę robimy?”.

Jak pracować z szablonami, żeby nie zrobić papierowej zgodności?

Najgorszy scenariusz wygląda tak:

  1. Pobierasz dokument.
  2. Zmieniasz logo.
  3. Wpisujesz nazwę firmy.
  4. Niczego nie czytasz.
  5. Wrzucasz plik do folderu.
  6. Uznajesz temat za zamknięty.

To jest droga do fikcji.

Lepszy sposób wygląda inaczej.

Krok 1: przeczytaj dokument jak mapę procesu

Nie zaczynaj od edycji.

Najpierw przeczytaj.

Zobacz, jaki proces dokument opisuje. Sprawdź, czy taki proces rzeczywiście istnieje w firmie.

Krok 2: usuń zapisy, które nie pasują

Jeżeli dokument mówi, że robicie kwartalne przeglądy, a nigdy ich nie robiliście, nie udawaj, że robicie.

Albo zmień zapis na realny plan, albo zaplanuj wdrożenie przeglądu.

Dokumentacja ma opisywać rzeczywistość albo świadomy plan dojścia do niej.

Nie fikcję.

Krok 3: wpisz właścicieli

Każdy proces powinien mieć właściciela.

Nie „dział IT”.

Konkretną rolę.

Na przykład:

  • IT Manager;
  • CISO;
  • Administrator systemu;
  • Właściciel systemu biznesowego;
  • Kierownik działu;
  • Zarząd;
  • Inspektor ochrony danych;
  • właściciel procesu zakupowego.

Bez właściciela proces jest niczyj.

A proces niczyj zwykle nie działa.

Krok 4: połącz dokument z rejestrem

Polityka bez rejestru często jest martwa.

Przykłady:

  • procedura incydentowa → rejestr incydentów;
  • analiza ryzyka → rejestr ryzyk;
  • zarządzanie dostawcami → rejestr dostawców;
  • zarządzanie dostępami → rejestr dostępów lub przeglądów;
  • backup → raporty z backupu i testów odtworzenia;
  • działania korygujące → rejestr działań.

Dokument mówi, co robimy.

Rejestr pokazuje, że to robimy.

Krok 5: zbierz dowody

Nie chodzi o to, żeby produkować dokumenty dla samego produkowania.

Chodzi o ślad działania.

Dowodem może być:

  • ticket;
  • raport;
  • log;
  • eksport konfiguracji;
  • protokół przeglądu;
  • potwierdzenie szkolenia;
  • wynik testu odtworzenia;
  • decyzja o akceptacji ryzyka;
  • notatka z przeglądu dostawcy;
  • potwierdzenie wyłączenia dostępu;
  • zapis z narzędzia EDR, SIEM, backupu lub IAM.

Krok 6: ustaw przegląd

Dokumentacja bezpieczeństwa nie powinna być jednorazowym projektem.

Procesy się zmieniają.

Systemy się zmieniają.

Dostawcy się zmieniają.

Ryzyka się zmieniają.

Ludzie odchodzą.

Nowe usługi trafiają na produkcję.

Dlatego dokumentacja musi mieć właściciela, wersję, datę, status i cykl przeglądu.

Największa wartość: brak pustej kartki

Pusta kartka jest brutalna.

Zwłaszcza kiedy masz mały zespół, mało czasu i kilka tematów naraz.

Masz przygotować analizę ryzyka.

Masz opisać incydenty.

Masz uporządkować dostawców.

Masz pokazać zarządowi odpowiedzialności.

Masz przygotować politykę bezpieczeństwa.

Masz udokumentować backup.

Masz wykazać, że dostępy są kontrolowane.

Masz coś pokazać klientowi, audytorowi, konsultantowi albo wewnętrznemu zespołowi.

I wtedy szablon nie jest „zgodnością”.

Jest punktem startowym.

To jest różnica.

Nie kupujesz gotowej zgodności.

Kupujesz strukturę, która pomaga zacząć sensownie pracować.

NIS2 i ISO 27001: nie mylmy dwóch rzeczy

ISO 27001 i NIS2 mogą się wspierać, ale nie są tym samym.

ISO 27001 mówi językiem systemu zarządzania bezpieczeństwem informacji: zakres, kontekst organizacji, ryzyka, cele, dokumentacja, odpowiedzialności, audyty wewnętrzne, działania korygujące, doskonalenie.

NIS2 mówi językiem obowiązków regulacyjnych, cyberodporności, środków technicznych i organizacyjnych, odpowiedzialności kierownictwa, incydentów, dostawców i sektorów objętych regulacją.

W praktyce wiele procesów będzie podobnych.

Analiza ryzyka.
Obsługa incydentów.
Zarządzanie dostępami.
Dostawcy.
Backup.
Ciągłość działania.
Szkolenia.
Zarządzanie aktywami.
Kryptografia.
MFA.
Przeglądy.
Dowody działania.

Ale nie warto mówić:

Mam ISO, więc NIS2 mnie nie dotyczy.

I nie warto mówić:

Mam dokumentację pod NIS2, więc mam wdrożone ISO 27001.

To są różne cele, różne mechaniki i różne konteksty.

Szablony mogą pomóc uporządkować dokumentację procesów, ale nie zwalniają z myślenia o konkretnym zakresie, obowiązkach i ryzykach organizacji.

Pakiety szablonów dokumentacji

Przygotowałem dwa pakiety szablonów dokumentacji procesów bezpieczeństwa.

Nie traktuj ich jako „zgodności w paczce”.

Traktuj je jako bazę do pracy nad dokumentacją procesów: polityk, procedur, rejestrów, odpowiedzialności, ryzyk, incydentów, dostępów, dostawców, kopii zapasowych i ciągłości działania.

Pakiet dokumentacji oparty na ISO 27001

https://lp.securitybeztabu.pl/dokumentacja-iso-27001

Pakiet dokumentacji oparty na NIS2

https://lp.securitybeztabu.pl/dokumentacja-nis2

Jak sprawdzić, czy dokumentacja nie jest fikcją?

Weź jeden dokument swojej organizacji i zrób prosty test.

Nie cały system.

Jeden dokument.

Na przykład procedurę backupu.

Odpowiedz:

  • Czy wiemy, które systemy są krytyczne?
  • Czy mamy właścicieli tych systemów?
  • Czy mamy określone RPO i RTO?
  • Czy backup faktycznie działa?
  • Czy mamy logi z backupu?
  • Czy testowaliśmy odtworzenie?
  • Czy mamy dowód testu?
  • Czy ktoś zaakceptował wynik?
  • Czy są działania korygujące po nieudanym teście?

Potem zrób to samo z incydentami.

  • Czy ludzie wiedzą, gdzie zgłosić incydent?
  • Czy mamy rejestr incydentów?
  • Czy mamy klasyfikację incydentów?
  • Czy ktoś wie, kiedy eskalować?
  • Czy wiadomo, kto kontaktuje się z zarządem?
  • Czy zabezpieczamy logi?
  • Czy robimy post-incident review?

Jeżeli dokument nie prowadzi do żadnego procesu, rejestru, decyzji ani dowodu, to prawdopodobnie jest papierem.

Jeżeli dokument pomaga wykonać proces i zostawić ślad, to zaczyna mieć sens.

Checklista techniczna: dokumentacja procesu bezpieczeństwa

Na koniec prosta checklista.

Dla każdego dokumentu sprawdź:

  • Czy dokument opisuje realny proces?
  • Czy proces ma właściciela?
  • Czy są zdefiniowane role i odpowiedzialności?
  • Czy wiadomo, kiedy proces się uruchamia?
  • Czy są dane wejściowe i wyjściowe procesu?
  • Czy dokument wskazuje rejestr lub dowód działania?
  • Czy są określone częstotliwości przeglądów?
  • Czy zapisy są dopasowane do skali organizacji?
  • Czy usunięto deklaracje, których firma nie spełnia?
  • Czy dokument jest zrozumiały dla osób, które mają go stosować?
  • Czy istnieje wersja, data, właściciel i status dokumentu?
  • Czy dokument łączy się z ryzykiem, incydentami, dostępami, dostawcami albo ciągłością działania?
  • Czy da się pokazać dowody, że proces działa?

Jeżeli na większość pytań odpowiadasz „nie”, to problemem nie jest brak kolejnego dokumentu.

Problemem jest brak procesu.

Stresczenie tego artykułu w formie filmu

Podsumowanie

Nie sprzedaję zgodności w paczce.

Nie sprzedaję certyfikacji.

Nie sprzedaję audytu.

Nie sprzedaję opinii prawnej.

Nie sprzedaję obietnicy, że po pobraniu dokumentów organizacja automatycznie spełnia wymagania NIS2, KSC albo ISO 27001.

Sprzedaję coś bardziej przyziemnego, ale bardzo potrzebnego: bazę do dokumentowania procesów bezpieczeństwa.

Dla ludzi, którzy mają mało czasu.

Dla małych zespołów.

Dla osób, które nie chcą zaczynać od pustej kartki.

Dla organizacji, które wiedzą, że dokumentacja sama nie robi bezpieczeństwa, ale bez dobrej dokumentacji trudno zarządzać ryzykiem, incydentami, dostępami, dostawcami, kopiami zapasowymi, ciągłością działania i odpowiedzialnościami.

Szablony nie kończą pracy.

One pomagają ją sensownie zacząć.

Weź dziś jeden proces: backup, incydenty albo dostępy.

Sprawdź, czy masz nie tylko dokument, ale też właściciela, rejestr, dowód działania i ostatni przegląd.

Jeżeli nie — zacznij od tego.

Nie od kolejnego slajdu.

Nie od kolejnego hasła o compliance.

Od jednego procesu, który da się pokazać, sprawdzić i utrzymać.

Bibliografia