4crypto.eu
Bezpłatna konsultacja
Compliance · Ustawa krajowa · 2026

KSC w 2026 r. - ustawa o krajowym systemie cyberbezpieczeństwa, operatorzy usług kluczowych, nowelizacja NIS2

Autor: dr inż. Adam Czubak Czas czytania: 14 min Aktualizacja: 2026-05-15

Ratio legis

Powstanie KSC wynika z prostej obserwacji: bez systemowej ochrony infrastruktury krytycznej zaburzenie usługi szpitala, banku czy operatora energetycznego ma skutki wykraczające daleko poza pojedynczą organizację. Ustawa z 5 lipca 2018 r. nakłada więc obowiązki na podmioty, których awaria oddziałuje na życie, zdrowie lub funkcjonowanie państwa - wymuszając wdrożenie SZBI, monitoring 24/7 i zgłaszanie incydentów do CSIRT poziomu krajowego. Cel jest dwojaki: ochrona obywateli przed kaskadowym skutkiem cyberataków oraz wymuszenie standardu, którego rynek samodzielnie by nie osiągnął.

Krajowy System Cyberbezpieczeństwa (KSC) [1] to fundament polskiego prawa cyberbezpieczeństwa. Ustawa z 5 lipca 2018 r. implementuje dyrektywę NIS i tworzy obowiązkową strukturę zarządzania bezpieczeństwem dla siedmiu sektorów krytycznych: energetyki, transportu, bankowości, ochrony zdrowia, zaopatrzenia w wodę, infrastruktury cyfrowej i sektora dostawców usług cyfrowych. Po ośmiu latach obowiązywania ustawa wchodzi w fazę głębokiej przebudowy - nowelizacja transponująca dyrektywę NIS2 [3] rozszerza zakres do 18 sektorów, podnosi kary do 10 mln EUR i wprowadza osobistą odpowiedzialność członków zarządu.

Artykuł porządkuje strukturę obecnego KSC, omawia obowiązki operatorów usług kluczowych (OUK) i dostawców usług cyfrowych (DUC), opisuje strukturę CSIRT poziomu krajowego, terminy zgłaszania incydentów i wymagania audytu. Druga część przedstawia nadchodzące zmiany wynikające z NIS2 [4] i co już dzisiaj należy przygotować, by w momencie wejścia nowelizacji w życie nie zostać zaskoczonym. Praktyka pokazuje, że najtrudniejszą częścią KSC nie są wymagania techniczne - tu odpowiadają polskie i międzynarodowe standardy hartowania - ale część organizacyjna: udokumentowane SZBI, dowody audytu, procedury zgłaszania incydentów i polityka łańcucha dostaw.

Geneza i podstawa prawna - od NIS do KSC

Ustawa o krajowym systemie cyberbezpieczeństwa weszła w życie 28 sierpnia 2018 r., transponując dyrektywę Parlamentu Europejskiego i Rady (UE) 2016/1148 (NIS). Była to pierwsza w polskim prawie regulacja systemowa cyberbezpieczeństwa - wcześniejsze przepisy (RODO, KRI, ustawa o ochronie informacji niejawnych) dotyczyły wybranych obszarów, ale brakowało ramowej regulacji obejmującej sektory krytyczne dla gospodarki państwa.

KSC wprowadza trzy poziomy struktury:

  • Poziom strategiczny - Pełnomocnik Rządu ds. Cyberbezpieczeństwa, Kolegium ds. Cyberbezpieczeństwa, Minister właściwy ds. informatyzacji (obecnie Minister Cyfryzacji). Zatwierdzanie strategii państwowej, koordynacja międzysektorowa, współpraca międzynarodowa.
  • Poziom operacyjny - trzy CSIRT poziomu krajowego (NASK, GOV, MON), organy właściwe dla sektorów, sektorowe zespoły CSIRT. Reagowanie na incydenty, koordynacja krajowa, wsparcie OUK.
  • Poziom wykonawczy - OUK, DUC, podmioty publiczne. Wdrażanie SZBI, monitorowanie, zgłaszanie incydentów, audyt.

Założeniem ustawodawcy było delegowanie obowiązków technicznych na poziom wykonawczy (OUK ma sam zorganizować SZBI), pozostawiając państwu rolę koordynacyjną, normatywną i wsparcia kryzysowego. Ten model przeniesiono niemal w całości z dyrektywy NIS.

Strategia Cyberbezpieczeństwa RP [6] (uchwała Rady Ministrów z 22 października 2019 r.) definiuje cele polityki państwa w tym obszarze: zapewnienie odporności systemów, budowa potencjału narodowego, edukacja społeczeństwa, silna pozycja w UE i NATO. Strategia obejmuje okres 2019-2024 i była podstawą do dalszej rozbudowy KSC oraz przygotowań do NIS2. Nowa Strategia 2024-2029 jest w trakcie procedowania i ma uwzględniać transpozycję NIS2 oraz nowe wyzwania (AI Act, DORA, cyberzagrożenia geopolityczne).

Zakres podmiotowy - OUK, DUC, podmioty publiczne

KSC w obecnym brzmieniu wyróżnia trzy kategorie adresatów obowiązków:

1. Operatorzy usług kluczowych (OUK)

Podmioty z siedmiu sektorów (energia, transport, bankowość i infrastruktura rynków finansowych, ochrona zdrowia, zaopatrzenie w wodę pitną, infrastruktura cyfrowa) wymienionych w załączniku nr 1 do ustawy. Status OUK jest nadawany decyzją administracyjną organu właściwego dla sektora (np. Minister Zdrowia, Komisja Nadzoru Finansowego, Minister Energii) pod warunkiem przekroczenia progu istotności zdefiniowanego w rozporządzeniu Rady Ministrów z 11 września 2018 r. [2]

2. Dostawcy usług cyfrowych (DUC)

Trzy kategorie wymienione w załączniku nr 2 do ustawy:

  • Internetowe platformy handlowe (online marketplace) - umożliwiające zawieranie umów drogą elektroniczną z konsumentami lub przedsiębiorcami.
  • Internetowe wyszukiwarki - umożliwiające wyszukiwanie informacji w internecie na podstawie zapytania.
  • Usługi przetwarzania w chmurze (cloud computing) - świadczone w modelu IaaS / PaaS / SaaS.

DUC nie wymagają decyzji administracyjnej - obowiązek powstaje automatycznie z chwilą rozpoczęcia świadczenia usługi i przekroczenia progu (mikroprzedsiębiorcy są wyłączeni, art. 17 ust. 3 KSC).

3. Podmioty publiczne

Choć ustawa nie nakłada bezpośrednio na podmioty publiczne obowiązków OUK, to art. 4 pkt 7 i 8 przewiduje obowiązek współpracy z CSIRT poziomu krajowego oraz zapewnienia odpowiednich środków bezpieczeństwa. Główny ciężar regulacyjny dla administracji niesie rozporządzenie KRI z 12 kwietnia 2012 r. (zob. artykuł o KRI oraz audyt KRI).

Kluczowa różnica: OUK to imienna lista z decyzjami administracyjnymi - około 400-500 podmiotów w Polsce. Po nowelizacji NIS2 lista rozszerzy się do prawdopodobnie kilkudziesięciu tysięcy podmiotów objętych jako essential lub important.

Siedem sektorów i progi istotności

Rozporządzenie Rady Ministrów z 11 września 2018 r. [2] precyzyjnie definiuje progi istotności dla każdego sektora. Poniżej najważniejsze (lista skrócona, pełna w rozporządzeniu):

Sektor energetyki

  • Energia elektryczna: operator OSP (przesyłowy), operator OSD (dystrybucyjny) z minimum 100 tys. odbiorców, wytwórca o mocy minimum 100 MW.
  • Ropa naftowa: operatorzy rurociągów przesyłowych ropy i produktów ropopochodnych.
  • Gaz: operator OSP gazowy, OSD z minimum 100 tys. odbiorców.

Sektor transportu

  • Transport lotniczy: przewoźnicy lotniczy (powyżej 1 mln pasażerów rocznie), lotniska (powyżej 2 mln pasażerów rocznie), zarządzający ruchem lotniczym (PAŻP).
  • Transport kolejowy: zarządca infrastruktury (PKP PLK), główni przewoźnicy.
  • Transport wodny: porty (powyżej 100 mln zł obrotu).
  • Transport drogowy: zarządcy autostrad i dróg ekspresowych powyżej 500 km.

Sektor bankowości i infrastruktury rynków finansowych

  • Banki krajowe wg ustawy Prawo bankowe.
  • Operatorzy infrastruktur rynków finansowych: KDPW, GPW, BondSpot, BIK, BIG.

Sektor ochrony zdrowia

  • Szpitale - od 75 łóżek ogólnoszpitalnych (lub mniej dla szpitali specjalistycznych z określonymi profilami).
  • Wytwórcy produktów leczniczych.

Sektor zaopatrzenia w wodę pitną

  • Przedsiębiorstwa wodociągowo-kanalizacyjne obsługujące powyżej 100 tys. mieszkańców.

Sektor infrastruktury cyfrowej

  • Punkty wymiany ruchu internetowego (IXP).
  • Dostawcy usług DNS.
  • Rejestratorzy domen najwyższego poziomu (TLD).

Praktyczna uwaga: progi istotności są ustalone na poziomie, który obejmuje większość średnich i dużych podmiotów w każdym sektorze, ale wyklucza najmniejsze. Powodem jest zasada proporcjonalności - obowiązki SZBI byłyby nieproporcjonalne dla małych podmiotów. Po NIS2 progi zostaną obniżone i wprowadzony zostanie podział podmioty kluczowe / podmioty ważne (essential / important entities).

Obowiązki operatora usługi kluczowej

Rdzeń KSC (art. 8-15) definiuje siedem grup obowiązków OUK:

Wdrożenie SZBI (art. 8)

Operator usługi kluczowej w terminie 6 miesięcy od dnia, w którym decyzja o uznaniu za OUK stała się ostateczna, wdraża system zarządzania bezpieczeństwem informacji obejmujący usługę kluczową. SZBI musi spełniać wymagania PN-ISO/IEC 27001 [7] (z modyfikacjami dla sektora) i obejmować w szczególności:

  1. Politykę bezpieczeństwa informacji - dokument strategiczny zatwierdzony przez kierownictwo.
  2. Analizę ryzyka i plan postępowania z ryzykiem (risk treatment plan).
  3. Inwentaryzację aktywów i klasyfikację informacji.
  4. Środki techniczne i organizacyjne - kontrola dostępu, kryptografia, hardening (zob. Hardening), kopie zapasowe, segmentacja sieci.
  5. Plan ciągłości działania (BCP) i plan odzyskiwania po awarii (DRP).
  6. Zarządzanie incydentami - procedury wykrywania, obsługi i raportowania.
  7. Procedury obsługi naruszeń bezpieczeństwa informacji.
  8. Szkolenia personelu - security awareness dla pracowników i kompetencje techniczne dla zespołu cyberbezpieczeństwa (zob. Security Awareness).

Wyznaczenie osoby odpowiedzialnej (art. 14)

OUK wyznacza osobę odpowiedzialną za utrzymywanie kontaktów z podmiotami krajowego systemu cyberbezpieczeństwa - w praktyce Chief Information Security Officer (CISO) lub równoważne stanowisko. Osoba musi posiadać kompetencje merytoryczne i mieć pełnomocnictwa do reprezentowania organizacji w komunikacji z CSIRT i organem właściwym.

Zapewnienie monitoringu 24/7 (art. 14)

OUK zapewnia obsługę incydentów w trybie ciągłym - co w praktyce oznacza obowiązek posiadania SOC[17] 24/7 (zob. SOC 24/7). Może to być:

  • (a) wewnętrzny zespół spełniający warunki organizacyjne i techniczne rozporządzenia Ministra Cyfryzacji z 4 grudnia 2019 r. [8], lub
  • (b) umowa z podmiotem zewnętrznym świadczącym usługi z zakresu cyberbezpieczeństwa spełniającym te same warunki.

Termin: 3 miesiące od uznania za OUK na zawarcie umowy z SOC lub uruchomienie własnego.

Zgłaszanie incydentów (art. 11)

Operator niezwłocznie, nie później niż w ciągu 24 godzin od stwierdzenia, zgłasza incydent poważny do właściwego CSIRT poziomu krajowego. Zgłoszenie zawiera:

  • Dane identyfikacyjne operatora i osoby zgłaszającej.
  • Opis incydentu (data, czas, zasięg, oddziaływanie na usługę).
  • Klasyfikację (krytyczny / poważny / istotny).
  • Podjęte działania zaradcze.
  • Szacowany czas usunięcia.

Po zakończeniu obsługi - raport końcowy. Dla incydentów długotrwałych - raporty pośrednie.

Audyt co 24 miesiące (art. 15)

Operator zleca audyt SZBI nie rzadziej niż raz na 24 miesiące akredytowanej jednostce audytorskiej. Audyt obejmuje weryfikację dokumentacji, środków technicznych i organizacyjnych, dowodów testowania. Raport audytowy jest podstawą dla działań korygujących i może być żądany przez organ właściwy.

Zarządzanie ryzykiem łańcucha dostaw (art. 8 ust. 6)

OUK wymaga od swoich dostawców (procesorów, dostawców IT, dostawców usług) zapewnienia odpowiedniego poziomu bezpieczeństwa. W praktyce realizuje się to przez:

  • Klauzule cyberbezpieczeństwa w umowach (security requirements).
  • Prawo do audytu dostawcy lub żądania raportu audytowego (ISO 27001, SOC 2 typ II).
  • Mapowanie krytycznych dostawców i scenariuszy ryzyka geopolitycznego.

Współpraca z CSIRT i organem właściwym (art. 9)

OUK współpracuje z CSIRT poziomu krajowego: udostępnia informacje o stanie systemu, uczestniczy w wymianie informacji (ISAC), realizuje rekomendacje wydane przez organ.

SOC i zarządzanie incydentami

Wymóg posiadania SOC 24/7 jest jednym z najczęściej dyskutowanych aspektów KSC. Rozporządzenie Ministra Cyfryzacji z 4 grudnia 2019 r. [8] precyzuje wymagania:

Wymagania organizacyjne

  • Dostępność całodobowa - 7 dni w tygodniu, 365 dni w roku, włącznie ze świętami.
  • Wykwalifikowany personel - co najmniej 2 osoby z certyfikatami (CISSP, CISM, OSCP lub równoważne) na poziomie L3.
  • Procedury - dokumentowane standard operating procedures (SOP) dla każdego typu incydentu (DDoS, ransomware, phishing, IRT, naruszenie poufności, naruszenie integralności).
  • Eskalacja - jasno zdefiniowane ścieżki eskalacji w organizacji i do CSIRT poziomu krajowego.

Wymagania techniczne

  • System monitorowania - SIEM lub równoważny system korelacji logów.
  • Detekcja - EDR/XDR na końcówkach, NDR na sieci, monitoring poczty (zob. Audyt poczty DMARC).
  • Threat intelligence - dostęp do źródeł zewnętrznych (CERT Polska [5], ENISA, komercyjne TI feedy).
  • Logi - retencja minimum 12 miesięcy, ochrona przed manipulacją (WORM, podpisy cyfrowe).

Klasyfikacja incydentów

KSC (art. 2 pkt 5-7) wprowadza trójstopniową klasyfikację:

  • Incydent krytyczny - skutkujący znaczącym zakłóceniem usługi kluczowej. Próg: utrata dostępności powyżej 24h dla minimum 50% odbiorców, lub naruszenie integralności mające wpływ na zdrowie / życie ludzi (np. szpitale).
  • Incydent poważny - skutkujący istotnym zakłóceniem. Próg: utrata dostępności 4-24h, lub naruszenie poufności dla dużej liczby rekordów (np. powyżej 100 tys.).
  • Incydent istotny - skutkujący zakłóceniem mniejszej skali, ale wymagający uwagi.

Każdy poziom ma inny tryb zgłaszania: krytyczny i poważny obowiązkowo do CSIRT (24h), istotny do raportu kwartalnego.

Praktyczne wyzwania SOC w KSC

Trzy największe problemy w polskich OUK:

  1. Niedobór kompetencji - rynek krajowy ma ograniczoną liczbę specjalistów L3, koszt zespołu wewnętrznego sięga 1,5-3 mln zł rocznie. Dlatego większość OUK wybiera outsourcing SOC.
  2. False positive fatigue - źle skonfigurowane SIEM generują tysiące alertów dziennie, większość fałszywych. Wymaga to tuning i use case engineering.
  3. Brak integracji z OT - sektory energetyki, wody, transportu mają systemy automatyki przemysłowej (SCADA, PLC), które wymagają specjalistycznego monitorowania (Claroty, Nozomi, Dragos). Tradycyjne SOC IT nie obejmuje OT bez dodatkowej konfiguracji.

CSIRT poziomu krajowego - NASK, GOV, MON

KSC tworzy trzy CSIRT poziomu krajowego z różnymi obszarami właściwości:

CSIRT NASK

Prowadzony przez Naukową i Akademicką Sieć Komputerową - Państwowy Instytut Badawczy (NASK). Właściwy dla:

  • OUK z sektorów cywilnych: bankowość, transport (poza specjalnymi), zaopatrzenie w wodę, infrastruktura cyfrowa (poza administracją rządową).
  • DUC (dostawcy usług cyfrowych).
  • Operatorzy telekomunikacyjni (na zasadzie współpracy).

CSIRT NASK obsługuje również publicznie znaną komórkę CERT Polska - najstarszy zespół reagowania na incydenty w Polsce (działający od 1996 r.). Publikuje raport roczny [5] z analizą krajobraz[9]u cyberzagrożeń.

CSIRT GOV

Prowadzony przez Agencję Bezpieczeństwa Wewnętrznego (ABW). Właściwy dla:

  • Administracji rządowej - ministerstwa, urzędy centralne, agencje rządowe.
  • Infrastruktura krytyczna państwa w sektorach: energetyka (operatorzy systemowi), transport (PAŻP, PKP PLK), sektor finansowy w części dotyczącej infrastruktury rynkowej.
  • Niektóre podmioty publiczne wskazane przez Pełnomocnika Rządu.

CSIRT MON

Prowadzony przez Ministerstwo Obrony Narodowej / Dowództwo Komponentu Wojsk Obrony Cyberprzestrzeni (DKWOC). Właściwy dla:

  • Sił Zbrojnych RP i jednostek organizacyjnych MON.
  • Przedsiębiorców o szczególnym znaczeniu gospodarczo-obronnym.
  • Wojskowych badawczo-rozwojowych i przemysłu obronnego.

Współpraca CSIRT

Trzy CSIRT współpracują w ramach Krajowej Sieci Reagowania na Incydenty. W przypadku incydentów wpływających na więcej niż jeden obszar właściwości (np. atak ransomware na łańcuch dostaw obejmujący zarówno sektor cywilny jak i administrację) odbywa się koordynacja na poziomie operacyjnym. CSIRT poziomu krajowego współpracują również z europejskim CSIRT Network (powołanym dyrektywą NIS) i wymianą informacji w ramach ENISA.

Sektorowe zespoły CSIRT

Niektóre sektory mają dodatkowe sektorowe CSIRT - np. FinCERT.pl dla sektora bankowego (prowadzony przez Związek Banków Polskich), CSIRT-KRD w obszarze niektórych instytucji. Sektorowe CSIRT funkcjonują jako wstępna linia zgłaszania i propagują informacje do CSIRT poziomu krajowego.

Audyt KSC - co 24 miesiące

Audyt SZBI (art. 15 KSC) to obowiązkowy i jednocześnie najlepiej zdefiniowany element kontroli zewnętrznej OUK. Wymóg jest jasny: nie rzadziej niż raz na 24 miesiące, przez niezależną akredytowaną jednostkę audytorską. Szczegóły w artykule o audycie KSC i NIS2.

Kto może być audytorem KSC

Audytor musi spełniać łącznie trzy kryteria:

  1. Niezależność - audytor nie może być powiązany kapitałowo, osobowo ani umownie ze sprawdzanym OUK w sposób mogący zagrozić obiektywizmowi. W szczególności nie może świadczyć bieżących usług bezpieczeństwa dla audytowanej organizacji.
  2. Kompetencje - personel audytorski musi posiadać kompetencje udokumentowane certyfikatami (CISA, CISM, ISO 27001 Lead Auditor lub równoważne) oraz doświadczenie w sektorze audytowanej organizacji.
  3. Akredytacja - jednostka audytorska powinna być akredytowana przez Polskie Centrum Akredytacji (PCA) w zakresie certyfikacji systemów zarządzania bezpieczeństwem informacji (PN-EN ISO/IEC 17021-1) lub innej właściwej normy.

Zakres audytu

Audyt obejmuje minimum trzy płaszczyzny:

  • Dokumentacyjna - polityka bezpieczeństwa, procedury, analiza ryzyka, plan ciągłości działania, plan postępowania z ryzykiem, rejestry incydentów.
  • Techniczna - skuteczność wdrożonych zabezpieczeń: hardening systemów, MFA, szyfrowanie, segmentacja, monitorowanie. Audytor weryfikuje przez próbkowanie konfiguracji, testy techniczne (skanowanie podatności - zob. Skanowanie podatności, ewentualnie pentest - zob. Testy penetracyjne) i wywiady techniczne.
  • Organizacyjna - świadomość personelu, szkolenia, obsługa incydentów w praktyce (tabletop exercises), ćwiczenia ciągłości działania, eskalacja.

Raport audytowy

Raport zawiera:

  1. Stwierdzenia (findings) - obserwacje niezgodności z wymaganiami KSC i PN-ISO/IEC 27001.
  2. Klasyfikacja niezgodności - duże (major), małe (minor), uwagi.
  3. Rekomendacje działań korygujących.
  4. Termin usunięcia niezgodności.
  5. Ogólna ocena stanu SZBI.

Raport przekazywany jest kierownictwu OUK i na żądanie organowi właściwemu. Brak audytu lub poważne niezgodności mogą skutkować karą administracyjną (art. 73-74 KSC).

Koszt audytu KSC

W zależności od skali i sektora:

  • Mały OUK (np. szpital powiatowy 75-150 łóżek): 25-50 tys. zł.
  • Średni OUK (np. dystrybutor energii 200-500 tys. odbiorców): 50-120 tys. zł.
  • Duży OUK (np. operator OSP, bank krajowy): 150-500 tys. zł.

Koszty obejmują audyt dokumentacyjny + techniczny + raport, nie obejmują działań korygujących.

Kary i sankcje

KSC w obecnym brzmieniu (art. 73-74) przewiduje kary administracyjne nakładane przez organ właściwy:

Wykaz naruszeń i kar (KSC 2018)

  • Brak wdrożenia SZBI w terminie 6 miesięcy: do 200 000 zł.
  • Brak audytu w terminie 24 miesięcy: do 200 000 zł.
  • Brak zgłoszenia incydentu poważnego w 24h: do 200 000 zł.
  • Brak SOC 24/7 lub umowy z dostawcą: do 200 000 zł.
  • Niewskazanie osoby odpowiedzialnej: do 200 000 zł.
  • Recydywa (powtórne naruszenia): do 1 000 000 zł.

W praktyce kary w pierwszych latach KSC były rzadkie - organy właściwe preferowały tryb pouczenia i nakaz usunięcia naruszeń. To zmienia się od 2023 r., gdy organy zaczęły systematycznie egzekwować obowiązki.

Kary po nowelizacji NIS2 (planowane)

Projekt nowelizacji UC59 [4] wprowadza diametralne zaostrzenie:

  • Podmioty kluczowe: do 10 000 000 EUR lub 2% rocznego obrotu (wyższa z kwot).
  • Podmioty ważne: do 7 000 000 EUR lub 1,4% rocznego obrotu.
  • Czasowe wstrzymanie funkcji kierowniczych dla osób odpowiedzialnych za niewdrożenie obowiązków NIS2.
  • Cofnięcie certyfikatów (np. dla dostawców usług zaufania).

To fundamentalna zmiana reżimu - z kar w wysokości pensji menedżera średniego szczebla na kary porównywalne z RODO (do 4% obrotu). Konsekwencja: cyberbezpieczeństwo z tematu IT awansuje na temat zarządu.

Nowelizacja transponująca NIS2 (2025)

Dyrektywa NIS2 [3] weszła w życie w UE 16 stycznia 2023 r. i wyznaczyła państwom członkowskim termin transpozycji do 17 października 2024 r. Polska, jak większość państw UE, przekroczyła ten termin - projekt nowelizacji KSC (UC59) [4] jest procedowany od 2024 r., a wejście w życie planowane jest w 2025 r. Szczegóły dyrektywy są omówione w osobnym artykule o NIS2.

Co zmienia nowelizacja UC59

Rozszerzenie zakresu z 7 do 18 sektorów

Obecnie KSC obejmuje 7 sektorów (energia, transport, bankowość, ochrona zdrowia, woda, infrastruktura cyfrowa, usługi cyfrowe). NIS2 dodaje:

  • Produkcja - wytwarzanie wyrobów medycznych, chemii, motoryzacji, elektroniki, maszyn.
  • Produkcja i dystrybucja chemii.
  • Produkcja i dystrybucja żywności.
  • Gospodarka odpadami.
  • Usługi pocztowe i kurierskie.
  • Administracja publiczna (włączona jako podmioty kluczowe na poziomie centralnym i regionalnym).
  • Badania naukowe (organizacje badawcze).
  • ICT service management (dostawcy zarządzanych usług bezpieczeństwa - MSSP).
  • Rozszerzenie infrastruktury cyfrowej (data centers, content delivery networks, trust service providers).

Dwie kategorie: podmioty kluczowe vs ważne

Podmioty kluczowe (essential) - sektory wysokokrytyczne, duże przedsiębiorstwa (powyżej 250 pracowników lub 50 mln EUR obrotu). Pełne wymagania, ostrzejszy nadzór, wyższe kary.

Podmioty ważne (important) - inne sektory ze załącznika lub średnie przedsiębiorstwa (50-250 pracowników lub 10-50 mln EUR obrotu) w sektorach kluczowych. Podstawowe wymagania, nadzór reaktywny.

Skala: szacuje się, że w Polsce po wejściu NIS2 liczba podmiotów objętych KSC wzrośnie z około 500 do nawet 20 000-30 000.

Samorejestracja zamiast decyzji administracyjnej

NIS2 wprowadza model samorejestracji: podmiot spełniający kryteria sam zgłasza się do wykazu prowadzonego przez organ właściwy. Brak zgłoszenia jest sankcjonowany. To fundamentalna zmiana w stosunku do obecnego modelu z decyzją administracyjną.

Odpowiedzialność zarządu

Art. 20 NIS2: członkowie organów zarządzających podmiotów kluczowych i ważnych ponoszą osobistą odpowiedzialność za niewdrożenie środków zarządzania ryzykiem cyberbezpieczeństwa. Konsekwencje: kary administracyjne dla osób fizycznych oraz możliwy zakaz pełnienia funkcji kierowniczych. Zarząd musi również nadzorować wdrożenie środków - co praktycznie oznacza obowiązek szkolenia zarządu w cyberbezpieczeństwie.

Łańcuch dostaw (supply chain security)

NIS2 wprowadza szczegółowe wymagania dotyczące ryzyka dostawców:

  • Identyfikacja krytycznych dostawców i scenariuszy ryzyka.
  • Klauzule cyberbezpieczeństwa w umowach.
  • Ocena ryzyk geopolitycznych (ryzyko dostawcy z państw wysokiego ryzyka).
  • Coordinated Risk Assessments na poziomie UE (np. dla łańcucha dostaw 5G).

Zaostrzenie terminów zgłaszania incydentów

  • 24 godziny - wstępne powiadomienie (early warning).
  • 72 godziny - ocena incydentu (incident notification).
  • 1 miesiąc - raport końcowy (final report).

Co przygotować już dzisiaj

Niezależnie od daty wejścia nowelizacji, podmioty potencjalnie objęte NIS2 powinny już teraz:

  1. Self-assessment - czy organizacja kwalifikuje się jako podmiot kluczowy lub ważny. Kryteria: sektor + rozmiar.
  2. Audyt SZBI - inwentaryzacja istniejących polityk, procedur, środków. Mapping do wymagań NIS2.
  3. Szkolenie zarządu - cyberbezpieczeństwo na poziomie strategicznym, znajomość NIS2.
  4. Inwentaryzacja dostawców - lista krytycznych dostawców z oceną ryzyka.
  5. Plan transpozycji - harmonogram wdrożenia do daty wejścia nowelizacji.

Mapping do innych norm

KSC nie istnieje w próżni - mapowanie do innych regulacji jest kluczowe dla efektywnego compliance:

KSC vs PN-ISO/IEC 27001

KSC odwołuje się bezpośrednio do PN-ISO/IEC 27001 [7] jako podstawowej normy SZBI. W praktyce posiadanie certyfikatu ISO 27001 znacznie ułatwia spełnienie wymagań KSC - audyt KSC obejmuje mniejszy zakres dodatkowy (specyficzne dla sektora, zgłaszanie incydentów). Szczegóły - artykuł o ISO 27001.

KSC vs KRI

KRI (Krajowe Ramy Interoperacyjności) - rozporządzenie z 12 kwietnia 2012 r. - dotyczy podmiotów realizujących zadania publiczne. KSC dotyczy OUK i DUC. Zakresy nie pokrywają się sektorowo, ale wymagania techniczne są bardzo podobne (oba odwołują się do PN-ISO/IEC 27001). JST może podlegać równocześnie KRI (jako podmiot publiczny) i KSC (jeśli np. prowadzi szpital przekraczający próg). Szczegóły - artykuł o KRI.

KSC vs NIS2

Po transpozycji NIS2 KSC pozostaje polską ustawą, ale jej brzmienie obejmie wszystkie wymagania dyrektywy. Praktycznie organizacje będą stosować znowelizowaną KSC - sama dyrektywa NIS2 nie jest bezpośrednio stosowana. Szczegóły - artykuł o NIS2.

KSC vs RODO

KSC i RODO są komplementarne: KSC chroni system informatyczny, RODO chroni dane osobowe. Naruszenie KSC (np. ransomware) może jednocześnie być naruszeniem RODO (jeśli zaszyfrowane dane zawierały dane osobowe). W praktyce wymaga to równoległego zgłoszenia: do CSIRT poziomu krajowego (KSC, 24h) i do PUODO (RODO, 72h). Szczegóły - artykuł o RODO.

KSC vs DORA

DORA (Digital Operational Resilience Act) dla sektora finansowego jest lex specialis wobec NIS2 - dla banków, instytucji finansowych i ich dostawców ICT DORA zastępuje NIS2 w obszarze odporności operacyjnej. Bank pozostaje OUK w KSC, ale w zakresie zarządzania ryzykiem ICT stosuje DORA. Szczegóły - artykuł o DORA.

KSC vs sektorowe regulacje

Sektor energetyki: Network Code on Cybersecurity (rozporządzenie wykonawcze UE 2024/1366) - dodatkowe wymagania dla operatorów elektroenergetycznych. Sektor finansowy: Rekomendacje KNF (np. Rekomendacja D, Rekomendacja Z). Sektor zdrowia: Rozporządzenie MZ w sprawie systemu informacji medycznej.

Najczęstsze błędy organizacji

Po latach audytów KSC obserwujemy powtarzające się błędy w polskich OUK:

  1. Polityka bezpieczeństwa = templatka z internetu. Dokument istnieje, ale nie odzwierciedla faktycznej organizacji. PUODO i organ właściwy oceniają realne wdrożenie, nie sam dokument.
  2. Brak udokumentowanej analizy ryzyka. Albo nie ma analizy, albo jest sprzed 5 lat, albo nie była aktualizowana po istotnych zmianach (np. cloud migration, fuzja, ekspansja na nowe rynki).
  3. Plan ciągłości działania na papierze. BCP nigdy nie był testowany. Brak ćwiczeń tabletop, brak praktycznego scenariusza (np. testu odzyskiwania backupu, testu trybu awaryjnego).
  4. SOC bez SLA na czas reakcji. Umowa z dostawcą jest, ale nie definiuje czasu reakcji (MTTR) ani konsekwencji niewykonania. SOC staje się formalnością.
  5. Brak prawdziwej eskalacji do CSIRT. Procedura jest, ale nigdy nie testowana. Pracownicy nie wiedzą, kto i jak zgłasza, jaki jest format zgłoszenia.
  6. Logi nie są centralizowane. Każdy system loguje lokalnie, brak SIEM, brak korelacji. W razie incydentu odtworzenie chronologii zajmuje tygodnie.
  7. Audyt KSC przeprowadzony przez własnego dostawcę. Konflikt interesów - audytor sprawdza własne wdrożenie. Niezgodność z art. 15 KSC. Raport audytowy nie ma wiarygodności.
  8. Brak zarządzania dostawcami. Lista dostawców istnieje, ale bez klasyfikacji ryzyka, bez klauzul cyberbezpieczeństwa w umowach, bez prawa do audytu.
  9. Brak szkoleń security awareness. Pracownicy nie wiedzą, jak rozpoznać phishing, jak zgłosić incydent. Brakuje cyklicznych szkoleń i testów (zob. Security Awareness).
  10. Hardening systemów na poziomie domyślnym. Serwery, routery, urządzenia sieciowe pracują z konfiguracją fabryczną. Brak benchmarków CIS, brak skanowania konfiguracji (zob. Hardening).
  11. Brak testów penetracyjnych. Skanowanie podatności bywa wykonywane, ale brak rzetelnego pentestu raz na 12-24 miesiące. To luka dowodowa w audycie (zob. Testy penetracyjne).
  12. Backup bez testów odzyskiwania. Klasyk - backup się robi, ale nikt go nigdy nie przywracał. W razie ransomware okazuje się, że backup był uszkodzony lub niekompletny.

Checklist: 10 punktów gotowości KSC

Lista high-impact - bez tych elementów ryzyko stwierdzenia niezgodności w audycie i kary administracyjnej jest znaczne. Po nowelizacji NIS2 punkty 1-10 będą obowiązywać szerszy katalog podmiotów.

  1. Identyfikacja statusu prawnego. Czy organizacja jest OUK / DUC / podmiotem publicznym? Po NIS2 - podmiot kluczowy czy ważny? Decyzja administracyjna lub samokwalifikacja z dokumentacją.
  2. SZBI wdrożone i udokumentowane. Polityka, procedury, analiza ryzyka, plan ciągłości działania. Zgodne z PN-ISO/IEC 27001, dostosowane do sektora.
  3. Wyznaczona osoba odpowiedzialna (CISO/koordynator). Z pełnomocnictwami, kompetencjami i jasno określoną pozycją w organizacji (podlegającą zarządowi).
  4. SOC 24/7 - wewnętrzny lub zewnętrzny. Umowa z dostawcą (lub etatowy zespół) z SLA na czas reakcji, monitoringiem ciągłym, procedurami eskalacji. Zob. SOC 24/7.
  5. Procedura zgłaszania incydentów. 24h dla incydentów poważnych, kontakty do CSIRT NASK/GOV/MON, szablony zgłoszeń, testy procedur.
  6. Plan ciągłości działania z testami. Tabletop minimum raz w roku, test odzyskiwania backupu, alternatywne tryby pracy.
  7. Hardening i monitoring. Benchmarki CIS dla systemów, MFA dla kont uprzywilejowanych, EDR/XDR, SIEM z retencją 12 miesięcy.
  8. Zarządzanie łańcuchem dostaw. Lista krytycznych dostawców z oceną ryzyka, klauzule cyberbezpieczeństwa w umowach, prawo do audytu.
  9. Audyt KSC co 24 miesiące. Przez niezależną akredytowaną jednostkę. Raport audytowy z planem działań korygujących, monitorowanie realizacji. Zob. Audyt KSC i NIS2.
  10. Szkolenia personelu. Onboarding + cykliczne szkolenia security awareness, kompetencje techniczne dla zespołu SOC, szkolenie zarządu (po NIS2 - obowiązkowe). Zob. Security Awareness.

Najczęściej zadawane pytania

Kiedy organizacja jest operatorem usługi kluczowej (OUK)?

Operatorem usługi kluczowej jest podmiot z jednego z siedmiu sektorów wymienionych w załączniku nr 1 do ustawy o KSC (energia, transport, bankowość i infrastruktura rynków finansowych, ochrona zdrowia, zaopatrzenie w wodę pitną, infrastruktura cyfrowa) oraz świadczący usługę kluczową wymienioną w rozporządzeniu Rady Ministrów z 11 września 2018 r. [2], który osiągnął próg istotności zdefiniowany w tym samym rozporządzeniu.

Przykłady progów: szpital powyżej 75 łóżek, oczyszczalnia obsługująca ponad 100 tys. mieszkańców, operator sieci OSD z minimum 100 tys. odbiorców. Decyzję administracyjną o uznaniu za OUK wydaje organ właściwy dla danego sektora (np. Minister Zdrowia dla szpitali, KNF dla banków, Minister Cyfryzacji dla infrastruktury cyfrowej).

Czy szkoła musi spełniać KSC?

Co do zasady - nie w obecnym brzmieniu KSC z 2018 r. Szkoły, ZSP, przedszkola nie znajdują się w sektorach OUK.

Po nowelizacji transponującej NIS2 (planowane wejście w 2025 r.) sytuacja zmienia się: jednostki administracji publicznej oraz sektor edukacji mogą zostać zakwalifikowane jako podmioty ważne lub kluczowe, w zależności od rozmiaru.

Szkoły jako jednostki organizacyjne JST podlegają natomiast rozporządzeniu KRI (Krajowe Ramy Interoperacyjności) z 12 kwietnia 2012 r. - wymaga ono wdrożenia SZBI i audytu co 24 miesiące. Zob. artykuł o KRI.

Czy szpital powiatowy podlega KSC?

Tak, jeśli przekracza próg istotności. Według rozporządzenia z 11 września 2018 r. próg dla sektora ochrony zdrowia wynosi 75 łóżek dla szpitali ogólnych. Większość szpitali powiatowych przekracza ten próg.

Szpital staje się OUK na mocy decyzji administracyjnej organu właściwego (Ministra Zdrowia). Z chwilą uzyskania statusu szpital ma 6 miesięcy na wdrożenie SZBI (art. 8 KSC), w tym wyznaczenie osoby odpowiedzialnej za cyberbezpieczeństwo, analizę ryzyka, plan ciągłości działania i procedurę zgłaszania incydentów. Niezależnie od KSC, szpital przetwarza dane medyczne (kategoria szczególna RODO) - co dodatkowo wymaga DPIA i innych obowiązków RODO.

Jak zgłosić się jako podmiot KSC?

Nie zgłasza się samodzielnie. To organ właściwy dla sektora wydaje decyzję administracyjną o uznaniu za OUK. Procedura:

  1. Organ właściwy identyfikuje podmioty spełniające kryteria (z urzędu lub na wniosek).
  2. Wydaje decyzję administracyjną uznającą za OUK.
  3. Podmiot jest wpisywany do rejestru OUK prowadzonego przez Pełnomocnika Rządu ds. Cyberbezpieczeństwa.
  4. Bieg terminów (6 miesięcy na SZBI, 3 miesiące na umowę z SOC, audyt co 24 miesiące) rozpoczyna się od daty uprawomocnienia decyzji.

Po nowelizacji NIS2 mechanizm zmienia się na samorejestrację podmiotów spełniających kryteria w wykazie prowadzonym przez Ministra Cyfryzacji.

Czy SOC może być zewnętrzny, czy musi być wewnętrzny?

KSC dopuszcza obie formy (art. 14 ust. 1 i 2). OUK może:

  • (a) utworzyć wewnętrzny zespół ds. cyberbezpieczeństwa spełniający warunki rozporządzenia Ministra Cyfryzacji z 4 grudnia 2019 r. [8],
  • (b) zawrzeć umowę z podmiotem zewnętrznym świadczącym usługi z zakresu cyberbezpieczeństwa spełniającym te same warunki.

Większość polskich OUK wybiera model hybrydowy lub outsourcingowy - własny CISO/koordynator + zewnętrzny SOC 24/7. Wymagania techniczne i organizacyjne dla obu modeli są identyczne: monitoring 24/7/365, kompetentny personel z certyfikacjami, dokumentacja procedur.

Ile czasu mam na zgłoszenie incydentu poważnego?

Niezwłocznie, nie później niż w 24 godziny od stwierdzenia (art. 11 ust. 1 KSC). Zgłoszenie do właściwego CSIRT poziomu krajowego:

  • CSIRT NASK - sektory cywilne ogólne, DUC.
  • CSIRT GOV - administracja rządowa, infrastruktura krytyczna państwa.
  • CSIRT MON - obszar wojskowy, przemysł obronny.

Po pierwszym zgłoszeniu obowiązuje dodatkowo raport końcowy (po zakończeniu obsługi incydentu) i, w razie potrzeby, raport pośredni dla incydentów długotrwałych.

Po nowelizacji NIS2 terminy zaostrzą się: wstępne powiadomienie w 24h, ocena w 72h, raport końcowy w miesiąc.

Kto przeprowadza audyt KSC?

Audytor zewnętrzny: jednostka certyfikacyjna akredytowana (np. przez Polskie Centrum Akredytacji - PCA) lub akredytowana firma audytorska z odpowiednimi kompetencjami. KSC art. 15 wymaga niezależności audytora - nie może to być ten sam podmiot, który wdrażał SZBI ani świadczy bieżące usługi cyberbezpieczeństwa dla audytowanej organizacji.

Audyt obejmuje weryfikację: (1) dokumentacji SZBI, (2) środków technicznych (hardening, MFA, szyfrowanie, monitoring), (3) dowodów organizacyjnych (szkolenia, testy ciągłości, raporty z incydentów). Audyt kończy się raportem przekazywanym kierownictwu OUK i, na żądanie, organowi właściwemu. Audyt musi być powtarzany min. co 24 miesiące.

Co grozi za naruszenie KSC?

Kara pieniężna do 200 000 zł (art. 73 KSC) za naruszenia jednorazowe - brak wdrożenia SZBI, brak audytu, brak zgłoszenia incydentu w terminie. Kara recydywy do 1 000 000 zł (art. 74) - powtarzające się naruszenia. Karę wymierza organ właściwy dla sektora.

Po nowelizacji NIS2 kary drastycznie rosną:

  • Podmioty kluczowe: do 10 mln EUR lub 2% obrotu (wyższa z kwot).
  • Podmioty ważne: do 7 mln EUR lub 1,4% obrotu.

Dodatkowo NIS2 wprowadza odpowiedzialność osobistą członków zarządu - możliwy zakaz pełnienia funkcji kierowniczych do czasu usunięcia naruszeń.

Czym różni się KSC od NIS2?

KSC to polska ustawa (z 5 lipca 2018) implementująca dyrektywę NIS (2016/1148). NIS2 (dyrektywa 2022/2555) uchyla NIS i zastępuje ją od 18 października 2024 r. w państwach członkowskich. Polska ma obowiązek transponować NIS2 do prawa krajowego - przez nowelizację ustawy o KSC (projekt UC59 procedowany od 2024 r.).

Główne różnice praktyczne:

  • NIS2 rozszerza zakres z 7 do 18 sektorów.
  • Wprowadza kategorie podmiotów kluczowych vs ważnych.
  • Podnosi kary (z 1 mln zł do 10 mln EUR).
  • Wprowadza odpowiedzialność zarządu.
  • Zaostrza wymogi łańcucha dostaw.

Po wejściu w życie nowelizacji KSC pozostaje krajową ramą, ale jego brzmienie znacząco się zmieni. Zob. artykuł o NIS2.

Czy mały urząd gminy musi spełnić KSC?

W obecnym KSC z 2018 r. - nie, jednostki samorządu terytorialnego nie są OUK ani DUC. Podlegają jednak rozporządzeniu KRI (Krajowe Ramy Interoperacyjności, § 20) - wymaga to wdrożenia SZBI opartego na podejściu opartym na ryzyku oraz audytu bezpieczeństwa min. co 24 miesiące.

Po transpozycji NIS2 sytuacja zmieni się: JST (od określonego rozmiaru lub kategorii) zostaną włączone jako podmioty publiczne w katalog NIS2.

Tymczasowo - mała gmina (poniżej progu) powinna stosować KRI, a w 2026 r. monitorować nowelizację KSC pod kątem nowych obowiązków.

KSC vs KRI - czym się różnią?

KSC to ustawa (sektory krytyczne, OUK/DUC, kary), KRI to rozporządzenie Rady Ministrów z 12 kwietnia 2012 r. § 20 KRI nakłada na podmioty realizujące zadania publiczne (administracja, JST, jednostki budżetowe) obowiązek wdrożenia SZBI i audytu co 24 miesiące.

Sektorowo:

  • KSC = krytyczna infrastruktura (energetyka, banki, szpitale).
  • KRI = administracja publiczna.

Wymagania techniczne są zbliżone (oba odsyłają do PN-ISO/IEC 27001), ale KSC ma kary do 1 mln zł i obowiązek zgłaszania incydentów do CSIRT, KRI nie ma sankcji pieniężnych (kontrola NIK lub organu nadzorczego, jednak bez bezpośrednich kar w sensie KSC).

Co z dostawcami IT - czy podlegają KSC?

Dostawcy IT sami w sobie nie są OUK w obecnym KSC, chyba że świadczą usługi cyfrowe wymienione w załączniku nr 2 (internet exchange points, DNS, TLD) - wtedy są DUC.

Jednak OUK ma obowiązek (art. 8 ust. 6 KSC) wymagać od swoich dostawców zapewnienia odpowiedniego poziomu bezpieczeństwa - w praktyce poprzez:

  • Klauzule umowne dotyczące cyberbezpieczeństwa.
  • Prawo do audytu lub żądania raportu audytowego (ISO 27001, SOC 2 typ II).
  • Wymagania certyfikacyjne.

Po NIS2 łańcuch dostaw zaostrza się: podmioty kluczowe i ważne mają obowiązek oceny ryzyka dostawców, w tym ryzyk geopolitycznych (np. dostawcy z państw wysokiego ryzyka). To fundamentalna zmiana dla polskiego rynku ICT - wszyscy dostawcy obsługujący NIS2-entities staną się de facto związani wymogami KSC/NIS2 przez umowy.

Potrzebujesz konsultacji w zakresie KSC?

Bezpłatna 30-60 minutowa konsultacja. Bez zobowiązań. Sprawdzamy status prawny (OUK / DUC / podmiot publiczny), mapujemy obowiązki i identyfikujemy luki przed audytem.

Zadzwoń: +48 691 122 312 office@4crypto.eu

Powiązane treści

Compliance i regulacje

Usługi związane

Bibliografia i źródła

Wszystkie cytowane źródła są publicznie dostępne. Akty prawne i rozporządzenia odsyłają do oryginalnych dokumentów w ISAP / EUR-Lex / ENISA.

  1. [1]regulationSejm RP (2018). Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Dz.U. 2018 poz. 1560 z późn. zm. · https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20180001560
  2. [2]regulationRada Ministrów (2018). Rozporządzenie z dnia 11 września 2018 r. w sprawie wykazu usług kluczowych oraz progów istotności skutku zakłócającego incydentu dla świadczenia usług kluczowych. Dz.U. 2018 poz. 1806 · https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20180001806
  3. [3]regulationParlament Europejski, Rada UE (2022). Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii (NIS2). Dz.U. UE L 333, 27.12.2022 · https://eur-lex.europa.eu/eli/dir/2022/2555/oj
  4. [4]regulationRada Ministrów, KPRM (2024). Projekt ustawy o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (UC59) - transpozycja NIS2. Rządowy Proces Legislacyjny · https://legislacja.rcl.gov.pl/projekt/12386504
  5. [5]reportNASK / CERT Polska (2024). Krajobraz bezpieczeństwa polskiego internetu - raport roczny CERT Polska 2023. NASK PIB · https://www.cert.pl/publikacje/
  6. [6]regulationRada Ministrów RP (2019). Strategia Cyberbezpieczeństwa Rzeczypospolitej Polskiej na lata 2019-2024 (uchwała nr 125 Rady Ministrów z 22 października 2019 r.). M.P. 2019 poz. 1037 · https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WMP20190001037
  7. [7]standardISO/IEC, Polski Komitet Normalizacyjny (2023). PN-EN ISO/IEC 27001:2023-08 - Bezpieczeństwo informacji, cyberbezpieczeństwo i ochrona prywatności - Systemy zarządzania bezpieczeństwem informacji - Wymagania · https://www.iso.org/standard/27001
  8. [8]regulationMinister Cyfryzacji (2019). Rozporządzenie z dnia 4 grudnia 2019 r. w sprawie warunków organizacyjnych i technicznych dla podmiotów świadczących usługi z zakresu cyberbezpieczeństwa oraz wewnętrznych struktur organizacyjnych operatorów usług kluczowych odpowiedzialnych za cyberbezpieczeństwo. Dz.U. 2019 poz. 2479 · https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20190002479
  9. [9]reportEuropean Union Agency for Cybersecurity (ENISA) (2024). ENISA Threat Landscape 2024. ENISA, Heraklion. DOI: 10.2824/0710888 · https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024
  10. [10]reportEuropean Union Agency for Cybersecurity (ENISA) (2024). NIS360 - Sectoral cybersecurity maturity model. ENISA · https://www.enisa.europa.eu/publications/nis360-2024
  11. [11]reportEuropean Union Agency for Cybersecurity (ENISA) (2023). Good Practices for Cyber Incident Reporting. ENISA · https://www.enisa.europa.eu/publications/good-practices-for-cyber-incident-reporting
  12. [12]standardNational Institute of Standards and Technology (NIST) (2024). NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, February 2024. DOI: 10.6028/NIST.CSWP.29 · https://doi.org/10.6028/NIST.CSWP.29
  13. [13]standardJoint Task Force (2020). NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. NIST. DOI: 10.6028/NIST.SP.800-53r5 · https://doi.org/10.6028/NIST.SP.800-53r5
  14. [14]standardCichonski, P., Millar, T., Grance, T., Scarfone, K. (2012). NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide. NIST. DOI: 10.6028/NIST.SP.800-61r2 · https://doi.org/10.6028/NIST.SP.800-61r2
  15. [15]standardInternational Organization for Standardization (2023). ISO/IEC 27035-1:2023 - Information security incident management - Part 1: Principles and process. ISO/IEC · https://www.iso.org/standard/78973.html
  16. [16]standardInternational Organization for Standardization (2022). ISO/IEC 27002:2022 - Information security controls. ISO/IEC · https://www.iso.org/standard/75652.html
  17. [17]peer-reviewedVielberth, M., Böhm, F., Fichtinger, I., Pernul, G. (2020). Security Operations Center: A Systematic Study and Open Challenges. IEEE Access, vol. 8, pp. 227756-227779. DOI: 10.1109/ACCESS.2020.3045514 · https://doi.org/10.1109/ACCESS.2020.3045514
  18. [18]reportNajwyższa Izba Kontroli (NIK) (2022). Informacja o wynikach kontroli: Realizacja zadań w obszarze cyberbezpieczeństwa przez podmioty publiczne (P/21/006). NIK, Warszawa · https://www.nik.gov.pl/kontrole/P/21/006/
  19. [19]reportMandiant (Google Cloud) (2024). M-Trends 2024 Special Report. Mandiant · https://services.google.com/fh/files/misc/m-trends-2024.pdf
  20. [20]reportIBM Security, Ponemon Institute (2024). Cost of a Data Breach Report 2024. IBM Corporation · https://www.ibm.com/reports/data-breach
  21. [21]reportVerizon Business (2024). 2024 Data Breach Investigations Report (DBIR). Verizon, 17th edition · https://www.verizon.com/business/resources/reports/dbir/