Przejdź do treściUP2
Baza wiedzy · stan na 13 sierpnia 2026 r.

Słownik NIS2 i KSC. Pojęcia, skróty i definicje od A do Z.

Praktyczny glossariusz dla zarządu, IT, bezpieczeństwa, prawa i operacji. Wyjaśnia najważniejsze terminy dyrektywy NIS2, polskiej ustawy KSC oraz systemu zarządzania bezpieczeństwem informacji - bez języka z prezentacji produktowych.

64
wyjaśnionych pojęć
PL + UE
KSC i dyrektywa NIS2
A-Z
prawo, proces i technologia
Najpierw trzy podstawy

NIS2, KSC i SZBI nie są synonimami.

Te trzy pojęcia opisują kolejne warstwy: europejską regulację, polskie przepisy i sposób ich wykonywania w organizacji.

01 · REGULACJA UE

NIS2

Dyrektywa (UE) 2022/2555 określa wspólne ramy cyberbezpieczeństwa. Wskazuje sektory, obowiązki kierownictwa, obszary zarządzania ryzykiem i model raportowania incydentów.

Przeczytaj definicję
02 · PRAWO KRAJOWE

KSC

Znowelizowana ustawa o Krajowym Systemie Cyberbezpieczeństwa przenosi wymagania NIS2 do polskiego porządku: określa podmioty, organy, terminy, Wykaz KSC i zasady nadzoru.

Przeczytaj definicję
03 · SYSTEM ORGANIZACJI

SZBI

System Zarządzania Bezpieczeństwem Informacji zamienia wymagania w codzienny sposób pracy: odpowiedzialności, analizę ryzyka, kontrole, obsługę incydentów, dowody i przeglądy.

Przeczytaj definicję
Słownik NIS2 · KSC · SZBI

Znajdź pojęcie albo skrót.

Wyszukiwarka rozpoznaje polskie i angielskie rozwinięcia, popularne warianty zapisu oraz pojęcia powiązane.

A5 pojęcia

Akceptacja ryzyka

Formalna decyzja, że określony poziom ryzyka może pozostać w organizacji przez ustalony czas. Nie oznacza rezygnacji z bezpieczeństwa: decyzja powinna wskazywać właściciela, uzasadnienie, warunki graniczne i datę ponownej oceny. Akceptować można wyłącznie ryzyko dobrze opisane i mieszczące się w mandacie osoby podejmującej decyzję. Jeżeli przekracza ono apetyt organizacji na ryzyko albo ustawowe minimum bezpieczeństwa, potrzebna jest eskalacja lub dodatkowe zabezpieczenie, a nie administracyjne „zamknięcie” tematu.

W praktyce

Akceptację zapisuje się po ocenie ryzyka rezydualnego, a nie zamiast analizy ryzyka. Zapis powinien zawierać ocenę przed i po zabezpieczeniach, możliwe skutki, osobę zatwierdzającą, termin ważności oraz zdarzenia powodujące wcześniejszy przegląd, np. incydent lub zmianę usługi.

#akceptacja-ryzyka

Aktywo

Zasób mający wartość dla organizacji albo potrzebny do świadczenia usługi. Aktywem może być informacja, aplikacja, infrastruktura, urządzenie OT (Operational Technology, technologia operacyjna), kompetencja pracownika, dostawca, lokalizacja lub reputacja. Znaczenie aktywa wynika z jego roli w procesie, a nie wyłącznie z ceny zakupu. Ten sam serwer może być mało ważny jako urządzenie, ale krytyczny jako jedyne miejsce przetwarzania danych potrzebnych do wykonania usługi.

W praktyce

Rejestr aktywów łączy zasoby z procesami, właścicielami, zależnościami i poziomem krytyczności. Rejestr powinien mieć właściciela i być aktualizowany przy zakupie, zmianie, przeniesieniu oraz wycofaniu zasobu. Dla aktywów krytycznych warto wskazać klasyfikację informacji, zależności, dostawcę i wymagania odtworzeniowe.

#aktywo

Analiza GAP

Uporządkowane porównanie obecnych sposobów działania z wymaganiami NIS2 (Network and Information Security Directive 2) i KSC (Krajowy System Cyberbezpieczeństwa). Dobra analiza obejmuje nie tylko deklaracje, lecz także istniejące dowody, luki, wpływ na ryzyko oraz rekomendowaną kolejność działań. Analiza luk nie rozstrzyga sama w sobie, czy firma podlega przepisom; wcześniej trzeba potwierdzić zakres prawny i organizacyjny. Jej celem jest pokazanie różnicy między wymaganym rezultatem a aktualną, potwierdzoną zdolnością organizacji.

W praktyce

Jej wynikiem powinien być wykonalny plan z priorytetami, właścicielami i terminami. Dla każdego wymagania warto zapisać stan, dowód, poziom luki, ryzyko, rekomendację, koszt lub wysiłek oraz zależności. Dzięki temu zarząd otrzymuje kolejność inwestycji, a zespoły jednoznaczne kryteria zakończenia działań.

#analiza-gap

Analiza ryzyka

Proces rozpoznawania zagrożeń i podatności oraz szacowania ich możliwego wpływu na usługi i organizację. Łączy wiedzę biznesową z techniczną i stanowi podstawę wyboru proporcjonalnych środków bezpieczeństwa. Rezultatem jest rejestr ryzyk pokazujący scenariusz, narażone aktywa i usługi, istniejące zabezpieczenia, poziom ryzyka pierwotnego oraz rezydualnego. Metoda może być jakościowa lub ilościowa, ale musi dawać porównywalne i zrozumiałe decyzje.

W praktyce

Analizę aktualizuje się po istotnej zmianie, incydencie i w ustalonym cyklu przeglądów. W ocenie powinni uczestniczyć właściciel procesu, bezpieczeństwo, technologia oraz osoby znające skutki biznesowe. Każde istotne założenie i ocena skuteczności zabezpieczeń powinny mieć źródło albo wskazany dowód.

#analiza-ryzyka

Audyt bezpieczeństwa

Niezależna, udokumentowana ocena bezpieczeństwa systemu informacyjnego oraz zgodności sposobu działania z wymaganiami. W polskiej ustawie o KSC (Krajowym Systemie Cyberbezpieczeństwa) cykliczny audyt ustawowy dotyczy podmiotów kluczowych; pierwszy jest co do zasady wymagany w ciągu 24 miesięcy od spełnienia przesłanek, a kolejne co najmniej raz na trzy lata. Audyt obejmuje ustalony zakres, kryteria, próbki i niezależną ocenę tego, czy środki są zaprojektowane poprawnie oraz działają w czasie. Raport powinien odróżniać niezgodności, obserwacje i rekomendacje, aby organizacja mogła właściwie ustalić działania naprawcze.

W praktyce

Audyt ocenia system i dowody jego działania, a nie tylko komplet polityk w folderze. Przygotowanie polega na uporządkowaniu zakresu, właścicieli i aktualnych dowodów, nie na tworzeniu dokumentów tuż przed badaniem. Po audycie każda niezgodność powinna otrzymać właściciela, termin, plan naprawy i sposób potwierdzenia zamknięcia.

#audyt-bezpieczenstwa
B3 pojęcia

BCP

Business Continuity Plan

Plan utrzymania lub wznowienia kluczowych procesów podczas zakłócenia. Obejmuje priorytety biznesowe, role, komunikację, tryby zastępcze, zasoby oraz moment przejścia do normalnej pracy. Plan uwzględnia scenariusze, w których część ludzi, lokalizacji, technologii lub dostawców jest niedostępna. Łączy wymagania ciągłości z kolejnością procesów i opisuje dopuszczalny tryb ograniczony, zanim możliwy będzie pełny powrót do działania.

W praktyce

BCP (Business Continuity Plan, plan ciągłości działania) opisuje ciągłość biznesu, a DRP (Disaster Recovery Plan, plan odtwarzania awaryjnego) skupia się na odtworzeniu technologii. Plan należy ćwiczyć w realistycznych scenariuszach, np. utraty budynku, dostawcy chmurowego lub systemu tożsamości. Test powinien wykazać decyzje, czasy, obejścia, problemy komunikacyjne i działania doskonalące.

#bcp

Bezpieczeństwo łańcucha dostaw

Zarządzanie ryzykiem wynikającym z produktów, usług i podmiotów zewnętrznych mających wpływ na systemy lub usługi organizacji. Obejmuje wybór dostawcy, wymagania umowne, dostęp zewnętrzny, podatności produktu, podwykonawców, monitoring i bezpieczne zakończenie współpracy. Ryzyko nie kończy się na bezpośrednim kontrahencie: znaczenie mogą mieć jego podwykonawcy, lokalizacja przetwarzania, zależność od jednego producenta i możliwość bezpiecznego wyjścia z usługi. Wymagania powinny obejmować cały cykl współpracy, od kwalifikacji do zwrotu lub usunięcia danych.

W praktyce

Ocena powinna zależeć od krytyczności i realnego dostępu dostawcy, a nie być identycznym kwestionariuszem dla wszystkich kontrahentów. Dostawców warto podzielić na poziomy krytyczności. Dla najważniejszych sprawdza się zabezpieczenia i dowody, uzgadnia terminy zgłoszeń, prawo do weryfikacji, zasady dostępu i ciągłości oraz regularnie ocenia zmiany ryzyka.

#bezpieczenstwo-lancucha-dostaw

BIA

Business Impact Analysis

Analiza skutków niedostępności procesów i usług w czasie. Pozwala ustalić, co jest naprawdę krytyczne, jakie zależności trzeba odtworzyć najpierw i po jakim czasie strata staje się nieakceptowalna. Analiza bada, jak skutki finansowe, prawne, operacyjne, reputacyjne i dotyczące bezpieczeństwa rosną wraz z czasem przerwy. Uwzględnia także okresy szczytowe, terminy regulacyjne, ręczne obejścia oraz zależności od ludzi, danych, systemów i dostawców.

W praktyce

Z BIA (Business Impact Analysis, analizy wpływu na biznes) wynikają m.in. RTO (Recovery Time Objective, docelowy czas odtworzenia), RPO (Recovery Point Objective, docelowy punkt odtworzenia), MTPD (Maximum Tolerable Period of Disruption, maksymalny tolerowany czas zakłócenia) i MBCO (Minimum Business Continuity Objective, minimalny poziom ciągłości działania). Najlepiej prowadzić ją warsztatowo z właścicielami procesów, a wyniki zatwierdzać biznesowo. Uzgodnione parametry trzeba następnie przenieść do planów ciągłości, umów, architektury i scenariuszy testów.

#bia
C3 pojęcia

CIR 2024/2690

rozporządzenie wykonawcze Komisji (UE) 2024/2690

Bezpośrednio stosowany akt UE (Unii Europejskiej) doprecyzowujący techniczne i metodologiczne wymagania NIS2 (Network and Information Security Directive 2) dla wskazanych rodzajów podmiotów cyfrowych, m.in. dostawców DNS (Domain Name System), chmury, centrów danych, CDN (Content Delivery Network), platform internetowych, wyszukiwarek oraz usług zarządzanych. Rozporządzenie opisuje szczegółowe wymagania m.in. dla polityk, obsługi incydentów, ciągłości, bezpieczeństwa łańcucha dostaw, kontroli dostępu i oceny skuteczności. Jako rozporządzenie wykonawcze działa bez krajowej transpozycji, lecz tylko wobec podmiotów wskazanych w jego zakresie.

W praktyce

Nie jest uniwersalną listą kontrolną dla każdej firmy objętej KSC (Krajowym Systemem Cyberbezpieczeństwa); zakres stosowania trzeba najpierw potwierdzić. Najpierw należy potwierdzić rodzaj świadczonej usługi, a potem przypisać poszczególne wymagania do właścicieli, kontroli i dowodów. Wymagań nie należy przenosić mechanicznie na podmiot, którego rozporządzenie nie obejmuje.

#cir-2024-2690

CSIRT

Computer Security Incident Response Team

Zespół reagowania na incydenty bezpieczeństwa komputerowego. W Polsce na poziomie krajowym działają zespoły CSIRT (Computer Security Incident Response Team): CSIRT NASK (zespół prowadzony przez Naukową i Akademicką Sieć Komputerową), CSIRT GOV (rządowy zespół reagowania) i CSIRT MON (zespół resortu obrony narodowej), a właściwość zespołu zależy od rodzaju podmiotu i sektora. Zespół przyjmuje zgłoszenia, analizuje informacje, może przekazywać ostrzeżenia i wspierać koordynację reakcji. Nie przejmuje jednak odpowiedzialności organizacji za ograniczenie skutków, komunikację z odbiorcami, zachowanie dowodów ani decyzje dotyczące ciągłości usługi.

W praktyce

Podmiot objęty KSC (Krajowym Systemem Cyberbezpieczeństwa) powinien z góry wiedzieć, do którego CSIRT (Computer Security Incident Response Team) i w jaki sposób zgłasza incydent poważny. W planie reagowania warto zapisać właściwy zespół, kanały kontaktu, osoby uprawnione, zastępstwa i szablony kolejnych zgłoszeń. Podczas incydentu trzeba zachować czas wykrycia, klasyfikacji, decyzji i wysłania każdego raportu.

#csirt

Cyberhigiena

Zestaw podstawowych, regularnych zachowań ograniczających najczęstsze ryzyka: aktualizowanie systemów, bezpieczna praca z pocztą, MFA (Multi-Factor Authentication, uwierzytelnianie wieloskładnikowe), kopie zapasowe, kontrola dostępów oraz reagowanie na podejrzane zdarzenia. Obejmuje zarówno zachowania użytkowników, jak i podstawową dyscyplinę administracyjną: aktualne oprogramowanie, bezpieczne konfiguracje, rozdzielanie kont, ochronę poczty i weryfikację kopii. Zakres szkolenia powinien zależeć od roli oraz dostępu danej osoby.

W praktyce

To stały nawyk organizacji wspierany szkoleniami i kontrolami, a nie jednorazowa kampania. Organizacja może mierzyć pokrycie aktualizacjami, użycie uwierzytelniania wieloskładnikowego, wyniki symulacji phishingu i terminowość odbierania dostępów. Słaby wynik powinien prowadzić do konkretnego działania, nie wyłącznie kolejnego szkolenia.

#cyberhigiena
D6 pojęcia

DLP

Data Loss Prevention

Procesy i narzędzia pomagające wykrywać oraz ograniczać nieuprawniony przepływ informacji. DLP (Data Loss Prevention, zapobieganie utracie danych) może kontrolować dane w poczcie, chmurze, na urządzeniach końcowych i nośnikach, ale jego zakres powinien wynikać z klasyfikacji informacji i ryzyka. Mechanizmy te opierają się na regułach rozpoznających typ informacji, odbiorcę, kanał i kontekst użycia. Zbyt szerokie wdrożenie może powodować liczne fałszywe alarmy lub blokować legalną pracę, dlatego wymaga właścicieli danych i jasno opisanych wyjątków.

W praktyce

NIS2 (Network and Information Security Directive 2) nie nakazuje zakupu produktu DLP (Data Loss Prevention); wymaga adekwatnej ochrony informacji. Wdrożenie warto zacząć od najważniejszych klas informacji i najbardziej ryzykownych kanałów. Każdy alert powinien mieć sposób oceny, eskalacji i dokumentowania decyzji, a reguły muszą być regularnie dostrajane.

#dlp

Dokumentacja SZBI

Spójny zestaw zasad, rejestrów i zapisów pokazujących, jak organizacja zarządza bezpieczeństwem informacji. Obejmuje m.in. zakres SZBI (Systemu Zarządzania Bezpieczeństwem Informacji), polityki, role, ocenę ryzyka, plan postępowania z ryzykiem, procedury, wyniki kontroli, incydenty, wyjątki i przeglądy zarządcze. Trzeba odróżnić dokumenty sterujące, takie jak polityki i procedury, od zapisów potwierdzających wykonanie, takich jak protokoły testów, wyniki przeglądów i decyzje. Obie grupy są potrzebne, aby wykazać zarówno zaprojektowanie systemu, jak i jego rzeczywiste działanie.

W praktyce

Dokumentacja ma odzwierciedlać realną pracę i zawierać dowody wykonania, a nie tylko wzory procedur. Każdy dokument powinien mieć właściciela, wersję, zatwierdzenie, datę przeglądu i zasady dostępu. Rejestry warto łączyć bezpośrednio z zadaniami i dowodami, aby aktualność można było sprawdzić bez ręcznego przeszukiwania folderów.

#dokumentacja-szbi

Dostawca wysokiego ryzyka

Dostawca produktów, usług lub procesów ICT (Information and Communication Technology, technologii informacyjno-komunikacyjnych) uznany w decyzji właściwego organu za stwarzającego poważne zagrożenie dla bezpieczeństwa. Taki status uruchamia ograniczenia dotyczące pozyskiwania i używania wskazanych produktów lub usług. Decyzja może odnosić się do określonych produktów, usług, procesów lub ich zastosowania, dlatego nie należy automatycznie rozciągać jej na wszystko, co oferuje dostawca. Skutki i terminy postępowania wynikają z treści decyzji oraz właściwych przepisów.

W praktyce

To szczególny status prawny, a nie wewnętrzna etykieta nadawana każdemu ryzykownemu kontrahentowi. Organizacja powinna monitorować oficjalne decyzje, znać produkty i usługi używane w swoim środowisku oraz ich zależności. Po zmianie statusu potrzebna jest ocena ekspozycji, decyzja zakupowa i kontrolowany plan zastąpienia rozwiązania.

#dostawca-wysokiego-ryzyka

DR

Disaster Recovery

Zdolność organizacji do odtworzenia środowiska technologicznego po poważnej awarii, cyberataku lub utracie lokalizacji. Obejmuje dane, infrastrukturę, sieć, tożsamości, kolejność uruchamiania i dostępność odpowiednich osób. Zdolność odtworzeniowa obejmuje nie tylko dostępność kopii, ale także zapasową infrastrukturę, konfiguracje, klucze, łącza, instrukcje i kompetencje. Musi odpowiadać kolejności zależności: zwykle nie da się uruchomić aplikacji bez tożsamości, sieci, danych i usług bazowych.

W praktyce

Kopia zapasowa jest jednym z elementów DR (Disaster Recovery, odtwarzania awaryjnego), ale sama nie potwierdza zdolności odtworzenia usługi. Test powinien zaczynać się od założenia utraty konkretnego elementu i kończyć potwierdzeniem działania usługi przez użytkownika. Wynik zapisuje rzeczywisty czas, utracone dane, obejścia oraz przeszkody wymagające naprawy.

#dr

DRP

Disaster Recovery Plan

Udokumentowany plan przywrócenia systemów, danych i infrastruktury po zakłóceniu. Określa scenariusze, role, sekwencję działań, wymagane zasoby, sposób komunikacji oraz parametry odtworzenia. Plan zawiera kroki techniczne i decyzyjne, kryteria uruchomienia, listę kontaktów, zależności, lokalizację kopii oraz sposób powrotu ze środowiska awaryjnego. Powinien także wskazywać, kto może zaakceptować utratę danych lub dłuższą niedostępność.

W praktyce

Plan staje się wiarygodnym zabezpieczeniem dopiero po testach i udokumentowaniu ich wyników. Aktualna kopia planu i danych kontaktowych powinna być dostępna także wtedy, gdy podstawowe systemy nie działają. Ćwiczenia stołowe sprawdzają decyzje, a testy techniczne potwierdzają, czy procedura rzeczywiście odtwarza usługę.

#drp

Dyrektywa NIS2

dyrektywa (UE) 2022/2555

Unijny akt ustanawiający wspólny, wysoki poziom cyberbezpieczeństwa w UE (Unii Europejskiej). Określa m.in. grupy podmiotów, obowiązki zarządcze, środki zarządzania ryzykiem, zgłaszanie incydentów oraz ramy nadzoru i kar. Dyrektywa wyznacza minimalny rezultat, który państwa członkowskie muszą osiągnąć w prawie krajowym, pozostawiając im część decyzji wdrożeniowych. Dlatego szczegółowe obowiązki, właściwe organy, tryb rejestracji i sankcje mogą różnić się między państwami.

W praktyce

W Polsce organizacje realizują te wymagania przede wszystkim przez znowelizowaną ustawę o KSC (Krajowym Systemie Cyberbezpieczeństwa). Polska firma powinna zaczynać od ustawy krajowej i oficjalnych wyjaśnień, a do tekstu unijnego wracać dla kontekstu i zasad nadrzędnych. Dodatkowo trzeba sprawdzić bezpośrednio stosowane akty wykonawcze właściwe dla danej usługi.

#dyrektywa-nis2
E3 pojęcia

EDR

Endpoint Detection and Response

Technologia monitorowania stacji roboczych i serwerów, wykrywania podejrzanych zachowań oraz wspierania reakcji. Może umożliwiać izolację urządzenia, analizę procesu i zebranie materiału do dochodzenia. Rozwiązanie zbiera telemetrię z urządzeń końcowych, porównuje zachowania i umożliwia działania takie jak zatrzymanie procesu, izolacja hosta czy pobranie artefaktów. Jego skuteczność zależy od pokrycia urządzeń, jakości konfiguracji i dostępności osoby obsługującej alert.

W praktyce

EDR (Endpoint Detection and Response, wykrywanie i reagowanie na urządzeniach końcowych) jest jednym ze sposobów realizacji zdolności detekcji; ustawa pozostaje technologicznie neutralna. Należy znać urządzenia objęte ochroną, wyłączenia, czas przechowywania danych oraz procedury reakcji. Regularna próba kontrolowanego zdarzenia pozwala sprawdzić, czy alert dociera do właściwej osoby i prowadzi do działania.

#edr

ENISA

Agencja Unii Europejskiej ds. Cyberbezpieczeństwa

Agencja UE (Unii Europejskiej) wspierająca państwa członkowskie, instytucje i rynek w budowaniu cyberbezpieczeństwa. Publikuje wytyczne, analizy zagrożeń i materiały wdrożeniowe, a także wspiera współpracę przewidzianą w NIS2 (Network and Information Security Directive 2). Agencja tworzy wspólne metody, dobre praktyki i analizy wspierające spójne podejście w państwach członkowskich. Nie jest jednak polskim organem nadzorczym i nie wydaje indywidualnej decyzji o tym, czy konkretna spółka podlega krajowym przepisom.

W praktyce

Materiały ENISA (Agencji Unii Europejskiej ds. Cyberbezpieczeństwa) pomagają interpretować i wdrażać wymagania, lecz nie zastępują polskiej ustawy ani decyzji właściwego organu. Jej poradniki warto wykorzystywać do projektowania kontroli, modeli dojrzałości i ćwiczeń, a następnie porównywać z polskim prawem i wymaganiami sektorowymi. W dokumentacji dobrze wskazać, które zalecenia przyjęto i dlaczego.

#enisa

EUR-Lex

Oficjalna baza prawa Unii Europejskiej. Zawiera treść dyrektywy NIS2 (Network and Information Security Directive 2), jej wersje językowe, sprostowania, historię dokumentu i powiązane akty wykonawcze. Baza pozwala odróżnić tekst pierwotny od wersji skonsolidowanej oraz sprawdzić daty, podstawę prawną i relacje z innymi aktami. Jest właściwym miejscem do cytowania prawa unijnego zamiast polegania na nieoficjalnych omówieniach.

W praktyce

Wyszukując NIS2 (Network and Information Security Directive 2) w EUR-Lex, warto użyć numeru 2022/2555 lub identyfikatora dokumentu 32022L2555. Przed użyciem przepisu należy sprawdzić status dokumentu, wybraną wersję językową i ewentualne sprostowania. Stabilny link do konkretnego aktu warto zapisać w rejestrze wymagań lub notatce kwalifikacyjnej.

#eur-lex
G1 pojęcie

GRC

Governance, Risk and Compliance

Sposób łączenia ładu organizacyjnego, zarządzania ryzykiem i zgodności w jednym modelu odpowiedzialności. Określenie GRC (Governance, Risk and Compliance, ład organizacyjny, ryzyko i zgodność) odnosi się zarówno do procesów, jak i do systemów wspierających rejestry, kontrole, dowody, wyjątki i raportowanie. Dojrzały model łączy wymagania z ryzykami, właścicielami, kontrolami, dowodami i decyzjami, dzięki czemu ta sama kontrola może wspierać kilka regulacji. Pozwala też oddzielić odpowiedzialność za rezultat od osoby wykonującej pojedyncze zadanie.

W praktyce

Narzędzie GRC (Governance, Risk and Compliance) daje wartość wtedy, gdy utrzymuje cykl pracy, a nie tylko przechowuje dokumenty. Przepływ powinien przypominać realną pracę: przypisanie, wykonanie, przegląd, wyjątek i eskalację. Przed konfiguracją narzędzia warto uzgodnić słownik statusów, role i minimalny zestaw dowodów.

#grc
I5 pojęcia

IAM

Identity and Access Management

Zarządzanie całym cyklem życia tożsamości i uprawnień: od utworzenia konta, przez zmianę roli, po odebranie dostępu. Obejmuje uwierzytelnianie, autoryzację, przeglądy dostępów i zasadę minimalnych uprawnień. Zakres obejmuje pracowników, współpracowników, konta techniczne, roboty i tożsamości dostawców. Kluczowe są procesy dołączania, zmiany roli i odejścia oraz rozdział obowiązków zapobiegający nadmiernemu skupieniu uprawnień.

W praktyce

Najważniejszy dowód to terminowe nadawanie, przeglądanie i odbieranie uprawnień zgodnie z rolą. Dla systemów krytycznych przeprowadza się cykliczne przeglądy dostępów potwierdzane przez właścicieli. Wyjątki, konta współdzielone i nieużywane uprawnienia powinny mieć termin usunięcia lub formalną decyzję.

#iam

Incydent

Zdarzenie, które narusza dostępność, autentyczność, integralność lub poufność przechowywanych, przekazywanych albo przetwarzanych danych lub usług oferowanych przez systemy informacyjne. Definicja obejmuje zarówno udany atak, jak i awarię lub inne zdarzenie naruszające bezpieczeństwo usługi. Wewnętrzna klasyfikacja może wyróżniać poziomy dotkliwości, lecz musi pozostawać spójna z ustawowymi kryteriami zgłaszania.

W praktyce

Każdy incydent należy obsłużyć i zarejestrować; nie każdy spełnia kryteria incydentu poważnego wymagającego zgłoszenia. Rejestr incydentów powinien zawierać chronologię, zakres, wpływ, podjęte działania, decyzje o zgłoszeniu i wnioski. Po zamknięciu istotnego zdarzenia trzeba sprawdzić, czy poprawiono zabezpieczenia, procedury i szkolenia.

#incydent

Incydent krytyczny

Incydent o skutkach wykraczających poza pojedynczą organizację, mogący powodować poważne zakłócenia funkcjonowania państwa, gospodarki lub życia społecznego. Jego obsługa wymaga koordynacji na poziomie krajowym. Ocenia się nie tylko bezpośrednią stratę podmiotu, ale także efekt kaskadowy, liczbę odbiorców, znaczenie usługi i wpływ na bezpieczeństwo publiczne. Takie zdarzenie może uruchamiać nadzwyczajne mechanizmy koordynacji i polecenia organów państwa.

W praktyce

Klasyfikacja krytyczna nie jest dowolną oceną firmy; wynika ze skali i charakteru skutków określonych w przepisach. Organizacja świadcząca istotną usługę powinna znać zależności zewnętrzne, kontakty kryzysowe i sposób przekazywania wiarygodnych danych sytuacyjnych. Decyzje techniczne muszą być skoordynowane z ciągłością oraz komunikacją publiczną.

#incydent-krytyczny

Incydent poważny

Incydent, który powoduje lub może spowodować poważne zakłócenie świadczenia usług, istotną stratę finansową albo znaczną szkodę dla innych osób lub podmiotów. W NIS2 (Network and Information Security Directive 2) uruchamia etapowe raportowanie, w tym wczesne ostrzeżenie w 24 godziny i zgłoszenie w 72 godziny. Ocena opiera się na rzeczywistym lub możliwym wpływie, a nie wyłącznie na technicznej nazwie ataku. Raportowanie jest kaskadowe: kolejne etapy uzupełniają informacje wraz z postępem analizy i nie wymagają pełnej wiedzy już przy pierwszym ostrzeżeniu.

W praktyce

Organizacja potrzebuje wcześniej uzgodnionych kryteriów klasyfikacji i ścieżki decyzyjnej działającej także poza godzinami pracy. Playbook powinien określać progi, rolę decyzyjną, minimalny zakres danych i zastępstwa. Zegar należy liczyć od wykrycia zgodnie z przepisami, dlatego precyzyjne znaczniki czasu i szybka eskalacja są równie ważne jak analiza techniczna.

#incydent-powazny

ISO/IEC 27001

Międzynarodowa norma ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) 27001 określająca wymagania dla systemu zarządzania bezpieczeństwem informacji. Pomaga ułożyć SZBI (System Zarządzania Bezpieczeństwem Informacji) w cykl planowania, wykonywania, oceny i doskonalenia, ale zakres normy i polskich obowiązków ustawowych nie jest identyczny. Norma opisuje wymagania dla systemu zarządzania, natomiast katalog zabezpieczeń w jej załączniku wspiera dobór kontroli do ryzyka. Organizacja może stosować ten model bez certyfikacji albo poddać określony zakres niezależnej ocenie certyfikacyjnej.

W praktyce

Certyfikat może wspierać wykazanie dojrzałości, lecz nie daje automatycznej zgodności z KSC (Krajowym Systemem Cyberbezpieczeństwa). Warto przygotować mapę zgodności normy z obowiązkami ustawowymi i wyraźnie zaznaczyć różnice. Szczególnej uwagi wymagają zakres podmiotu, zgłoszenia incydentów, rejestracja, odpowiedzialność kierownictwa i wymagania sektorowe.

#iso-iec-27001
K5 pojęcia

Kierownik podmiotu

Osoba albo organ zarządzający podmiotem kluczowym lub ważnym; w spółce kapitałowej będzie to co do zasady zarząd. Kierownik zatwierdza rozwiązania organizacyjne, nadzoruje wykonanie obowiązków i odpowiada za właściwe decyzje zarządcze. Odpowiedzialność dotyczy ustanowienia właściwych warunków organizacyjnych, zatwierdzania kluczowych rozwiązań i kontroli postępu. Kierownik nie musi sam wykonywać czynności technicznych, ale powinien rozumieć ryzyka i podejmować udokumentowane decyzje.

W praktyce

Zadania można rozdzielić między zespoły, ale nadzoru i decyzji zarządu nie zastępuje delegacja do IT (Information Technology, działu technologii informacyjnej). W kalendarzu zarządu warto zaplanować zatwierdzenie systemu, szkolenia, przeglądy ryzyka, ocenę wyjątków i decyzje budżetowe. Materiał powinien pokazywać skutki biznesowe, właścicieli i opóźnienia, a nie tylko listę technicznych alertów.

#kierownik-podmiotu

Kod PKD / NACE

PKD (Polska Klasyfikacja Działalności) i NACE (Nomenclature statistique des Activités économiques dans la Communauté européenne) klasyfikują rodzaje działalności gospodarczej i są używane pomocniczo przy ustalaniu, czy organizacja działa w sektorze objętym NIS2 (Network and Information Security Directive 2) lub KSC (Krajowym Systemem Cyberbezpieczeństwa). Sam kod rejestrowy nie przesądza jednak statusu - liczy się faktycznie wykonywana działalność lub świadczona usługa. Klasyfikacje porządkują działalności, ale wpis może być nieaktualny, zbyt ogólny albo nie odzwierciedlać wszystkich usług spółki. W kwalifikacji znaczenie mają także załączniki sektorowe, progi wielkości, podmioty powiązane i wyjątki niezależne od skali.

W praktyce

Kwalifikacja zakresu powinna łączyć kody z opisem usług, klientami, zezwoleniami i strukturą grupy. Dobrą podstawą jest tabela łącząca każdą realną usługę z kodem, przychodem, klientami, zezwoleniami, systemami i osobą prawną. Pozwala ona uzasadnić zarówno objęcie, jak i wyłączenie danego zakresu.

#kod-pkd-nace

KPI

Key Performance Indicator

Wskaźnik pokazujący, czy proces osiąga zamierzony wynik. W SZBI (Systemie Zarządzania Bezpieczeństwem Informacji) może mierzyć np. terminowość usuwania podatności, wykonanie testów odtworzeniowych albo odsetek zamkniętych działań naprawczych. Wskaźnik wykonania odpowiada na pytanie, czy zaplanowany proces działa sprawnie i osiąga cel. Nie powinien być mylony ze wskaźnikiem ryzyka: wysoka terminowość działań może współistnieć z nadal wysoką ekspozycją organizacji.

W praktyce

KPI (Key Performance Indicator, kluczowy wskaźnik efektywności) powinien mieć właściciela, częstotliwość pomiaru, źródło danych i próg wymagający reakcji. Oprócz wartości bieżącej warto pokazywać cel, trend, zakres danych i komentarz właściciela. Jeśli wskaźnik przekracza próg, raport powinien automatycznie prowadzić do decyzji lub działania korygującego.

#kpi

KRI

Key Risk Indicator

Wskaźnik sygnalizujący wzrost ekspozycji na ryzyko, zanim wystąpi szkoda. Przykładem może być liczba krytycznych podatności po terminie, kont uprzywilejowanych bez MFA (Multi-Factor Authentication, uwierzytelniania wieloskładnikowego) albo dostawców bez aktualnej oceny. Dobry wskaźnik ryzyka reaguje wcześniej niż wynik finansowy lub incydent i pokazuje kierunek zmiany ekspozycji. Jego próg powinien wynikać z apetytu na ryzyko, historii zdarzeń i zdolności organizacji do podjęcia reakcji.

W praktyce

KRI (Key Risk Indicator, kluczowy wskaźnik ryzyka) służy wczesnej eskalacji; powinien być powiązany z apetytem na ryzyko i decyzjami zarządu. Dla każdego progu trzeba określić odbiorcę, oczekiwaną decyzję i maksymalny czas reakcji. Wskaźnik bez wiarygodnego źródła, właściciela i procedury eskalacji staje się tylko liczbą w raporcie.

#kri

KSC

Krajowy System Cyberbezpieczeństwa

Polskie ramy prawne i instytucjonalne cyberbezpieczeństwa, oparte na ustawie z 5 lipca 2018 r. znowelizowanej w 2026 r. w celu wdrożenia NIS2 (Network and Information Security Directive 2). Ustawa określa m.in. podmioty kluczowe i ważne, ich obowiązki, organy właściwe, zespoły CSIRT (Computer Security Incident Response Team), nadzór oraz kary. System obejmuje nie tylko obowiązki firm, lecz także organy właściwe, zespoły reagowania, mechanizmy współpracy, nadzór i wymianę informacji. Nowelizacja rozszerzyła zakres sektorów i przeniosła ciężar rozpoznania statusu w dużej mierze na same organizacje.

W praktyce

Dla polskiej organizacji punktem operacyjnym jest aktualna ustawa o KSC (Krajowym Systemie Cyberbezpieczeństwa), nie sama treść dyrektywy. Pierwszym krokiem jest udokumentowana kwalifikacja działalności i wielkości. Dopiero potem można poprawnie ustalić wpis do wykazu, właściwy organ, terminy, zakres systemu bezpieczeństwa i wymagane dowody.

#ksc
M4 pojęcia

MBCO

Minimum Business Continuity Objective

Najniższy akceptowalny poziom świadczenia procesu lub usługi podczas zakłócenia. Wskazuje, co organizacja musi utrzymać nawet wtedy, gdy pełna wydajność jest czasowo niemożliwa. Parametr opisuje minimalny rezultat biznesowy, a nie minimalną liczbę działających serwerów. Może być wyrażony np. liczbą obsłużonych klientów, przepustowością, zakresem funkcji albo bezpiecznym trybem ręcznym.

W praktyce

MBCO (Minimum Business Continuity Objective, minimalny poziom ciągłości działania) ustala właściciel biznesowy na podstawie BIA (Business Impact Analysis, analizy wpływu na biznes), zależności i zobowiązań wobec odbiorców. Dla scenariusza awaryjnego warto wskazać minimalną obsadę, dane, lokalizację, dostawców i funkcje potrzebne do utrzymania poziomu. Test powinien potwierdzić, czy taki tryb jest realny i jak długo można go utrzymać.

#mbco

MDR

Managed Detection and Response

Zewnętrzna usługa monitorowania, wykrywania i wspierania reakcji na zagrożenia. Zwykle łączy technologię telemetryczną z zespołem analityków pracującym w rozszerzonym lub całodobowym trybie. Zakres usług rynkowych jest różny: niektóre kończą się na przekazaniu alertu, inne obejmują dochodzenie, izolację urządzeń i udział w reagowaniu. Dlatego nazwę usługi trzeba przełożyć na dokładne role, godziny dostępności i odpowiedzialność.

W praktyce

MDR (Managed Detection and Response, zarządzana detekcja i reakcja) może uzupełnić braki kompetencyjne, ale odpowiedzialność za decyzje, zgłoszenia i ciągłość usługi pozostaje po stronie organizacji. Umowa powinna określać źródła danych, czasy wykrycia i eskalacji, uprawnienia do reakcji, kanały awaryjne oraz dostęp do zapisów. Trzeba też sprawdzić, czy dostawca wspiera terminowe zgłoszenie incydentu i zachowanie dowodów.

#mdr

MFA

Multi-Factor Authentication

Uwierzytelnianie wykorzystujące co najmniej dwa niezależne rodzaje składników, np. hasło oraz klucz sprzętowy lub aplikację. Istotnie ogranicza ryzyko przejęcia konta po ujawnieniu samego hasła. Składniki powinny pochodzić z różnych kategorii: wiedzy, posiadania lub cechy użytkownika. Największą odporność na phishing zapewniają metody kryptograficznie związane z właściwą usługą, np. klucze sprzętowe i nowoczesne klucze dostępu.

W praktyce

Pierwszeństwo mają konta uprzywilejowane, dostęp zdalny, poczta, chmura i systemy krytyczne. Wdrożenie obejmuje reguły dostępu warunkowego, bezpieczne metody odzyskiwania i konta awaryjne. Należy monitorować wyłączenia oraz próby obchodzenia mechanizmu, a słabsze metody pozostawiać tylko z uzasadnieniem.

#mfa

MTPD

Maximum Tolerable Period of Disruption

Najdłuższy czas, przez jaki proces lub usługa mogą pozostawać zakłócone, zanim konsekwencje staną się nieakceptowalne. Parametr uwzględnia m.in. klientów, bezpieczeństwo, prawo, finanse i reputację. Jest to granica nieakceptowalnego wpływu, a nie planowany czas powrotu. Powinna uwzględniać także czas potrzebny po technicznym odtworzeniu na usunięcie zaległości, weryfikację danych i przywrócenie normalnej jakości usługi.

W praktyce

RTO (Recovery Time Objective, docelowy czas odtworzenia) powinno być krótsze niż MTPD (Maximum Tolerable Period of Disruption, maksymalny tolerowany czas zakłócenia) i uwzględniać czas potrzebny na stabilizację procesu. Właściciele procesów oceniają skutki w kolejnych przedziałach czasu i wskazują moment przekroczenia tolerancji. Wynik należy uzgodnić z parametrami dostawców oraz realną zdolnością zespołów odtworzeniowych.

#mtpd
N2 pojęcia

NDR

Network Detection and Response

Monitorowanie ruchu sieciowego w celu wykrywania anomalii, podejrzanej komunikacji i zachowań wskazujących na atak. Uzupełnia widoczność z urządzeń końcowych, zwłaszcza w środowiskach bez agentów. Analiza może wykorzystywać metadane, wzorce komunikacji i zachowania protokołów, także gdy treść jest szyfrowana. Rozwiązanie pomaga zauważyć ruch boczny i urządzenia, których nie można objąć oprogramowaniem końcowym.

W praktyce

NDR (Network Detection and Response, wykrywanie i reagowanie w sieci) jest środkiem technicznym dobieranym do architektury i ryzyka, a nie obowiązkową pozycją zakupową NIS2 (Network and Information Security Directive 2). Najpierw trzeba znać architekturę, krytyczne segmenty i normalny ruch, następnie dostroić detekcje i przypisać reakcję. Alert bez kontekstu zasobu, właściciela i procedury może pozostać niewykorzystany.

#ndr

NIS2

Network and Information Security Directive 2

Powszechna nazwa dyrektywy UE (Unii Europejskiej) 2022/2555 w sprawie bezpieczeństwa sieci i informacji, czyli NIS2 (Network and Information Security Directive 2), która rozszerzyła wymagania cyberbezpieczeństwa na większą liczbę sektorów i organizacji. Dyrektywa mocniej akcentuje odpowiedzialność kierownictwa, zarządzanie ryzykiem, łańcuch dostaw, obsługę incydentów i nadzór. Nie jest certyfikatem, normą ani produktem technologicznym. Dyrektywa określa rezultat zarządzania cyberbezpieczeństwem, a państwa członkowskie przenoszą go do prawa krajowego i ustanawiają konkretne mechanizmy nadzoru.

W praktyce

W Polsce NIS2 (Network and Information Security Directive 2) została wdrożona nowelizacją ustawy o KSC (Krajowym Systemie Cyberbezpieczeństwa) obowiązującą od 3 kwietnia 2026 r. Status firmy ustala się na podstawie polskiej ustawy, rodzaju działalności, wielkości, powiązań oraz wyjątków. Następnie wymagania przekłada się na odpowiedzialności, środki, dowody i terminy w organizacji.

#nis2
O2 pojęcia

Odpowiedzialność kierownictwa

Obowiązek aktywnego zatwierdzania i nadzorowania środków zarządzania ryzykiem cyberbezpieczeństwa przez osoby kierujące organizacją. NIS2 (Network and Information Security Directive 2) i KSC (Krajowy System Cyberbezpieczeństwa) traktują bezpieczeństwo jako odpowiedzialność zarządczą, a nie wyłącznie techniczne zadanie IT (Information Technology, technologii informacyjnej). Kierownictwo powinno mieć wystarczającą wiedzę, aby rozumieć ryzyka, zatwierdzać adekwatne środki i oceniać ich wykonanie. Odpowiedzialności nie realizuje samo podpisanie polityki ani powołanie osoby do spraw bezpieczeństwa.

W praktyce

Zarząd potrzebuje cyklicznej informacji o ryzykach, wykonaniu kontroli, incydentach, wyjątkach i decyzjach wymagających zasobów. Potrzebny jest stały rytm raportowania, protokoły decyzji, szkolenia kierownictwa i jasna eskalacja braków zasobowych. Raport powinien łączyć ryzyko z usługą, właścicielem, terminem, dowodem i decyzją oczekiwaną od zarządu.

#odpowiedzialnosc-kierownictwa

Organ właściwy

Organ administracji odpowiedzialny za nadzór nad cyberbezpieczeństwem w określonym sektorze. Może żądać informacji i dowodów, prowadzić kontrole, wydawać zalecenia lub nakazy oraz stosować środki przewidziane w ustawie. Właściwość wynika z sektora i rodzaju działalności określonych w ustawie. Organ współpracuje z innymi uczestnikami systemu, a jego uprawnienia i model nadzoru zależą m.in. od statusu podmiotu oraz podstawy prawnej działania.

W praktyce

Właściwość ustala się na podstawie rodzaju działalności; jedna organizacja może podlegać więcej niż jednemu organowi. Organizacja powinna udokumentować ustalenie właściwości, wyznaczyć osoby do korespondencji i przechowywać historię przekazanych danych. Przy wielu działalnościach warto opisać zakres relacji z każdym organem.

#organ-wlasciwy
P7 pojęcia

PAM

Privileged Access Management

Kontrole i narzędzia chroniące konta administracyjne oraz inne wysokie uprawnienia. Obejmują m.in. sejf poświadczeń, zatwierdzanie dostępu, rotację haseł, rejestrowanie sesji i dostęp awaryjny. Podejście ogranicza stałe uprawnienia i pozwala przyznawać dostęp na żądanie, na określony czas i do konkretnego celu. Obejmuje również konta awaryjne, konta techniczne, dostęp dostawców oraz kontrolę poleceń wykonywanych w sesji.

W praktyce

Program PAM (Privileged Access Management, zarządzanie dostępem uprzywilejowanym) zaczyna się od inwentaryzacji kont i właścicieli, a nie od samego wdrożenia sejfu haseł. Należy ustalić właścicieli kont, wymóg zatwierdzenia, uwierzytelnianie, czas dostępu i przegląd nagrań lub logów. Konta awaryjne trzeba regularnie testować, chronić osobno i kontrolować po każdym użyciu.

#pam

Plan postępowania z ryzykiem

Zestaw uzgodnionych decyzji i działań dotyczących ryzyk: ograniczenia, unikania, przeniesienia albo akceptacji. Łączy każde istotne ryzyko ze środkiem bezpieczeństwa, właścicielem, terminem, zasobami i oczekiwanym wynikiem. Działanie może polegać na wdrożeniu nowej kontroli, poprawie istniejącej, zmianie procesu, ubezpieczeniu albo świadomej akceptacji. Plan powinien wskazywać oczekiwaną zmianę poziomu ryzyka, aby nie zamienić się w listę projektów bez mierzalnego celu.

W praktyce

Plan powinien pokazywać postęp i opóźnienia oraz być aktualizowany razem z rejestrem ryzyka. Każda pozycja potrzebuje właściciela działania, właściciela ryzyka, terminu, statusu, zależności i dowodu zakończenia. Opóźnienie powinno automatycznie uruchamiać ponowną ocenę ryzyka i właściwą eskalację.

#plan-postepowania-z-ryzykiem

Podatność

Słabość zasobu, konfiguracji, procesu lub sposobu organizacji, którą może wykorzystać zagrożenie. Podatności mogą być techniczne, ale również proceduralne, kompetencyjne i kontraktowe. Sama obecność podatności nie opisuje jeszcze ryzyka; znaczenie zależy od możliwości wykorzystania, ekspozycji, wartości zasobu i istniejących zabezpieczeń. Podatnością może być również brak zastępstwa, niejasna procedura albo słaby zapis umowny.

W praktyce

Zarządzanie podatnościami obejmuje wykrycie, ocenę ryzyka, termin naprawy, wyjątek oraz potwierdzenie skuteczności poprawki. Terminy naprawy należy różnicować według ryzyka, a nie samej punktacji technicznej. Wyjątek wymaga uzasadnienia, zabezpieczenia zastępczego, właściciela, daty końcowej i późniejszego potwierdzenia usunięcia luki.

#podatnosc

Podmiot kluczowy

Jedna z dwóch głównych kategorii organizacji objętych KSC (Krajowym Systemem Cyberbezpieczeństwa). Obejmuje co do zasady duże podmioty z sektorów o wysokiej krytyczności oraz niektóre podmioty wskazane niezależnie od wielkości. Podlega pełnemu zakresowi obowiązków i proaktywnemu nadzorowi. Status wynika z połączenia rodzaju działalności, wielkości oraz szczególnych reguł wskazanych w ustawie. Nie jest uzależniony wyłącznie od otrzymania zawiadomienia lub wpisu do wykazu, dlatego organizacja musi przeprowadzić własną ocenę.

W praktyce

Podmioty kluczowe mają m.in. cykliczny obowiązek audytu bezpieczeństwa; szczegółowy status wymaga kwalifikacji działalności i wielkości. Warto przygotować kartę kwalifikacji z opisem usług, progami, grupą, wyjątkami i źródłami danych. Następnie ustala się właściwy organ, zakres systemu bezpieczeństwa, harmonogram audytu i sposób wykazywania wykonania obowiązków.

#podmiot-kluczowy

Podmiot ważny

Druga główna kategoria organizacji objętych KSC (Krajowym Systemem Cyberbezpieczeństwa). Zwykle obejmuje średnie podmioty z sektorów o wysokiej krytyczności oraz średnie i duże podmioty z pozostałych sektorów krytycznych, z uwzględnieniem ustawowych wyjątków. Nazwa „ważny” nie oznacza niższego standardu podstawowych środków zarządzania ryzykiem. Różnica dotyczy przede wszystkim sposobu nadzoru i niektórych konsekwencji prawnych, a wymagany poziom ochrony nadal wynika z ryzyka oraz znaczenia usług.

W praktyce

Podstawowe wymagania bezpieczeństwa są podobne jak dla podmiotów kluczowych, ale model nadzoru jest co do zasady reaktywny. Nie należy obniżać kontroli tylko z powodu reaktywnego nadzoru. Podmiot powinien utrzymywać aktualną analizę ryzyka, dowody działania, gotowość incydentową i materiał, który można sprawnie przedstawić po żądaniu organu.

#podmiot-wazny

Polecenie zabezpieczające

Nadzwyczajny, czasowy środek prawny pozwalający nakazać określonym podmiotom konkretne działania w celu ograniczenia skutków incydentu krytycznego lub poważnego zagrożenia. Może dotyczyć np. konfiguracji, aktualizacji albo ograniczenia komunikacji. Treść polecenia określa adresatów, wymagane zachowanie, zakres i okres obowiązywania. Jego celem jest szybkie ograniczenie wspólnego zagrożenia, nawet jeżeli standardowy proces zmian lub zakupów trwałby znacznie dłużej.

W praktyce

Polecenie wymaga szybkiego wykonania, dlatego organizacja potrzebuje ścieżki eskalacji i zdolności do wprowadzania zmian awaryjnych. Plan kryzysowy powinien przewidywać odbiór polecenia, ocenę wpływu, uprawnienie do zmiany awaryjnej, komunikację i potwierdzenie wykonania. Trzeba także zapisać działania uboczne oraz sposób bezpiecznego wycofania zmiany.

#polecenie-zabezpieczajace

Polityka SZBI

Dokument nadrzędny SZBI (Systemu Zarządzania Bezpieczeństwem Informacji) opisujący cele, zasady, zakres i odpowiedzialność za bezpieczeństwo informacji. Powinien wynikać z kontekstu organizacji, być zatwierdzony przez kierownictwo i wskazywać, jak zarządza się ryzykiem oraz odstępstwami. Polityka powinna być na tyle zwięzła, aby kierownictwo i pracownicy rozumieli kierunek, a szczegółowe instrukcje przenosić do dokumentów niższego poziomu. Musi być spójna z profilem ryzyka, obowiązkami prawnymi i rzeczywistą strukturą odpowiedzialności.

W praktyce

Polityka wyznacza kierunek; procedury, rejestry, kontrole i dowody pokazują jej wykonanie. Przegląd wykonuje się cyklicznie oraz po istotnej zmianie lub incydencie. Organizacja powinna potrafić wskazać, które procedury i kontrole realizują poszczególne zasady oraz jak pracownicy zostali z nimi zapoznani.

#polityka-szbi
R3 pojęcia

RPO

Recovery Point Objective

Maksymalny akceptowalny zakres utraty danych mierzony czasem. RPO (Recovery Point Objective, docelowy punkt odtworzenia) równe czterem godzinom oznacza, że po odtworzeniu organizacja dopuszcza powrót do danych sprzed nie więcej niż czterech godzin. Parametr nie określa częstotliwości wykonywania kopii wprost, ponieważ liczy się osiągalny punkt odtworzenia całej usługi. Replikacja również nie gwarantuje właściwego wyniku, jeśli błąd lub szyfrowanie zostaną natychmiast skopiowane do środowiska zapasowego.

W praktyce

RPO (Recovery Point Objective) ustala biznes na podstawie BIA (Business Impact Analysis, analizy wpływu na biznes), a technologia kopii zapasowych ma umożliwić jego osiągnięcie. Test polega na odtworzeniu danych z wybranego punktu, sprawdzeniu ich spójności i uzgodnieniu brakujących transakcji. Wynik porównuje się z wymaganiem właściciela procesu, a rozbieżność prowadzi do planu naprawy.

#rpo

RTO

Recovery Time Objective

Docelowy czas przywrócenia procesu, usługi albo systemu po zakłóceniu. RTO (Recovery Time Objective, docelowy czas odtworzenia) jest wymaganiem biznesowym, które wpływa na architekturę, procedury awaryjne, umowy i priorytety odtwarzania. Pomiar powinien obejmować pełną gotowość usługi do użycia, nie moment uruchomienia pojedynczego komponentu. Na czas wpływają wykrycie awarii, decyzja, dostępność ludzi, odtworzenie zależności, testy oraz przekazanie usługi użytkownikom.

W praktyce

Osiągalność RTO (Recovery Time Objective) potwierdza się testem obejmującym cały proces, a nie tylko uruchomienie serwera. Podczas ćwiczenia zapisuje się czas każdego etapu i punkt zakończenia uzgodniony z biznesem. Jeśli wynik przekracza cel, trzeba poprawić architekturę, procedurę, zasoby albo samo wymaganie po ponownej analizie skutków.

#rto

Ryzyko rezydualne

Poziom ryzyka pozostający po uwzględnieniu istniejących albo planowanych zabezpieczeń. Pokazuje, czy organizacja może ryzyko zaakceptować, czy potrzebuje kolejnych działań. Powinno uwzględniać rzeczywistą skuteczność zabezpieczeń, a nie tylko fakt ich formalnego istnienia. Jeżeli kontrola nie została przetestowana, ocena pozostałego ryzyka musi odzwierciedlać tę niepewność.

W praktyce

Ryzyko rezydualne musi mieć właściciela, uzasadnioną decyzję i termin ponownego przeglądu. Właściciel porównuje wynik z apetytem na ryzyko i wybiera dalsze działanie. Akceptacja ponad ustalony próg wymaga eskalacji, a zmiana kontroli, podatności lub skutku powinna uruchomić ponowną ocenę.

#ryzyko-rezydualne
S6 pojęcia

S46

System teleinformatyczny S46 wspierający komunikację i wymianę informacji w KSC (Krajowym Systemie Cyberbezpieczeństwa). Jest powiązany z Wykazem KSC (wykazem podmiotów kluczowych i ważnych) i służy podmiotom m.in. do realizacji obowiązków operacyjnych oraz kontaktu z właściwymi uczestnikami systemu. W praktyce składa się z funkcji związanych z wykazem oraz z przestrzeni służącej podmiotom do współpracy i realizacji obowiązków. Dostęp, harmonogram uruchomienia funkcji i wymagane dane należy sprawdzać w aktualnych komunikatach urzędowych.

W praktyce

Wpis do Wykazu KSC (wykazu podmiotów kluczowych i ważnych) i dostęp do Systemu S46 są powiązane, ale pozostają odrębnymi etapami organizacyjnymi. Warto wyznaczyć administratora, zastępstwo i osoby kontaktowe, przetestować logowanie oraz przygotować dane identyfikacyjne i sektorowe. Zmiany osób, adresów lub zakresu działalności powinny mieć właściciela i termin aktualizacji.

#s46

SIEM

Security Information and Event Management

Platforma gromadząca i analizująca logi oraz zdarzenia z wielu systemów. Wspiera korelację sygnałów, wykrywanie incydentów, dochodzenie i zachowanie historii potrzebnej do analizy. Platforma może przechowywać dane dla różnych celów: bieżącej detekcji, dochodzenia, wymagań prawnych i analizy trendów. Potrzebuje katalogu źródeł, przypadków użycia, reguł, czasu retencji oraz kontroli dostępu do wrażliwych logów.

W praktyce

Skuteczność SIEM (Security Information and Event Management, zarządzania informacjami i zdarzeniami bezpieczeństwa) zależy od jakości źródeł, reguł, obsługi alertów i reakcji - samo uruchomienie licencji nie tworzy monitoringu. Należy monitorować, czy źródła nadal przesyłają kompletne dane, i testować reguły na znanych scenariuszach. Każdy istotny alert powinien prowadzić do instrukcji analizy, właściciela i mierzonego czasu reakcji.

#siem

SOAR

Security Orchestration, Automation and Response

Rozwiązanie automatyzujące powtarzalne etapy obsługi alertów i incydentów, takie jak zebranie kontekstu, utworzenie sprawy czy blokada wskaźnika ataku. Łączy narzędzia bezpieczeństwa z ustalonymi scenariuszami reakcji. Scenariusz automatyzacji może łączyć wzbogacenie alertu, komunikację, zmianę konfiguracji i dokumentowanie sprawy. Ponieważ część działań wpływa na dostępność usług, potrzebne są warunki bezpieczeństwa, zatwierdzenia i możliwość ręcznego zatrzymania.

W praktyce

Automatyzacja daje wartość, gdy proces, odpowiedzialność i warunki decyzji są już jasno opisane. Najlepiej zaczynać od czynności częstych, odwracalnych i mało ryzykownych, a dopiero potem automatyzować blokady. Każdy scenariusz trzeba wersjonować, testować i przeglądać po zmianach narzędzi lub procesu.

#soar

SOC

Security Operations Center

Zorganizowana zdolność ludzi, procesów i technologii do ciągłego monitorowania, analizowania i obsługi zagrożeń. SOC (Security Operations Center, centrum operacji bezpieczeństwa) może działać wewnętrznie, usługowo albo w modelu mieszanym. Zdolność operacyjna wymaga określenia godzin pokrycia, źródeł danych, poziomów analizy, zasad eskalacji i współpracy podczas incydentu. Może być rozproszona między zespoły oraz dostawców, jeżeli odpowiedzialność i przekazanie spraw są jednoznaczne.

W praktyce

KSC (Krajowy System Cyberbezpieczeństwa) wymaga adekwatnej zdolności wykrywania i reakcji, ale nie narzuca każdej organizacji budowy własnego SOC (Security Operations Center) działającego całodobowo. Organizacja powinna mieć katalog monitorowanych usług, matrycę dyżurów i ścieżkę do osoby podejmującej decyzje biznesowe. Ćwiczenie poza godzinami pracy pokazuje, czy model pozwala dotrzymać terminów i ograniczyć skutki.

#soc

System informacyjny

Zorganizowany układ zasobów technicznych i organizacyjnych służący do przetwarzania, przechowywania lub przekazywania informacji. Obejmuje nie tylko aplikacje, lecz także sieci, urządzenia, dane, procedury i osoby potrzebne do działania usługi. Granice systemu wyznacza zdolność świadczenia usługi, dlatego mogą obejmować elementy pozostające u dostawcy oraz procesy ręczne. Pominięcie tożsamości, łączy, integracji lub danych prowadzi do zaniżenia ryzyka i nierealnych planów odtworzenia.

W praktyce

Zakres systemu informacyjnego powinien wynikać z usług i zależności biznesowych, nie z samego spisu serwerów. Dobrą reprezentacją jest mapa usługi pokazująca komponenty, przepływy danych, właścicieli, dostawców i zależności. Mapę aktualizuje się wraz ze zmianą architektury i wykorzystuje w analizie ryzyka, incydentach oraz ciągłości.

#system-informacyjny

SZBI

System Zarządzania Bezpieczeństwem Informacji

Całościowy sposób zarządzania bezpieczeństwem informacji: cele, role, ocena ryzyka, polityki, procesy, zabezpieczenia, dowody, pomiary i doskonalenie. SZBI (System Zarządzania Bezpieczeństwem Informacji) łączy decyzje zarządcze z codziennym wykonaniem i pozwala wykazać, że środki bezpieczeństwa rzeczywiście działają. System działa w cyklu: ustala kontekst i cele, ocenia ryzyko, wdraża środki, mierzy skuteczność oraz koryguje niezgodności. Powinien obejmować zarówno bezpieczeństwo technologii, jak i ludzi, dostawców, ciągłość, dokumentację oraz decyzje kierownictwa.

W praktyce

SZBI (System Zarządzania Bezpieczeństwem Informacji) nie jest pojedynczą polityką ani aplikacją; jest utrzymywanym cyklem odpowiedzialności, kontroli i przeglądów. Potrzebny jest roczny kalendarz ocen ryzyka, kontroli, testów, szkoleń, przeglądów dostawców i spotkań zarządczych. Każda czynność powinna pozostawiać wynik, właściciela, dowód i następne działanie.

#szbi
Ś2 pojęcia

Ścieżka audytu

Chronologiczny zapis działań i decyzji pozwalający odtworzyć, kto, kiedy i na jakiej podstawie wykonał lub zatwierdził daną czynność. Łączy wymaganie z właścicielem, zadaniem, dowodem, wynikiem kontroli i zmianą statusu. Zapis powinien być kompletny, chroniony przed nieuprawnioną zmianą i przechowywany przez uzasadniony okres. Musi pozwalać połączyć decyzję z obowiązującą wersją wymagania i materiałem, na którym osoba decyzyjna się opierała.

W praktyce

Dobra ścieżka audytu skraca przygotowanie do kontroli i ujawnia miejsca, w których proces istnieje tylko na papierze. W jednym widoku warto łączyć wymaganie, kontrolę, wykonanie, załącznik, przegląd i wyjątek. Uprawnienia, wersjonowanie i znaczniki czasu powinny umożliwiać wykazanie integralności historii.

#sciezka-audytu

Środki zarządzania ryzykiem

Organizacyjne, operacyjne i techniczne rozwiązania ograniczające ryzyko cyberbezpieczeństwa. NIS2 (Network and Information Security Directive 2) obejmuje nimi m.in. analizę ryzyka, incydenty, ciągłość działania, łańcuch dostaw, bezpieczny rozwój, ocenę skuteczności, cyberhigienę, kryptografię i kontrolę dostępu. Nie istnieje jedna poprawna lista zabezpieczeń dla wszystkich podmiotów. Dobór bierze pod uwagę aktualny stan wiedzy, koszt, prawdopodobieństwo, możliwy skutek oraz charakter i skalę usługi, a skuteczność trzeba później oceniać.

W praktyce

Środki powinny być proporcjonalne do ryzyka, skali, kosztu wdrożenia oraz możliwych skutków incydentu. Każdy środek powinien mieć cel, właściciela, zakres, częstotliwość, sposób wykonania i oczekiwany dowód. Wyjątki oraz nieskuteczne kontrole wracają do oceny ryzyka i planu postępowania.

#srodki-zarzadzania-ryzykiem
W3 pojęcia

Właściciel procesu

Osoba biznesowo odpowiedzialna za wynik procesu, jego wymagania, krytyczność i zależności. Podejmuje lub przygotowuje decyzje dotyczące priorytetów, ciągłości działania oraz akceptowalnego poziomu usługi. Odpowiada za biznesową definicję procesu i uzgodnienie wymagań z zespołami wspierającymi. Może delegować wykonanie zadań, lecz pozostaje źródłem decyzji o krytyczności, dopuszczalnym przestoju i priorytecie naprawy.

W praktyce

Właściciel procesu ustala potrzeby biznesowe, a IT (Information Technology, zespół technologii informacyjnej) przekłada je na wykonalne rozwiązania techniczne. Powinien zatwierdzać wyniki analizy wpływu, parametry ciągłości, istotne wyjątki i kryteria odbioru. W rejestrach należy odróżnić go od właściciela systemu oraz osoby wykonującej kontrolę.

#wlasciciel-procesu

Właściciel ryzyka

Osoba mająca mandat do decydowania o sposobie postępowania z konkretnym ryzykiem i do zatwierdzenia ryzyka rezydualnego w granicach swoich uprawnień. Nie musi być osobą, która wykonuje działania naprawcze; odpowiada za decyzję i zapewnienie właściwego kierunku postępowania. Jego poziom w organizacji powinien odpowiadać skali możliwych skutków i potrzebnym zasobom.

W praktyce

Ryzyko bez wskazanego właściciela zwykle nie ma ani decyzji, ani budżetu, ani terminu działania. W rejestrze warto wskazać granice mandatu, próg eskalacji i zastępstwo. Właściciel okresowo potwierdza ocenę, monitoruje plan działań i formalnie decyduje o ryzyku pozostającym po zabezpieczeniach.

#wlasciciel-ryzyka

Wykaz KSC

Wykaz KSC (wykaz podmiotów kluczowych i podmiotów ważnych) prowadzony przez ministra właściwego do spraw informatyzacji. Wpis potwierdza status wynikający z ustawowych przesłanek; nie zwalnia podmiotu z samodzielnej oceny zakresu działalności. Wpis ma charakter potwierdzający status wynikający z przepisów, a brak wpisu nie zawsze oznacza brak obowiązków. Wykaz gromadzi dane identyfikacyjne, klasyfikację, działalności regulowane i osoby kontaktowe potrzebne do działania systemu.

W praktyce

Podmiot składa wniosek co do zasady w ciągu sześciu miesięcy od spełnienia przesłanek, przez usługę powiązaną z Systemem S46 (systemem teleinformatycznym Krajowego Systemu Cyberbezpieczeństwa). Przed złożeniem wniosku trzeba potwierdzić kwalifikację, przygotować dane i ustalić osobę uprawnioną do podpisu. Po wpisie należy utrzymywać aktualność informacji oraz kontrolować dostęp administratora i osób kontaktowych.

#wykaz-ksc
X1 pojęcie

XDR

Extended Detection and Response

Podejście do detekcji i reakcji łączące sygnały z kilku warstw środowiska, np. urządzeń końcowych, poczty, sieci, tożsamości i chmury. Ma ułatwiać korelację zdarzeń oraz skrócić analizę incydentu. Rozwiązanie może łączyć dane pochodzące od jednego producenta albo integrować wiele źródeł, dlatego zakres tej nazwy różni się rynkowo. Wartością jest wspólny kontekst incydentu i możliwość skoordynowanej reakcji w kilku warstwach.

W praktyce

O wyborze XDR (Extended Detection and Response, rozszerzonej detekcji i reakcji) powinien decydować model operacyjny i luki w widoczności, a nie sama nazwa kategorii produktu. Przed wyborem trzeba sprawdzić pokrycie własnych systemów, jakość integracji, przechowywanie danych i uprawnienia reakcji. Test scenariusza powinien potwierdzić, czy analityk otrzymuje pełniejszy obraz i oszczędza czas.

#xdr
Z3 pojęcia

Zagrożenie

Potencjalna przyczyna niepożądanego zdarzenia, np. działalność przestępcza, błąd człowieka, awaria techniczna, przerwa w dostawie lub zjawisko naturalne. Zagrożenie może wykorzystać podatność i spowodować szkodę dla aktywa albo usługi. Należy odróżnić je od podatności, która jest słabością, oraz od ryzyka, które opisuje prawdopodobieństwo i skutek konkretnego scenariusza. To samo zagrożenie może tworzyć zupełnie inne ryzyko dla różnych usług.

W praktyce

Analiza ryzyka łączy zagrożenia z podatnościami, aktywami, istniejącymi zabezpieczeniami i skutkami biznesowymi. Katalog zagrożeń warto budować z historii incydentów, analiz sektorowych, informacji o dostawcach i zmian geopolitycznych. Dla priorytetowych zagrożeń tworzy się scenariusze powiązane z aktywami, zabezpieczeniami i planami reakcji.

#zagrozenie

Załączniki nr 1 i 2 do KSC

Katalogi sektorów i rodzajów działalności wykorzystywane do ustalania zakresu polskiej ustawy o KSC (Krajowym Systemie Cyberbezpieczeństwa). Załącznik nr 1 obejmuje sektory o wysokiej krytyczności, a załącznik nr 2 pozostałe sektory krytyczne. Załączniki posługują się precyzyjnymi opisami działalności i usług, które nie zawsze pokrywają się z potoczną nazwą branży. Klasyfikację uzupełniają przepisy dotyczące wielkości, podmiotów publicznych, wyjątków i wskazania niezależnego od progu.

W praktyce

Samo odnalezienie branży w załączniku nie kończy kwalifikacji - trzeba sprawdzić konkretną działalność, wielkość, powiązania i wyjątki. Dla każdej usługi należy wskazać właściwą pozycję albo uzasadnione wyłączenie, osobę prawną, dane o wielkości i powiązaniach. Taka mapa staje się podstawą wniosku do wykazu oraz zakresu dalszego wdrożenia.

#zalaczniki-ksc

Zero Trust

Model bezpieczeństwa zakładający ciągłą weryfikację tożsamości, urządzenia i kontekstu oraz przyznawanie tylko niezbędnych uprawnień. Zaufanie nie wynika automatycznie z obecności użytkownika wewnątrz sieci. Model łączy zarządzanie tożsamością, stan urządzeń, segmentację, ochronę aplikacji i danych oraz ciągłe monitorowanie. Decyzja o dostępie jest podejmowana na podstawie aktualnego kontekstu i może zostać ponownie oceniona w trakcie sesji.

W praktyce

Zero Trust to kierunek architektury wdrażany etapami, a nie pojedynczy produkt zapewniający zgodność z NIS2 (Network and Information Security Directive 2). Roadmapę warto zaczynać od silnej tożsamości, inwentaryzacji zasobów i ograniczenia uprawnień, a następnie rozwijać kontrolę urządzeń i segmentację. Każdy etap powinien rozwiązywać wskazane ryzyko i mieć mierzalny rezultat.

#zero-trust
SZBI · co to jest i jak wygląda

Przykład SZBI to działający cykl, nie jeden dokument.

Polityka SZBI porządkuje zasady, ale dopiero właściciele, rejestry, kontrole i dowody pokazują, że system zarządzania bezpieczeństwem informacji działa.

  1. 01

    Zakres i odpowiedzialność

    Usługi, systemy, właściciele, role zarządu i zasady eskalacji.

  2. 02

    Ryzyko i priorytety

    Aktywa, zagrożenia, podatności, ocena ryzyka i plan postępowania.

  3. 03

    Środki i procedury

    Kontrole organizacyjne, operacyjne i techniczne dobrane proporcjonalnie do ryzyka.

  4. 04

    Wykonanie i dowody

    Zadania, testy, akceptacje, zgłoszenia, protokoły i ścieżka audytu.

  5. 05

    Pomiar i przegląd

    KPI, KRI, wyjątki, wyniki kontroli i decyzje kierownictwa.

  6. 06

    Doskonalenie

    Działania po incydentach, audytach i zmianach organizacji lub otoczenia.

Dokumentacja SZBI w skrócie

Zakres i polityka · role i odpowiedzialności · metodyka oraz rejestr ryzyka · plan postępowania · procedury · rejestry aktywów, dostawców i incydentów · plan ciągłości · wyniki kontroli · wyjątki · przeglądy zarządcze.

Od definicji do wykonania

Wybierz następny krok dla organizacji.

Słownik pomaga mówić wspólnym językiem. Zakres obowiązków i sposób wdrożenia trzeba jednak dopasować do działalności, wielkości i gotowości zespołu.

01 · STATUS FIRMY

Nie wiecie, czy podlegacie?

Zacznijcie od bezpłatnego Pre-checku, a jeśli wynik wymaga potwierdzenia - od udokumentowanej Kwalifikacji KSC.

Sprawdź firmę w 3 minuty
02 · WDROŻENIE

Potrzebujecie prowadzenia?

W 90 dni uruchamiamy z Wami podstawowy program KSC: właścicieli, listę działań, kontrole, dowody i przegląd zarządu.

Zobacz wdrożenie 90 dni
03 · SAAS NIS2

Chcecie prowadzić system dalej?

Aplikacja UP² łączy wymagania z właścicielami, zadaniami, terminami, dowodami oraz decyzjami kierownictwa.

Poznaj aplikację NIS2