KSC i ISO 27001 - czy certyfikat oznacza spełnienie wszystkich obowiązków?

W skrócieCertyfikat ISO/IEC 27001 nie oznacza spełnienia wszystkich obowiązków z ustawy o krajowym systemie cyberbezpieczeństwa (KSC). Ustawa wymaga systemu zarządzania bezpieczeństwem informacji (SZBI) z art. 8, a nie certyfikatu. Norma daje fundament i dowody, ale nie załatwia wpisu do wykazu, zgłoszeń incydentów w 24 i 72 godziny, szkolenia kierownika ani audytu z art. 15.

Zarząd, który od kilku lat utrzymuje certyfikat ISO/IEC 27001, może zadać sobie pytanie: skoro mamy certyfikowany system, czego jeszcze wymaga od nas ustawa o KSC? Od odpowiedzi zależy budżet i harmonogram na najbliższe miesiące. Podmioty, które w dniu wejścia w życie nowelizacji spełniały przesłanki uznania za podmiot kluczowy albo podmiot ważny, mają na wykonanie obowiązków z rozdziału 3 ustawy czas do 3 kwietnia 2027 r. (art. 33 ust. 1 ustawy nowelizującej z 23 stycznia 2026 r.).

Krótka odpowiedź: certyfikat to mocny punkt startu, ale ustawa i norma to dwa różne porządki. Ustawa nakłada obowiązki prawne, za które odpowiada kierownik podmiotu i za które grożą kary. Norma opisuje dobrowolny system zarządzania, którego zakres organizacja ustala sama. Jeśli dopiero porządkujesz podstawy, zacznij od naszego przewodnika po NIS2 i ustawie o KSC, a tutaj wejdź w szczegóły.

W tym tekście porównujemy SZBI z art. 8 ustawy z systemem według normy, pokazujemy, gdzie zakres certyfikatu może rozmijać się z zakresem ustawy, i wymieniamy obowiązki, których certyfikat z natury nie obejmuje. Na końcu znajdziesz plan uzupełnienia luk w sześciu krokach.

Ustawa o KSC wymaga SZBI, a nie certyfikatu

Podstawowy obowiązek 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 lit. a-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-5).

W tekście ujednoliconym ustawy według stanu na 8 października 2026 r. nie ma żadnego odesłania do normy ISO/IEC 27001. Ustawa nie każe się certyfikować i nie przewiduje, że certyfikat zastępuje wykonanie któregokolwiek obowiązku. Normy pojawiają się w przepisach w kilku miejscach, ale żadne z nich nie tworzy obowiązku certyfikacji. Najważniejsze są cztery:

• Kwalifikacje audytora. Rozporządzenie Ministra Cyfryzacji z 12 października 2018 r. (Dz.U. 2018 poz. 1999), wydane na podstawie art. 15 ust. 8, wymienia 11 certyfikatów uprawniających do przeprowadzenia audytu. Dwa z nich to certyfikaty audytora wiodącego według PN-EN ISO/IEC 27001 i PN-EN ISO 22301. To kwalifikacja osoby, która audytuje, a nie wymóg wobec audytowanej firmy.
• Rekomendacje organów. Rekomendacje i wytyczne sektorowe przygotowuje się z uwzględnieniem m.in. Polskich Norm przenoszących normy europejskie (art. 42 ust. 8). Minister ma też rekomendować i wspierać wykorzystywanie europejskich lub międzynarodowych standardów (art. 45 ust. 1 pkt 7).
• Zestawienie wymogów norm. Minister właściwy do spraw informatyzacji „może opublikować” w Biuletynie Informacji Publicznej zestawienie wymogów dokumentów normalizacyjnych, „których wykonywanie realizuje obowiązki wynikające z przepisów ustawy” (art. 45 ust. 3). Projekt przeszedł 30-dniowe konsultacje, które trwały do 10 czerwca 2026 r. Ministerstwo zapowiedziało, że zestawienie będzie miało „charakter pomocniczy i informacyjny”. Ostatecznej wersji nie znaleźliśmy (stan na 12 października 2026 r.).
• Dostawcy chmury, centrów danych i usług zarządzanych. Dostawcy usług chmurowych, centrów przetwarzania danych, usług zarządzanych i kilku innych usług cyfrowych stosują w ramach SZBI środki z rozporządzenia wykonawczego Komisji (UE) 2024/2690 (art. 8b ust. 1). Wymogi tego rozporządzenia „opierają się na normach europejskich i międzynarodowych takich jak ISO/IEC 27001, ISO/IEC 27002 i ETSI EN 319401” (motyw 3 rozporządzenia 2024/2690). Dla tych firm norma jest bliżej prawa, ale obowiązuje tekst rozporządzenia, a nie certyfikat.

Ministerstwo Cyfryzacji ujęło to wprost w zaproszeniu do konsultacji zestawienia norm na gov.pl: „wdrożenie określonej normy, standardu lub uzyskanie certyfikatu odnoszącego się wyłącznie do części obowiązków wynikających z ustawy nie zwalnia podmiotu z obowiązku realizacji pozostałych wymagań przewidzianych przepisami ustawy o KSC”. To stanowisko ministerstwa, a nie przepis, ale trudno o czytelniejszą wskazówkę. Autorzy projektu pisali podobnie w ocenie skutków regulacji (OSR): obowiązki pokrywają się z normami stosowanymi dobrowolnie i wielu przedsiębiorców wdraża systemy zgodne z ISO 27001 i ISO 22301, ale „nie są to oczywiście jedyne sposoby zapewnienia zgodności z projektowanymi przepisami”.

SZBI z art. 8 a system zarządzania według ISO/IEC 27001

Oba systemy mają ten sam rdzeń: szacujesz ryzyko, dobierasz zabezpieczenia, sprawdzasz, czy działają, i poprawiasz. Ministerstwo Cyfryzacji opisuje rolę kierownika podmiotu w tym samym 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). Różnice zaczynają się tam, gdzie kończy się metoda, a zaczyna prawo.

Najważniejsza praktyczna różnica dotyczy wyłączeń. W normie wolno pominąć zabezpieczenie, jeśli uzasadnisz to w deklaracji stosowania. Ustawa wymienia obszary środków wprost (art. 8 ust. 1 pkt 2 lit. a-n) i nie zawiera przepisu, który pozwalałby któryś z nich pominąć. Pozwala natomiast dobrać intensywność do ryzyka: środki mają być odpowiednie i proporcjonalne, z uwzględnieniem m.in. kosztów wdrożenia i wielkości podmiotu, a szyfrowanie i uwierzytelnianie wieloskładnikowe stosuje się „w stosownych przypadkach” (lit. k i l). Jeśli w Twojej deklaracji stosowania wyłączono na przykład zabezpieczenia dotyczące dostawców albo kryptografii, sprawdź, czy da się to obronić wobec lit. e i lit. k.

Druga różnica to ryzyko. Ustawa mówi o ryzyku „wystąpienia incydentu” w systemie wpływającym na usługę, a przy doborze środków każe brać pod uwagę także skutki społeczne i gospodarcze. Jeśli kryteria w Twojej analizie ryzyka liczą tylko straty własne firmy, dopisz kryterium wpływu na odbiorców usługi. Przyda się to również przy klasyfikacji incydentów, bo incydent poważny ustawa definiuje m.in. przez wpływ na świadczenie usługi i poważną szkodę u innych osób (art. 2 pkt 7).

Zakres: systemy objęte ustawą a zakres certyfikatu

Od tego porównania warto zacząć, bo tu najłatwiej przeoczyć lukę. Zakres certyfikatu wybiera organizacja: może obejmować tylko dział IT, serwerownię albo wytwarzanie oprogramowania. Zakres SZBI według ustawy wyznacza usługa, czyli system informacyjny wykorzystywany w procesach wpływających na jej świadczenie (art. 8 ust. 1). System informacyjny to w ustawie nie tylko serwery i aplikacje, ale także „urządzenie lub grupę połączonych urządzeń i oprogramowania zaprogramowanych w celu przetwarzania danych” wraz z danymi (art. 2 pkt 14). Ministerstwo Cyfryzacji potwierdza, że definicja „uwzględnia także systemy automatyki przemysłowej” (odpowiedź 6.6).

Przykład. Przedsiębiorstwo ciepłownicze zatrudniające 320 osób od trzech lat ma certyfikat ISO/IEC 27001 obejmujący dział IT i serwerownię. Poza zakresem certyfikatu zostały: system nadzoru i sterowania siecią ciepłowniczą (SCADA, czyli system, który zbiera dane z instalacji i steruje nią zdalnie), sterowanie węzłami cieplnymi, system rozliczeń oraz elektroniczne biuro obsługi klienta. Firma jest podmiotem kluczowym: przedsiębiorstwo energetyczne z koncesją na wytwarzanie i dystrybucję ciepła znajduje się w załączniku nr 1 do ustawy, a 320 osób to więcej niż próg średniego przedsiębiorstwa (art. 5 ust. 1 pkt 1). Usługą jest dostarczanie ciepła, więc system sterowania siecią należy do SZBI bez dyskusji: steruje procesami, od których zależy usługa, a jego awaria może przerwać dostawy.

Z systemem rozliczeń i obsługą klienta jest trudniej. Ministerstwo zaleca brać pod uwagę nie tylko procesy techniczne, ale także procesy „wymagane przez przepisy prawa np. procesy służące realizacji uprawnień użytkownika, klienta, konsumenta czy abonenta”, a z SZBI wyłączać tylko systemy „w pełni odseparowane od świadczenia usługi” (odpowiedź 3.4, stanowisko niewiążące). Jeśli przez elektroniczne biuro obsługi odbiorcy zgłaszają awarie i składają reklamacje, trudno uznać je za odseparowane. System kadrowy, który nie łączy się z siecią technologiczną i nie ma wpływu na usługę, może zostać poza SZBI, ale decyzję i jej uzasadnienie trzeba zapisać.

Masz dwie drogi. Możesz rozszerzyć zakres certyfikatu przy najbliższym audycie albo prowadzić SZBI według ustawy szerzej niż certyfikat. Ustawa nie wymaga, by zakresy były identyczne, bo w ogóle nie wymaga certyfikatu. Wymaga natomiast, by SZBI obejmował wszystkie systemy wpływające na usługę. Ministerstwo dopuszcza jeden SZBI dla wielu systemów, a nawet dla całego podmiotu, z osobnymi elementami dla poszczególnych systemów (odpowiedzi 3.31 i 14.7).

Co certyfikat realnie daje: mapa art. 8 i obszarów normy

Utrzymywany system według ISO/IEC 27001 to mocny punkt startu przed terminem 3 kwietnia 2027 r. Daje cztery rzeczy, których zbudowanie od zera zajmuje dużo czasu.

• Działający proces zarządzania ryzykiem. Metoda, rejestr ryzyk, plan postępowania z ryzykiem i właściciele ryzyk to dokładnie to, czego wymaga „prowadzenie systematycznego szacowania ryzyka” (art. 8 ust. 1 pkt 1). Trzeba go rozszerzyć o zakres z ustawy, ale nie trzeba go budować od nowa.
• Dokumentacja do przeniesienia. Ministerstwo Cyfryzacji pisze, że organizacje z SZBI według jednego ze standardów „mogą wykorzystać i dostosować już istniejącą dokumentację”, i zastrzega, że „sama dokumentacja to za mało” (odpowiedź 3.6). Polityki tematyczne z art. 8 ust. 1 pkt 2 lit. a ministerstwo wprost utożsamia z politykami tematycznymi z normy ISO 27001 (odpowiedź 3.3).
• Dowody działania. Audyty wewnętrzne, przeglądy zarządzania, rejestr incydentów, zapisy ze szkoleń i wyniki testów to dokumentacja operacyjna w rozumieniu art. 10 ust. 4, czyli „zapisy poświadczające wykonywanie czynności”. Organ może zażądać „dowodów realizacji wymogów” z art. 8 ust. 1 (art. 53 ust. 2 pkt 6), a ministerstwo podkreśla, że liczy się „udowodnienie stosowania przepisów ustawy a nie przedstawienie formalnie poprawnych dokumentów” (odpowiedź 11.6).
• Argument w łańcuchu dostaw. Klienci objęci ustawą oceniają dostawców, w tym „ogólną jakość produktów ICT, usług ICT i procesów ICT” (art. 8 ust. 2 pkt 2). Ministerstwo zauważa, że certyfikacja u dostawców ułatwia zarządzanie bezpieczeństwem łańcucha dostaw (odpowiedź 3.3). Jeśli Twoja firma dostarcza usługi IT podmiotom kluczowym i ważnym, certyfikat jest dla nich czytelnym sygnałem.

Poniższa mapa pokazuje, jak elementy art. 8 odpowiadają obszarom typowego SZBI według normy. Opis normy jest celowo ogólny, bez cytowania jej treści. Prawa kolumna działa jak lista kontrolna: to rzeczy do dopisania, nawet jeśli certyfikat jest aktualny.

Czego certyfikat nie załatwia: obowiązki poza SZBI

Część obowiązków ustawowych w ogóle nie należy do systemu zarządzania. To relacje z państwem: wykaz, system S46, zespoły CSIRT i organ nadzoru. Norma ich nie opisuje, a audyt certyfikacyjny nie potwierdza ich wykonania. Za większość z nich kierownik podmiotu odpowiada także wtedy, gdy powierzył je innej osobie (art. 8c ust. 1 i 3).

Dwa obowiązki z tej listy mają wymiar osobisty. Szkolenie przechodzi kierownik podmiotu oraz osoba, której powierzono jego obowiązki w zakresie cyberbezpieczeństwa (art. 8e ust. 1). W spółce kapitałowej kierownikiem w rozumieniu ustawy jest członek zarządu, a przy zarządzie wieloosobowym jego członkowie (art. 2 pkt 8a ustawy o KSC w związku z art. 3 ust. 1 pkt 6 ustawy o rachunkowości). Termin pierwszego szkolenia i sposoby dokumentowania udziału opisujemy w artykule o obowiązkowym szkoleniu zarządu z KSC. Drugi obowiązek dotyczy osób, które mają realizować zadania z art. 8 lub art. 11: kierownik dopuszcza je do tych zadań dopiero po otrzymaniu informacji z KRK o niekaralności za przestępstwa przeciwko ochronie informacji (art. 8f ust. 1). Za niewykonanie obowiązków z art. 8e albo art. 8f kierownikowi może grozić kara do 300% wynagrodzenia liczonego jak ekwiwalent za urlop, a w podmiocie publicznym do 100% (art. 73a ust. 1 i 4-5). Pierwsze takie kary mogą zostać nałożone dopiero po 3 kwietnia 2028 r. (art. 35 ustawy nowelizującej), ale same obowiązki trzeba wykonać wcześniej.

Lista nie skraca się po certyfikacji, bo dotyczy prawa, a nie systemu zarządzania. Kolejne kroki po wpisie, w tym rolę systemu S46 w zgłoszeniach, omawiamy w tekście o tym, co robić, gdy firma jest już w Wykazie KSC.

Ostatni wiersz tabeli jest na razie teoretyczny. Według stanu na 12 października 2026 r. minister nie wydał żadnej decyzji o uznaniu dostawcy za dostawcę wysokiego ryzyka, a przepisy o tej procedurze są przedmiotem wniosku Prezydenta do Trybunału Konstytucyjnego (sprawa K 19/26, w toku). Inwentaryzacja sprzętu i oprogramowania przyda się jednak niezależnie od wyniku tej sprawy, bo jest częścią zarządzania aktywami (art. 8 ust. 1 pkt 2 lit. m).

Audyt certyfikacyjny a audyt z art. 15

Skoro jednostka certyfikująca regularnie przeprowadza audyty, czy to nie wystarczy? Nie. Ustawa nie przewiduje zaliczenia audytu certyfikacyjnego jako audytu z art. 15, a oba badania różnią się w kilku istotnych punktach.

• Kto musi. Audyt z art. 15 dotyczy podmiotu kluczowego, który przeprowadza go „na własny koszt, co najmniej raz na 3 lata”, licząc od podpisania raportu z ostatniego audytu (art. 15 ust. 1). Podmiot ważny nie ma obowiązku okresowego audytu, ale organ może go nakazać po incydencie poważnym albo innym naruszeniu ustawy (art. 15 ust. 1b). Pozostałe różnice między kategoriami zebraliśmy w tekście o tym, czym podmiot kluczowy różni się od podmiotu ważnego.
• Termin pierwszego audytu. Podmioty kluczowe, które spełniały przesłanki w dniu wejścia w życie nowelizacji, przeprowadzają pierwszy audyt do 3 kwietnia 2028 r. (art. 33 ust. 2 ustawy nowelizującej), a pozostałe w ciągu 24 miesięcy od spełnienia przesłanek (art. 16 pkt 2). Dawni operatorzy usług kluczowych, którzy mieli audyt przed nowelizacją, zachowują swój trzyletni cykl (art. 25 ustawy nowelizującej, tak też ministerstwo w odpowiedzi 9.5).
• Kto może audytować. Akredytowana jednostka oceniająca zgodność „w zakresie właściwym do podejmowanych ocen bezpieczeństwa systemów informacyjnych”, co najmniej dwóch audytorów z certyfikatami z rozporządzenia albo z wymaganą praktyką, albo CSIRT sektorowy, jeżeli jego audytorzy spełniają te same warunki (art. 15 ust. 2).
• Niezależność. Audytu nie może przeprowadzić osoba, która w podmiocie realizuje zadania z art. 8 i art. 9-13 albo realizowała je w ciągu roku przed rozpoczęciem audytu (art. 15 ust. 2a). Pracownik, który na co dzień prowadzi analizę ryzyka w SZBI, nie może więc audytować tego samego podmiotu.
• Wynik. Audytor sporządza pisemne sprawozdanie (art. 15 ust. 5), a podmiot kluczowy przekazuje kopię raportu organowi właściwemu do spraw cyberbezpieczeństwa w 3 dni robocze (art. 15 ust. 1a).

Ministerstwo Cyfryzacji dodaje dwie wskazówki. Audyt z art. 15 to audyt „na zgodność z przepisami ustawy”, który „może być audytem wewnętrznym lub zewnętrznym”, i według ministerstwa powinien dotyczyć „całego systemu informacyjnego wykorzystywanego przez dany podmiot, a nie jedynie jego części związanych z konkretną usługą” (odpowiedź 9.1). Ustawa mówi węziej, o audycie systemu informacyjnego „wykorzystywanego w procesie świadczenia usługi” (art. 15 ust. 1), więc szeroki zakres to interpretacja ministerstwa. Przy planowaniu audytu lepiej się z nią liczyć.

Czy ta sama jednostka może przeprowadzić oba audyty? Ustawa tego nie zabrania, o ile jednostka ma akredytację we właściwym zakresie. Nawet wtedy będą to w praktyce dwa badania z dwoma raportami: jedno mierzy zgodność z normą, drugie wykonanie ustawy. Dowody mogą być wspólne, co może skrócić przygotowanie.

Od czego zacząć, gdy masz certyfikat, i gdy go nie masz

Jeśli masz certyfikat, potraktuj go jak gotowy szkielet i przejdź sześć kroków z grafiki poniżej. Zacznij od porównania zakresu certyfikatu z listą usług z działalności objętej załącznikiem nr 1 lub nr 2 i systemów, które na nie wpływają, bo od tego zależy skala pozostałych prac. Potem przygotuj pakiet procedur ustawowych: wpis i aktualizację danych, osoby do kontaktu, dostęp do S46 i procedurę zgłoszeń z mierzeniem czasu od wykrycia. Bez nich firma z certyfikatem nadal nie wykonuje ustawy.

Jeśli nie masz certyfikatu, nie zaczynaj od niego. Ustawa wymaga SZBI z art. 8 i pozostałych obowiązków z rozdziału 3, a nie certyfikacji. Normę możesz wykorzystać jako wzorzec budowy systemu, a decyzję o certyfikacji odłożyć do chwili, gdy SZBI zacznie działać. Mapę dokumentów, które trzeba przygotować niezależnie od normy, opisujemy w artykule o tym, jakie dokumenty przygotować do wdrożenia KSC.

Kiedy certyfikat ma sens mimo braku wymogu ustawowego? Gdy wymagają go klienci albo zamawiający w przetargach, gdy dostarczasz usługi podmiotom kluczowym i ważnym, które muszą oceniać swoich dostawców (art. 8 ust. 2), albo gdy zarząd chce mieć regularną ocenę zewnętrzną systemu. Kiedy nie ma sensu? Gdy jedynym celem jest „spełnienie KSC”. Certyfikat tego celu nie osiągnie, a koszty audytów certyfikacyjnych dojdą do kosztów obowiązków ustawowych. Jeśli minister opublikuje zestawienie wymogów norm z art. 45 ust. 3, sprawdź je przed decyzją, pamiętając, że będzie to dokument pomocniczy, a nie źródło prawa.

Podstawa prawna i źródła

• art. 8 ust. 1-3 ustawy o KSC - system zarządzania bezpieczeństwem informacji
• art. 8b ust. 1 ustawy o KSC - środki z rozporządzenia wykonawczego Komisji (UE) 2024/2690 m.in. dla dostawców chmury, centrów danych i usług zarządzanych
• art. 8c-8f ustawy o KSC - odpowiedzialność i zadania kierownika, szkolenie kierownika, informacja z KRK
• art. 7c, art. 9 i art. 11 ustawy o KSC - wykaz, osoby do kontaktu, obsługa i zgłaszanie incydentów
• art. 10 ustawy o KSC - dokumentacja normatywna i operacyjna
• art. 15-16 ustawy o KSC - audyt podmiotu kluczowego
• art. 42 ust. 8 i art. 45 ust. 3-5 ustawy o KSC - normy w rekomendacjach i zestawienie wymogów dokumentów normalizacyjnych
• art. 73a ustawy o KSC - kary dla kierownika podmiotu
• art. 25, art. 33 ust. 1-2 i art. 35 ustawy nowelizującej - cykl audytowy dawnych operatorów, terminy dostosowania, pierwsze kary
• motyw 3 rozporządzenia wykonawczego Komisji (UE) 2024/2690 - normy, na których oparto środki
• Ustawa o krajowym systemie cyberbezpieczeństwa, tekst ujednolicony, stan na 8.10.2026 (Sejm, ELI)
• Ustawa nowelizująca z 23 stycznia 2026 r., Dz.U. 2026 poz. 252
• Rozporządzenie Ministra Cyfryzacji w sprawie wykazu certyfikatów uprawniających do przeprowadzenia audytu, Dz.U. 2018 poz. 1999
• Ministerstwo Cyfryzacji, pytania i odpowiedzi do ustawy o KSC, aktualizacja październik 2026
• Ministerstwo Cyfryzacji, konsultacje zestawienia wymagań dokumentów normalizacyjnych
• Druk sejmowy nr 1955: projekt nowelizacji z oceną skutków regulacji