ISO/IEC 27001:2022 pokrywa 69% wymagań KSC w pełnym zakresie — to jest dobra wiadomość dla każdej organizacji z działającym SZBI. Pozostałe 30% wykracza poza normę i koncentruje się w trzech blokach, których ISO 27001 nie adresuje, bo nie po to powstała. Jeśli traktujesz certyfikat jako wystarczającą podstawę pod audyt KSC, w tym tekście pokazuję gdzie i dlaczego to założenie nie wytrzyma audytu.
Dlaczego 30% wymagań KSC wykracza poza ISO 27001
ISO 27001 jest normą dobrowolną. Mówi organizacji jak zarządzać bezpieczeństwem informacji wewnętrznie: jak identyfikować ryzyka, jak wybierać kontrole, jak prowadzić nadzór, jak budować świadomość. Te wymagania kończą się na granicy organizacji.
KSC nakłada warstwę dodatkową — obowiązki wobec państwa. Raportowanie do CSIRT, podłączenie do infrastruktury krajowej, współpraca z organem nadzorczym, audyt według ustawowo określonych warunków. To nie są „surowsze kontrole ISO”. To inna kategoria wymagań — proceduralna, formalna, ze ściśle zdefiniowanym kontrahentem (państwo) i ściśle zdefiniowanym formatem działania.
Z mapowania 268 kontrolek KSC na ISO/IEC 27001:2022 wynika konkretny rozkład: 69% pokrywa się w pełnym zakresie, 30% jest „surowszych” niż ISO, mniej niż 1% to przypadki gdzie ISO wymaga więcej. Ale liczba „30%” rozkłada się nierównomiernie. W blokach governance, ryzyka i kontroli technicznych ISO pokrywa 70–87% wymagań. Rozjazd koncentruje się w trzech blokach poniżej.
System S46 i współpraca z CSIRT — 94% wymagań poza ISO
Blok E listy audytowej KSC obejmuje 16 kontrolek. Z nich 15 wykracza poza ISO 27001 — bo norma dobrowolna z definicji nie wymaga podłączenia do konkretnego systemu państwowego.
Co realnie trzeba zrobić:
- złożyć wniosek o dostęp do S46 z oświadczeniem (FAQ 7.3),
- wyznaczyć użytkowników z zakresem uprawnień,
- zapewnić stałe dyżury umożliwiające zgłaszanie incydentów,
- uwierzytelniać dostęp przez Węzeł Krajowy (profil zaufany),
- spełnić wymagania techniczne stacji roboczej: przeglądarka oparta na Chromium, łącze min. 10 Mbps, ochrona przed nieautoryzowanym dostępem.
Żadne z tych wymagań nie jest „uzupełnieniem ISO”. To budowa nowego kawałka procesu, z osobnymi rolami, osobnym SLA (dyżury) i osobną integracją techniczną. CISO który czyta ISO 27001 nie znajdzie wskazówki jak to zrobić — bo norma nie sugeruje istnienia takiej kategorii obowiązków. Większość wymagań tego bloku opiera się na FAQ Ministerstwa Cyfryzacji, nie na artykule ustawy — wrócę do tego przy incydentach.
Audyt bezpieczeństwa — 80% wymagań poza ISO
Dla podmiotów kluczowych (PK) KSC definiuje audyt bezpieczeństwa systemu informacyjnego jako odrębną konstrukcję prawną:
- obowiązkowy co najmniej raz na trzy lata (art. 15 ust. 1 KSC),
- wyłącznie zewnętrzny, przez akredytowaną jednostkę,
- prowadzony przez audytora z certyfikatem z listy Ministra,
- prowadzony pod warunkiem że audytor nie uczestniczył w budowie audytowanego systemu (zakaz audytowania własnej pracy),
- na koszt podmiotu, z obowiązkiem wdrożenia zaleceń w wyznaczonym terminie.
ISO 27001 wymaga audytów wewnętrznych jako element SZBI, ale nie precyzuje częstotliwości, nie wymaga audytora zewnętrznego i nie nakłada wymagań certyfikacyjnych na osobę audytora. Audyt wewnętrzny prowadzony przez własny zespół w ramach ISO 27001 nie spełnia warunków KSC. Pierwszy obowiązkowy audyt dla PK to 3 kwietnia 2028 — co oznacza że organizacja powinna mieć kontrahenta wybranego z wyprzedzeniem, a SZBI w stanie nadającym się do oceny przez kogoś z zewnątrz co najmniej rok wcześniej.
Dla podmiotów ważnych (PW) audyt nie jest obligatoryjny w cyklu, lecz może być żądany przez organ. Reszta wymagań SZBI jest identyczna z PK.
Zarządzanie incydentami — 52% wymagań poza ISO, z twardymi terminami
ISO 27001 mówi: ustanów proces zarządzania incydentami, wykrywaj, reaguj, ucz się. Nie nakłada ram czasowych. Nie wymaga konkretnego kanału. Nie definiuje treści raportu.
KSC nakłada twardy schemat:
- wczesne ostrzeżenie w 24 godziny od wykrycia,
- pełne zgłoszenie w 72 godziny,
- sprawozdanie końcowe w 30 dni,
- zgłoszenie do CSIRT sektorowego we wskazanym formacie,
- udokumentowany moment wykrycia (od niego liczone są terminy),
- procedura musi obejmować systemy automatyki przemysłowej (OT/ICS), jeśli organizacja je posiada,
- umowy z dostawcami ICT muszą zawierać obowiązek niezwłocznego informowania podmiotu o incydentach.
Tych wymagań organizacja z ISO 27001 nie spełnia automatycznie — bo ISO ich nie generuje. Część z nich (sprawozdanie końcowe, OT/ICS, klauzule w umowach z dostawcami) ma podstawę w FAQ Ministerstwa Cyfryzacji, nie w artykule ustawy. Z perspektywy audytu to bez znaczenia — są obowiązkowe. Z perspektywy zarządzania ryzykiem regulacyjnym warto wiedzieć, że tę warstwę wymagań organ może doprecyzować bez nowelizacji ustawy.
Co z tego wynika dla CISO z certyfikatem ISO 27001
ISO/IEC 27001:2022 jest solidnym fundamentem pod KSC, ale nie jest stanem zgodności. 70% drogi przebiegnie tak samo. Pozostałe 30% to trzy osobne projekty wdrożeniowe: integracja z S46, audyt zewnętrzny PK, dostosowanie obsługi incydentów do ram czasowych i formatów państwowych. Każdy z nich ma osobny koszt, osobnego właściciela i osobny harmonogram.
Najbardziej zaskakujący dla organizacji z ISO jest blok E — bo to nie jest „dopisanie procedury”, to integracja z infrastrukturą zewnętrzną z wymaganiami technicznymi po obu stronach. Im wcześniej trafi do budżetu i harmonogramu, tym mniejsze prawdopodobieństwo, że stanie się wąskim gardłem przed kwietniem 2027 — terminem wdrożenia SZBI i podłączenia do S46.
Liczby pochodzą z autorskiej listy audytowej KSC — mapowania 268 kontrolek ustawowych na ISO/IEC 27001:2022. Wartości procentowe ilustrują relację między obu reżimami; nie są oficjalną statystyką Ministerstwa Cyfryzacji ani ENISA.