Czy ISO 27001 wystarczy do zgodności z ustawą o KSC

Nie wystarczy. To jest cała odpowiedź na pytanie z tytułu i nie warto jej rozcieńczać: certyfikat jest dobrowolny, ustawa obowiązuje z mocy prawa, a dokument wydany przez jednostkę certyfikującą nie znosi obowiązku nałożonego przepisem.

Zdanie odwrotne, które słychać równie często – „norma to zupełnie co innego niż ustawa” – jest jednak tak samo nieprawdziwe i kosztuje więcej. Pokrycie treściowe jest duże. Na tyle duże, że firma z żywym systemem zarządzania bezpieczeństwem informacji ma przed sobą kilka tygodni pracy, a nie kwartał. Poniżej rozdzielamy jedno od drugiego: co certyfikat zamyka, czego nie zamknie nigdy i w jakiej kolejności to uzupełnić.

Norma i ustawa: dwie różne konstrukcje

Zanim porównamy wymagania, trzeba zauważyć jedno: oba dokumenty są zbudowane inaczej i odpowiadają na inne pytanie. Norma pyta, czy zarządzasz bezpieczeństwem w sposób powtarzalny. Ustawa pyta, czy wykonałeś to, co masz nakazane, i czy zrobiłeś to na czas.

Najważniejszy jest drugi wiersz. Zakres systemu zarządzania bezpieczeństwem informacji – ISMS w języku normy – to Twoja decyzja i wiele certyfikatów opisuje starannie wybrany wycinek organizacji. Zakres obowiązków ustawowych wynika z tego, czym firma się zajmuje. Jeśli w certyfikacie stoi „utrzymanie centrum danych w lokalizacji X”, a ustawa dotyczy całej platformy obsługującej klientów, masz papier, który nie obejmuje tego, o co zapyta organ. To jest najczęstsza luka, jaką widzimy, i jedyna, która potrafi unieważnić cały argument o pokryciu.

Co certyfikat naprawdę załatwia

Teraz dobra wiadomość – należy się każdemu, kto przeszedł certyfikację. Ustawa wymaga systemu zarządzania bezpieczeństwem informacji (SZBI), a to dokładnie ten sam gatunek konstrukcji, który opisuje norma. Nie trzeba budować drugiego systemu obok pierwszego. Trzeba zbudować tabelę zgodności: te same dowody, opisane numerami przepisów zamiast numerami zabezpieczeń.

Warunek jest jeden i nie jest formalny: system musi żyć poza tygodniem audytu. Rejestr ryzyka aktualizowany raz do roku, dzień przed wizytą jednostki certyfikującej, przejdzie certyfikację i nie przejdzie konfrontacji z incydentem.

Czego certyfikat nie załatwi nigdy

Cztery obowiązki nie mają odpowiednika w normie. Nie dlatego, że norma jest słaba, tylko dlatego, że norma nie zna pojęcia organu nadzoru.

1. Wpis do wykazu podmiotów kluczowych i ważnych

Do 3 października 2026 r. podmiot objęty ustawą musi sam ustalić swój status i sam zgłosić się do wykazu. Organ nikogo nie wskazuje z urzędu, a jednostka certyfikująca nie zna takiej czynności, bo w normie jej nie ma. To czysta formalność administracyjna i właśnie dlatego umyka najczęściej – nikt jej nie planuje, bo nikt jej nie ma w harmonogramie ISMS.

Kwalifikacja wynika z załączników. Firma sama sprawdza swój sektor i próg wielkości, żeby ustalić, czy jest podmiotem kluczowym, czy ważnym. Krążące po mediach szacunki liczby objętych organizacji rozjeżdżają się o rząd wielkości i żadnego oficjalnego wyliczenia nikt nie opublikował, więc jedyna wiarygodna odpowiedź to lektura załączników nr 1 i 2.

2. Zegar zgłaszania incydentów

Zabezpieczenia A.5.24–A.5.26 wymagają procedury obsługi incydentu: kto klasyfikuje, kto decyduje, jak się to dokumentuje. Norma nie zna natomiast terminu liczonego wobec organu.

Ustawa taki zegar wprowadza i liczy go w godzinach, nie w dniach roboczych. Schemat jest dwustopniowy, tak jak w dyrektywie NIS2: najpierw wczesne ostrzeżenie, potem pełne zgłoszenie – zwykle opisywane jako 24 i 72 godziny od wykrycia incydentu istotnego. Twój dotychczasowy proces jest dobrą podstawą, ale wymaga dodatkowej gałęzi: kto w środku nocy decyduje, że incydent jest „istotny”, i kto fizycznie wysyła zgłoszenie. Same liczby godzin, adresata i formę zgłoszenia sprawdź w tekście nowelizacji, zanim wpiszesz je do procedury – wiąże przepis, a nie skrót z artykułu.

3. Audyt z art. 15 ust. 1

Art. 15 ust. 1 nakłada na podmiot kluczowy obowiązek przeprowadzenia audytu bezpieczeństwa systemu informacyjnego na własny koszt, co najmniej raz na trzy lata. Audyt certyfikacyjny go nie zastępuje: inna podstawa prawna, inny zakres, inny adresat wyników. Certyfikat pomaga tu inaczej, ale realnie: większość dowodów zebranych dla normy nadaje się do przedstawienia audytorowi bez przerabiania. Skraca się przygotowanie, a nie obowiązek.

4. Odpowiedzialność kierownika podmiotu

Rozdział 5.1 normy wymaga przywództwa i zaangażowania kierownictwa, ale zwraca się do organizacji. Ustawa zwraca się do konkretnej osoby. Dla podmiotów kluczowych kara może wynieść do 10 mln euro albo 2% obrotu, dla podmiotów ważnych do 7 mln euro albo 1,4% obrotu, a w najcięższych przypadkach ustawa przewiduje karę do 100 mln zł. Osobno odpowiada kierownik podmiotu – tu kara sięga 300% wynagrodzenia.

Praktyczny wniosek jest prosty: akceptacja kierownictwa musi być udokumentowana i musi się opierać na czymś sprawdzalnym. Raport z audytu ISMS do tego nie wystarcza, bo opisuje stan systemu zarządzania, a nie odporność systemów.

Skąd się wzięło „80% pokrycia”

Na polskich stronach doradczych powtarza się szacunek, że norma ISO/IEC 27001 pokrywa około 80% wymagań SZBI z ustawy o KSC. Warto wiedzieć, skąd się bierze: to liczba marketingowa, przepisywana ze strony na stronę, a nie wynik opublikowanego mapowania przepis po przepisie. Nikt nie pokazuje metody liczenia ani tego, czy liczone są jednostki redakcyjne, obszary tematyczne, czy nakład pracy.

Procent i tak nie odpowiada na pytanie, które ma znaczenie. Zgodność nie działa jak egzamin, który zdaje się na 80 punktów. Organ nie sprawdzi, ile procent masz zrobione – sprawdzi, czy jesteś w wykazie, czy zgłosiłeś incydent w terminie i czy przeprowadziłeś audyt. Dlatego zamiast liczby lepiej mieć listę z poprzedniej sekcji, bo z listy wynika harmonogram, a z procentu nie wynika nic.

Co dostarczamy do audytu z art. 15

Audyt przeprowadza jeden z trzech podmiotów wskazanych w ustawie: akredytowana jednostka oceniająca zgodność, sektorowy zespół CSIRT albo co najmniej dwóch audytorów z certyfikatami z listy Ministra Cyfryzacji – CISA, CISM, CRISC, CISSP, CIA, audytor wiodący ISO/IEC 27001 lub ISO 22301, ISA/IEC 62443 Cybersecurity Expert. Audytora warto wybrać z wyprzedzeniem, bo termin audytu wyznacza kolejność wcześniejszych prac.

Audytor patrzy na proces: czy organizacja zleca testy, czy robi to regularnie i czy wyciąga z wyników wnioski. Ma po temu wyraźną podstawę, bo art. 8 ust. 1 pkt 2 lit. b wymaga, żeby SZBI obejmował „testowanie systemu informacyjnego”.

Z jednego projektu testowego wychodzi komplet materiału, o który audytor poprosi:

• testy – zakres, metodyka i daty, czyli dowód, że testowanie systemu informacyjnego rzeczywiście się odbyło;
• znaleziska z dowodami – kroki odtworzenia i materiał potwierdzający, a nie sam wynik skanera;
• oceny ryzyka – waga każdego znaleziska, w formie, którą można wprost przenieść do rejestru ryzyka;
• działania naprawcze – zalecenia przypisane do konkretnego systemu i możliwe do rozliczenia;
• pisemne potwierdzenie z retestu – że poprawki działają, z datą weryfikacji.

Testy prowadzą pentesterzy z certyfikatami klasy OSCP, a formę dokumentów znamy z drugiej strony stołu: firma Haxoris ma własny certyfikat ISO 27001 od TÜV SÜD, więc z własnego wdrożenia wiemy, jak wygląda dowód, który przechodzi przez audyt. W takiej formie piszemy raporty.

Różnicę między audytem a testem rozbieramy szerzej w artykule o audycie cyberbezpieczeństwa.

Punkt wspólny: A.8.8 i testowanie systemu informacyjnego

Jest jedno miejsce, w którym oba reżimy chcą dokładnie tego samego – i w którym w praktyce najczęściej brakuje dowodów.

Zabezpieczenie A.8.8 wymaga zarządzania podatnościami technicznymi: pozyskiwania informacji o podatnościach używanych systemów, oceny narażenia i wdrożenia odpowiednich działań. Zabezpieczenie A.8.29 dokłada do tego testy bezpieczeństwa w rozwoju i przy odbiorze. Po stronie ustawy art. 8 ust. 1 pkt 2 lit. b wymaga, żeby SZBI obejmował bezpieczeństwo w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego, „w tym testowanie systemu informacyjnego”.

To jest jedna praca, nie dwie. Na bieżąco – analiza podatności, która wychwytuje nowo opublikowane błędy w używanych komponentach. Okresowo – test penetracyjny, który sprawdza, czy wdrożone zabezpieczenia faktycznie zatrzymują atakującego. Jeden projekt daje dowód do obu reżimów, o ile raport wiąże znaleziska z konkretnymi wymaganiami – i dokładnie tak przygotowujemy raporty do certyfikacji ISO 27001 oraz pod ustawę o KSC i dyrektywę NIS2.

Gdzie dokładnie biegnie granica między skanem a testem, opisaliśmy w artykule skanowanie podatności a testy penetracyjne.

Terminy, które wyznaczają kolejność prac

Najbliższy termin jest jednocześnie najtańszy do wykonania i najłatwiejszy do przegapienia, bo nie wymaga ani projektu, ani budżetu – tylko decyzji, kto to zrobi.

Masz certyfikat: zrób to w tej kolejności

1. Porównaj zakresy. Czy zakres ISMS obejmuje usługę, przez którą firma podlega ustawie? To pierwsza rzecz do sprawdzenia i najgroźniejsza w skutkach.
2. Ustal status i zgłoś się do wykazu. Sektor i próg wielkości z załączników, potem wpis do 3 października 2026 r.
3. Zbuduj tabelę zgodności. Wymagania ustawy w jednej kolumnie, zabezpieczenia z Załącznika A i numery istniejących dowodów w drugiej. Większość wierszy wypełnisz numerem dokumentu, który już masz.
4. Uzupełnij trzy brakujące obszary. Zgłaszanie incydentów w ustawowych terminach liczonych w godzinach, udokumentowana akceptacja kierownictwa i przygotowanie do audytu z art. 15.
5. Sprawdź skuteczność. Test penetracyjny, który i tak robisz dla A.8.29, pokrywa jednocześnie wymóg testowania systemu informacyjnego – pod warunkiem że raport to nazywa.

Realny nakład dla firmy z żywym ISMS: kilka tygodni, w większości na tabelę zgodności i na procedurę zgłoszeniową.

Nie masz certyfikatu

Nie ma obowiązku certyfikacji – ustawa wymaga systemu i jego skuteczności, a nie papieru. Załącznik A pozostaje mimo to najlepiej przemyślanym planem budowy takiego systemu, bo tłumaczy obowiązki na konkretne zabezpieczenia, których nie trzeba wymyślać od nowa.

Dwie drogi, obie sensowne:

• Z certyfikacją, jeśli dowód i tak jest potrzebny do ankiet bezpieczeństwa klientów i do przetargów. Cykl certyfikacyjny trwa zwykle trzy lata, z audytami nadzoru co roku.
• Bez certyfikacji, traktując Załącznik A jako strukturę. Oszczędzasz koszt audytu certyfikacyjnego i tracisz argument handlowy.

Techniczna część jest w obu wariantach identyczna i tylko jej nie da się przesunąć na później: trzeba umieć pokazać, że zabezpieczenia działają.

ISO 27001 a ustawa o KSC – najczęstsze pytania

Powiązane usługi Haxoris: testy penetracyjne do certyfikacji ISO 27001 · testy penetracyjne zgodne z NIS2 i ustawą o KSC · testy penetracyjne aplikacji i infrastruktury