system zarządzania bezpieczeństwem informacji (SZBI)

System zarządzania bezpieczeństwem informacji (SZBI), po angielsku ISMS (information security management system), to udokumentowany i stale doskonalony zbiór polityk, ról, procesów i zabezpieczeń, przez który organizacja zarządza ryzykiem dla poufności, integralności i dostępności informacji. Według ISO norma ISO/IEC 27001 określa wymagania, które taki system musi spełnić, i opisuje jego ustanowienie, wdrożenie, utrzymanie i ciągłe doskonalenie ^[4]. W polskim prawie pojęcie występuje w rozporządzeniu o Krajowych Ramach Interoperacyjności (KRI) ^[1], a od 2026 roku także w ustawie o krajowym systemie cyberbezpieczeństwa (KSC) ^[2].

Jak działa

SZBI nie jest programem ani pojedynczym dokumentem. To sposób prowadzenia bezpieczeństwa, który powtarza się w cyklu. Rozporządzenie KRI opisuje go czterema parami czynności: podmiot „opracowuje i ustanawia, wdraża i eksploatuje, monitoruje i przegląda oraz utrzymuje i doskonali” system zarządzania bezpieczeństwem informacji ^[1]. Schemat poniżej pokazuje ten cykl.

RYS. 1Cykl SZBI według KRI

Punktem wyjścia jest szacowanie ryzyka. ISO wskazuje, że system zgodny z ISO/IEC 27001 chroni poufność, integralność i dostępność informacji właśnie przez stosowanie procesu zarządzania ryzykiem ^[4]. Na tej podstawie dobiera się zabezpieczenia, spisuje politykę bezpieczeństwa, przydziela role i sprawdza, czy środki działają.

Składniki

KRI w § 20 ust. 2 wymienia działania, które kierownictwo podmiotu publicznego ma zapewnić w ramach SZBI ^[1]. Wśród nich są:

• aktualność regulacji wewnętrznych i inwentaryzacji sprzętu oraz oprogramowania ^[1];
• okresowe analizy ryzyka utraty integralności, dostępności lub poufności informacji ^[1];
• uprawnienia adekwatne do zadań i ich niezwłoczna zmiana, gdy zadania się zmieniają ^[1];
• szkolenia osób przetwarzających informacje ^[1];
• dbałość o aktualizację oprogramowania i redukcja ryzyk wynikających z opublikowanych podatności ^[1];
• zapisy o bezpieczeństwie informacji w umowach serwisowych ze stronami trzecimi ^[1];
• niezwłoczne zgłaszanie incydentów i audyt wewnętrzny nie rzadziej niż raz na rok ^[1].

Rozporządzenie uznaje te wymagania za spełnione, jeśli SZBI opracowano na podstawie Polskiej Normy PN-ISO/IEC 27001, a zarządzanie ryzykiem opiera się na PN-ISO/IEC 27005 ^[1].

Kogo dotyczy

Obowiązek ma kilka źródeł. Tabela zestawia trzy najważniejsze.

W pierwotnym brzmieniu z 2018 roku art. 8 KSC wymagał od operatora usługi kluczowej „systemu zarządzania bezpieczeństwem w systemie informacyjnym” ^[5]. Nowelizacja z 23 stycznia 2026 roku zastąpiła go „systemem zarządzania bezpieczeństwem informacji” wdrażanym przez podmioty kluczowe i ważne ^[2]. Art. 8 wymienia teraz m.in. polityki szacowania ryzyka, bezpieczeństwo łańcucha dostaw, plany ciągłości działania, edukację personelu, zasady cyberhigieny, kryptografię, uwierzytelnianie wieloskładnikowe (MFA) w stosownych przypadkach, zarządzanie aktywami i polityki kontroli dostępu ^[2].

Nowelizacja weszła w życie 3 kwietnia 2026 roku ^[3]. Podmioty, które wtedy spełniały kryteria, mają 12 miesięcy, czyli do 3 kwietnia 2027 roku, na wdrożenie obowiązków dotyczących SZBI ^[3]. Za niewdrożenie systemu grożą kary pieniężne ^[3]. Ustawa wdraża dyrektywę NIS2 ^[2].

Wdrożenie i certyfikacja

ISO zaznacza, że firma wdrażająca ISO/IEC 27001 sama decyduje, czy przejdzie certyfikację ^[4]. Część organizacji stosuje normę tylko jako zbiór dobrych praktyk, inne certyfikują się, by dać pewność klientom ^[4]. Certyfikat wydaje jednostka certyfikująca, a jej kompetencje potwierdza jednostka akredytująca ^[4]. Niezależnie od certyfikacji podmioty kluczowe objęte KSC muszą przeprowadzać audyty bezpieczeństwa przewidziane w ustawie ^[3].

KRI łączy SZBI z innymi normami. Poza PN-ISO/IEC 27005 dla zarządzania ryzykiem wskazuje PN-ISO/IEC 24762 dla odtwarzania techniki informatycznej po katastrofie w ramach zarządzania ciągłością działania ^[1], czyli dla disaster recovery (DR). Gdy analiza ryzyka to uzasadnia, podmiot ma ustanowić zabezpieczenia dodatkowe ponad listę z § 20 ^[1]. Lista z rozporządzenia jest więc minimum, a nie zamkniętym katalogiem.

Cykl z KRI zakłada, że system nie kończy się na spisaniu polityk: po monitorowaniu i przeglądzie następuje utrzymanie i doskonalenie ^[1]. Polityka spisana raz i nieaktualizowana nie spełnia tego założenia.

W WordPressie

Strona internetowa jest jednym z systemów objętych SZBI firmy, jeśli służy świadczeniu usługi albo przetwarza informacje chronione systemem. Wymagania z KRI i KSC przekładają się wtedy na zwykłe prace przy WordPressie.

• Aktualizacje. Nowy art. 8 KSC mówi o regularnych aktualizacjach oprogramowania zgodnie z zaleceniami producenta i z oceną ich krytyczności ^[2]. Dokumentacja WordPressa przypomina, że starsze wersje WordPressa nie dostają poprawek bezpieczeństwa ^[6]. To obszar zarządzania poprawkami (patch management).
• Inwentaryzacja. Wymóg aktualnej inwentaryzacji oprogramowania ^[1] obejmuje listę wtyczek i motywów. Dokumentacja zaleca usuwanie wtyczek, których się nie używa ^[6].
• Dostawcy. Dokumentacja wyjaśnia, że hosting odpowiada zwykle za infrastrukturę, a nie za zainstalowaną aplikację, i że trzeba rozumieć, gdzie kończy się odpowiedzialność hostingu ^[6]. W SZBI zapisuje się ten podział w umowach, zgodnie z wymogiem KRI dotyczącym umów serwisowych ^[1].
• Kopie i plan odtworzenia. Dokumentacja zaleca mieć plan tworzenia kopii i odtwarzania instalacji na wypadek katastrofy ^[6]. W SZBI jest to część planu ciągłości działania.

Historia i przykłady

Rozporządzenie KRI wydano 12 kwietnia 2012 roku ^[1]. Aktualna wersja normy ISO/IEC 27001 to wydanie trzecie z października 2022 roku ^[4]. ISO zaleca, by certyfikat opisywać pełnym oznaczeniem, na przykład „certyfikowany na zgodność z ISO/IEC 27001:2022”, a nie samym „ISO 27001” ^[4]. Po nowelizacji KSC z 2026 roku pierwszy audyt bezpieczeństwa podmiot kluczowy ma przeprowadzić do 3 kwietnia 2028 roku, a kolejne co najmniej raz na trzy lata ^[3].