Incydent bezpieczeństwa może zdarzyć się w każdej organizacji. O jego skutkach często decyduje pierwsza godzina: czy pracownik wie, komu zgłosić problem, i czy zespół IT ma gotowy plan działania. Procedura zgłaszania incydentów bezpieczeństwa porządkuje te kroki i pomaga dotrzymać terminów z ustawy o krajowym systemie cyberbezpieczeństwa oraz RODO. Poniżej opisujemy, jak ją przygotować, wdrożyć i sprawdzić w praktyce. Korzystamy z doświadczeń z audytów i wdrożeń prowadzonych przez ICT Future w firmach, instytucjach kultury, jednostkach samorządu i placówkach ochrony zdrowia.
Co uznać za incydent w procedurze zgłaszania?
Procedura zaczyna się od definicji. Jeśli będzie zbyt wąska, pracownicy nie zgłoszą podejrzanych zdarzeń. Jeśli zbyt szeroka, zespół IT utonie w zgłoszeniach bez znaczenia. W praktyce przyjmujemy, że incydentem jest każde zdarzenie, które narusza lub może naruszyć poufność, integralność albo dostępność informacji. Nie ma znaczenia, czy dotyczy systemów IT, czy dokumentów papierowych.
W procedurze dobrze rozróżnić trzy pojęcia:
- incydent, czyli zdarzenie o niekorzystnym wpływie na bezpieczeństwo systemów lub danych,
- incydent poważny w rozumieniu ustawy o KSC, czyli taki, który powoduje lub może powodować poważne zakłócenie świadczenia usług albo straty finansowe, lub może wyrządzić szkody innym osobom,
- naruszenie ochrony danych osobowych w rozumieniu RODO, czyli przypadkowe lub niezgodne z prawem zniszczenie, utrata, zmiana albo ujawnienie danych osobowych.
Do procedury dopisujemy też przykłady zdarzeń do zgłoszenia: podejrzany mail z linkiem, zgubiony telefon służbowy, niedziałający system, komunikat programu antywirusowego, obecność osoby postronnej w serwerowni. Dodajemy jasną zasadę: lepiej zgłosić fałszywy alarm niż przemilczeć realny problem. Pracownik nie musi oceniać, czy zdarzenie jest groźne. To zadanie zespołu, który przyjmuje zgłoszenie.
Kto zgłasza incydent i jakim kanałem?
Obowiązek zgłoszenia ma każdy: pracownik etatowy, osoba na umowie cywilnoprawnej, stażysta, a także dostawca pracujący w systemach organizacji. Procedura powinna mówić o tym wprost, bo w praktyce wiele zdarzeń przepada przez przekonanie, że ktoś już to zgłosił.
Równie ważne są role po stronie przyjmującej. W typowej procedurze wskazujemy:
- osobę przyjmującą zgłoszenia, na przykład koordynatora bezpieczeństwa informacji lub helpdesk,
- zespół IT odpowiedzialny za analizę i pierwsze działania techniczne,
- inspektora ochrony danych, jeśli zdarzenie może dotyczyć danych osobowych,
- osobę kontaktową z CSIRT, jeśli organizacja podlega ustawie o KSC,
- kierownika jednostki lub zarząd, który decyduje w sprawach o dużym znaczeniu.
Kanał zgłoszeń musi być prosty i znany wszystkim. Najlepiej sprawdza się dedykowany adres mailowy, numer telefonu dostępny także poza godzinami pracy oraz formularz w systemie zgłoszeń. Jeśli incydent dotyczy poczty, mail przestaje być wiarygodny, dlatego telefon jest obowiązkowym kanałem zapasowym. Na koniec zasada, od której zależy skuteczność całej procedury: zgłoszenie nie może grozić karą. Pracownik, który kliknął w zły link i od razu to zgłosił, pomógł organizacji. Jeśli będzie się bał konsekwencji, następnym razem przemilczy problem.
Jakie informacje powinno zawierać zgłoszenie?
Pierwsze zgłoszenie ma być szybkie, nie kompletne. Pracownik nie powinien zbierać informacji przez godzinę, zanim da znać działowi IT. Szczegóły uzupełnia później zespół obsługujący incydent. Procedura powinna jednak wskazać minimalny zakres danych, najlepiej w formie krótkiego formularza.
| Pole w zgłoszeniu | Przykład |
|---|---|
| Data i godzina zauważenia zdarzenia | 14 marca, 9:40 |
| Osoba zgłaszająca i kontakt do niej | imię, nazwisko, dział, telefon |
| Opis zdarzenia własnymi słowami | po otwarciu załącznika pliki zmieniły rozszerzenia |
| Systemy, urządzenia lub dokumenty, których dotyczy | laptop służbowy, dysk sieciowy działu kadr |
| Rodzaj informacji, które mogły zostać naruszone | dane osobowe pracowników, umowy |
| Podjęte już działania | odłączenie komputera od sieci |
Zespół IT dopisuje do zgłoszenia moment wykrycia incydentu, czyli chwilę, w której zdarzenie zostało rozpoznane jako incydent. Zgodnie z ustawą o KSC od tego momentu liczą się terminy na wczesne ostrzeżenie i zgłoszenie do CSIRT. W przypadku danych osobowych termin 72 godzin biegnie od stwierdzenia naruszenia.
Dobrą praktyką jest też zabezpieczenie dowodów: zrzut ekranu, treść podejrzanej wiadomości z nagłówkami, numer seryjny zgubionego urządzenia. Pracownik nie powinien jednak usuwać plików ani samodzielnie naprawiać komputera, bo może zatrzeć ślady potrzebne do analizy.
Klasyfikacja incydentu i pierwsze działania zespołu IT
Po przyjęciu zgłoszenia zespół IT ocenia, z jakim zdarzeniem ma do czynienia. Klasyfikacja decyduje o tempie reakcji, liczbie zaangażowanych osób i o tym, czy trzeba powiadomić CSIRT lub Prezesa UODO. Przykładowy podział:
| Poziom | Przykład | Czas reakcji |
|---|---|---|
| Niski | pojedynczy mail phishingowy, nikt nie kliknął | w ciągu dnia roboczego |
| Średni | kliknięcie w link, podanie hasła do jednego konta | do 4 godzin |
| Wysoki | infekcja kilku stanowisk, wyciek danych osobowych | natychmiast |
| Krytyczny | zaszyfrowane serwery, przestój usług dla klientów lub mieszkańców | natychmiast, z udziałem zarządu |
Pierwsze działania techniczne mają ograniczyć szkody i zachować ślady. Zwykle obejmują:
- odizolowanie zainfekowanego urządzenia od sieci bez jego wyłączania,
- zablokowanie lub zmianę haseł do przejętych kont,
- zabezpieczenie logów systemowych i poczty,
- sprawdzenie, czy podobne zdarzenie nie występuje na innych stanowiskach,
- ocenę, czy incydent dotyczy danych osobowych i czy spełnia kryteria incydentu poważnego.
Ostatni punkt ma znaczenie formalne. Od tej oceny zależy, czy organizacja musi zgłosić incydent do CSIRT, do UODO, do obu instytucji, czy wystarczy wpis do wewnętrznego rejestru. Decyzję i jej uzasadnienie trzeba zapisać, bo organ nadzoru może o nie zapytać.
Zgłoszenie incydentu do CSIRT według ustawy o KSC
Obowiązek zgłaszania incydentów poważnych mają podmioty kluczowe i podmioty ważne w rozumieniu znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa. Nowelizacja obowiązuje od 3 kwietnia 2026 roku. Podmioty, które spełniały jej przesłanki w tym dniu, mają czas na wdrożenie obowiązków z rozdziału 3 ustawy do 3 kwietnia 2027 roku. Procedura zgłaszania incydentów powinna być gotowa przed tą datą.
Ustawa przewiduje trzy etapy raportowania:
- Wczesne ostrzeżenie w ciągu 24 godzin od wykrycia incydentu poważnego.
- Zgłoszenie incydentu w ciągu 72 godzin od wykrycia, ze wstępną oceną jego wagi i skutków.
- Raport końcowy w ciągu miesiąca od zgłoszenia, z opisem przyczyny i podjętych działań. Jeśli incydent wciąż trwa, organizacja przekazuje najpierw raport z postępów, a raport końcowy po zakończeniu obsługi incydentu.
Zgłoszenia trafiają do właściwego zespołu CSIRT poziomu krajowego, czyli CSIRT NASK, CSIRT GOV lub CSIRT MON, zależnie od rodzaju podmiotu. Służy do tego system teleinformatyczny prowadzony przez ministra właściwego do spraw informatyzacji, znany jako S46.
Terminy liczymy od chwili, gdy zdarzenie zostało rozpoznane jako incydent. Procedura musi więc jasno wskazywać, kto podejmuje tę decyzję i jak ją dokumentuje. Do czasu wydania nowego rozporządzenia, nie dłużej niż do 3 kwietnia 2027 roku, przy ocenie, czy incydent jest poważny, stosuje się progi z rozporządzenia z 2018 roku.
Zgłoszenie naruszenia danych osobowych do UODO
Jeśli incydent dotyczy danych osobowych, administrator ma 72 godziny od stwierdzenia naruszenia na zgłoszenie go Prezesowi Urzędu Ochrony Danych Osobowych. Wyjątek dotyczy sytuacji, w których naruszenie prawdopodobnie nie powoduje ryzyka dla praw i wolności osób. Taką ocenę trzeba jednak udokumentować.
Zgłoszenie składa się przez formularz elektroniczny udostępniony przez UODO. Powinno zawierać:
- opis charakteru naruszenia, kategorie danych i przybliżoną liczbę osób,
- dane kontaktowe inspektora ochrony danych lub innej osoby kontaktowej,
- możliwe konsekwencje dla osób, których dane dotyczą,
- środki zastosowane lub planowane w celu usunięcia skutków.
Jeśli ryzyko dla osób jest wysokie, administrator musi je także bez zbędnej zwłoki zawiadomić. Dotyczy to na przykład wycieku numerów PESEL, danych o zdrowiu czy danych logowania. Gdy zgłoszenie następuje po 72 godzinach, trzeba wyjaśnić przyczyny opóźnienia. Ten sam incydent może wymagać dwóch zgłoszeń. Atak ransomware na szpital będący podmiotem kluczowym lub ważnym to jednocześnie incydent poważny według KSC i naruszenie ochrony danych pacjentów według RODO.
| CSIRT (ustawa o KSC) | Prezes UODO (RODO) | |
|---|---|---|
| Kogo dotyczy | podmioty kluczowe i ważne | każdego administratora danych |
| Początek biegu terminu | wykrycie incydentu | stwierdzenie naruszenia |
| Termin | 24 h, 72 h, raport końcowy | 72 h |
Rejestr incydentów i raport końcowy
Każdy incydent, także ten niezgłoszony do żadnego urzędu, powinien trafić do wewnętrznego rejestru. RODO wprost wymaga dokumentowania wszystkich naruszeń ochrony danych osobowych, razem z okolicznościami, skutkami i podjętymi działaniami. Rejestr jest też podstawowym dowodem dla audytora i organu nadzoru, że procedura działa.
W rejestrze zapisujemy:
- numer i datę zgłoszenia oraz moment wykrycia,
- opis zdarzenia i jego klasyfikację,
- osoby odpowiedzialne za obsługę,
- podjęte działania z datami,
- decyzję o zgłoszeniu do CSIRT lub UODO z uzasadnieniem,
- przyczynę źródłową i wnioski na przyszłość.
Po zamknięciu incydentu zespół przygotowuje raport końcowy. Dla incydentów poważnych jego elementy określa ustawa o KSC: szczegółowy opis incydentu, jego wagi i skutków, rodzaj zagrożenia lub prawdopodobną przyczynę, zastosowane środki zaradcze oraz informację o skutkach transgranicznych, jeśli wystąpiły. Wewnętrzny raport powinien odpowiedzieć na jeszcze jedno pytanie: jak nie dopuścić do powtórki. Regularny przegląd rejestru pokazuje wzorce. Jeśli w ciągu kwartału pięć zgłoszeń dotyczy phishingu w dziale księgowości, to sygnał, by właśnie tam skierować dodatkowe szkolenie i mocniejsze zabezpieczenia poczty.
Testowanie procedury i szkolenie pracowników
Procedura, której nikt nie przećwiczył, zwykle zawodzi przy pierwszym prawdziwym incydencie. Okazuje się wtedy, że numer telefonu jest nieaktualny, osoba decyzyjna jest na urlopie, a nikt nie wie, gdzie złożyć wczesne ostrzeżenie do CSIRT. Dlatego procedurę testujemy, zanim będzie potrzebna.
Najprostsze formy sprawdzenia to:
- ćwiczenie przy stole, podczas którego zespół krok po kroku omawia scenariusz, na przykład zaszyfrowanie serwera plików w piątek wieczorem,
- symulowana kampania phishingowa, która pokazuje, ilu pracowników zgłosi podejrzaną wiadomość,
- test kanałów kontaktu i listy zastępstw,
- przegląd procedury przynajmniej raz w roku oraz po każdym poważnym incydencie.
Drugim filarem jest szkolenie. Pracownicy muszą umieć rozpoznać incydent i wiedzieć, komu go zgłosić. Ustawa o KSC wymaga dodatkowo, by kierownik podmiotu kluczowego lub ważnego przechodził szkolenie z cyberbezpieczeństwa raz w roku kalendarzowym.
W ICT Future prowadzimy szkolenia Security Awareness dla firm i instytucji oraz szkolenia z Systemu Zarządzania Bezpieczeństwem Informacji i wymagań normy ISO 27001:2022. Przeprowadzamy audyt zgodności z KSC, audyty organizacyjne i RODO, wdrażamy politykę RODO i SZBI. Dzięki temu procedura zgłaszania incydentów staje się częścią spójnego systemu, a nie osobnym dokumentem w segregatorze.
Co warto zapamiętać?
Dobra procedura zgłaszania incydentów bezpieczeństwa mieści się na kilku stronach. Mówi, co jest incydentem, kto go zgłasza, kto decyduje o dalszych krokach i w jakich terminach organizacja informuje CSIRT oraz UODO. Jeśli chcesz przygotować lub sprawdzić taką procedurę w swojej organizacji, skontaktuj się z nami. Pomożemy ją napisać, dopasować do wymagań KSC i RODO oraz przećwiczyć z Twoim zespołem.