Załącznik nr 4 do ustawy o KSC: wymagania SZBI dla podmiotu ważnego będącego podmiotem publicznym

Załącznik nr 4 do ustawy o krajowym systemie cyberbezpieczeństwa określa szczególny model systemu zarządzania bezpieczeństwem informacji, dalej „SZBI”, stosowany przez podmiot ważny będący podmiotem publicznym.

Model ten jest mniej rozbudowany niż pełny SZBI oparty na systematycznym szacowaniu ryzyka, wymagany na podstawie art. 8 ust. 1 ustawy o KSC. Nie jest jednak rozwiązaniem symbolicznym. Podmiot musi wdrożyć konkretne środki organizacyjne i techniczne, przeglądać ich aktualność oraz dokumentować rzeczywistą realizację działań.

Okres przejściowy

Podmioty, które spełniały przesłanki uznania ich za podmiot kluczowy albo podmiot ważny w dniu wejścia nowelizacji w życie, czyli 3 kwietnia 2026 r., realizują obowiązki rozdziału 3 w terminie 12 miesięcy od tego dnia — co do zasady do 3 kwietnia 2027 r.

Podmiot, który zacznie spełniać przesłanki później, realizuje obowiązki rozdziału 3 zasadniczo w terminie 12 miesięcy od dnia spełnienia przesłanek.

Kto stosuje załącznik nr 4?

Podstawową grupą adresatów są podmioty ważne będące podmiotami publicznymi. W odniesieniu do samorządowych podmiotów publicznych status ten wynika z art. 5 ust. 2 pkt 8 ustawy o KSC.

Podmiotem ważnym może być podmiot publiczny, który:

• nie jest podmiotem kluczowym;
• jest samorządową jednostką budżetową, samorządowym zakładem budżetowym, samorządową instytucją kultury albo spółką wykonującą zadania o charakterze użyteczności publicznej;
• realizuje zadanie publiczne z wykorzystaniem systemów informacyjnych.

Sama forma organizacyjna nie wystarcza. Wszystkie przesłanki muszą zostać spełnione łącznie.

Art. 8 ust. 3 obejmuje również wskazane w nim podmioty systemu szkolnictwa wyższego i nauki, o ile nie są organizacjami badawczymi — w zakresie, w jakim realizują zadania publiczne z wykorzystaniem systemów informacyjnych. Nie chodzi więc wyłącznie o uczelnie publiczne, lecz o konkretne kategorie podmiotów wymienione w art. 7 ust. 1 pkt 1–4 i 6–7 ustawy – Prawo o szkolnictwie wyższym i nauce.

Załącznika nr 4 nie stosuje podmiot kluczowy. Jeżeli jednostka spełnia przesłanki statusu kluczowego, wdraża pełny model SZBI z art. 8 ust. 1.

Jak zbudowany jest załącznik nr 4?

Załącznik składa się z czterech części:

Część I określa ustawowe minimum. Część II wskazuje przykładowe dodatkowe środki, które mogą uzupełniać system. Części III i IV nakładają obowiązek przeglądania SZBI oraz dokumentowania wykonanych działań.

Część I – obowiązkowe minimum SZBI

Załącznik wymienia 18 punktów obowiązkowych. Poniżej zostały one połączone w 10 praktycznych obszarów wdrożeniowych. Nie jest to zmiana treści wymagań, lecz ich tematyczne uporządkowanie.

1. Inwentaryzacja produktów, usług i procesów ICT

Podmiot musi prowadzić inwentaryzację:

• produktów ICT;
• usług ICT;
• procesów ICT służących do przetwarzania informacji.

Nie jest to wyłącznie spis komputerów i serwerów. Inwentaryzacja powinna obejmować również oprogramowanie, systemy operacyjne, urządzenia sieciowe, usługi chmurowe, pocztę elektroniczną, hosting, systemy SaaS oraz procesy wykorzystujące te rozwiązania.

W praktyce warto wskazać dla każdego elementu:

Powyższy zakres jest rekomendacją praktyczną. Załącznik nie narzuca konkretnego formularza ani szczegółowego zakresu danych w rejestrze.

2. Kontrola wersji i cyklu życia

Załącznik posługuje się określeniem „podstawowe wersje” produktów i usług ICT. W praktyce oznacza to konieczność ustalenia, jakie zasadnicze wersje rozwiązań są rzeczywiście używane, oraz objęcia ich kontrolą.

Podmiot powinien:

• kontrolować używane wersje produktów i usług;
• w miarę możliwości kontrolować instalowanie oprogramowania na urządzeniach, w tym mobilnych;
• monitorować częstotliwość publikowania nowych wersji;
• sprawdzać źródła dystrybucji;
• monitorować cykl życia produktów;
• stosować wersje stabilne, które nie są obciążone znanymi krytycznymi podatnościami albo nie powodują istotnego negatywnego wpływu na bezpieczeństwo.

Jednostka powinna wiedzieć:

• jaka wersja jest zainstalowana;
• czy producent nadal ją wspiera;
• kto może instalować oprogramowanie;
• czy występują podatności krytyczne;
• kiedy i dlaczego aktualizacja została wdrożona albo odroczona.

Dowodami realizacji mogą być raporty inwentaryzacyjne, harmonogramy aktualizacji, rejestry podatności, raporty instalacji poprawek oraz decyzje o czasowym odroczeniu aktualizacji.

3. Ochrona informacji i infrastruktury

Podmiot musi chronić przetwarzane informacje przed kradzieżą, nieuprawnionym dostępem, uszkodzeniem i zakłóceniami.

W zależności od sposobu przetwarzania informacji załącznik przewiduje:

• ochronę fizyczną miejsc przetwarzania;
• zabezpieczenia programowe lub sprzętowe urządzeń;
• w przypadku korzystania z chmury obliczeniowej albo centrum przetwarzania danych — udokumentowanie mechanizmów ochrony zapewnianych przez dostawcę.

Nie oznacza to, że każda jednostka musi stosować identyczny zestaw tych rozwiązań. Dobór zabezpieczeń zależy między innymi od tego, czy informacje są przetwarzane lokalnie, na urządzeniach mobilnych, w zewnętrznym centrum danych czy w chmurze.

W przypadku systemu chmurowego nie wystarczy ogólne stwierdzenie, że bezpieczeństwo zapewnia dostawca. Jednostka powinna znać podział odpowiedzialności oraz dysponować dokumentacją potwierdzającą zastosowane mechanizmy ochrony.

W praktyce należy ustalić między innymi:

• gdzie są przetwarzane dane;
• kto odpowiada za zabezpieczenie kont i dostępów;
• jak wykonywane są kopie zapasowe;
• jak zgłaszane są incydenty;
• jak odzyskać dane po zakończeniu umowy;
• jakie informacje i raporty bezpieczeństwa udostępnia dostawca.

4. Zarządzanie dostępem

Załącznik wymaga:

• dopuszczania do informacji wyłącznie osób uprawnionych;
• zabezpieczenia systemów przed nieautoryzowanym dostępem;
• stosowania zasady minimalnych uprawnień;
• bezzwłocznego cofania uprawnień, gdy ustała podstawa dostępu;
• zawieszania uprawnień w przypadku niewykonywania obowiązków przez co najmniej miesiąc;
• zmiany zakresu uprawnień po zmianie zadań.

Proces musi być powiązany z informacjami kadrowymi i organizacyjnymi. Dział IT powinien odpowiednio wcześnie otrzymywać informacje o:

• zatrudnieniu pracownika;
• zmianie stanowiska lub obowiązków;
• dłuższej nieobecności;
• rozwiązaniu stosunku pracy;
• zakończeniu współpracy z wykonawcą.

Samo posiadanie procedury nadawania kont nie wystarcza. Potrzebne są dowody zatwierdzania dostępów, ich modyfikowania, zawieszania i odbierania.

5. Bezpieczna praca mobilna i zdalna

Podmiot ustanawia podstawowe zasady gwarantujące bezpieczną pracę podczas przetwarzania mobilnego i pracy na odległość.

W praktyce zasady warto odnieść do:

• urządzeń dopuszczonych do pracy;
• korzystania ze sprzętu prywatnego;
• dostępu zdalnego;
• przechowywania dokumentów poza siedzibą;
• zabezpieczenia urządzeń mobilnych;
• zgłaszania utraty albo kradzieży sprzętu;
• korzystania z publicznych sieci;
• ochrony ekranu i miejsca pracy;
• usuwania danych po zakończeniu korzystania z urządzenia.

Ustawa nie narzuca jednej technologii. Zabezpieczenia muszą jednak odpowiadać rzeczywistemu modelowi pracy jednostki.

6. Bezpieczeństwo poczty elektronicznej

Załącznik wymaga kontrolowania usług poczty elektronicznej wykorzystujących mechanizmy określone w art. 24 ust. 1 ustawy o zwalczaniu nadużyć w komunikacji elektronicznej, czyli:

• SPF;
• DKIM;
• DMARC.

W praktyce warto:

• zinwentaryzować domeny używane do wysyłania poczty;
• sprawdzić poprawność rekordów SPF;
• potwierdzić podpisywanie wiadomości DKIM;
• sprawdzić politykę DMARC;
• analizować raporty DMARC;
• ponawiać kontrolę po zmianie dostawcy albo konfiguracji.

Zakup usługi pocztowej nie zastępuje okresowej kontroli jej zabezpieczeń.

7. Kopie zapasowe i odtwarzanie danych

Podmiot musi:

• wykonywać kopie zapasowe;
• odseparować je logicznie i fizycznie od danych produkcyjnych;
• testować kompletność kopii;
• testować możliwość odtworzenia danych.

Nie oznacza to automatycznie obowiązku przechowywania kopii w innym budynku. Istotne jest, aby kopia nie była narażona na te same zagrożenia co środowisko produkcyjne. Materiały Ministerstwa Cyfryzacji potwierdzają, że sposób separacji należy oceniać przez pryzmat celu zabezpieczenia.

Za bezpieczną kopię trudno uznać:

• dane przechowywane wyłącznie na tym samym serwerze;
• kopię dostępną przez to samo konto administracyjne;
• synchronizację automatycznie powielającą usunięcie lub zaszyfrowanie danych;
• nośnik stale podłączony do środowiska produkcyjnego;
• kopię, której nigdy nie próbowano odtworzyć.

Dowodem realizacji obowiązku powinny być nie tylko logi wykonania kopii, lecz także protokoły testów odtworzeniowych.

8. Procedury awaryjne i incydentowe

Załącznik wymaga:

• przygotowania i testowania procedury na wypadek awarii lub incydentu;
• określenia procedur i zasad działania w przypadku cyberzagrożenia albo incydentu.

Procedura powinna w praktyce określać:

• sposób zgłaszania zdarzeń;
• osoby dokonujące wstępnej oceny;
• zasady eskalacji;
• sposób zabezpieczania dowodów;
• działania ograniczające skutki;
• komunikację z kierownictwem i użytkownikami;
• zasady klasyfikowania incydentu;
• tryb zgłoszenia do właściwego CSIRT;
• dokumentowanie obsługi;
• analizę przyczyn i działania naprawcze.

Załącznik nr 4 nie zawiera pełnego katalogu obowiązków raportowych. Wynikają one z art. 11–12c ustawy.

Podmiot ważny będący podmiotem publicznym:

• zgłasza incydent poważny niezwłocznie, nie później niż w ciągu 72 godzin od jego wykrycia;
• nie przekazuje wczesnego ostrzeżenia w ciągu 24 godzin;
• nie przekazuje sprawozdania okresowego;
• nie przekazuje sprawozdania z postępu obsługi;
• nie przekazuje sprawozdania końcowego.

Wyłączenia te wynikają z art. 12c ustawy.

Podmiot nadal musi informować użytkowników o poważnym cyberzagrożeniu oraz o incydencie poważnym, jeżeli wpływa on niekorzystnie na świadczenie usług.

9. Oprogramowanie antywirusowe

Załącznik wymaga stosowania oprogramowania antywirusowego.

Obowiązek nie sprowadza się do zakupu licencji. Jednostka powinna ustalić:

• które urządzenia są chronione;
• czy zabezpieczenie jest aktywne;
• czy aktualizacje są instalowane;
• kto otrzymuje alerty;
• jak reaguje się na wykryte zagrożenia;
• czy użytkownik może samodzielnie wyłączyć ochronę.

W większym środowisku zasadne jest centralne zarządzanie i raportowanie. Załącznik nie narzuca jednak konkretnego produktu.

10. Cyberhigiena i szkolenia

Podmiot musi zapewnić:

• stosowanie zasad cyberhigieny przez pracowników korzystających z systemów, w tym przez kierownika;
• szkolenie osób zaangażowanych w przetwarzanie informacji.

Szkolenia mają obejmować w szczególności rodzaje cyberzagrożeń, podstawowe zasady cyberhigieny, reagowanie na incydenty oraz skutki naruszania zasad bezpieczeństwa.

Cyberhigiena obejmuje codzienne zachowania, takie jak:

• ochrona danych uwierzytelniających;
• rozpoznawanie prób phishingu;
• bezpieczne korzystanie z urządzeń;
• nieodraczanie aktualizacji i umożliwianie ich instalowania zgodnie z zasadami jednostki;
• blokowanie stanowiska;
• zgłaszanie podejrzanych zdarzeń;
• przestrzeganie zasad dostępu.

Szkolenia powinny być dostosowane do roli. Innego zakresu potrzebuje użytkownik, innego administrator, a innego kierownik odpowiadający za decyzje organizacyjne i finansowe.

Część II – środki dodatkowe

Część II wskazuje przykładowe dodatkowe środki, które mogą uzupełniać SZBI. Nie są one automatycznie obowiązkowe dla każdego podmiotu.

Dobrą praktyką wdrożeniową jest odrębne rozważenie każdego środka z części II i udokumentowanie najważniejszych decyzji. Załącznik nie ustanawia jednak wprost obowiązku sporządzania formalnej oceny każdego punktu.

Materiały Ministerstwa Cyfryzacji wskazują, że wdrożenie części II należy rozważać z uwzględnieniem potrzeb bezpieczeństwa oraz możliwości organizacyjnych, finansowych i osobowych podmiotu. Materiały te mają charakter pomocniczy i nie są źródłem prawa.

Chmura i generatywna sztuczna inteligencja

Część II wskazuje zasady korzystania z:

• ogólnodostępnych usług chmurowych;
• ogólnodostępnych dużych generatywnych modeli sztucznej inteligencji.

W praktyce regulacja może obejmować:

• katalog dopuszczonych usług;
• zasady korzystania z kont służbowych i prywatnych;
• rodzaje informacji, których nie wolno przesyłać;
• zasady dotyczące danych osobowych i informacji chronionych;
• akceptowanie regulaminów i zawieranie umów;
• usuwanie danych;
• wykorzystywanie danych przez dostawcę;
• obowiązek weryfikowania odpowiedzi generowanych przez AI;
• odpowiedzialność za ostateczną treść dokumentu.

Jest to rekomendowany zakres polityki, a nie literalne rozwinięcie załącznika.

Część III – przegląd SZBI

Podmiot ważny będący podmiotem publicznym dokonuje przeglądu SZBI:

1. co najmniej raz w roku;
2. bezzwłocznie po wydaniu dotyczącej go rekomendacji Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa;
3. bezzwłocznie po wystąpieniu okoliczności mogących wpłynąć na ryzyko incydentu poważnego i wymagających ponownego wykonania działań albo zmiany systemu.

Przeglądu nie należy utożsamiać z okresowym audytem bezpieczeństwa przeprowadzanym co najmniej raz na trzy lata. Ten automatyczny obowiązek dotyczy podmiotu kluczowego.

Organ właściwy do spraw cyberbezpieczeństwa może jednak, na podstawie art. 15 ust. 1b, nakazać podmiotowi ważnemu przeprowadzenie zewnętrznego audytu w przypadku wystąpienia incydentu poważnego albo innego naruszenia przepisów ustawy przez ten podmiot. W decyzji organ określa również termin przekazania kopii raportu oraz rodzaj podmiotów uprawnionych do przeprowadzenia audytu.

W praktyce warto, aby coroczny lub zdarzeniowy przegląd SZBI obejmował:

• aktualność inwentaryzacji;
• wersje i cykl życia produktów;
• stan uprawnień;
• kopie zapasowe i testy odtworzenia;
• incydenty oraz podatności;
• zmiany systemów i dostawców;
• wykonanie szkoleń;
• stan działań naprawczych;
• zasadność wdrożenia środków dodatkowych.

Efektem przeglądu powinny być ustalenia, decyzje, zadania, terminy i osoby odpowiedzialne. Sama zmiana daty lub numeru wersji dokumentu nie stanowi rzeczywistego przeglądu.

Część IV – dokumentowanie realizacji

Podmiot musi dokumentować realizację działań wskazanych w SZBI.

Oznacza to konieczność połączenia dwóch rodzajów dokumentacji:

• normatywnej — polityk, procedur, regulaminów i instrukcji;
• operacyjnej — zapisów potwierdzających, że działania zostały wykonane.

Procedura bez dowodów operacyjnych może nie wystarczyć do wykazania rzeczywistego wykonania obowiązku.

Ustawa określa również zasady nadzoru nad dokumentacją, jej przechowywania oraz protokolarnego brakowania. Do podmiotów podlegających ustawie o narodowym zasobie archiwalnym i archiwach stosuje się właściwe przepisy archiwalne.

Czy konieczna jest analiza ryzyka?

Podmiot stosujący art. 8 ust. 3 nie ma obowiązku wdrożenia pełnego systematycznego szacowania ryzyka określonego w art. 8 ust. 1.

Rzetelne wdrożenie załącznika nr 4 wymaga jednak w praktyce rozpoznania:

• chronionych systemów;
• istotnych zagrożeń i podatności;
• możliwych skutków awarii;
• braków w zabezpieczeniach;
• potrzeby zastosowania środków z części II.

Nie musi to przyjmować formy pełnego systematycznego szacowania ryzyka właściwego dla podmiotów stosujących art. 8 ust. 1. Bez podstawowej oceny zagrożeń trudno jednak dobrać zabezpieczenia adekwatne do konkretnej jednostki.

Niezależnie od KSC obowiązek podejścia opartego na ryzyku może wynikać także z innych regulacji, między innymi z przepisów o ochronie danych osobowych.

Załącznik nr 4 nie wyczerpuje wszystkich obowiązków

Załącznik określa model SZBI, ale nie stanowi kompletnego katalogu obowiązków podmiotu ważnego będącego podmiotem publicznym.

Poza nim pozostają między innymi:

• odpowiedzialność kierownika;
• coroczne szkolenie kierownika oraz osoby, której powierzono jego obowiązki w zakresie cyberbezpieczeństwa;
• wyznaczenie osoby albo osób kontaktowych;
• weryfikacja niekaralności osób wykonujących zadania z art. 8 lub art. 11;
• korzystanie z systemu S46;
• obsługa i zgłaszanie incydentów;
• informowanie użytkowników;
• współpraca z właściwym CSIRT;
• ogólne wymagania dotyczące dokumentacji bezpieczeństwa.

Jak rozpocząć wdrożenie?

Najpierw należy potwierdzić kwalifikację podmiotu i wykluczyć status podmiotu kluczowego wynikający z innego sektora.

Następnie trzeba:

1. określić zadania publiczne oraz systemy wykorzystywane do ich realizacji;
2. przygotować inwentaryzację produktów, usług i procesów ICT;
3. porównać stan jednostki z 18 wymaganiami części I;
4. rozważyć środki dodatkowe z części II;
5. przypisać osoby odpowiedzialne, dokumenty i dowody;
6. zaplanować działania naprawcze i terminy;
7. ustanowić cykl przeglądów SZBI.

Praktycznym narzędziem może być rejestr zawierający:

Ustawa nie wymaga takiego formularza. Pomaga on jednak powiązać wymagania z odpowiedzialnością i dowodami.

Najczęstsze błędy

Ograniczenie inwentaryzacji do sprzętu

Załącznik obejmuje również usługi oraz procesy ICT.

Brak informacji o wersjach

Lista nazw systemów bez danych o wersjach i cyklu życia nie pozwala skutecznie zarządzać podatnościami.

Nadmierne albo nieaktualne uprawnienia

Szczególne ryzyko powstaje, gdy proces kadrowy nie jest powiązany z blokowaniem i modyfikowaniem dostępów.

Kopia na tej samej infrastrukturze

Kopia musi być odseparowana logicznie i fizycznie oraz odporna na zagrożenia dotyczące środowiska produkcyjnego.

Brak testów odtworzeniowych

Poprawne zakończenie zadania kopii nie dowodzi jeszcze, że dane można odtworzyć.

Procedury bez dowodów

Dokument opisujący działanie nie potwierdza, że działanie zostało rzeczywiście wykonane.

Automatyczne pominięcie części II

Środki dodatkowe nie są obowiązkowe w każdym przypadku, ale ich zastosowanie powinno zostać rozsądnie rozważone.

Błędne przyjęcie obowiązku raportu 24-godzinnego

Podmiot ważny będący podmiotem publicznym zgłasza incydent poważny w terminie 72 godzin, lecz art. 12c wyłącza wobec niego wczesne ostrzeżenie oraz późniejsze sprawozdania.

Założenie, że audyt nigdy nie będzie wymagany

Podmiot ważny publiczny nie przeprowadza automatycznie audytu raz na trzy lata. Organ właściwy może jednak nakazać audyt zewnętrzny po incydencie poważnym albo innym naruszeniu ustawy.

Podsumowanie

Załącznik nr 4 ustanawia uproszczony, ale realny model SZBI dla podmiotu ważnego będącego podmiotem publicznym.

Obowiązkowe minimum obejmuje przede wszystkim:

• inwentaryzację środowiska ICT;
• kontrolę wersji i cyklu życia;
• ochronę informacji i infrastruktury;
• zarządzanie dostępem;
• bezpieczeństwo pracy zdalnej;
• kontrolę poczty elektronicznej;
• kopie zapasowe i testy odtworzenia;
• procedury awaryjne i incydentowe;
• oprogramowanie antywirusowe;
• cyberhigienę i szkolenia;
• okresowe przeglądy;
• dokumentowanie wykonania działań.

Część II wskazuje przykładowe dodatkowe środki, które mogą uzupełniać system, między innymi monitoring, wysoką dostępność, testy bezpieczeństwa oraz zasady korzystania z chmury i generatywnej sztucznej inteligencji.

Uproszczenie polega na zastosowaniu innego modelu wymagań niż w art. 8 ust. 1. Nie oznacza zwolnienia z rzeczywistego wdrożenia zabezpieczeń, odpowiedzialności i mechanizmów kontrolnych.

Podstawy prawne i źródła

• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa – tekst jednolity ogłoszony w Dz.U. z 2026 r. poz. 20 ↗, z późniejszymi zmianami;
• Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw – Dz.U. z 2026 r. poz. 252 ↗;
• Ustawa z dnia 29 maja 2026 r. o zmianie ustawy o zarządzaniu kryzysowym oraz niektórych innych ustaw – Dz.U. z 2026 r. poz. 815 ↗;
• aktualny tekst ujednolicony ustawy o KSC, uwzględniający Dz.U. z 2026 r. poz. 20, 252 i 815 ↗;
• „Q&A Nowelizacja KSC”, Ministerstwo Cyfryzacji, wersja opublikowana 12 czerwca 2026 r. ↗.

Tekst ujednolicony Kancelarii Sejmu oraz materiały Ministerstwa Cyfryzacji mają charakter informacyjny i pomocniczy. W przypadku rozbieżności pierwszeństwo mają akty prawne ogłoszone w Dzienniku Ustaw.

Zastrzeżenie: Artykuł ma charakter informacyjny i nie stanowi opinii prawnej ani indywidualnej oceny zgodności konkretnej jednostki. Zakres wdrożenia powinien uwzględniać status podmiotu, realizowane zadania, wykorzystywane systemy, regulacje sektorowe oraz inne przepisy dotyczące bezpieczeństwa informacji.