System zarządzania bezpieczeństwem informacji (SZBI) składa się z zakresu, ról, analizy ryzyka, wybranych zabezpieczeń, dokumentacji, audytów wewnętrznych i przeglądu zarządzania. ISO/IEC 27001:2022 opisuje te elementy w rozdziałach 4–10. Budowę zaczyna się od zakresu i analizy ryzyka, ponieważ pozostałe części systemu są ich konsekwencją, a nie odwrotnie.
Stan prawny na dzień 5 września 2026 r.
- Struktura — wymagania certyfikowalne to rozdziały 4–10 ISO/IEC 27001:2022; wykluczenie któregokolwiek z nich jest niedopuszczalne, jeżeli organizacja deklaruje zgodność z normą.
- Zabezpieczenia — Załącznik A zawiera 93 zabezpieczenia w czterech grupach; każde trzeba rozpatrzyć, ale nie każde wdrożyć.
- Kolejność — najpierw zakres i kontekst, potem analiza ryzyka i wybór zabezpieczeń, dopiero na końcu polityki, procedury i cykl audytowy.
- Podmioty publiczne — obowiązek prowadzenia SZBI wynika z § 19 rozporządzenia KRI z 21 maja 2024 r. Powielany w poradnikach § 20 pochodzi z rozporządzenia z 2012 r., które już nie obowiązuje.
Czym jest system zarządzania bezpieczeństwem informacji
System zarządzania bezpieczeństwem informacji (SZBI) to udokumentowany sposób, w jaki organizacja ustala, co chroni, przed czym, jakimi środkami i jak sprawdza skuteczność tej ochrony. Nie jest to pojedynczy dokument ani zestaw narzędzi technicznych, tylko powtarzalny cykl decyzji i dowodów. Kierownictwo wyznacza zakres i odpowiedzialności, zespół identyfikuje ryzyka i dobiera zabezpieczenia. Potem organizacja mierzy, audytuje i poprawia to, co nie działa.
Wymagania dla takiego systemu opisuje ISO/IEC 27001:2022, wydanie trzecie z października 2022 r. Norma obejmuje bezpieczeństwo informacji, cyberbezpieczeństwo i ochronę prywatności. Polski Komitet Normalizacyjny opublikował 22 sierpnia 2023 r. wersję PN-EN ISO/IEC 27001:2023-08 i jednocześnie wycofał PN-EN ISO/IEC 27001:2017-06.
System można prowadzić bez żadnego certyfikatu, na potrzeby własne, kontraktowe lub regulacyjne. Certyfikat wydaje niezależna jednostka certyfikująca po audycie i potwierdza jedynie to, że system w danym zakresie spełnia wymagania normy.
Z czego składa się SZBI według ISO/IEC 27001
SZBI składa się z siedmiu obszarów wymagań opisanych w rozdziałach 4–10 normy. Rozdział 1 normy (Zakres) stwierdza wprost, że jeżeli organizacja deklaruje zgodność z ISO/IEC 27001:2022, wykluczenie któregokolwiek z wymagań tych rozdziałów jest niedopuszczalne.
| Rozdział normy | Czego dotyczy | Dowód, o który pyta audytor |
|---|---|---|
| 4. Context of the organization (kontekst organizacji) | Czynniki wewnętrzne i zewnętrzne, strony zainteresowane i ich wymagania, granice i zakres systemu. | Zatwierdzony, udokumentowany zakres SZBI oraz zapis wymagań stron zainteresowanych. |
| 5. Leadership (przywództwo) | Zaangażowanie najwyższego kierownictwa, polityka bezpieczeństwa informacji, przypisanie ról i uprawnień. | Polityka zatwierdzona przez kierownictwo i formalne przypisanie ról wraz z zakresem odpowiedzialności. |
| 6. Planning (planowanie) | Ocena ryzyka i postępowanie z ryzykiem, cele bezpieczeństwa informacji, uzasadnienie doboru zabezpieczeń. | Metodyka i wyniki analizy ryzyka, plan postępowania z ryzykiem, Deklaracja Stosowania, cele wraz z planami ich osiągnięcia. |
| 7. Support (wsparcie) | Zasoby, kompetencje, świadomość, komunikacja oraz nadzór nad udokumentowaną informacją. | Zapisy ze szkoleń i działań uświadamiających, opisy wymaganych kompetencji, zasady wersjonowania dokumentów. |
| 8. Operation (działania operacyjne) | Realizacja zaplanowanych działań, cykliczna ocena ryzyka, nadzór nad zmianami i procesami zlecanymi na zewnątrz. | Zapisy z przeprowadzonych ocen ryzyka i dowody wykonania planu postępowania z ryzykiem. |
| 9. Performance evaluation (ocena efektów działania) | Monitorowanie i pomiary, audyt wewnętrzny, przegląd zarządzania. | Program i raporty audytów wewnętrznych, protokół z przeglądu zarządzania, wyniki przyjętych mierników. |
| 10. Improvement (doskonalenie) | Postępowanie z niezgodnościami, działania korygujące, ciągłe doskonalenie systemu. | Rejestr niezgodności i działań korygujących wraz z oceną ich skuteczności. |
Nazwy rozdziałów podano w oryginale, a polskie odpowiedniki stanowią tłumaczenie robocze. Do rozdziału 4 odnosi się dodatkowo poprawka ISO/IEC 27001:2022/Amd 1:2024, omówiona w sekcji z pytaniami poniżej.
Czym Załącznik A różni się od rozdziałów 4–10
Rozdziały 4–10 mówią, jak ma działać system, a Załącznik A dostarcza katalogu zabezpieczeń, które trzeba rozpatrzyć przy postępowaniu z ryzykiem. To rozróżnienie decyduje o kolejności prac: katalog zabezpieczeń jest narzędziem sprawdzającym kompletność wyborów, a nie listą zadań do wdrożenia od pierwszego dnia.
Załącznik A ISO/IEC 27001:2022 zawiera 93 zabezpieczenia podzielone na cztery grupy tematyczne. Spadek ze 114 pozycji w poprzednim wydaniu wynika głównie z konsolidacji, więc porównywanie samych liczb niewiele mówi o zakresie pracy.

Zestawienie decyzji o zastosowaniu lub pominięciu każdego z 93 zabezpieczeń nosi nazwę Deklaracji Stosowania (Statement of Applicability, SoA). Od tego dokumentu audytor zwykle zaczyna badanie doboru zabezpieczeń. Sposób realizacji poszczególnych zabezpieczeń opisuje ISO/IEC 27002:2022, która ma charakter wytycznych, a nie wymagań certyfikowalnych. Certyfikuje się zgodność z ISO/IEC 27001, nie z ISO/IEC 27002. Szerzej samą normę, jej zakres i wymogi omawia wpis o tym, czym jest ISO 27001 i czego wymaga od organizacji.
Od czego zacząć budowę SZBI
Zacznij od zakresu i kontekstu, a zaraz po nich od analizy ryzyka. Kryterium kolejności jest proste: buduj najpierw ten element, który jest wejściem dla największej liczby pozostałych. Zakres wyznacza, czego dotyczy analiza ryzyka; analiza ryzyka wyznacza dobór zabezpieczeń; dobór zabezpieczeń wyznacza treść polityk i procedur; dopiero to wszystko można sensownie audytować.

- Ustal zakres i kontekst SZBI. Opisz lokalizacje, procesy, systemy i dane objęte systemem oraz wymagania stron zainteresowanych. Gotowe, gdy zakres mieści się w jednym akapicie, wskazuje konkretne procesy i systemy, a kierownictwo go zatwierdziło.
- Wyznacz właściciela systemu i mandat kierownictwa. Bez jednoznacznej odpowiedzialności decyzje o ryzyku nie zapadają w terminie. Gotowe, gdy rola jest formalnie przypisana, ma zdefiniowane uprawnienia i bezpośredni dostęp do najwyższego kierownictwa.
- Zinwentaryzuj aktywa informacyjne i przeprowadź analizę ryzyka. Ustal metodykę, kryteria akceptacji i sposób szacowania przed pierwszym warsztatem, nie po nim. Gotowe, gdy każde zidentyfikowane ryzyko ma właściciela, ocenę oraz zapisaną decyzję o postępowaniu.
- Wybierz zabezpieczenia i uzasadnij decyzje. Przejdź katalog Załącznika A jako test kompletności wyborów. Gotowe, gdy dla każdego z 93 zabezpieczeń istnieje zapisana decyzja o zastosowaniu lub pominięciu wraz z uzasadnieniem wynikającym z ryzyka.
- Dopiero teraz napisz polityki i procedury. Dokument, który nie realizuje żadnego zabezpieczenia ani nie odpowiada na żadne ryzyko, jest zbędny. Gotowe, gdy każdy dokument wskazuje ryzyko lub zabezpieczenie, które obsługuje, i ma właściciela oraz datę przeglądu.
- Uruchom cykl sprawdzania. Zaplanuj audyt wewnętrzny, przegląd zarządzania i obsługę niezgodności. Gotowe, gdy pełny cykl przeszedł co najmniej raz, a niezgodności mają zamknięte działania korygujące z oceną skuteczności.
W projektach, które prowadzimy, najczęściej pierwszym gotowym dokumentem okazuje się polityka bezpieczeństwa informacji napisana zanim powstał zakres i analiza ryzyka. Skutek jest powtarzalny: po pierwszej rzetelnej ocenie ryzyka polityki trzeba przepisać, bo deklarują zasady, których organizacja nie stosuje, i milczą o ryzykach, które faktycznie wyszły. Gotowy wzór polityki bezpieczeństwa informacji warto traktować jako szkielet do wypełnienia po analizie ryzyka, a nie jako punkt startu.
Inwentaryzacja aktywów i analiza ryzyka, czyli krok trzeci, wymaga rzeczywistej wiedzy o stanie środowiska, a nie deklaracji z ankiety. Techniczny przegląd konfiguracji, uprawnień i podatności daje wejście do analizy ryzyka, którego nie zastąpi warsztat przy tablicy; taką rolę pełni usługa audytu bezpieczeństwa IT.
Obowiązek SZBI w podmiocie publicznym według rozporządzenia KRI
Podmioty realizujące zadania publiczne mają obowiązek opracowania, wdrożenia, monitorowania i doskonalenia SZBI. Podstawą jest § 19 ust. 1 rozporządzenia Rady Ministrów z 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. 2024 poz. 773), które weszło w życie 23 maja 2024 r. Obowiązek dotyczy całego cyklu, a nie samego przygotowania dokumentacji.
Zgodnie z § 19 ust. 3 wymagania uznaje się za spełnione, jeżeli SZBI opracowano na podstawie Polskiej Normy PN-ISO/IEC 27001. Ustanawianie zabezpieczeń, zarządzanie ryzykiem i audytowanie mają się przy tym opierać na normach związanych. Przepis wymienia PN-ISO/IEC 27002 dla zabezpieczeń oraz PN-ISO/IEC 27005 dla zarządzania ryzykiem.
Tu kryje się pułapka, która wciąż krąży po wzorach dokumentów. Poprzednie rozporządzenie KRI z 12 kwietnia 2012 r. utraciło moc 23 maja 2024 r. W jego tekście jednolitym (Dz.U. 2017 poz. 2247) przepis o SZBI miał numer § 20. Powoływanie się dziś na § 20 rozporządzenia KRI oznacza odesłanie do podstawy, która nie obowiązuje. Zmieniła się też lista norm związanych: w § 19 ust. 3 nie ma już PN-ISO/IEC 24762, dotyczącej odtwarzania techniki informatycznej po katastrofie. Przepisywanie starego wykazu do nowej dokumentacji tworzy więc odwołanie bez podstawy prawnej.
Uwagi wymaga też rozbieżność oznaczeń: rozporządzenie odsyła do PN-ISO/IEC 27001, a Polski Komitet Normalizacyjny publikuje normę jako PN-EN ISO/IEC 27001:2023-08. W praktyce chodzi o tę samą normę w polskim systemie normalizacyjnym.
Organizacje objęte ustawą o krajowym systemie cyberbezpieczeństwa mają odrębny zestaw obowiązków i terminów, opisany we wpisie o tym, co robić po wpisie do wykazu KSC.
Według komunikatu NIK w ponad połowie urzędów gmin skontrolowanych w projekcie grantowym nie wdrożono SZBI, choć jego dokumentacja była wydatkiem kwalifikowalnym. Ustalenia kontroli i obowiązki urzędu po zakończeniu grantu omawia wpis o programie grantowym Cyberbezpieczny Samorząd.
Najczęstsze pytania o system zarządzania bezpieczeństwem informacji
Czy SZBI to to samo co certyfikat ISO 27001?
Nie. System zarządzania bezpieczeństwem informacji to sposób organizacji pracy: zakres, analiza ryzyka, dobór zabezpieczeń, dokumentacja, audyty wewnętrzne i przegląd zarządzania. Certyfikat to potwierdzenie wydawane przez niezależną jednostkę certyfikującą po audycie zgodności z ISO/IEC 27001. System można prowadzić bez certyfikatu, natomiast certyfikatu nie da się uzyskać bez działającego systemu, ponieważ audytor ocenia zapisy z jego funkcjonowania.
Czy trzeba wdrożyć wszystkie 93 zabezpieczenia z Załącznika A?
Nie każde zabezpieczenie musi zostać wdrożone, ale każde musi zostać rozpatrzone. Dla każdej z 93 pozycji Załącznika A zapisuje się decyzję o zastosowaniu lub pominięciu wraz z uzasadnieniem wynikającym z analizy ryzyka. Pominięcie bez zapisanego uzasadnienia jest niezgodnością, którą audytor wykaże w raporcie.
Co zmieniła poprawka klimatyczna do ISO/IEC 27001?
Poprawka ISO/IEC 27001:2022/Amd 1:2024 Climate action changes ukazała się 23 lutego 2024 r. Do punktu 4.1 dodaje wymaganie ustalenia, czy zmiana klimatu jest zagadnieniem istotnym dla organizacji. Do punktu 4.2 dodaje notę, że strony zainteresowane mogą mieć wymagania związane ze zmianą klimatu. Ze wspólnego komunikatu ISO i IAF z lutego 2024 r. wynika, że intencja obu wymagań pozostaje niezmieniona, a poprawka nie ustanawia okresu przejściowego ani obowiązku recertyfikacji.
Czy certyfikaty wydane na ISO/IEC 27001:2013 są jeszcze ważne?
Nie. Okres przejściowy z ISO/IEC 27001:2013 na wydanie z 2022 r. zakończył się 31 października 2025 r., zgodnie z dokumentem obowiązkowym IAF MD 26 w wydaniu drugim. Certyfikaty oparte na wydaniu z 2013 r. wygasły albo zostały wycofane. Organizacja, która chce dziś potwierdzić zgodność, przechodzi audyt certyfikacyjny na zgodność z wydaniem ISO/IEC 27001 z 2022 r.
Jak Pentestica może pomóc
Wspieramy budowę SZBI od strony, od której zaczyna się realna praca: ustalenia zakresu, technicznego rozpoznania środowiska i analizy ryzyka opartej na faktach, a nie na deklaracjach. Prowadzimy testy penetracyjne i audyty bezpieczeństwa IT, pełnimy funkcję vCISO oraz przygotowujemy organizacje do audytu certyfikacyjnego i do wdrożeń wynikających z NIS2, DORA i KRI. Nie jesteśmy jednostką certyfikującą i nie wydajemy certyfikatów ISO. Nasza rola kończy się na doprowadzeniu systemu do stanu, w którym organizacja ma komplet dowodów wymaganych przez audytora zewnętrznego. Mamy ponad 10 lat doświadczenia i setki zrealizowanych projektów. Zakres prac dla konkretnej organizacji pomaga ustalić konfigurator zakresu audytu i testów.
Źródła
- ISO/IEC 27001:2022, karta katalogowa — status normy, wydanie trzecie z października 2022 r. i zakres wymagań dla systemu zarządzania bezpieczeństwem informacji.
- ISO/IEC 27002:2022, karta katalogowa — wytyczne do zabezpieczeń bezpieczeństwa informacji, dokument niecertyfikowalny.
- ISO/IEC 27001:2022/Amd 1:2024, karta katalogowa — poprawka Climate action changes z 23 lutego 2024 r. dotycząca punktów 4.1 i 4.2.
- Wspólny komunikat ISO i IAF, luty 2024 r. — wyjaśnienie, że ogólna intencja wymagań 4.1 i 4.2 pozostaje niezmieniona.
- IAF MD 26, wydanie 2 — obowiązkowe wymagania przejścia na ISO/IEC 27001:2022 wraz z datą zakończenia okresu przejściowego.
- Komunikat PKN o PN-EN ISO/IEC 27001:2023-08 — informacja o publikacji normy 22 sierpnia 2023 r. i wycofaniu PN-EN ISO/IEC 27001:2017-06.
- Rozporządzenie KRI (Dz.U. 2024 poz. 773) — tekst rozporządzenia z 21 maja 2024 r. wraz z § 19 dotyczącym SZBI w podmiotach realizujących zadania publiczne.
- Karta aktu prawnego RCL — potwierdzenie utraty mocy rozporządzenia KRI z 12 kwietnia 2012 r. z dniem 23 maja 2024 r.
- Przewodnik wdrożeniowy BSI do ISO/IEC 27001 — omówienie struktury rozdziałów 4–10 oraz układu Załącznika A.

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.