SZBI a norma ISO 27001 - czym jest system zarządzania bezpieczeństwem informacji i jak się mają do siebie

W skrócieSZBI (system zarządzania bezpieczeństwem informacji) to powtarzalny sposób zarządzania bezpieczeństwem oparty na ryzyku, a nie jednorazowy projekt. Ustawa o krajowym systemie cyberbezpieczeństwa (KSC) wymaga wdrożenia SZBI (art. 8), a norma ISO/IEC 27001 to dobrowolny wzorzec, który pokazuje, jak taki system zbudować. Norma daje szkielet, ustawa nakłada obowiązek. Nie są tym samym, ale znakomicie się uzupełniają.

Pojęcie SZBI wraca w każdej rozmowie o ustawie o KSC, a zaraz obok niego pada skrót ISO 27001. Łatwo je pomylić albo uznać za synonimy. To nieporozumienie kosztuje konkretne decyzje: firma albo kupuje certyfikat w przekonaniu, że załatwia obowiązek ustawowy, albo odwrotnie, buduje system od zera, nie wiedząc, że norma podałaby gotowy przepis. W tym artykule tłumaczymy, czym jest sam SZBI, czym jest norma ISO/IEC 27001, jak jedno ma się do drugiego i od czego zacząć. Jeśli dopiero porządkujesz podstawy całej ustawy, zacznij od naszego przewodnika po NIS2 i ustawie o KSC.

SZBI to system, a nie dokument

Skrót SZBI rozwija się jako system zarządzania bezpieczeństwem informacji. Słowo klucz to zarządzanie. SZBI nie jest pojedynczym dokumentem, programem antywirusowym ani jednorazowym wdrożeniem, po którym temat się zamyka. To powtarzalny sposób pracy, w którym organizacja robi cztery rzeczy w kółko: szacuje ryzyko dla swoich informacji i systemów, dobiera do tego ryzyka zabezpieczenia techniczne i organizacyjne, sprawdza, czy te zabezpieczenia działają, i poprawia to, co zawiodło. Ten rytm w świecie norm nazywa się cyklem Deminga albo cyklem planuj, wykonaj, sprawdź, działaj (po angielsku PDCA).

Ministerstwo Cyfryzacji opisuje rolę kierownika podmiotu dokładnie w tym duchu: kierownik odpowiada za system zarządzania bezpieczeństwem informacji i jego rozwój zgodnie z cyklem Deminga (odpowiedź 4.1 w pytaniach i odpowiedziach Ministerstwa Cyfryzacji do ustawy o KSC, stanowisko niewiążące). To ważna zmiana sposobu myślenia. Bezpieczeństwo przestaje być listą zakupów sprzętu, a staje się procesem, którym ktoś zarządza, mierzy go i rozlicza.

Skąd bierze się SZBI w polskim prawie

Dla firmy objętej ustawą o KSC SZBI to nie dobra praktyka, tylko obowiązek. Podstawowy przepis brzmi: podmiot kluczowy lub podmiot ważny wdraża system zarządzania bezpieczeństwem informacji w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi przez ten podmiot (art. 8 ust. 1 ustawy o KSC). Dalej ustawa wylicza, co ten system ma zapewniać: systematyczne szacowanie ryzyka wystąpienia incydentu i zarządzanie tym ryzykiem, odpowiednie i proporcjonalne środki techniczne i organizacyjne z katalogu wymienionego wprost w literach a do n, zbieranie informacji o cyberzagrożeniach i podatnościach, zarządzanie incydentami oraz środki zapobiegające incydentom i ograniczające ich wpływ (art. 8 ust. 1 pkt 1 do 5).

SZBI nie jest przy tym pomysłem wymyślonym na potrzeby ustawy o KSC. To samo pojęcie pojawia się w innych miejscach. Rozporządzenie o ogólnej ochronie danych (RODO) wymaga, by zapewnić bezpieczeństwo danych osobowych środkami odpowiednimi do ryzyka i regularnie je oceniać (art. 32), co w praktyce realizuje się właśnie przez zarządzany system bezpieczeństwa. W podmiotach publicznych system zarządzania bezpieczeństwem informacji jest oczekiwany od lat na gruncie przepisów o Krajowych Ramach Interoperacyjności. Dla jednej firmy te obowiązki zwykle się zazębiają i najlepiej prowadzić je w jednym systemie, o czym piszemy w poście o łączeniu SZBI, RODO i KSC.

Norma ISO/IEC 27001 i rodzina ISO 27000

ISO/IEC 27001 to międzynarodowa norma, która opisuje wymagania wobec systemu zarządzania bezpieczeństwem informacji. Jest dobrowolna: nikt nie ma prawnego obowiązku jej stosować, dopóki konkretny przepis albo umowa z klientem tego nie wymaga. Jej wartość polega na tym, że porządkuje cały temat. Zamiast wymyślać własną metodę, organizacja dostaje sprawdzony układ: jak ustalić kontekst i zakres systemu, jak zaangażować kierownictwo, jak oszacować ryzyko i zaplanować postępowanie z nim, jak zapewnić zasoby i kompetencje, jak prowadzić działania operacyjne, jak oceniać skuteczność przez monitorowanie, audyt wewnętrzny i przegląd zarządzania oraz jak system doskonalić. Te obszary odpowiadają kolejnym rozdziałom normy, od czwartego do dziesiątego.

Do wymagań dochodzi katalog zabezpieczeń zebrany w załączniku A. W wydaniu normy z 2022 roku jest ich dziewięćdziesiąt trzy, pogrupowane w cztery tematy: zabezpieczenia organizacyjne, dotyczące ludzi, fizyczne i technologiczne. Organizacja nie musi stosować wszystkich. Wybiera te, które odpowiadają jej ryzyku, a decyzje zapisuje w dokumencie zwanym Deklaracją Stosowania. To jedna z ważniejszych różnic wobec ustawy, do której zaraz wrócimy. Czym dokładnie jest Deklaracja Stosowania, tłumaczymy w osobnym poście o Deklaracji Stosowania (SoA).

ISO/IEC 27001 nie jest sama. Należy do rodziny norm ISO 27000, w której każda pozycja dokłada jeden element. Dla osoby budującej SZBI najważniejsze są cztery, a piąta pochodzi z sąsiedniej rodziny, ale ściśle się z nimi łączy.

Jak SZBI z ustawy ma się do ISO 27001

Najprościej ująć to tak: ustawa mówi, że masz mieć zarządzany system bezpieczeństwa informacji, a norma pokazuje, jak go zbudować. Oba porządki mają ten sam rdzeń oparty na ryzyku, więc nie konkurują ze sobą, tylko się uzupełniają. Firma, która wdrożyła system według ISO/IEC 27001, ma już gotowy szkielet SZBI wymaganego przez ustawę: proces zarządzania ryzykiem, polityki, podział odpowiedzialności, audyty wewnętrzne i przeglądy zarządzania. Ministerstwo Cyfryzacji wprost utożsamia polityki tematyczne z art. 8 z politykami tematycznymi znanymi z normy (odpowiedź 3.3) i pisze, że organizacja z systemem według jednego ze standardów może wykorzystać i dostosować istniejącą dokumentację (odpowiedź 3.6).

Różnice zaczynają się tam, gdzie kończy się metoda, a zaczyna prawo. Zebraliśmy te, które w praktyce najczęściej zaskakują.

Z tej tabeli płynie wniosek praktyczny. Certyfikat ISO/IEC 27001 jest mocnym punktem startu, ale nie jest równoznaczny ze spełnieniem ustawy, bo ustawa wymaga więcej niż sam system zarządzania i nie przewiduje zaliczenia certyfikatu. To osobny, częsty problem, który rozkładamy na czynniki w artykule o tym, czy certyfikat ISO 27001 wystarcza do spełnienia obowiązków z ustawy o KSC.

Chcesz wiedzieć, na jakim standardzie oprzeć SZBI i jak połączyć go z obowiązkami ustawowymi? Szkolenie Obowiązki z NIS2 / KSC2 w praktyce decyzji zarządczych --> porównuje ISO/IEC 27001 z podejściem NIST, omawia zakres i harmonogram wdrożenia systemu, a prowadzi je audytor wiodący normy ISO/IEC 27001. To szkolenie ma terminy gwarantowane.

Certyfikat czy sama zgodność

Skoro ustawa nie wymaga normy, po co w ogóle certyfikat? Odpowiedź zależy od sytuacji firmy. Certyfikat ISO/IEC 27001 ma sens, gdy wymagają go klienci albo zamawiający w przetargach, gdy dostarczasz usługi podmiotom objętym ustawą, które muszą oceniać swoich dostawców, albo gdy zarząd chce regularnej, niezależnej oceny systemu. Nie ma sensu, gdy jedynym celem jest spełnienie KSC, bo tego celu certyfikat nie osiągnie, a koszty audytów certyfikacyjnych dojdą do kosztów obowiązków ustawowych.

Można też pójść drogą pośrednią: zbudować SZBI według normy jako wzorca, ale bez formalnej certyfikacji. System działa wtedy tak samo, a firma oszczędza na audytach jednostki certyfikującej. Którą drogę wybrać, rozkładamy w poście o wyborze między certyfikatem ISO 27001 a samą zgodnością.

Od czego zacząć budowę SZBI

Kolejność prac jest zawsze podobna, niezależnie od tego, czy celujesz w certyfikat, czy tylko w zgodność z ustawą. Poniższe kroki to szkielet, a każdy z nich rozwijamy w osobnym poście z tej serii.

1. Wyznacz zakres. Ustal, które systemy i procesy obejmuje system. W ustawie zakres narzuca usługa, więc nie da się go dowolnie zawęzić. Jak to zrobić, opisujemy w poście o wyznaczaniu zakresu SZBI.
2. Oszacuj ryzyko. To serce systemu. Bez analizy ryzyka nie wiadomo, które zabezpieczenia są potrzebne. Metodę i dokumentowanie opisujemy w poście o analizie ryzyka w SZBI.
3. Napisz polityki. Polityka bezpieczeństwa informacji i polityki tematyczne nadają systemowi ramy. Co muszą zawierać, tłumaczymy w poście o polityce bezpieczeństwa informacji.
4. Dobierz i wdroż zabezpieczenia. Z katalogu środków wybierasz te, które odpowiadają ryzyku, i wdrażasz je w praktyce, nie tylko na papierze.
5. Sprawdzaj i poprawiaj. Audyt wewnętrzny i przegląd zarządzania pokazują, co działa, a działania korygujące zamykają luki. Różnicę między audytem wewnętrznym a audytem z art. 15 ustawy wyjaśniamy w poście o audycie wewnętrznym SZBI.

Jeżeli zastanawiasz się, czy przejść tę drogę samodzielnie, czy z konsultantem, i ile to realnie zajmuje, zajrzyj do postu o wdrażaniu SZBI własnymi siłami. A jeśli chcesz najpierw zrozumieć całą ustawę, od klasyfikacji firmy po incydenty, przejdź do bezpłatnego kursu NIS2 i KSC w praktyce.

Podstawa prawna i źródła

• art. 8 ust. 1-3 ustawy z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (tekst ujednolicony, stan na 8.10.2026) - system zarządzania bezpieczeństwem informacji
• art. 8a ustawy o KSC - fakultatywne upoważnienie Rady Ministrów do szczegółowych wymagań SZBI
• art. 10 ustawy o KSC - dokumentacja normatywna i operacyjna systemu
• art. 15 ustawy o KSC - audyt bezpieczeństwa w podmiocie kluczowym
• art. 32 rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - bezpieczeństwo przetwarzania danych osobowych oparte na ryzyku
• rozporządzenie Ministra Cyfryzacji z dnia 12 października 2018 r. w sprawie wykazu certyfikatów uprawniających do przeprowadzenia audytu (Dz.U. 2018 poz. 1999) - m.in. audytor wiodący PN-EN ISO/IEC 27001 i PN-EN ISO 22301
• Ustawa o krajowym systemie cyberbezpieczeństwa, tekst ujednolicony, stan na 8.10.2026 (Sejm, ELI)
• Ministerstwo Cyfryzacji, pytania i odpowiedzi do ustawy o KSC, aktualizacja październik 2026 - m.in. odpowiedzi 3.3, 3.6, 4.1 (dokument niewiążący)

Stan prawny na 14 października 2026 r. Opis normy ISO/IEC 27001 jest celowo ogólny, bez cytowania jej treści, bo norma jest objęta prawem autorskim. Wyjaśnienia Ministerstwa Cyfryzacji nie są źródłem prawa. W sprawach spornych warto oprzeć decyzję na opinii prawnika lub stanowisku organu właściwego do spraw cyberbezpieczeństwa.