Politykę bezpieczeństwa informacji pisze się od własnych systemów, ról i decyzji, a nie od pobranego pliku. Gotowy wzór bywa użytecznym szkieletem, ale dokumentem staje się dopiero po podstawieniu realiów jednostki. Problem w tym, że wiele krążących w sieci wzorów opiera się na przepisach, które już nie obowiązują.
Stan prawny na dzień 6 września 2026 r.
- Wzór to szkielet — układ rozdziałów można przenieść, ale treść musi opisywać realia twojej jednostki, nie organizacji, dla której wzór powstał.
- Podstawę prawną sprawdź przed treścią — odwołanie do poprzedniego rozporządzenia KRI z 2012 r., do § 20 albo do rozporządzenia MSWiA z 2004 r. oznacza wzór oparty na uchylonych przepisach.
- Nazwy ról zdradzają wiek wzoru — administrator bezpieczeństwa informacji pochodzi z ustawy z 1997 r., a RODO mówi o inspektorze ochrony danych.
- Na koniec przetestuj zapisy — przeprowadź przez dokument jeden incydent i jedno zwolnienie pracownika; jeśli nie wiadomo, kto działa i w jakim terminie, polityka nie jest gotowa.
Dlaczego przepisana polityka nie broni się przy audycie
Przepisana polityka nie broni się przy audycie, bo audytor porównuje jej zapisy z rzeczywistością jednostki. Sprawdzana jest wykonalność zasad w tej organizacji, a nie zgodność ze wzorcem dokumentu.
RODO stawia ten wymóg wprost. Zgodnie z art. 24 ust. 1 administrator wdraża środki techniczne i organizacyjne, uwzględniając charakter, zakres, kontekst i cele przetwarzania. Przepis każe wziąć pod uwagę także ryzyko naruszenia praw lub wolności osób fizycznych o różnym prawdopodobieństwie i wadze zagrożenia. Kopia cudzego dokumentu nie uwzględnia żadnego z tych elementów, bo powstała dla innej organizacji.
Tak samo działa rozporządzenie Rady Ministrów z 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności, dalej: rozporządzenie KRI. Jego § 19 ust. 1 mówi, że podmiot realizujący zadania publiczne opracowuje i ustanawia, wdraża i eksploatuje, monitoruje i przegląda oraz utrzymuje i doskonali system zarządzania bezpieczeństwem informacji. To opis cyklu działania. Obowiązkiem jest utrzymywanie systemu, nie posiadanie pliku. Pomaga tu wiedza, z jakich elementów składa się system zarządzania bezpieczeństwem informacji.
W projektach, które prowadzimy, najczęściej widzimy dwa objawy tej samej przyczyny: dokument wymienia systemy, których jednostka nigdy nie miała, albo przypisuje zadania rolom, których nikt nie pełni. Wystarczy pytanie, kto ostatnio wykonał opisaną czynność.
Po czym poznać, że wzór pochodzi z nieaktualnego źródła
Wzór rozpoznaje się po odwołaniach do uchylonych przepisów i wycofanych norm oraz po nazwach ról, które zniknęły z porządku prawnego. Wszystkie sześć sygnałów z tabeli sprawdza się w rozdziale z podstawą prawną i w wykazie norm.
| Co widać w dokumencie | Dlaczego to sygnał ostrzegawczy | Co z tym zrobić |
|---|---|---|
| Odwołanie do rozporządzenia MSWiA z 2004 r. lub obowiązek prowadzenia instrukcji zarządzania systemem informatycznym | Rozporządzenie z 29 kwietnia 2004 r. (Dz.U. 2004 nr 100 poz. 1024) obowiązywało do 6 lutego 2019 r. Jego podstawa, ustawa z 1997 r., utraciła moc 25 maja 2018 r., ale część przepisów utrzymano czasowo, więc akt wykonawczy obowiązywał jeszcze przez ponad osiem miesięcy. | Usuń tę podstawę prawną. Zdecyduj osobno, czy podział na politykę i instrukcję jest wygodny, i zapisz go jako własną decyzję. |
| Wyznaczenie administratora bezpieczeństwa informacji (ABI) w opisie ról | Funkcję wprowadzała ustawa z 29 sierpnia 1997 r. o ochronie danych osobowych, która utraciła moc 25 maja 2018 r. RODO posługuje się pojęciem inspektora ochrony danych. | Przejrzyj cały rozdział o rolach. Sprawdź, czy zadania dawnej funkcji ktoś dziś realnie wykonuje. |
| Powołanie na rozporządzenie KRI z 12 kwietnia 2012 r. albo na § 20 | Poprzednie rozporządzenie KRI, z 12 kwietnia 2012 r., utraciło moc 23 maja 2024 r. Zastąpiło je rozporządzenie z 21 maja 2024 r. (Dz.U. 2024 poz. 773), w którym ten przepis ma numer § 19. | Popraw podstawę prawną i numer przepisu, a potem porównaj treść dokumentu z czternastoma punktami § 19 ust. 2. |
| Odwołanie do normy PN-ISO/IEC 24762 | W § 19 ust. 3 rozporządzenia KRI tej normy nie ma. Przepis wymienia PN-ISO/IEC 27001 oraz normy związane, w tym PN-ISO/IEC 27002 i PN-ISO/IEC 27005. | Usuń normę z listy. Jeśli jednostka nadal opiera na niej plany ciągłości działania, opisz to jako własny wybór. |
| Odwołanie do ISO/IEC 27001:2013 albo do 114 zabezpieczeń Załącznika A | ISO/IEC 27001:2022 opublikowano 25 października 2022 r., a Załącznik A ma 93 zabezpieczenia: organizacyjne (37), dotyczące ludzi (8), fizyczne (14), technologiczne (34). IAF MD 26:2023 wyznaczył koniec okresu przejściowego na 31 października 2025 r. | Zaktualizuj odwołanie do wydania z 2022 r. i przemapuj deklarację stosowania na nową strukturę Załącznika A. |
| Norma przywołana z rokiem wydania tam, gdzie przepis roku nie podaje | § 19 ust. 3 wymienia PN-ISO/IEC 27001, 27002 i 27005 bez lat wydania. Polski Komitet Normalizacyjny opublikował 22 sierpnia 2023 r. PN-EN ISO/IEC 27001:2023-08 i wycofał PN-EN ISO/IEC 27001:2017-06. | Przywołuj normy bez roku, tak jak przepis. Numery wydań trzymaj w rejestrze aktualizowanym przez wskazaną osobę. |
Jak napisać politykę na własnych danych
Politykę pisze się od faktów do zapisów: najpierw podstawa prawna i stan faktyczny, potem zasady. Odwrotna kolejność daje dokument oderwany od organizacji.
- Ustal podstawę prawną. Podmiot publiczny opiera się na rozporządzeniu Rady Ministrów z 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności, a administrator danych także na RODO. Podmiot objęty NIS2 uwzględnia dodatkowo ustawę z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252). Zapisz w dokumencie datę ustalenia stanu prawnego.
- Spisz, co jednostka faktycznie ma. Wypisz systemy, zbiory danych, lokalizacje, dostawców usług i osoby z dostępem uprzywilejowanym. Bez tej listy każdy kolejny rozdział opisuje organizację, która nie istnieje.
- Przypisz role do stanowisk z własnego regulaminu. Zamiast nazw ze wzoru użyj stanowisk występujących w strukturze jednostki i sprawdź, czy te osoby mają czas oraz uprawnienia. Przy tym kroku potrzebni są zwykle administrator systemów, kadry, inspektor ochrony danych i osoba z kierownictwa, bo każde z nich zna inny fragment stanu faktycznego. Pomaga w tym lista kontrolna czternastu punktów § 19 stosowana w audycie KRI.
- Opisz decyzje, które już zapadły. Polityka utrwala reguły, które w jednostce faktycznie obowiązują. Jeżeli kopie zapasowe powstają raz na dobę, zapisz raz na dobę. Decyzje jeszcze niepodjęte zostaw na liście zadań.
- Rozdziel poziomy dokumentacji. W polityce zostają zasady i odpowiedzialności zmieniające się rzadko, a parametry techniczne i szczegółowe kroki schodzą do procedur niższego rzędu. Dzięki temu zmiana jednego systemu nie wymusza zatwierdzania polityki od nowa.
- Zaplanuj przegląd i wskaż wykonawcę. Zapisz, jak często dokument jest przeglądany, kto to robi i jakie zdarzenia wymuszają przegląd poza terminem. Należą do nich zmiana przepisu, zmiana dostawcy, incydent i wdrożenie nowego systemu.
- Sprawdź dokument na przykładzie. Przeprowadź przez zapisy dwa scenariusze: incydent bezpieczeństwa oraz zwolnienie pracownika z dostępem do systemów. Jeżeli po każdym kroku wiadomo, kto działa, w jakim terminie i co odnotowuje, polityka jest wykonalna.
Co można wziąć z gotowego wzoru, a czego nie
Z gotowego wzoru można przenieść formę, nie treść. Struktura dokumentu, nazewnictwo rozdziałów i lista zagadnień dają się przenieść, bo wynikają z przepisów i norm wspólnych dla wszystkich organizacji.
Przenieść nie da się niczego, co opisuje konkretną jednostkę: zakresu, ról, systemów, progów decyzyjnych ani terminów. Te elementy powstają z inwentaryzacji i decyzji kierownictwa, więc przepisane z cudzego dokumentu stają się deklaracją bez pokrycia. Jako punkt wyjścia dla układu treści pomocny jest wzór struktury polityki bezpieczeństwa informacji w dwunastu rozdziałach.
- Do wzięcia ze wzoru: układ rozdziałów, słownik pojęć i puste szablony rejestrów.
- Zakres podmiotowy i przedmiotowy wraz z wykazem systemów oraz dostawców powstaje z inwentaryzacji.
- Podział ról musi być powiązany z regulaminem organizacyjnym jednostki.
- Progi zgłaszania incydentów, terminy przeglądów i zasady nadawania uprawnień to decyzje kierownictwa.
Najczęstsze pytania o pisanie polityki bezpieczeństwa informacji
Poniżej pięć pytań, które wracają w rozmowach o dokumentacji bezpieczeństwa informacji w jednostkach publicznych i firmach.
Czy można korzystać z gotowego wzoru polityki bezpieczeństwa informacji?
Tak, ale wyłącznie jako szkieletu. RODO w art. 24 ust. 1 wymaga środków dobranych z uwzględnieniem charakteru, zakresu, kontekstu i celów przetwarzania oraz ryzyka naruszenia praw lub wolności osób fizycznych. Wzór tego nie zrobi za jednostkę. Weź z niego układ rozdziałów, a treść napisz z własnych systemów, ról i decyzji.
Czy polityka bezpieczeństwa informacji musi być jednym dokumentem?
Nie, przepisy nie narzucają jednej formy. Rozporządzenie KRI mówi o systemie zarządzania bezpieczeństwem informacji, który podmiot opracowuje, wdraża, eksploatuje, monitoruje, przegląda, utrzymuje i doskonali. RODO w art. 24 ust. 2 mówi o politykach ochrony danych w liczbie mnogiej. W praktyce sprawdza się dokument nadrzędny i zestaw procedur szczegółowych.
Kto podpisuje politykę bezpieczeństwa informacji?
Przepis nie wskazuje osoby ani nazwy stanowiska. Rozporządzenie KRI nakłada obowiązek opracowania, ustanowienia, wdrożenia i doskonalenia systemu zarządzania bezpieczeństwem informacji na podmiot realizujący zadania publiczne. Odpowiedzialność spoczywa więc na jednostce jako całości, a w praktyce dokument zatwierdza jej kierownik. Podpis przesądza, że zapisy są decyzją organizacji, a nie propozycją działu IT.
Jak często aktualizować politykę bezpieczeństwa informacji?
Nie ma sztywnego terminu. Opisany wyżej cykl z § 19 ust. 1 rozporządzenia KRI oznacza dwa tryby: przegląd cykliczny w terminie zapisanym w dokumencie oraz przegląd po zdarzeniu. Zdarzeniem wymuszającym przegląd jest zmiana przepisu. Ostatnie dwa takie zdarzenia to utrata mocy poprzedniego rozporządzenia KRI 23 maja 2024 r. i wejście w życie przepisów wdrażających NIS2 3 kwietnia 2026 r.
Czy polityka według ISO/IEC 27001 wystarczy jednostce publicznej?
Rozporządzenie KRI przewiduje domniemanie zgodności. Wymagania uznaje się za spełnione, jeżeli system zarządzania bezpieczeństwem informacji opracowano na podstawie Polskiej Normy PN-ISO/IEC 27001. Ustanawianie zabezpieczeń, zarządzanie ryzykiem i audytowanie muszą się przy tym opierać na normach związanych, w tym PN-ISO/IEC 27002 oraz PN-ISO/IEC 27005. Sama nazwa normy w dokumencie nie wystarczy.
Jak Pentestica może pomóc
Pomagamy napisać politykę od strony faktów: inwentaryzujemy systemy i dane, weryfikujemy podstawę prawną, a przy audycie KRI opartym na § 19 sprawdzamy, czy zapisy da się wykonać. Mamy ponad 10 lat doświadczenia i setki zrealizowanych projektów.
Nakład pracy zależy od czterech czynników: liczbę systemów i lokalizacji, stan istniejącej dokumentacji, konieczność przeprowadzenia inwentaryzacji od zera oraz reżim prawny, któremu podlega jednostka. Jednostka objęta wyłącznie rozporządzeniem KRI i podmiot objęty równocześnie przepisami wdrażającymi NIS2 to dwa różne zakresy. Nie podajemy tu żadnej liczby, bo bez tych czterech danych byłaby zgadywaniem. Zakres ustala się, odpowiadając na pytania w konfiguratorze zakresu usług, a informacje o wycenie znajdują się w sekcji cennika na stronie audytu bezpieczeństwa IT.
Źródła
- Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. 2024 poz. 773) — tekst § 19.
- Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności — metryka aktu, data utraty mocy.
- Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych — akt archiwalny; metryka podaje okres obowiązywania do 6 lutego 2019 r. oraz akt uchylający, ustawę z 14 grudnia 2018 r. (Dz.U. 2019 poz. 125).
- Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych — metryka aktu, data utraty mocy.
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) — art. 24.
- ISO/IEC 27001:2022 — metryka normy.
- BSI, zestawienie zmian w Załączniku A ISO/IEC 27001:2022 — podział 93 zabezpieczeń.
- IAF MD 26:2023 w serwisie Polskiego Centrum Akredytacji — koniec okresu przejściowego.
- Polski Komitet Normalizacyjny, komunikat o PN-EN ISO/IEC 27001:2023-08 — publikacja i wycofanie normy.
- Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252) — metryka aktu w rejestrze Urzędu Komunikacji Elektronicznej, z datą wejścia w życie.
- Tekst ustawy z dnia 23 stycznia 2026 r. (Dz.U. 2026 poz. 252) w repozytorium ELI Sejmu RP — przypis o wdrożeniu dyrektywy (UE) 2022/2555 (NIS2).
Redakcja Pentestica to zespół pentesterów i konsultantów bezpieczeństwa, którzy na co dzień wykonują testy penetracyjne, testy TLPT wymagane przez DORA, red teaming i audyty bezpieczeństwa IT, a także prowadzą wdrożenia zgodności z NIS2, DORA i MiCA. Teksty na tym blogu piszemy z tej praktyki, a nie z opracowań. Każde twierdzenie o przepisie, terminie albo karze opieramy na źródle pierwotnym: dzienniku ustaw, tekście dyrektywy, komunikacie organu nadzoru. Jeśli czegoś nie da się potwierdzić, piszemy o tym wprost, zamiast powtarzać liczbę krążącą po branżowych portalach.