SZBI w ustawie o KSC: które obowiązki dotyczą systemów IT

System zarządzania bezpieczeństwem informacji (SZBI), który ustawa o krajowym systemie cyberbezpieczeństwa (KSC) nakłada na podmioty kluczowe i ważne, trzeba wdrożyć do 3 kwietnia 2027 roku. Termin wynika z art. 33 ust. 1 ustawy z 23 stycznia 2026 roku (Dz.U. 2026 poz. 252), która weszła w życie 3 kwietnia 2026 roku. Obejmuje on obowiązki z rozdziału 3 podmiotów, które spełniały przesłanki w dniu jej wejścia w życie. Dawni operatorzy usług kluczowych mają sześć miesięcy na nowe zasady zgłaszania incydentów (art. 33 ust. 4), a do czasu wdrożenia nowego SZBI stosują dotychczasowy (art. 33 ust. 6). Sektor bankowości i infrastruktury rynków finansowych przepisów o SZBI i zgłaszaniu poważnych incydentów co do zasady nie stosuje (art. 8i ust. 1).

Kogo ustawa obejmuje, opisuje przegląd ustawy o KSC w CyberKatalogu. Tu chodzi o to, co po wejściu pod ustawę trzeba zrobić w systemach. Znaczna część wymogów z art. 8 sprawdza się konfiguracją, logami i procesem wytwórczym, a dokumentację operacyjną z art. 10 ust. 4 tworzą także zapisy generowane automatycznie w dziennikach systemów informacyjnych.

Co art. 8 ustawy o KSC każe wdrożyć

SZBI to system zarządzania bezpieczeństwem informacji, który art. 8 ust. 1 ustawy o KSC każe wdrożyć podmiotom kluczowym i ważnym w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi. Ma zapewniać pięć rzeczy: systematyczne szacowanie ryzyka i zarządzanie nim, środki techniczne i organizacyjne proporcjonalne do tego ryzyka, zbieranie informacji o cyberzagrożeniach i podatnościach, zarządzanie incydentami oraz środki zapobiegające incydentom i ograniczające ich skutki.

Obowiązek ciąży na podmiocie, a za wykonanie obowiązków z art. 8 odpowiada kierownik podmiotu (art. 8c), także wtedy, gdy powierzył je innej osobie. Decyduje o przygotowaniu, wdrożeniu i nadzorze systemu, planuje na niego środki (art. 8d) i raz w roku kalendarzowym przechodzi udokumentowane szkolenie (art. 8e). Za niewykonanie obowiązków z art. 8 może zostać ukarany osobno (art. 73a). Część systemową prowadzi zwykle dział IT.

Zadania z art. 8 i art. 11 może rozpocząć osoba, która przedstawi informację z Krajowego Rejestru Karnego o niekaralności za przestępstwa przeciwko ochronie informacji, a osoba prawomocnie skazana za takie przestępstwo nie może ich wykonywać (art. 8f ust. 1 i 4). Kierownik dopuszcza ją do pracy po otrzymaniu tej informacji, a zamiast niej wystarcza ważne poświadczenie bezpieczeństwa o klauzuli poufne lub wyższej (ust. 3).

Które wymogi z art. 8 trafiają do systemów, a które do dokumentów

Przepis nie przypisuje wymogów do kategorii. Podział poniżej wynika z ich treści:

Dokumentacja jest osobnym obowiązkiem z art. 10, zagrożonym karą (art. 73 ust. 1 pkt 4). Obejmuje dokumentację normatywną, w tym dokumentację SZBI i dokumentację techniczną systemu informacyjnego (ust. 3 pkt 1 i 4), oraz dokumentację operacyjną, czyli zapisy z wykonania wymaganych czynności, także generowane automatycznie w dziennikach systemów (ust. 4). Art. 73 ust. 1 pkt 3 przewiduje karę za brak SZBI, a osobno za SZBI, który nie zapewnia wymaganej funkcjonalności albo nie spełnia wymogów z art. 8.

SZBI a ISO 27001: czym się różnią

Art. 8 nie powołuje żadnej normy i nie uznaje certyfikatu za dowód spełnienia wymogów. Takie domniemanie zawiera rozporządzenie w sprawie Krajowych Ram Interoperacyjności (KRI). Jego § 19 ust. 3 uznaje wymagania wobec SZBI podmiotu publicznego za spełnione, gdy system oparto na PN-ISO/IEC 27001, a zabezpieczenia i ryzyko na normach PN-ISO/IEC 27002 i 27005. Baza ELI Sejmu oznacza jednak to rozporządzenie jako uchylone z dniem 23 lutego 2027 roku, czyli przed terminem z art. 33 ust. 1. Ustawa o KSC dokłada obowiązki, których norma nie obejmuje, bo wynikają z prawa: zgłoszenia do CSIRT-u sektorowego, odpowiedzialność kierownika i korzystanie z S46.

Norma ISO/IEC 27001:2022 (więcej w słowniku CyberKatalogu) opisuje wymagania wobec systemu zarządzania bezpieczeństwem informacji (information security management system, ISMS). Z SZBI z art. 8 łączy ją zarządzanie ryzykiem, więc organizacja z takim systemem nie zaczyna od zera, ale musi sprawdzić go z art. 8 punkt po punkcie.

Podmiot ważny będący podmiotem publicznym nie stosuje art. 8 ust. 1 i wdraża SZBI spełniający wymogi załącznika nr 4 (art. 8 ust. 3). To samo dotyczy podmiotów z art. 7 ust. 1 pkt 1-4 i 6-7 Prawa o szkolnictwie wyższym i nauce, niebędących organizacją badawczą, w zakresie, w jakim realizują zadania publiczne z wykorzystaniem systemów informacyjnych. Jak KRI i KSC nakładają się w samorządzie, opisuje artykuł o MDM w jednostkach samorządu terytorialnego.

Zegar 24, 72 godzin i miesiąca: co muszą zbierać systemy

Podmiot kluczowy i podmiot ważny niebędący podmiotem publicznym zgłasza incydent poważny do właściwego CSIRT-u sektorowego trzy razy (art. 11 ust. 1 pkt 4, 4a i 4c). Wczesne ostrzeżenie idzie niezwłocznie, najpóźniej w ciągu 24 godzin od wykrycia, zgłoszenie w ciągu 72 godzin od wykrycia, a sprawozdanie końcowe w ciągu miesiąca od dnia zgłoszenia. Zegar rusza w chwili wykrycia, a sprawozdanie końcowe liczy się od zgłoszenia z 72. godziny. Dłuższa obsługa zmienia ten termin. Jeśli trwa jeszcze, gdy mija miesiąc, podmiot przekazuje sprawozdanie z postępu, a sprawozdanie końcowe w ciągu miesiąca od zakończenia obsługi (art. 12b).

Ważny podmiot publiczny składa tylko zgłoszenie z 72. godziny, bo art. 12c wyłącza dla niego wczesne ostrzeżenie, sprawozdanie okresowe, sprawozdanie z postępu i sprawozdanie końcowe. Podmioty z sektora bankowości i infrastruktury rynków finansowych tych przepisów nie stosują, poza wyjątkami wyliczonymi w art. 8i ust. 1. Dostawca usług zaufania zgłasza incydent poważny niezwłocznie, najpóźniej w ciągu 24 godzin od wykrycia (art. 11 ust. 1a).

Treść zgłoszeń pokazuje, czego potrzebują systemy. Wczesne ostrzeżenie ma wskazać moment wystąpienia i wykrycia incydentu oraz czas jego trwania (art. 12 ust. 1 pkt 4). Zgłoszenie podaje liczbę użytkowników, których incydent dotknął, i jego przebieg (art. 12 ust. 3), a sprawozdanie końcowe prawdopodobną przyczynę źródłową (art. 12a). Takich danych nie odtworzy się z pamięci administratora, tylko z logów, a ustawa wymaga monitorowania systemu w trybie ciągłym (art. 8 ust. 1 pkt 2 lit. g).

Ustawa nie wskazuje narzędzia. Aby podać moment wystąpienia i wykrycia incydentu, trzeba centralnie zbierać logi (system klasy SIEM albo prostsze rozwiązanie), synchronizować zegary i przechowywać logi dłużej, niż trwa wykrywanie. Incydent poważny to według ustawy między innymi incydent, który powoduje lub może spowodować poważne obniżenie jakości lub przerwanie ciągłości świadczenia usługi (art. 2 pkt 7), więc ransomware zatrzymujący usługę zwykle go spełnia. Decyzję o okupie omawia artykuł o płaceniu okupu po ataku ransomware.

Czym jest S46

S46 to system teleinformatyczny z art. 46 ust. 1 ustawy o KSC, który utrzymuje minister właściwy do spraw informatyzacji. Ustawa nazywa go tylko numerem artykułu, a skrót S46 pochodzi z dokumentacji projektu Centralnego Ośrodka Informatyki. System obsługuje zgłaszanie incydentów i prowadzenie wykazu podmiotów. Podmiot zaczyna z niego korzystać w ciągu 12 miesięcy od spełnienia przesłanek (art. 46 ust. 4), a według komunikatu Ministra Cyfryzacji okno kończy się 3 kwietnia 2027 roku.

Ustawa nakłada przy tym obowiązki na własne systemy podmiotu. Ma on zapewnić ich bezpieczeństwo, ciągłość działania i rozliczalność (ust. 6) oraz w ciągu 6 miesięcy od publikacji w Biuletynie Informacji Publicznej dostosować je do minimalnych wymagań technicznych i funkcjonalnych, które ogłosi minister (ust. 7). W tym samym systemie mają trafiać zgłoszenia naruszeń ochrony danych z art. 33 RODO. Minister uruchomi tę funkcję w ciągu roku od wejścia ustawy w życie (art. 46 ust. 1 pkt 7 i art. 36). Jedno zdarzenie może oznaczać dwa zgłoszenia oparte na tych samych logach.

Dostęp, aktualizacje i podatności

Ustawa wymaga bezpiecznych środków komunikacji elektronicznej, które w stosownych przypadkach uwzględniają uwierzytelnianie wieloskładnikowe (multi-factor authentication, MFA), tak jak NIS2 w art. 21 ust. 2 lit. j (art. 8 ust. 1 pkt 2 lit. l). Żaden z tych przepisów nie podaje kryterium, kiedy MFA jest konieczne, więc rozstrzyga ocena ryzyka, a punktem wyjścia jest dostęp administracyjny i zdalny.

Wobec podatności ustawa wymienia trzy obowiązki. Pierwszy to zbieranie informacji o nich (ust. 1 pkt 3), drugi regularne aktualizacje oprogramowania stosownie do zaleceń producenta, z analizą wpływu na usługę i krytyczności poprawki (pkt 5 lit. b), trzeci niezwłoczne działania po dostrzeżeniu podatności, w tym czasowe ograniczenie ruchu przychodzącego (pkt 5 lit. d). Do tego dochodzi mechanizm zewnętrzny. CSIRT MON, CSIRT NASK lub CSIRT GOV może wystąpić do organu o wezwanie podmiotu, aby w wyznaczonym terminie usunął podatności, które doprowadziły lub mogłyby doprowadzić do incydentu poważnego lub krytycznego (art. 32 ust. 2). Nieusunięcie ich jest podstawą kary (art. 73 ust. 1 pkt 12).

Dla aplikacji można to przełożyć na inwentarz zależności, alerty o podatnościach w CI i test, który zatrzymuje wydanie przy krytycznej podatności. Aktualizacje zależności mogą mieć okres karencji, żeby świeżo opublikowana i przejęta wersja pakietu nie trafiła od razu do builda, z wyjątkiem poprawek usuwających znane podatności. Przedmiotem przeglądu bezpieczeństwa i zgodności są kod, architektura i CI/CD zespołów wydających oprogramowanie, a nie dokumentacja SZBI ani audyt zgodności z ustawą o KSC.

Łańcuch dostaw: o co klient objęty KSC może zapytać dostawcę oprogramowania

Środki z art. 8 obejmują bezpieczeństwo i ciągłość łańcucha dostaw produktów, usług i procesów ICT, od których zależy świadczenie usługi (ust. 1 pkt 2 lit. e). Podmiot uwzględnia przy nich podatności związane z dostawcą, ogólną jakość produktów, usług i procesów ICT pochodzących od dostawcy, unijną skoordynowaną ocenę ryzyka oraz wyniki postępowania w sprawie dostawcy wysokiego ryzyka (ust. 2). Dyrektywa NIS2 dodaje w art. 21 ust. 3 procedury bezpiecznego opracowywania; polski przepis mówi o jakości ogólnie.

Dostawca sprzętu lub oprogramowania może sam zostać uznany za dostawcę wysokiego ryzyka. Minister właściwy do spraw informatyzacji może wszcząć takie postępowanie w celu ochrony bezpieczeństwa państwa lub bezpieczeństwa i porządku publicznego (art. 67b ust. 1). Dotyczy to sprzętu lub oprogramowania używanego przez podmioty kluczowe lub ważne (poza podsektorem komunikacji elektronicznej), przedsiębiorców komunikacji elektronicznej z rocznymi przychodami z działalności telekomunikacyjnej powyżej 10 milionów złotych oraz podmioty finansowe. Przed decyzją minister zasięga opinii Kolegium (art. 67b ust. 10). Opinia analizuje między innymi, z jakim prawdopodobieństwem dostawca znajduje się pod kontrolą państwa spoza Unii Europejskiej lub NATO, jego strukturę własnościową i powiązania z podmiotami z załącznika do rozporządzenia Rady (UE) 2019/796 (ust. 11). Klient musi uwzględnić wyniki postępowania (art. 8 ust. 2 pkt 4).

Dostawca oprogramowania może usłyszeć w ankiecie bezpieczeństwa lub w umowie pytania:

• Jak dostawca znajduje i usuwa podatności we własnym kodzie i w zależnościach, w jakim czasie i jak wygląda jego proces wytwarzania?
• Czy dostarcza aktualizacje bezpieczeństwa z opisem ich wpływu, tak aby klient mógł ocenić je zgodnie z art. 8 ust. 1 pkt 5 lit. b?
• Z jakich komponentów składa się produkt, żeby po ogłoszeniu krytycznej podatności w bibliotece dało się szybko ustalić, czy dotyczy ona klienta?
• W jakim czasie dostawca powiadomi klienta o incydencie lub podatności we własnym produkcie, skoro klient ma 24 godziny od wykrycia na wczesne ostrzeżenie?

Osobny obowiązek może spaść na samego dostawcę. Rozporządzenie (UE) 2024/2847, czyli akt o cyberodporności (CRA), stosuje się od 11 grudnia 2027 roku (art. 71 ust. 2). Art. 14 obowiązuje już od 11 września 2026 roku, a rozdział IV (art. 35-51) od 11 czerwca 2026 roku. Od 11 września 2026 roku producent produktu z elementami cyfrowymi zgłasza aktywnie wykorzystywane podatności i poważne incydenty: wczesne ostrzeżenie w 24 godziny, zgłoszenie w 72 godziny i sprawozdanie końcowe. Czy dotyczy to danego produktu, rozstrzyga definicja produktu z elementami cyfrowymi w rozporządzeniu, a zgłaszanie podatności i incydentów z art. 14 CRA opisuje CyberKatalog.

Daty z ustawy w kolejności

Z ustawy i komunikatu Ministra Cyfryzacji wynikają trzy daty, które porządkują prace. Pierwsza, 3 października 2026 roku, dotyczy wpisu do wykazu i dawnych operatorów usług kluczowych, nie samego SZBI, i już minęła. Kalendarz obowiązków z NIS2, CRA i DORA zbiera CyberKatalog.

Kara pieniężna, także za brak SZBI, nie może przekroczyć dla podmiotu kluczowego 10 milionów euro albo 2% przychodów z poprzedniego roku obrotowego, przy czym zastosowanie ma kwota wyższa (art. 73 ust. 3). Dla podmiotu ważnego granicą jest 7 milionów euro albo 1,4% przychodów (ust. 4). Do 100 milionów złotych sięga kara za naruszenie, które powoduje bezpośrednie i poważne cyberzagrożenie dla obronności, bezpieczeństwa państwa, bezpieczeństwa i porządku publicznego lub życia i zdrowia ludzi, albo zagrożenie poważną szkodą majątkową lub poważnymi utrudnieniami w świadczeniu usług (art. 73 ust. 5). Art. 35 nie wymienia ust. 5 wśród kar, które można nałożyć dopiero po dwóch latach.

Najczęściej zadawane pytania

Czy SZBI to zadanie działu IT?

Nie wyłącznie. Za wykonanie obowiązków odpowiada kierownik podmiotu (art. 8c), a część wymogów dotyczy bezpieczeństwa fizycznego, zasobów ludzkich i szkoleń. Dział IT prowadzi zwykle część systemową: dostęp, logi, aktualizacje, kopie zapasowe i zgłoszenia incydentów.

Co to jest S46?

S46 to system teleinformatyczny z art. 46 ust. 1 ustawy o KSC, utrzymywany przez ministra właściwego do spraw informatyzacji. Służy między innymi do zgłaszania i obsługi incydentów oraz do prowadzenia wykazu podmiotów kluczowych i ważnych. Podmioty zaczynają z niego korzystać do 3 kwietnia 2027 roku.

Czym SZBI różni się od ISO 27001?

Art. 8 ustawy o KSC nie powołuje normy ISO 27001 i nie uznaje certyfikatu za dowód spełnienia wymogów. Domniemanie zgodności dla podmiotów publicznych zawiera rozporządzenie KRI (§ 19 ust. 3), uznane za uchylone z dniem 23 lutego 2027 roku. Norma opisuje wymagania wobec systemu zarządzania bezpieczeństwem informacji, a ustawa dokłada obowiązki spoza niej: zgłoszenia do CSIRT-u sektorowego, odpowiedzialność kierownika i korzystanie z S46.

Czy dostawca oprogramowania musi wdrożyć SZBI?

To zależy od sektora i wielkości firmy, nie od samego pisania oprogramowania; kryteria opisuje przegląd ustawy o KSC. Konkretna gałąź dotyczy firm, które oprócz oprogramowania prowadzą usługi chmurowe, zarządzane lub inną działalność z art. 8b ust. 1 (na przykład centrum przetwarzania danych, sieć dostarczania treści albo internetową platformę handlową). Stosują one w ramach SZBI środki zarządzania ryzykiem z rozporządzenia wykonawczego Komisji (UE) 2024/2690. Pytania z sekcji o łańcuchu dostaw mogą trafić do dostawcy niezależnie od jego statusu, bo klient objęty ustawą uwzględnia przy środkach łańcucha dostaw podatności i jakość produktów swoich dostawców (art. 8 ust. 2).

Dokumenty u doradcy, systemy w kodzie

Dokumentacyjną stronę SZBI, czyli metodykę ryzyka, polityki i procedury, prowadzą doradcy GRC. Wykonawców zbiera kategoria GRC i zgodność w CyberKatalogu oraz zestawienie w artykule o wdrożeniu NIS2 i ustawy o KSC.

Po stronie systemów pytania są inne: co loguje aplikacja, skąd wiadomo o podatności w zależności, kto może wydać wersję na produkcję. Art. 10 wymaga obu rodzajów dokumentacji: polityk i zapisów z działania systemów, w tym dzienników.

Źródła

1. Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, art. 33 ust. 1, 2, 4 i 6, art. 35, art. 36 i art. 49 oraz nadane przez nią brzmienie art. 2 pkt 7, art. 8, 8b, 8c-8f, 8i, 10, 11, 12, 12a-12c, 32 ust. 2, 46 ust. 1 i 4-7, 67b, 73 i 73a ustawy o krajowym systemie cyberbezpieczeństwa, a także metryka aktu w bazie ELI Sejmu z datami ogłoszenia 02.03.2026 i wejścia w życie 03.04.2026 (odczyt 08.10.2026)
2. Obwieszczenie Marszałka Sejmu Rzeczypospolitej Polskiej z dnia 29 grudnia 2025 r. w sprawie ogłoszenia jednolitego tekstu ustawy o krajowym systemie cyberbezpieczeństwa, art. 46 ust. 1 pkt 1-5 w brzmieniu sprzed nowelizacji (odczyt 08.10.2026)
3. Komunikat Ministra Cyfryzacji z dnia 08 kwietnia 2026 r. w sprawie harmonogramu złożenia wniosków o wpis do wykazu podmiotów kluczowych i podmiotów ważnych oraz rozpoczęcia korzystania z systemu teleinformatycznego przez podmioty kluczowe lub podmioty ważne, Dz. Urz. MC 2026 poz. 7, pkt 1 i 2 (odczyt 08.10.2026)
4. Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii (dyrektywa NIS 2), art. 21 ust. 2 lit. j i art. 21 ust. 3 (odczyt 08.10.2026)
5. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847 z dnia 23 października 2024 r. w sprawie horyzontalnych wymagań w zakresie cyberbezpieczeństwa w odniesieniu do produktów z elementami cyfrowymi (akt o cyberodporności), art. 14 ust. 1-4 oraz art. 71 ust. 2 (odczyt 08.10.2026)
6. Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych, § 19 ust. 3, oraz metryka rozporządzenia w bazie ELI Sejmu z datą uznania za uchylone 23.02.2027 (odczyt 08.10.2026)
7. Ustawa z dnia 25 lipca 2025 r. o zmianie ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne oraz niektórych innych ustaw - akt wskazany w metryce ELI jako podstawa uchylenia rozporządzenia KRI z dniem 23.02.2027 (odczyt 08.10.2026)
8. ISO, "ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection - Information security management systems - Requirements", wydanie 3, 2022 - opis normy jako zbioru wymagań wobec systemu zarządzania bezpieczeństwem informacji (odczyt 08.10.2026)
9. Centralny Ośrodek Informatyki, "Podłączenie podmiotów krajowego systemu cyberbezpieczeństwa do zintegrowanego systemu zarządzania cyberbezpieczeństwem S46 (S46-react)" - definicja systemu S46 jako systemu z art. 46 ust. 1 ustawy o KSC (odczyt 08.10.2026)