Polityka Bezpieczeństwa Informacji w 2026 r.: dokument kierownictwa, który ma sterować systemem

Czym jest polityka, a czym nie jest

To rozróżnienie chroni przed częstym błędem: tworzeniem jednego dokumentu po to, aby "spełnić KRI, KSC, NIS2, RODO i ISO". Te reżimy mają różny zakres i charakter prawny. Jedna dobrze zaprojektowana polityka może być wspólnym elementem systemu zarządzania, ale zgodność trzeba wykazywać wobec każdego właściwego kryterium osobno.

W języku bezpieczeństwa słowo "polityka" bywa używane zarówno dla deklaracji kierownictwa, jak i technicznego ustawienia systemu. W SZBI polityka nadrzędna powinna pozostać dokumentem strategicznym. Określa kierunek, zasady, odpowiedzialność i ramy dla bardziej szczegółowych dokumentów.

Nie powinna zawierać wszystkich ustawień technicznych. Parametry TLS, długości retencji konkretnego logu, konfiguracja EDR, reguły zapory czy procedura odtworzenia serwera zmieniają się częściej i należą do standardów, procedur, instrukcji oraz zapisów operacyjnych.

Nie jest też regulaminem pracownika, planem projektu, instrukcją reagowania na incydent ani klauzulą informacyjną z art. 13 lub 14 RODO. Te dokumenty mogą być powiązane z polityką, ale mają inne zadania i inny cykl życia.

Najważniejsza cecha polityki jest prostsza: po jej przeczytaniu powinno być wiadomo, jakie zasady organizacja przyjęła i kto odpowiada za ich realizację. Zdanie "organizacja zapewnia bezpieczeństwo informacji" bez wskazania mechanizmu odpowiedzialności nie daje takiej odpowiedzi.

Miejsce polityki w dokumentacji

Nie istnieje jedna prawnie obowiązkowa liczba poziomów dokumentacji. Praktyczny układ może jednak oddzielać dokumenty według stabilności i szczegółowości:

• polityka nadrzędna - kierunek, cele, zasady i odpowiedzialność;
• polityki lub standardy tematyczne - na przykład kontrola dostępu, kryptografia, kopie zapasowe, dostawcy, praca zdalna, zarządzanie podatnościami;
• procedury - sposób wykonywania procesu i role operacyjne;
• instrukcje techniczne - konkretne kroki dla systemu lub technologii;
• rejestry i zapisy - dowody, że procedury rzeczywiście wykonano.

Taki podział ogranicza problem ciągłego zatwierdzania przez kierownictwo drobnych zmian technicznych. Jeśli instrukcja konfiguracji konkretnej usługi zostanie zmieniona po aktualizacji produktu, nie musi to automatycznie oznaczać zmiany polityki wysokiego poziomu.

Polityka powinna być stabilna, ale nie martwa. Przegląda się ją w ustalonych odstępach oraz wtedy, gdy zmienia się kontekst organizacji, prawo, model ryzyka, struktura odpowiedzialności albo podstawowe zasady systemu. ISO/IEC 27001 nie ustanawia uniwersalnego obowiązku zmiany polityki raz w roku. Organizacja powinna natomiast zapewnić jej ciągłą adekwatność i nadzór jako udokumentowanej informacji.^[2]

Co wymaga ISO/IEC 27001:2022

Klauzula 5.2 ISO/IEC 27001 wymaga, aby najwyższe kierownictwo ustanowiło politykę bezpieczeństwa informacji odpowiednią do celu organizacji. Polityka ma zawierać cele bezpieczeństwa informacji albo tworzyć ramy do ich ustalania, zobowiązanie do spełniania mających zastosowanie wymagań oraz do ciągłego doskonalenia SZBI. Powinna być dostępna jako udokumentowana informacja, zakomunikowana w organizacji oraz udostępniana stronom zainteresowanym w odpowiednim zakresie.^[2]

Norma nie wymaga jednego wzoru, konkretnej liczby stron ani konkretnej formy podpisu. Najwyższe kierownictwo musi jednak rzeczywiście ustanowić politykę i ponosić odpowiedzialność za kierunek SZBI. Podpis, uchwała, zarządzenie albo inny zatwierdzony mechanizm może być dowodem tego działania, zależnie od ustroju organizacji.

Załącznik A i ISO/IEC 27002 rozwijają obszary zabezpieczeń, lecz nie oznacza to, że wszystkie 93 zabezpieczenia trzeba przepisać do polityki nadrzędnej. Ich stosowalność ocenia się w kontekście ryzyka i wymagań SZBI, a decyzje dokumentuje między innymi w Deklaracji Stosowania.^[2][6]

Co wynika z KRI

Rozporządzenie KRI z 21 maja 2024 r. wymaga od kierownictwa objętych podmiotów ustanowienia, wdrożenia, eksploatowania, monitorowania, przeglądania, utrzymywania i doskonalenia systemu zarządzania bezpieczeństwem informacji. § 19 ust. 2 wymienia czternaście grup wymagań, w tym aktualizowanie regulacji wewnętrznych, analizę ryzyka, inwentaryzację, zarządzanie uprawnieniami, szkolenia, ochronę przed podatnościami, obsługę incydentów, kontrole zgodności i coroczny audyt wewnętrzny.^[1]

KRI nie mówi jednak, że wszystkie te wymagania mają znaleźć się w jednym dokumencie nazwanym PBI. Audyt KRI powinien sprawdzić cały system regulacji, odpowiedzialności i zapisów. Polityka może stanowić jego najwyższy poziom, a wymagania szczegółowe mogą być rozłożone na procedury i standardy.

§ 19 ust. 3 przewiduje mechanizm uznania wymagań za spełnione, jeżeli SZBI opracowano na podstawie właściwych Polskich Norm, w tym PN-ISO/IEC 27001, a ustanawianie zabezpieczeń i zarządzanie ryzykiem realizuje się na podstawie powiązanych norm.^[1] Nie jest to nakaz certyfikacji.

Na 29 sierpnia 2026 r. rozporządzenie KRI z 2024 r. pozostaje obowiązujące. Równolegle trwa projekt RD313 nowego rozporządzenia.^[7] Aktualnego dokumentu organizacji nie należy więc pisać tak, jakby projektowane wymagania były już prawem.

KSC i NIS2: polityka jako część zarządzania ryzykiem

Po nowelizacji obowiązującej od 3 kwietnia 2026 r. KSC wymaga od podmiotów kluczowych i ważnych wdrożenia SZBI w systemach wykorzystywanych w procesach wpływających na świadczenie usługi oraz systematycznego zarządzania ryzykiem. Art. 8 obejmuje między innymi polityki bezpieczeństwa, bezpieczeństwo nabywania i utrzymania systemów, łańcuch dostaw, ciągłość działania, monitorowanie, ocenę skuteczności, edukację, kryptografię oraz zarządzanie aktywami, podatnościami i incydentami.^[3]

Dyrektywa NIS2 w art. 21 ust. 2 wymienia polityki analizy ryzyka i bezpieczeństwa systemów informacyjnych jako jedną z kategorii środków.^[4] W polskiej organizacji podstawowym kryterium zgodności jest jednak aktualna KSC, a NIS2 służy do rozumienia wspólnego kontekstu unijnego.

Kierownictwo ma w tym systemie realną rolę: powinno zatwierdzać właściwe środki i nadzorować ich wdrożenie. Nie należy jednak utożsamiać ustawowego zatwierdzania środków zarządzania ryzykiem z wymogiem podpisania konkretnego pliku pod nazwą PBI. Forma dokumentacyjna musi odpowiadać strukturze zarządczej i pozwalać wykazać podjęte decyzje, co jest jednym z badanych obszarów w audycie KSC/NIS2.

RODO: polityki, ale nie zawsze dokument o nazwie PBI

Art. 24 ust. 2 RODO stanowi, że jeżeli jest to proporcjonalne w stosunku do czynności przetwarzania, środki administratora obejmują wdrożenie odpowiednich polityk ochrony danych. Art. 32 wymaga odpowiednich środków bezpieczeństwa opartych na ryzyku, a art. 25 ochrony danych w fazie projektowania i domyślnej ochrony danych.^[5]

RODO nie nakazuje jednak każdemu administratorowi dokumentu "Polityka Bezpieczeństwa Informacji" w określonym wzorze. Organizacja może łączyć część zasad prywatności z polityką bezpieczeństwa albo utrzymywać odrębne dokumenty. Ważne jest, aby nie pomieszać odpowiedzialności: polityka bezpieczeństwa informacji nie zastępuje rejestru czynności przetwarzania, klauzul informacyjnych, oceny skutków, umów powierzenia ani procedury naruszeń, co bywa przedmiotem ustaleń w audycie RODO.

Co powinno znaleźć się w dobrej polityce

Zakres należy dopasować do organizacji. W praktyce warto rozważyć następujące elementy.

Cel i zakres. Dokument powinien jasno wskazać, czego dotyczy: jednostek, lokalizacji, systemów, rodzajów informacji i osób. Zbyt ogólny zakres sprawia, że później nie da się ustalić, czy zasada dotyczy konkretnego środowiska.

Zobowiązanie kierownictwa. Powinno wynikać z niego, że bezpieczeństwo informacji jest elementem zarządzania organizacją, a nie samodzielnym projektem działu IT.

Cele i zasady. Przykładem są minimalne uprawnienia, rozdzielenie obowiązków, uwzględnianie bezpieczeństwa przy zmianach, ochrona wielowarstwowa, zarządzanie ryzykiem i wymaganie udokumentowanych wyjątków. Zasady powinny być na tyle jednoznaczne, aby dało się ocenić ich przestrzeganie.

Role i odpowiedzialności. Dokument powinien wyjaśnić role kierownictwa, właścicieli informacji i systemów, zespołu bezpieczeństwa, administratorów, użytkowników, inspektora ochrony danych tam, gdzie ma zastosowanie, oraz dostawców. Sformułowanie "dział IT odpowiada za bezpieczeństwo" jest zwykle zbyt szerokie i błędne.

Klasyfikacja i postępowanie z informacjami. Organizacja powinna określić własne kategorie adekwatne do rzeczywistego sposobu pracy. Nie istnieje uniwersalny prawny obowiązek stosowania trzech albo czterech poziomów.

Odwołania do polityk tematycznych. Polityka może wskazywać, gdzie znajdują się wymagania dotyczące dostępu, kryptografii, kopii zapasowych, dostawców, podatności, incydentów, ciągłości, pracy zdalnej i bezpieczeństwa fizycznego.

Zgłaszanie naruszeń i incydentów. Polityka powinna wskazywać kanał i zasadę szybkiej eskalacji. Szczegółowe terminy prawne i algorytm kwalifikacji lepiej utrzymywać w procedurach reagowania, ponieważ różnią się między KSC, RODO, DORA i innymi reżimami.

Przegląd i nadzór. Trzeba określić właściciela dokumentu, sposób inicjowania przeglądu, zatwierdzania zmian, publikowania obowiązującej wersji oraz wycofywania wersji nieaktualnych.

Klasyfikacja informacji tylko wtedy, gdy prowadzi do działania

Sama tabela "publiczne / wewnętrzne / poufne / ściśle poufne" niczego nie chroni. Dla każdej kategorii powinny istnieć reguły, które da się zastosować: kto może mieć dostęp, czy dopuszczalna jest poczta zewnętrzna, jakie szyfrowanie jest potrzebne, gdzie dane mogą być przechowywane, jak są oznaczane i jak się je usuwa.

Klasyfikację warto budować na skutkach nieuprawnionego ujawnienia, modyfikacji lub utraty dostępności, a nie na intuicji autora dokumentu. W organizacji publicznej trzeba dodatkowo uwzględnić regulacje szczególne dotyczące określonych kategorii informacji. Klasyfikacja wewnętrzna nie zmienia statusu informacji wynikającego z przepisów prawa.

Macierz zgodności: użyteczna, ale nie magiczna

Do polityki lub dokumentacji SZBI warto utrzymywać macierz pokazującą, które dokumenty i procesy wspierają określone wymagania KRI, KSC, RODO, ISO/IEC 27001 lub innych właściwych regulacji. Dzięki temu audyt nie zaczyna się od ręcznego przeszukiwania kilkudziesięciu plików.

Macierz nie powinna jednak sugerować równoważności dokumentów o różnym charakterze. Jedno zabezpieczenie może wspierać kilka wymagań, ale spełnienie klauzuli ISO nie oznacza automatycznie spełnienia przepisu prawa. Każde mapowanie trzeba czytać w granicach jego zakresu, a metodykę takiego badania porządkuje ISO 19011:2026.^[9]

Polityka a praktyka

Najważniejszy audyt polityki polega na sprawdzeniu, czy zasady widoczne w dokumencie pozostawiają ślad w systemach i decyzjach.

• Jeśli polityka mówi o minimalnych uprawnieniach, sprawdź próbę kont uprzywilejowanych.
• Jeśli wymaga zarządzania ryzykiem dostawców, sprawdź umowę i ocenę kluczowej usługi chmurowej.
• Jeśli deklaruje odtwarzanie usług, sprawdź dowód ostatniego testu kopii zapasowej.
• Jeśli zobowiązuje do zgłaszania incydentów, prześledź ostatni incydent od wykrycia do decyzji.
• Jeśli mówi o klasyfikacji, sprawdź rzeczywiste dokumenty i sposób ich udostępniania.

Polityka, której nie da się poddać takim testom, jest prawdopodobnie zbyt ogólna. Kontrole NIK w jednostkach publicznych pokazują, że problemem bywa nie brak dokumentu, lecz brak śladu jego stosowania.^[10] Ocena ryzyka prowadzona zgodnie z ISO/IEC 27005 jest tu naturalnym punktem odniesienia, bo łączy zasadę z decyzją o zabezpieczeniu.^[8]

Najczęstsze błędy

1. Wzór skopiowany z internetu. Rozpoznaje się go po nieistniejących rolach, nieaktualnych przepisach, technologiach, których organizacja nie używa, i ogólnym słowie "Organizacja" pozostawionym w kilku miejscach.
2. Dokument zawierający wszystko. Jeśli polityka opisuje każdą konfigurację, jej aktualizacja staje się tak kosztowna, że nikt jej nie wykonuje.
3. Zasady bez właściciela. Odpowiedzialność musi być przypisana do roli, a rola powinna istnieć w rzeczywistej strukturze.
4. Arbitralna częstotliwość przeglądu przedstawiona jako wymaganie normy. Coroczny przegląd może być rozsądną decyzją organizacji, ale nie należy przypisywać ISO/IEC 27001 nakazu corocznej zmiany treści polityki.
5. Szczegółowe terminy prawne bez procesu aktualizacji. Jeżeli przepis się zmieni, dokument wysokiego poziomu staje się źródłem błędnej instrukcji. Lepiej rozdzielić zasadę natychmiastowej eskalacji od szczegółowej procedury regulacyjnej.
6. Utożsamienie podpisu z wdrożeniem. Podpis dowodzi zatwierdzenia, nie dowodzi działania kontroli.
7. Brak komunikacji. Polityka znajdująca się wyłącznie na dysku osoby odpowiedzialnej za SZBI nie spełnia swojej funkcji organizacyjnej.

Jak wdrożyć politykę

Po zatwierdzeniu trzeba ustalić, które grupy muszą znać całość dokumentu, a które konkretne zasady. Administrator potrzebuje innych informacji niż pracownik działu finansowego. Dostawca zewnętrzny nie musi otrzymywać całej wewnętrznej polityki, ale wymagania, które go dotyczą, powinny znaleźć się w umowie, załączniku bezpieczeństwa albo instrukcji dostępu.

Szkolenie powinno przekładać zasady na decyzje: jak zgłosić incydent, czego nie wysyłać, jak chronić dostęp, gdzie przechowywać dane, kto zatwierdza wyjątek. Sam test wiedzy po przeczytaniu dokumentu nie pokazuje, czy pracownik potrafi wykonać proces.

W 4crypto przy projektowaniu polityki zwykle warto rozpocząć od zakresu SZBI, mapy ryzyka i istniejących procesów, a dopiero potem pisać dokument. Odwrotna kolejność często prowadzi do polityki, która opisuje organizację wyobrażoną zamiast rzeczywistej.

Kiedy politykę zmienić

Zmiana jest potrzebna wtedy, gdy polityka przestaje opisywać aktualny kierunek i zasady. Typowe wyzwalacze to:

• istotna zmiana struktury lub odpowiedzialności;
• wejście w nowy reżim prawny lub istotna zmiana wymagań;
• wdrożenie modelu chmurowego, outsourcingu lub nowej klasy technologii zmieniającej ryzyko;
• poważny incydent ujawniający błędną zasadę;
• wynik audytu lub przeglądu zarządzania;
• zmiana apetytu na ryzyko lub celów bezpieczeństwa.

Przegląd może zakończyć się decyzją "bez zmian". Taki wynik również warto udokumentować. Nie ma natomiast sensu zmieniać daty i numeru wersji tylko po to, aby stworzyć pozór aktualizacji: audytor sprawdzi treść, a nie stopkę.