Dokumentacja SZBI nie jest jednym dokumentem ani gotowym pakietem wzorów, który można wdrożyć bez znajomości organizacji. Powinna obejmować zasady zarządzania bezpieczeństwem, procedury wykonywania konkretnych czynności, rejestry oraz dowody potwierdzające, że przyjęte zabezpieczenia rzeczywiście działają. Jej zakres wynika z usług, systemów, ryzyka, dostawców i obowiązków prawnych firmy, dlatego dwa podmioty tej samej wielkości mogą potrzebować innego zestawu dokumentów.
Polityka określa zasadę, procedura opisuje sposób wykonania, rejestr pokazuje aktualny stan, a zapis operacyjny potwierdza wykonanie czynności. Jeżeli dokumentacja kończy się na polityce bezpieczeństwa i nie prowadzi do testów, przeglądów, decyzji oraz działań korygujących, nie tworzy działającego Systemu Zarządzania Bezpieczeństwem Informacji.
Strukturazasady, wykonanie, dowody
Celpowtarzalność i kontrola
UoKSC wskazuje obowiązkowe obszary zarządzania i rodzaje dokumentacji. Organizacja musi przełożyć je na rozwiązania odpowiednie do własnego ryzyka. Liczy się kompletność pokrycia wymagań, zgodność dokumentów ze stanem faktycznym oraz możliwość wykazania ich stosowania.
Czym jest dokumentacja SZBI?
Dokumentacja SZBI utrwala sposób, w jaki organizacja rozpoznaje ryzyko, podejmuje decyzje, wdraża zabezpieczenia i kontroluje ich skuteczność. Obejmuje informacje przeznaczone dla różnych odbiorców: zarząd potrzebuje zasad, odpowiedzialności i raportów, pracownik krótkiej instrukcji, zespół IT procedur technicznych, a audytor dowodów wykonania.
Nie należy utożsamiać jej z samym SZBI. System obejmuje również ludzi, technologię, działania zarządcze, procesy, dostawców i codzienną praktykę. Dokumentacja opisuje system i pozostawia ślad jego działania. Szersze wyjaśnienie tej różnicy zawiera artykuł SZBI – co to jest System Zarządzania Bezpieczeństwem Informacji?
Art. 10 UoKSC nakazuje podmiotom kluczowym i ważnym dokumentację opracowywać, stosować i aktualizować. To trzy odrębne obowiązki. Prawidłowa dokumentacja SZBI musi więc odpowiadać aktualnym systemom, dostawcom i ryzykom. Firma może posiadać poprawnie nazwane polityki, ale nadal naruszać wymagania, jeżeli nie są stosowane albo od lat nie były aktualizowane.
Dokumentacja normatywna i operacyjna w UoKSC
Ustawa dzieli dokumentację bezpieczeństwa na normatywną i operacyjną. Rozróżnienie pozwala szybko ocenić, czy organizacja posiada jedynie deklaracje, czy również dowody wykonania. Podczas audytu albo kontroli oba poziomy powinny tworzyć spójną ścieżkę.
Ład i polityki
Zakres SZBI, polityka nadrzędna, cele, role, odpowiedzialność, wymagania prawne i zasady zarządzania ryzykiem.
Procedury i plany
Opisują konkretne działania: dostęp, incydenty, backup, podatności, dostawców, BCP, DRP i komunikację kryzysową.
Rejestry
Pokazują aktualny stan aktywów, ryzyk, uprawnień, dostawców, incydentów, podatności, zmian i działań naprawczych.
Zapisy i dowody
Logi, zgłoszenia, protokoły, wyniki testów, raporty, potwierdzenia szkoleń i decyzje wykazują rzeczywiste stosowanie zasad.
Dokumentację normatywną stanowią według UoKSC dokumentacja SZBI, dokumentacja ochrony infrastruktury, systemu zarządzania ciągłością działania, dokumentacja techniczna systemu informacyjnego oraz dokumenty wynikające ze specyfiki sektora. Dokumentacja operacyjna obejmuje zapisy poświadczające wykonanie czynności, w tym automatycznie generowane dzienniki systemów.
Jeden dokument może obsługiwać kilka wymagań
UoKSC nie wymaga mnożenia plików. Zasady kopii zapasowych mogą być częścią polityki ciągłości albo osobną procedurą. Rejestr systemów może jednocześnie zawierać klasyfikację, właścicieli i zależności. Struktura powinna być czytelna dla użytkowników i audytowalna, a nie rozbudowana dla samej liczby dokumentów.
Pełna mapa dokumentacji SZBI
Poniższa tabela pokazuje, jak może wyglądać dokumentacja SZBI w średniej organizacji. Nie każdy element musi funkcjonować jako osobny dokument, a jego szczegółowość powinna wynikać z ryzyka. Kolumna „dowód stosowania” jest równie ważna jak sama nazwa polityki lub procedury.
| Obszar | Dokument normatywny | Rejestr lub zapis | Dowód stosowania | Typowy właściciel |
|---|---|---|---|---|
| Zakres i ład | Zakres SZBI, polityka bezpieczeństwa, role i odpowiedzialność | Rejestr wymagań oraz dokumentów | Zatwierdzenie zarządu, komunikacja i przegląd | Zarząd / Pełnomocnik SZBI |
| Ryzyko | Metodyka i kryteria oceny ryzyka | Rejestr ryzyka i plan postępowania | Akceptacje ryzyka, status działań i ponowna ocena | Właściciele ryzyk |
| Aktywa | Polityka klasyfikacji i postępowania z aktywami | Inwentaryzacja informacji, systemów, sprzętu i właścicieli | Wyniki okresowej weryfikacji i zwrotu aktywów | Właściciele aktywów / IT |
| Dostęp | Polityka kontroli dostępu i uwierzytelniania | Rejestr kont, uprawnień oraz dostępów uprzywilejowanych | Wnioski, zatwierdzenia, przeglądy i offboarding | IT / HR / właściciel systemu |
| Incydenty | Procedura reagowania, eskalacji i raportowania | Rejestr zdarzeń i incydentów | Chronologia, logi, zgłoszenia S46 i raport po incydencie | Koordynator incydentu |
| Ciągłość | BIA, BCP, DRP i plan komunikacji kryzysowej | Rejestr procesów krytycznych, RTO/RPO i zależności | Raport z testu odtworzenia oraz lista korekt | Właściciele procesów / IT |
| Kopie zapasowe | Procedura wykonywania, ochrony i testowania kopii | Harmonogram, zakres oraz status kopii | Logi backupu i protokół skutecznego odtworzenia | IT / dostawca |
| Podatności i zmiany | Procedura podatności, aktualizacji, konfiguracji i zmian | Rejestr podatności, wyjątków, poprawek i zmian | Tickety, wyniki skanów, akceptacje oraz testy | IT / bezpieczeństwo |
| Monitoring | Polityka logowania, monitorowania i retencji | Katalog źródeł logów, alertów i przypadków użycia | Alerty, raporty SOC i przeglądy skuteczności | SOC / IT |
| Dostawcy | Polityka bezpieczeństwa łańcucha dostaw | Rejestr dostawców, usług, kontaktów i podwykonawców | Oceny, ankiety, umowy, SLA i wyniki przeglądów | Zakupy / prawo / IT |
| Personel | Polityka bezpieczeństwa zasobów ludzkich i cyberhigieny | Rejestr ról, szkoleń, oświadczeń i wymaganych weryfikacji | Listy obecności, testy wiedzy i potwierdzenia zapoznania | HR / Pełnomocnik |
| Kryptografia | Polityka kryptografii i zarządzania kluczami | Rejestr kluczy, certyfikatów i zatwierdzonych mechanizmów | Wyniki przeglądów, wymiany i wycofania kluczy | IT / bezpieczeństwo |
| Ocena skuteczności | Program pomiarów, audytów i przeglądów | Rejestr niezgodności i działań korygujących | Raporty audytowe, KPI, protokoły i zamknięte działania | Pełnomocnik / audyt |
| Dokumentacja techniczna | Standardy architektury, konfiguracji i bezpiecznej eksploatacji | Katalog systemów, połączeń, wersji i zależności | Diagramy, konfiguracje bazowe i historia zmian | Architekt / IT |
Zakres SZBI – pierwszy dokument całego systemu
W praktyce dokumentacja SZBI zaczyna się od określenia zakresu: jednostek, lokalizacji, procesów, informacji, systemów i usług objętych systemem zarządzania. Bez niego nie można wiarygodnie przeprowadzić oceny ryzyka ani ustalić, czy dokumenty dotyczą wszystkich procesów wpływających na świadczenie regulowanej usługi.
Dokument powinien opisywać granice organizacyjne i technologiczne, interfejsy z dostawcami, zależności od innych spółek oraz uzasadnione wyłączenia. Nie wystarczy zdanie „SZBI obejmuje całą organizację”, jeżeli później nie wiadomo, czy dotyczy ono chmury, oddziałów, urządzeń OT, pracy zdalnej albo systemów utrzymywanych przez podwykonawców.
Zakres powinien pozostawać spójny z analizą statusu na gruncie UoKSC, wykazem usług, umowami i architekturą systemów. Jego zmiana jest potrzebna po przejęciu spółki, uruchomieniu nowej usługi, migracji do chmury, istotnej zmianie dostawcy albo przebudowie infrastruktury.
Metodyka, rejestr i plan postępowania z ryzykiem
Trzy dokumenty związane z ryzykiem pełnią inne funkcje. Metodyka określa sposób liczenia i oceny. Rejestr pokazuje aktualne zagrożenia, podatności, skutki i zabezpieczenia. Plan postępowania zamienia wynik oceny na działania, właścicieli, budżet i terminy.
Metodyka ryzyka
Definiuje skalę prawdopodobieństwa i skutku, kryteria akceptacji, sposób oceny poufności, integralności, dostępności i autentyczności oraz częstotliwość przeglądu.
Rejestr ryzyka
Łączy usługę, aktywo, zagrożenie, podatność, istniejące środki, właściciela oraz poziom ryzyka pierwotnego i rezydualnego.
Plan postępowania
Wskazuje sposób reakcji, zabezpieczenie, odpowiedzialność, termin, koszt, status i oczekiwany poziom ryzyka po wykonaniu działania.
W modelu ISO/IEC 27001 istotna jest także Deklaracja Stosowania, która wskazuje niezbędne zabezpieczenia, status ich wdrożenia i uzasadnienie włączenia lub wyłączenia zabezpieczeń z załącznika A. Nie należy jednak przedstawiać dokumentu o tej nazwie jako powszechnego obowiązku ustawowego każdej firmy. Staje się on wymaganiem, gdy organizacja wdraża zgodność z ISO 27001 albo przyjęła ten model jako element własnego SZBI.
Jakie polityki tematyczne powinny znaleźć się w SZBI?
Art. 8 UoKSC wskazuje obszary, które system powinien objąć odpowiednimi i proporcjonalnymi środkami. Organizacja może opisać je w jednej rozbudowanej polityce albo w zestawie krótszych dokumentów. W średniej firmie bardziej użyteczna jest zwykle struktura modułowa, ponieważ właściciel dostępu nie musi otrzymywać całej dokumentacji ciągłości działania.
Aktywa, klasyfikacja i uprawnienia
- klasyfikacja oraz zasady postępowania z informacjami;
- zarządzanie sprzętem, oprogramowaniem i nośnikami;
- kontrola dostępu fizycznego i logicznego;
- uwierzytelnianie wieloskładnikowe oraz dostęp uprzywilejowany;
- kryptografia, klucze i bezpieczna komunikacja.
Bezpieczne utrzymanie systemów
- bezpieczne nabywanie, rozwój i eksploatacja;
- zarządzanie podatnościami, poprawkami i konfiguracją;
- zarządzanie zmianą i testowanie systemów;
- logowanie, monitoring oraz retencja dzienników;
- kopie zapasowe i separacja repozytoriów.
Personel i dostawcy
- bezpieczeństwo zasobów ludzkich;
- cyberhigiena, szkolenia i odpowiedzialność personelu;
- praca zdalna, urządzenia mobilne i BYOD;
- wybór, ocena i monitoring dostawców;
- wymagania umowne oraz bezpieczne zakończenie współpracy.
Incydenty i ciągłość działania
- identyfikacja, klasyfikacja i eskalacja incydentów;
- komunikacja z CSIRT, organem, UODO i klientami;
- BCP, DRP, BIA i zarządzanie kryzysowe;
- testy odtworzenia i ćwiczenia incydentowe;
- wnioski, działania korygujące i doskonalenie.
Szczegółową zawartość dokumentu nadrzędnego omawia artykuł Polityka bezpieczeństwa informacji ISO 27001. Nowy poradnik nie powinien jej zastępować. Pokazuje szerszą architekturę i relację polityki z dokumentami wykonawczymi.
Jakie procedury operacyjne trzeba przygotować?
Procedura powinna prowadzić użytkownika od zdarzenia inicjującego do wyniku i dowodu. Dobra procedura wskazuje odpowiedzialność, kanał komunikacji, wymagany czas, kryterium decyzji, formularz albo system używany do rejestracji oraz ścieżkę zastępstwa.
W praktyce potrzebne są procedury nadawania, zmiany i odbierania dostępów; przeglądu kont uprzywilejowanych; obsługi incydentów; zabezpieczania dowodów; zgłaszania do S46; wykonywania i testowania kopii; odtwarzania usług; obsługi podatności i aktualizacji; zarządzania zmianą; oceny dostawców; bezpiecznego zakupu systemów; zwrotu i niszczenia aktywów; przeglądu dokumentacji; audytów oraz działań korygujących.
Instrukcja może być krótsza od procedury i kierowana do konkretnej roli. Przykładem jest karta pierwszych działań dla pracownika zgłaszającego phishing, instrukcja odłączenia urządzenia od sieci albo checklista administratora podczas odbierania uprawnień. Dokument ma być możliwy do użycia pod presją czasu.
Procedura incydentowa i dokumentacja kontaktu z CSIRT
Procedura reagowania powinna obejmować wykrycie, potwierdzenie, klasyfikację, powstrzymanie, usunięcie przyczyny, odtworzenie i działania po incydencie. Musi także łączyć dane techniczne z decyzjami prawnymi i biznesowymi. Dla incydentu poważnego UoKSC przewiduje wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin oraz sprawozdanie końcowe zasadniczo w ciągu miesiąca.
Dokumentacja powinna wskazywać właściciela procesu, zastępstwo, kryteria kwalifikacji, książkę kontaktową, dostęp do S46, zasady współpracy z dostawcami oraz wzory informacji potrzebnych do zgłoszenia. Rejestr incydentów powinien zawierać chronologię, systemy i usługi objęte zdarzeniem, podjęte działania, decyzje, dowody i wnioski.
Sama procedura nie potwierdza gotowości. Potrzebne są raporty z ćwiczeń, wyniki testów kanałów alarmowych i dowody, że osoby decyzyjne znają swoje role. Praktyczny przebieg reakcji opisuje poradnik dotyczący zgłoszenia incydentu NIS2.
BIA, BCP i DRP – dokumentacja ciągłości działania
Business Impact Analysis identyfikuje procesy krytyczne, skutki ich przerwania, zależności i dopuszczalny czas niedostępności. BCP określa, jak organizacja utrzyma lub wznowi procesy biznesowe. DRP opisuje techniczne odtworzenie systemów, danych i infrastruktury. Dokumenty powinny być spójne z oceną ryzyka, umowami SLA oraz możliwościami dostawców.
Plan powinien zawierać warunki uruchomienia i zamknięcia, role, kolejność odtwarzania, kanały komunikacji, zasoby awaryjne, lokalizacje, zależności oraz wartości RTO i RPO. Do dokumentacji operacyjnej trafiają wyniki testów kopii, protokoły ćwiczeń, rzeczywiste czasy odtworzenia i działania korygujące.
Informacja, że kopia została wykonana, nie potwierdza możliwości odtworzenia kompletnej usługi w wymaganym czasie. Dowodem jest udokumentowany test obejmujący dane, konfigurację, zależności, dostęp personelu i decyzję o powrocie do działania.
Jakie rejestry należy prowadzić?
Rejestr jest kontrolowanym źródłem aktualnej informacji. Powinien mieć właściciela, jednoznaczny zakres, datę aktualizacji i zasady dostępu. Arkusz bez wskazania odpowiedzialnej osoby szybko staje się historycznym zestawieniem, którego nikt nie wykorzystuje do decyzji.
Podstawowy katalog obejmuje rejestr dokumentacji, wymagań prawnych, aktywów, systemów, właścicieli, ryzyk, planów postępowania, dostawców, umów, uprawnień, incydentów, podatności, wyjątków, zmian, kopii zapasowych, szkoleń, audytów, niezgodności i działań korygujących. Rejestry mogą być prowadzone w dedykowanych narzędziach ITSM, GRC, systemie HR albo kontrolowanym arkuszu.
W przypadku dostawców warto rejestrować nie tylko nazwę firmy, ale usługę, produkt, kontakt alarmowy, właściciela biznesowego, krytyczność, dostęp do danych i systemów, podwykonawców, lokalizację, termin przeglądu oraz plan wyjścia. Wymagania umowne rozwija poradnik Umowa z dostawcą IT NIS2 – 12 klauzul chroniących firmę.
Audyt zerowy KSC/NIS2 powinien połączyć przegląd dokumentacji ze stanem systemów, umów, zabezpieczeń i dowodów. Wynikiem jest mapa luk oraz plan działań, a nie tylko lista brakujących nazw plików.
Jakie dowody potwierdzają stosowanie dokumentacji?
Dowody powstają podczas wykonywania procedur. Mogą być tworzone ręcznie, jak protokół przeglądu zarządu, albo automatycznie, jak log uwierzytelnienia. Ważne, aby można było ustalić, czego dotyczą, kiedy powstały, kto odpowiadał za działanie oraz jaki był jego rezultat.
Do najważniejszych należą wyniki testów odtworzenia, raporty z ćwiczeń incydentowych, zapisy przeglądów uprawnień, logi i alerty, tickety zmian, potwierdzenia aktualizacji, ankiety dostawców, raporty SLA, listy obecności i testy wiedzy, wyniki audytów, protokoły przeglądów kierownictwa oraz decyzje o akceptacji ryzyka.
Dowód powinien być adekwatny. Zrzut ekranu może potwierdzić konfigurację w konkretnym momencie, ale nie zastąpi cyklicznego raportu. Podpisana lista obecności potwierdza udział w szkoleniu, lecz nie wykazuje zrozumienia materiału. Dlatego organizacja powinna dobierać zapisy tak, aby potwierdzały rezultat, a nie wyłącznie wykonanie formalnego kroku.
Jak wersjonować, chronić i archiwizować dokumentację?
Dokumentacja SZBI podlega nadzorowi wymaganemu przez art. 10 UoKSC. Organizacja musi zapewnić dostęp wyłącznie osobom upoważnionym, ochronę przed uszkodzeniem, zniszczeniem, utratą, niewłaściwym użyciem i utratą integralności oraz oznaczanie kolejnych wersji w sposób pozwalający ustalić zmiany.
Opracowanie
Właściciel, cel, zakres, klasyfikacja i osoby konsultowane.
Zatwierdzenie
Formalna akceptacja przez osobę posiadającą właściwe uprawnienia.
Publikacja
Kontrolowana dystrybucja aktualnej wersji do właściwych odbiorców.
Przegląd
Terminowy lub uruchamiany przez zmianę, incydent albo wynik audytu.
Wycofanie
Archiwizacja, retencja, protokół brakowania i trwały zapis zniszczenia.
Wycofaną dokumentację przechowuje się zasadniczo przez co najmniej dwa lata od wycofania z użytkowania albo zakończenia świadczenia usługi, z uwzględnieniem sposobu liczenia terminu wskazanego w ustawie. Zniszczenie potwierdza protokół brakowania zawierający między innymi datę, oznaczenie dokumentacji, sposób zniszczenia i osobę zatwierdzającą. Protokoły brakowania przechowuje się trwale.
Nie wszystkie dokumenty powinny być dostępne całemu personelowi. Diagram sieci, konfiguracje bezpieczeństwa, rejestr podatności i plan awaryjnego dostępu wymagają większego ograniczenia niż instrukcja zgłaszania phishingu. Poziom dostępu powinien wynikać z roli oraz zasady wiedzy koniecznej.
Kto zatwierdza i aktualizuje dokumentację SZBI?
Zarząd lub kierownik podmiotu powinien zatwierdzać dokumenty wyznaczające kierunek, odpowiedzialność, poziom akceptowanego ryzyka i zasoby. Właściciele procesów odpowiadają za zgodność procedur z praktyką. IT i bezpieczeństwo utrzymują dokumentację techniczną, a Pełnomocnik SZBI koordynuje rejestr dokumentów, przeglądy oraz spójność systemu.
Powierzenie przygotowania dokumentów zewnętrznemu ekspertowi nie przenosi ustawowej odpowiedzialności kierownictwa. Zarząd powinien otrzymywać informację o brakach, ryzyku rezydualnym, opóźnieniach i wynikach testów. Model bieżącego utrzymania opisuje artykuł Stała opieka nad SZBI – zakres zabezpieczenia dla zarządu.
Jak sprawdzić kompletność dokumentacji przed audytem?
Kontrola powinna przebiegać od wymagań i ryzyka do dokumentów, a następnie od dokumentów do dowodów. Sam spis treści nie pokaże, czy system działa. Poniższa checklista pozwala wykryć podstawowe luki organizacyjne.
Kontrola dokumentacji SZBI
Zaznacz wyłącznie elementy posiadające właściciela, aktualną wersję i dowód stosowania.
Niski wynik nie oznacza, że trzeba natychmiast stworzyć kilkadziesiąt nowych plików. Najpierw należy sprawdzić, które wymagania są już realizowane w istniejących systemach HR, ITSM, zarządzaniu jakością, RODO i ciągłości działania. Następnie można uzupełnić luki oraz zintegrować dokumentację, zamiast budować równoległe silosy.
FAQ: dokumentacja SZBI
Ile dokumentów powinien zawierać SZBI?
Nie istnieje jedna prawidłowa liczba. Zakres zależy od wielkości, usług, technologii, sektora, dostawców i ryzyka organizacji. Jeden dokument może obejmować kilka obszarów, o ile pozostaje czytelny, aktualny i pozwala jednoznacznie ustalić odpowiedzialność oraz sposób wykonania.
Czy polityka bezpieczeństwa informacji wystarczy?
Nie. Polityka wyznacza kierunek i zasady, ale potrzebne są także procedury, plany, rejestry oraz zapisy potwierdzające wykonanie. UoKSC rozróżnia dokumentację normatywną i operacyjną, dlatego sama podpisana polityka nie wykazuje działania systemu.
Czy UoKSC wymaga Deklaracji Stosowania?
UoKSC nie wskazuje powszechnego dokumentu o tej nazwie. Deklaracja Stosowania jest wymagana w modelu ISO/IEC 27001 i łączy ocenę ryzyka z wyborem zabezpieczeń z załącznika A. Będzie potrzebna, jeśli organizacja wdraża zgodność lub certyfikację według tej normy.
Czy dokumentacja SZBI może być elektroniczna?
Tak. Art. 10 UoKSC dopuszcza postać papierową i elektroniczną. Niezależnie od nośnika trzeba zapewnić dostęp osobom upoważnionym, ochronę integralności, wersjonowanie, retencję oraz możliwość wykazania zmian.
Jak często aktualizować dokumentację SZBI?
W zaplanowanych odstępach oraz po zdarzeniach wpływających na ryzyko: zmianie systemu, usługi, dostawcy lub organizacji, istotnym incydencie, audycie, zmianie prawa albo wykryciu poważnej podatności. Roczny przegląd bywa minimum organizacyjnym, ale dokumenty operacyjne mogą wymagać częstszej aktualizacji.
Czy dokumentacja RODO może być częścią SZBI?
Tak, część zasad, rejestrów i procedur może być współdzielona, szczególnie w obszarze dostępu, incydentów, dostawców i retencji. Trzeba jednak zachować różne kryteria ryzyka. RODO chroni prawa i wolności osób, a SZBI obejmuje także inne informacje, systemy oraz ciągłość usług.
Jak długo przechowywać wycofane dokumenty?
UoKSC przewiduje zasadniczo co najmniej dwuletni okres przechowywania od wycofania dokumentacji z użytkowania albo zakończenia świadczenia usługi, liczony zgodnie z regułą wskazaną w art. 10. Odrębne przepisy archiwalne albo sektorowe mogą wymagać dłuższego okresu.
Kto powinien zatwierdzać dokumentację SZBI?
Dokumenty strategiczne, zakres, politykę i decyzje dotyczące akceptacji ryzyka powinno zatwierdzać właściwe kierownictwo. Dokumenty operacyjne mogą być zatwierdzane przez wyznaczonych właścicieli. Matryca uprawnień powinna jasno wskazywać, kto opracowuje, konsultuje, zatwierdza i przegląda każdy dokument.
Czy gotowy pakiet wzorów zapewni zgodność z KSC/NIS2?
Nie. Wzór może pomóc uporządkować strukturę, ale nie odzwierciedla automatycznie usług, systemów, zależności, dostawców i ryzyka konkretnej firmy. Dokumentacja musi opisywać stan faktyczny, a organizacja powinna posiadać dowody jej stosowania.
Sprawdź, czego brakuje w dokumentacji SZBI
Podczas bezpłatnej konsultacji omówimy status organizacji na gruncie KSC/NIS2, istniejące polityki, procedury i rejestry oraz największe luki w dowodach działania. Wskażemy, czy właściwym krokiem jest audyt zerowy, uzupełnienie dokumentacji, pełne wdrożenie albo objęcie SZBI stałym nadzorem.