Zgłaszanie incydentów NIS2/KSC w 24 i 72 godziny. Procedura i checklista

Zgłaszanie incydentów NIS2/KSC wymaga znacznie więcej niż zapisania dwóch terminów w polityce bezpieczeństwa. Podmiot kluczowy lub podmiot ważny powinien przekazać wczesne ostrzeżenie o incydencie poważnym niezwłocznie, nie później niż w ciągu 24 godzin od jego wykrycia. Następnie, nie później niż w ciągu 72 godzin liczonych od tego samego momentu, przekazuje właściwe zgłoszenie incydentu. Co do zasady w ciągu miesiąca od zgłoszenia składa także sprawozdanie końcowe. Dlatego procedura musi działać przez całą dobę, określać moment rozpoczęcia biegu terminów, zastępstwa, kryteria incydentu poważnego, aktualnego adresata oraz równoległą ocenę obowiązków z RODO i przepisów sektorowych. W artykule przedstawiamy praktyczny model reakcji, matrycę odpowiedzialności i checklistę, którą można wykorzystać podczas ćwiczenia lub rzeczywistego ataku.

Najważniejsze informacje

• Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa weszła w życie 3 kwietnia 2026 roku i wdrożyła zasadniczą część wymagań NIS2 do prawa polskiego.
• Obowiązek raportowania dotyczy incydentów poważnych w podmiotach kluczowych i podmiotach ważnych. Nie każdy alert techniczny ani każdy incydent bezpieczeństwa wymaga zgłoszenia w tym trybie.
• Wczesne ostrzeżenie należy przekazać niezwłocznie, najpóźniej w ciągu 24 godzin od momentu wykrycia incydentu poważnego.
• Pełniejsze zgłoszenie należy przekazać niezwłocznie, najpóźniej w ciągu 72 godzin od tego samego momentu wykrycia. Nie jest to dodatkowe 72 godziny liczone po wczesnym ostrzeżeniu.
• Brak wszystkich informacji nie uzasadnia czekania. Podmiot przekazuje dane znane w chwili zgłoszenia, a następnie uzupełnia je podczas obsługi incydentu.
• Co do zasady sprawozdanie końcowe należy przekazać w ciągu miesiąca od zgłoszenia dokonanego do 72 godzin. Jeżeli obsługa nadal trwa, najpierw przekazuje się sprawozdanie z postępu.
• Zgłoszenia są przekazywane przez System S46. W okresie przejściowym właściwym adresatem może być CSIRT poziomu krajowego, dopóki sektorowy CSIRT nie ogłosi zdolności operacyjnej.
• Terminy są określone w godzinach, a nie w dniach roboczych. Weekend, święto, noc ani nieobecność członka zarządu nie zatrzymują ich biegu.
• Jeden cyberatak może uruchomić niezależne obowiązki z KSC, RODO, DORA, Prawa komunikacji elektronicznej, umów z klientami i zasad zawiadamiania organów ścigania.
• Procedura powinna zawierać wewnętrzne terminy krótsze niż ustawowe, gotowe formularze, aktualną matrycę CSIRT, zastępstwa i dowody wysłania.

Zapraszamy do współpracy

Szczegółowe informacje o ofercie i warunkach współpracy można uzyskać telefonicznie lub wysyłając zapytanie za pomocą formularza kontaktowego.

BPPZ – Biuro Porad Prawnych Zacharski

– Chcesz przygotować procedurę KSC i przećwiczyć pierwsze 72 godziny?

• +48 600 784 526
• kontakt@bppz.pl

Zadzwoń Napisz wiadomość

Od kiedy obowiązuje raportowanie według nowych zasad?

Ustawa z 23 stycznia 2026 roku została opublikowana 2 marca 2026 roku i weszła w życie 3 kwietnia 2026 roku. Jednocześnie ustawodawca przewidział okresy przejściowe. Dlatego data rozpoczęcia stosowania nowych obowiązków może zależeć od statusu konkretnego podmiotu.

Podmioty, które spełniały przesłanki uznania za podmiot kluczowy albo podmiot ważny już 3 kwietnia 2026 roku, mają co do zasady czas do 3 kwietnia 2027 roku na wdrożenie obowiązków z rozdziału 3 KSC. Obejmuje to także zarządzanie incydentami i nowe raportowanie. Natomiast podmioty, które przed wejściem nowelizacji w życie były operatorami usług kluczowych, powinny rozpocząć zgłaszanie według nowych art. 11 do 12b w terminie sześciu miesięcy, czyli najpóźniej od 3 października 2026 roku.

Grupa	Najważniejszy termin przejściowy	Znaczenie
Podmiot spełniający kryteria podmiotu kluczowego lub ważnego 3 kwietnia 2026 roku	3 kwietnia 2027 roku	Co do zasady do tego dnia wdraża obowiązki z rozdziału 3 KSC, w tym procedurę incydentową
Dotychczasowy operator usługi kluczowej	3 października 2026 roku	Najpóźniej w tym terminie przechodzi na nowe raportowanie incydentów poważnych
Podmiot, który spełni przesłanki później	Termin ustalany według przepisów właściwych dla zmiany statusu	Należy przeanalizować moment objęcia ustawą i obowiązki rejestrowe
Podmiot kluczowy podlegający pierwszemu audytowi	Zależnie od statusu, z uwzględnieniem przepisów przejściowych	Audyt nie zastępuje gotowości do raportowania incydentów

Co istotne, okres przejściowy nie powinien być traktowany jako czas na rozpoczęcie prac w ostatnim tygodniu. Organizacja musi wcześniej uzyskać dostęp do S46, wyznaczyć osoby kontaktowe, ustalić adresata, przygotować formularze, podpisać umowy z dostawcami i przeprowadzić ćwiczenie. Jeżeli chcesz najpierw potwierdzić status organizacji i harmonogram, punktem wyjścia może być kwalifikacja oraz wdrożenie NIS2.

Kogo dotyczy obowiązek zgłaszania incydentów?

Podstawowy obowiązek z art. 11 KSC dotyczy podmiotów kluczowych i podmiotów ważnych. Dlatego przed projektowaniem raportowania trzeba ustalić, czy organizacja rzeczywiście mieści się w zakresie ustawy, w jakim sektorze działa i jaki ma status.

Nie należy przyjmować, że każda firma korzystająca z chmury, prowadząca sklep internetowy albo przetwarzająca dużą ilość danych automatycznie podlega KSC. Z drugiej strony mały fragment działalności, na przykład usługa zarządzana ICT świadczona na rzecz klientów, może mieć znaczenie dla kwalifikacji całej organizacji.

W praktyce trzeba sprawdzić:

1. rzeczywisty rodzaj świadczonych usług;
2. sektor lub podsektor wskazany w załączniku nr 1 albo 2 do KSC;
3. wielkość organizacji z uwzględnieniem przedsiębiorstw partnerskich i powiązanych;
4. wyjątki, które obejmują określone podmioty niezależnie od typowych progów;
5. tryb wpisu do wykazu KSC;
6. datę rozpoczęcia stosowania obowiązków;
7. szczególne przepisy sektorowe, w tym dotyczące finansów, komunikacji elektronicznej i usług zaufania.

Szczegółową samoidentyfikację opisuje artykuł Czy moja firma podlega NIS2? Test kwalifikacyjny. Sam wpis do wykazu również nie powinien być jedynym kryterium uruchomienia procedury. Jeżeli podmiot spełnia przesłanki ustawowe, powinien przeanalizować obowiązki materialne niezależnie od stanu obsługi formalności rejestrowych.

Czym jest incydent poważny?

KSC definiuje incydent jako zdarzenie, które ma lub może mieć niekorzystny wpływ na bezpieczeństwo systemów informacyjnych. Natomiast incydent poważny to incydent, który:

• powoduje lub może spowodować poważne obniżenie jakości świadczenia usługi przez podmiot kluczowy lub ważny;
• powoduje lub może spowodować przerwanie ciągłości świadczenia tej usługi;
• powoduje straty finansowe dla podmiotu;
• wpływa na inne osoby przez wywołanie poważnej szkody materialnej lub niematerialnej.

W definicji pojawia się zwrot „może spowodować”. Dlatego nie trzeba czekać, aż usługa zostanie całkowicie zatrzymana, klient poniesie szkodę albo firma obliczy ostateczną stratę. Jeżeli wiarygodnie przewidywany skutek jest poważny, zdarzenie może wymagać raportowania przed pełnym urzeczywistnieniem szkody.

Progi sektorowe mają znaczenie

Ustawa przewiduje uszczegółowienie progów uznania incydentu za poważny według sektorów i rodzajów zdarzeń. Kryteria mogą odnosić się między innymi do liczby użytkowników, czasu zakłócenia, zasięgu geograficznego oraz innych czynników charakterystycznych dla danego sektora.

Ponadto dla dostawców DNS, rejestrów TLD, chmury, centrów danych, CDN, usług zarządzanych, usług zarządzanych w zakresie cyberbezpieczeństwa, internetowych platform handlowych, wyszukiwarek, platform społecznościowych i dostawców usług zaufania zastosowanie ma rozporządzenie wykonawcze Komisji (UE) 2024/2690. Zawiera ono zarówno kryteria horyzontalne, jak i progi właściwe dla określonych rodzajów podmiotów.

W sierpniu 2026 roku krajowe upoważnienie do wydania nowych progów pozostawało według publicznego wykazu RCL niezrealizowane, a przepisy przejściowe zachowały dotychczasowe regulacje wykonawcze maksymalnie przez 12 miesięcy od wejścia nowelizacji w życie. Dlatego procedura nie powinna zawierać jednej, niezmiennej tabeli przepisanej z dawnego rozporządzenia. Powinna natomiast wskazywać właściciela aktualizacji oraz datę ostatniej weryfikacji progów.

Prosty test kwalifikacyjny

Podczas incydentu zespół powinien odpowiedzieć co najmniej na następujące pytania:

• Jaka usługa objęta KSC została lub może zostać zakłócona?
• Ilu użytkowników dotyczy zdarzenie i jak długo trwa wpływ?
• Jaki jest zasięg geograficzny i czy incydent ma wymiar transgraniczny?
• Czy inne podmioty zależą od tej usługi?
• Czy występuje ryzyko dla życia, zdrowia, bezpieczeństwa publicznego albo ciągłości istotnej działalności?
• Jakie straty finansowe już wystąpiły lub są prawdopodobne?
• Czy osoby fizyczne lub prawne mogą ponieść poważną szkodę materialną albo niematerialną?
• Czy spełniono próg z właściwego aktu krajowego lub unijnego?
• Czy informacje są wystarczająco wiarygodne, aby uznać, że incydent poważny został wykryty?

Jeżeli odpowiedzi nie są jeszcze pełne, zespół powinien zapisać założenia, źródła i poziom niepewności. Brak pewności co do każdego szczegółu nie może prowadzić do bezczynności aż do siedemdziesiątej pierwszej godziny.

Od kiedy liczyć 24 i 72 godziny?

KSC wiąże oba terminy z momentem wykrycia incydentu poważnego. To najważniejszy punkt całej procedury. Zegar nie powinien rozpoczynać się dopiero wtedy, gdy zarząd podpisze notatkę, prawnik zatwierdzi formularz albo dostawca przekaże pełny raport techniczny.

Jednocześnie pojedynczy, niewiarygodny alert nie zawsze oznacza wykrycie incydentu poważnego. Dlatego organizacja powinna opisać, kiedy uznaje informacje za wystarczająco wiarygodne. Bezpieczne podejście zakłada zapisanie co najmniej trzech momentów:

Znacznik czasu	Przykład	Znaczenie
Pierwszy sygnał	System EDR generuje alert o nietypowym szyfrowaniu plików	Rozpoczyna analizę, ale nie zawsze przesądza o incydencie poważnym
Potwierdzenie incydentu	SOC potwierdza nieautoryzowane szyfrowanie i niedostępność zasobu	Uzasadnia uruchomienie formalnej obsługi incydentu
Wykrycie incydentu poważnego	Zespół ustala, że zdarzenie zakłóca lub może poważnie zakłócić usługę objętą KSC	Od tego momentu należy liczyć ustawowe 24 i 72 godziny

Granice między tymi etapami mogą być bardzo bliskie. Dlatego każde przesunięcie kwalifikacji trzeba uzasadnić faktami, a nie dostępnością osoby decyzyjnej. Procedura powinna zabraniać sztucznego odkładania momentu wykrycia przez wymaganie formalnej uchwały, pełnego raportu forensycznego albo pewności co do sprawcy.

Co więcej, terminy biegną w godzinach. Jeżeli incydent poważny wykryto w piątek o 18:20, pierwsze ostrzeżenie powinno zostać przekazane najpóźniej w sobotę o 18:20, a zgłoszenie najpóźniej w poniedziałek o 18:20. Wewnętrzne cele powinny być wcześniejsze, ponieważ awaria systemu, problem z uwierzytelnieniem albo nieobecność osoby podpisującej nie przedłużają ustawowego terminu.

Oś czasu zgłaszania incydentu NIS2/KSC

Etap	Termin ustawowy	Najważniejsza treść	Praktyczny cel wewnętrzny
Rejestracja i eskalacja	Niezwłocznie po sygnale	Fakty, źródło alertu, system, usługa, osoby kontaktowe	Do 15 minut od potwierdzenia incydentu
Wstępna kwalifikacja	Bez zbędnej zwłoki	Ocena wpływu, progów i możliwego statusu incydentu poważnego	Do 2 godzin
Wczesne ostrzeżenie	Niezwłocznie, maksymalnie 24 godziny od wykrycia	Podmiot, kontakty, czas, możliwe bezprawne działanie, wymiar transgraniczny	Gotowe do 12 godzin, wysłane najpóźniej do 20 godzin
Zgłoszenie incydentu	Niezwłocznie, maksymalnie 72 godziny od wykrycia	Wpływ, użytkownicy, zasięg, przyczyny, przebieg, skutki, działania	Projekt do 48 godzin, wysłanie najpóźniej do 68 godzin
Sprawozdanie okresowe	Na wniosek CSIRT	Aktualny stan obsługi i wymagane uzupełnienia	Właściciel i termin ustalone natychmiast po wniosku
Sprawozdanie końcowe	Co do zasady do miesiąca od zgłoszenia 72-godzinnego	Szczegółowy opis, szkody, źródło, środki ograniczające i skutki transgraniczne	Projekt po przeglądzie przyczyn źródłowych i działań naprawczych
Sprawozdanie z postępu	Jeżeli obsługa nie zakończyła się w terminie końcowym	Stan prac, ryzyka, działania i plan zakończenia	Przygotowane przed upływem miesiąca
Końcowe po trwającej obsłudze	Do miesiąca od zakończenia obsługi	Ostateczne ustalenia i środki	Termin zapisany w rejestrze incydentu

Wewnętrzne cele z ostatniej kolumny nie wynikają wprost z ustawy. Są buforem organizacyjnym. Firma może przyjąć inne wartości, jeżeli wynikają z jej modelu działania, ale nie powinna ustawiać pierwszego terminu wewnętrznego dokładnie na ustawową granicę.

Co powinno zawierać wczesne ostrzeżenie do 24 godzin?

Wczesne ostrzeżenie ma umożliwić szybkie poinformowanie krajowego systemu cyberbezpieczeństwa. Nie jest pełnym raportem forensycznym. Zgodnie z art. 12 KSC zawiera:

1. dane podmiotu zgłaszającego, w tym firmę, numer właściwego rejestru, siedzibę i adres;
2. imię i nazwisko, służbowy numer telefonu i służbowy adres e-mail osoby dokonującej zgłoszenia;
3. analogiczne dane osoby uprawnionej do składania wyjaśnień;
4. moment wystąpienia i wykrycia incydentu oraz czas jego trwania;
5. informację, czy incydent mógł zostać wywołany działaniem bezprawnym lub działaniem w złej wierze, jeżeli można to ocenić;
6. informację, czy zdarzenie dotyczy innych państw członkowskich Unii Europejskiej.

Ponadto ostrzeżenie może zawierać wniosek o wytyczne dotyczące środków ograniczających skutki albo o dodatkowe wsparcie techniczne. CSIRT powinien wówczas przekazać wytyczne lub udzielić wsparcia w ustawowym terminie. Jeżeli incydent może wyczerpywać znamiona przestępstwa, podmiot może również otrzymać informację o sposobie zgłoszenia go organom ścigania.

Jak pisać, gdy fakty nie są jeszcze znane?

Nie należy zastępować braków przypuszczeniami przedstawianymi jako pewnik. Bezpieczny formularz rozdziela:

• fakty potwierdzone;
• wstępne ustalenia;
• hipotezy wymagające sprawdzenia;
• informacje obecnie niedostępne;
• termin następnej aktualizacji.

Przykładowo zamiast pisać „atakujący wykradł bazę klientów”, gdy potwierdzono jedynie pobranie dużej ilości danych, lepiej wskazać: „potwierdzono nietypowy transfer z serwera; trwa ustalanie zakresu plików i odbiorcy”. Dzięki temu organizacja nie ukrywa ryzyka, ale nie tworzy nieprawdziwego opisu.

Co powinno zawierać zgłoszenie do 72 godzin?

Zgłoszenie składane do 72 godzin rozwija wczesne ostrzeżenie. Powinno zawierać:

• wskazanie usługi, na którą incydent miał wpływ;
• liczbę użytkowników dotkniętych incydentem;
• zasięg geograficzny;
• wpływ na świadczenie usług przez inne podmioty;
• opis przyczyn, przebiegu i prawdopodobnych skutków dla systemów lub usług;
• informacje o działaniach zapobiegawczych;
• informacje o działaniach naprawczych;
• aktualizację danych z wczesnego ostrzeżenia, jeżeli się zmieniły;
• inne informacje istotne dla przebiegu i obsługi, jeżeli organizacja je posiada.

Co istotne, ustawa wprost pozwala przekazać informacje znane w chwili dokonywania zgłoszenia i uzupełniać je później. Dlatego procedura powinna przewidywać wersjonowanie informacji. Każda aktualizacja powinna wskazywać datę, autora, zmienione ustalenia i źródło.

W zgłoszeniu należy oznaczyć informacje stanowiące tajemnice prawnie chronione, w tym tajemnicę przedsiębiorstwa. Nie oznacza to jednak prawa do pominięcia wszystkiego, co firma uznaje za poufne. Informacje przekazuje się w niezbędnym zakresie, a poufny charakter odpowiednio zaznacza.

Sprawozdanie końcowe i raport z postępu

Co do zasady sprawozdanie końcowe trzeba przekazać w ciągu miesiąca od zgłoszenia dokonanego w terminie 72 godzin. Powinno ono obejmować:

1. szczegółowy opis incydentu, zakłóceń i szkód;
2. rodzaj zagrożenia albo prawdopodobną przyczynę źródłową;
3. zastosowane i wdrażane środki ograniczające ryzyko;
4. skutki transgraniczne, jeżeli wystąpiły.

Jeżeli obsługa incydentu nadal trwa, organizacja przekazuje sprawozdanie z postępu zamiast udawać, że sprawa została zamknięta. Następnie składa sprawozdanie końcowe nie później niż w ciągu miesiąca od zakończenia obsługi.

Wewnętrzny raport po incydencie powinien być szerszy niż formularz ustawowy. Warto ująć w nim także:

• oś czasu techniczną i decyzyjną;
• przyczyny źródłowe oraz czynniki organizacyjne;
• skuteczność detekcji i eskalacji;
• zgodność wysłanych informacji z późniejszymi ustaleniami;
• działanie kopii zapasowych i planów ciągłości;
• ocenę dostawców;
• wpływ na dane osobowe;
• komunikację z klientami i pracownikami;
• listę działań naprawczych, właścicieli i terminy;
• decyzję o aktualizacji analizy ryzyka, umów, szkoleń i zabezpieczeń.

Taki raport nie powinien powstawać wyłącznie w IT. Przy incydencie obejmującym dane osobowe, zobowiązania umowne albo ryzyko sporu potrzebna jest współpraca techniczna i prawna. Pomóc może w tym projektowe doradztwo prawne dla procesów technologicznych i compliance.

Do którego CSIRT wysłać zgłoszenie?

Docelowy model zakłada przekazywanie wczesnego ostrzeżenia, zgłoszenia i sprawozdań do właściwego CSIRT sektorowego przez system teleinformatyczny wskazany w art. 46 KSC, czyli System S46.

Jednocześnie nowelizacja przewiduje okres przejściowy na tworzenie sektorowych CSIRT. Do czasu opublikowania komunikatu o osiągnięciu zdolności operacyjnej przez właściwy CSIRT sektorowy podmiot zgłasza incydent do właściwego CSIRT MON, CSIRT NASK albo CSIRT GOV. Od dnia następującego po publikacji komunikatu właściwy staje się CSIRT sektorowy. Szczególną sytuację stanowią zespoły sektorowe powołane przed 2025 rokiem, które z mocy ustawy stały się sektorowymi CSIRT.

Dlatego procedura powinna zawierać aktualizowaną tabelę:

Element	Informacja do uzupełnienia przez organizację
Sektor i podsektor	Zgodnie z kwalifikacją KSC
Właściwy organ	Organ właściwy do spraw cyberbezpieczeństwa dla sektora
Aktualny CSIRT przyjmujący zgłoszenie	Sektorowy albo właściwy krajowy w okresie przejściowym
Podstawa ustalenia adresata	Link i data komunikatu o zdolności operacyjnej
Kanał podstawowy	Konto i uprawnienia w S46
Osoby uprawnione	Co najmniej właściciel i zastępca
Tryb awaryjny	Aktualna instrukcja właściwego CSIRT, telefon alarmowy, dokumentowanie niedostępności
Data ostatniego testu	Data próbnego logowania i weryfikacji dostępów

Nie wystarczy zapisać „zgłoszenie wysyła dział IT”. Procedura musi wskazywać konkretne role, konta, zastępstwa oraz sposób ustalenia aktualnego adresata. Jeżeli zgłoszenie trafi do niewłaściwego sektorowego CSIRT, ustawa przewiduje jego przekazanie do właściwego zespołu. Nie powinno to jednak zastępować prawidłowej matrycy po stronie organizacji.

Co zrobić, gdy S46 nie działa?

Ustawa wskazuje S46 jako kanał obowiązkowych zgłoszeń. Dlatego firma nie powinna z góry zakładać, że zwykły e-mail zawsze będzie równoważny formalnemu zgłoszeniu. Procedura awaryjna powinna natomiast nakazywać:

1. zapisać czas i objawy niedostępności;
2. wykonać zrzuty ekranu lub zachować komunikaty błędu;
3. natychmiast skontaktować się z właściwym CSIRT według jego aktualnej instrukcji;
4. zastosować wskazany kanał zastępczy;
5. ponowić wysłanie przez S46, gdy stanie się dostępny, jeżeli CSIRT tak zaleci;
6. dołączyć do akt dowody prób i uzgodnień.

Najgorszym rozwiązaniem jest czekanie do końca terminu i dopiero wtedy sprawdzanie, czy użytkownik pamięta hasło, ma właściwe uprawnienie oraz dostęp do wymaganego sposobu uwierzytelnienia.

Wyjątki, których nie można pominąć

Podstawowa sekwencja 24 godziny, 72 godziny i miesiąc nie działa identycznie dla każdego podmiotu.

Dostawcy usług zaufania

Dostawca usług zaufania zgłasza incydent poważny niezwłocznie, nie później niż w ciągu 24 godzin od momentu wykrycia. Jest to szczególna reguła. Taki podmiot powinien dodatkowo sprawdzić obowiązki wynikające z przepisów o usługach zaufania, zamiast mechanicznie stosować ogólną tabelę.

Podmiot ważny będący podmiotem publicznym

KSC wyłącza wobec podmiotu ważnego będącego podmiotem publicznym przepisy o wczesnym ostrzeżeniu, sprawozdaniu okresowym, sprawozdaniu z postępu i sprawozdaniu końcowym. Nadal znaczenie ma zgłoszenie incydentu poważnego do 72 godzin oraz pozostałe obowiązki, których wyłączenie nie obejmuje. Podmiot kluczowy będący podmiotem publicznym nie korzysta automatycznie z tego wyjątku.

Podmioty finansowe

W sektorze finansowym trzeba uwzględnić rozporządzenie DORA oraz przepisy krajowe określające właściwe obowiązki i kanały. Nie należy zakładać, że wysłanie raportu według jednego reżimu automatycznie zastępuje każdy inny obowiązek. Najpierw trzeba ustalić, które przepisy są sektorowym odpowiednikiem, jaki organ jest właściwy oraz czy konkretne zdarzenie spełnia progi w obu reżimach.

Przedsiębiorcy komunikacji elektronicznej

Podmioty z tego sektora powinny sprawdzić szczególne przepisy i okresy przejściowe związane z wcześniejszymi obowiązkami telekomunikacyjnymi. Procedura ogólna KSC nie powinna usuwać obowiązków sektorowych bez udokumentowanej analizy.

Jedno zdarzenie, kilka obowiązków zgłoszeniowych

Atak ransomware, przejęcie konta administratora albo wyciek z chmury może jednocześnie:

• być incydentem poważnym w rozumieniu KSC;
• stanowić naruszenie ochrony danych osobowych;
• być poważnym incydentem ICT według DORA;
• uruchamiać obowiązki wobec UKE lub innego organu sektorowego;
• wymagać poinformowania klientów na podstawie umowy;
• wyczerpywać znamiona przestępstwa;
• wpływać na obowiązki informacyjne wobec użytkowników usługi.

Dlatego potrzebna jest jedna karta incydentu z kilkoma ścieżkami prawnymi, a nie kilka niezależnych zespołów, które wzajemnie czekają na swoje decyzje.

Reżim	Co uruchamia ocenę	Podstawowy termin	Adresat
KSC	Wykrycie incydentu poważnego w podmiocie objętym obowiązkiem	24 godziny na ostrzeżenie i 72 godziny na zgłoszenie	Właściwy CSIRT zgodnie z etapem przejściowym
RODO	Stwierdzenie naruszenia ochrony danych powodującego ryzyko dla praw lub wolności	Do 72 godzin od stwierdzenia	Prezes UODO
DORA	Poważny incydent związany z ICT według kryteriów sektorowych	Według etapów i formularzy DORA	Właściwy organ finansowy
Umowa	Zdarzenie objęte klauzulą notyfikacyjną	Często krócej niż termin ustawowy	Klient, partner albo ubezpieczyciel
Prawo karne	Podejrzenie popełnienia przestępstwa	Bez zbędnej zwłoki, zależnie od sytuacji i obowiązków	Policja, prokuratura lub inny właściwy organ

KSC i RODO to nie ten sam test

Nie każdy incydent poważny według KSC narusza dane osobowe. Przykładem może być atak powodujący długą niedostępność systemu, w którym nie przetwarza się danych osób fizycznych. Jednocześnie naruszenie danych osobowych może wymagać zgłoszenia do Prezesa UODO, chociaż nie osiąga progów incydentu poważnego dla usługi objętej KSC.

Ponadto terminy rozpoczynają się według odrębnych przesłanek. KSC odwołuje się do wykrycia incydentu poważnego, natomiast RODO do stwierdzenia naruszenia ochrony danych. Czas może być zbliżony, ale procedura nie powinna automatycznie przyjmować jednego znacznika bez analizy.

Jeżeli zdarzenie obejmuje dane osobowe, warto od razu uruchomić wsparcie przy obsłudze naruszenia ochrony danych. Pozwala to prowadzić ocenę ryzyka RODO równolegle z raportowaniem KSC, bez blokowania pracy zespołu technicznego.

Procedura reagowania krok po kroku

Krok 1. Przyjmij sygnał i nie pozwól go zgubić

Każdy pracownik i dostawca powinien znać prosty kanał zgłoszenia zdarzenia. Formularz wewnętrzny nie może wymagać od osoby zgłaszającej samodzielnego ustalenia, czy incydent jest poważny. Wystarczy opis objawów, czasu, systemu i wykonanych działań.

Kanał powinien działać poza godzinami pracy. Jeżeli skrzynka jest sprawdzana wyłącznie od poniedziałku do piątku, organizacja nie ma realnej procedury na 24 godziny.

Krok 2. Zabezpiecz ludzi, usługę i dowody

Następnie zespół ogranicza skutki, ale nie niszczy materiału potrzebnego do analizy. Trzeba między innymi:

• odizolować zainfekowane zasoby, jeżeli jest to bezpieczne;
• zabezpieczyć logi, obrazy systemów i historię zmian;
• zapisać czas w jednej strefie czasowej;
• ograniczyć dostęp atakującego;
• zachować kopie komunikacji z dostawcą;
• nie uruchamiać bezrefleksyjnie ponownie systemów;
• dokumentować decyzje i ich uzasadnienie.

Pierwszeństwo może mieć bezpieczeństwo ludzi oraz ciągłość krytycznej usługi. Dlatego procedura powinna wskazywać, kto może podjąć pilną decyzję bez oczekiwania na pełny skład zespołu.

Krok 3. Wyznacz kierownika incydentu

Jedna osoba powinna zarządzać osią czasu, zadaniami i przepływem informacji. Nie musi samodzielnie podejmować wszystkich decyzji. Jej zadaniem jest dopilnowanie, aby technika, prawo, komunikacja i biznes pracowały na wspólnej karcie incydentu.

Kierownik incydentu powinien od razu ustalić:

• numer sprawy;
• moment pierwszego sygnału;
• moment potwierdzenia incydentu;
• wstępny moment wykrycia incydentu poważnego;
• osoby pełniące role i zastępstwa;
• najbliższe terminy wewnętrzne;
• częstotliwość aktualizacji sytuacyjnych.

Krok 4. Oceń wpływ na usługę i progi

Zespół techniczny opisuje systemy i wektory ataku, natomiast właściciel biznesowy określa wpływ na usługę, użytkowników i zależności. Sam SOC może nie wiedzieć, że pozornie niewielki serwer obsługuje proces, od którego zależy kilku kluczowych klientów.

Kwalifikacja powinna być aktualizowana. Incydent początkowo lokalny może stać się poważny po wykryciu ruchu bocznego, utraty kopii zapasowej albo zależności między usługami.

Krok 5. Uruchom równoległe ścieżki prawne

W pierwszych godzinach należy sprawdzić KSC, RODO, DORA lub inne przepisy sektorowe, umowy, polisę cyber oraz możliwość przestępstwa. Każda ścieżka otrzymuje właściciela, termin i status.

Nie należy czekać, aż informatycy „zamkną incydent”. Prawnik i IOD mogą pracować na danych wstępnych, a pytania prawne pomagają zespołowi technicznemu ustalić, jakie dowody są potrzebne.

Krok 6. Przygotuj i wyślij wczesne ostrzeżenie

Wypełnij formularz na podstawie potwierdzonych informacji, oznacz niepewności i wskaż osoby dostępne do kontaktu. Jeżeli potrzebne jest wsparcie CSIRT, zawrzyj odpowiedni wniosek. Zachowaj kopię zgłoszenia, potwierdzenie, czas wysłania i identyfikator sprawy.

Zatwierdzenie powinno odbywać się zgodnie z gotową matrycą. Jeżeli każdy raport wymaga zebrania całego zarządu, procedura nie jest odporna na incydent nocny.

Krok 7. Kontynuuj analizę i ograniczanie skutków

Po wysłaniu ostrzeżenia praca nie zwalnia. Do zgłoszenia 72-godzinnego trzeba ustalić wpływ na użytkowników, zasięg, usługi zależne, prawdopodobne przyczyny i działania naprawcze.

W tym czasie należy także kontrolować komunikację. Pracownicy powinni wiedzieć, kto wypowiada się na zewnątrz. Zbyt wczesne publiczne przypisanie ataku konkretnej grupie może być błędne, natomiast całkowite milczenie wobec użytkowników może naruszać obowiązek ich poinformowania.

Krok 8. Wyślij zgłoszenie do 72 godzin

Zgłoszenie powinno zawierać aktualny obraz sytuacji, także wtedy, gdy analiza nadal trwa. Wersja wysłana musi zostać zarchiwizowana. Jeżeli późniejsze ustalenia zmienią ocenę, organizacja aktualizuje informacje w toku obsługi.

Krok 9. Informuj użytkowników i współpracuj z CSIRT

Podmiot kluczowy lub ważny informuje użytkowników o incydencie poważnym, jeżeli ma on niekorzystny wpływ na świadczenie usług. Ponadto przy poważnym cyberzagrożeniu powinien przekazać możliwe środki zapobiegawcze, a w określonych warunkach także informacje o samym zagrożeniu.

Komunikat powinien być użyteczny. Zamiast ogólnego „dbamy o bezpieczeństwo” powinien wyjaśniać, której usługi dotyczy problem, co użytkownik powinien zrobić, gdzie znajdzie aktualizacje i jak rozpoznać próby wykorzystania incydentu do phishingu.

Krok 10. Zamknij obsługę i wdróż wnioski

Po przywróceniu usługi trzeba potwierdzić usunięcie przyczyny, monitorować nawroty, przygotować raport końcowy i przypisać działania naprawcze. Zamknięcie biletu technicznego nie oznacza automatycznie zakończenia obsługi prawnej, komunikacyjnej i biznesowej.

Warto przeprowadzić spotkanie lessons learned bez szukania kozła ofiarnego. Celem jest ustalenie, dlaczego zabezpieczenia, detekcja albo decyzje zadziałały lub zawiodły oraz jak skrócić czas reakcji przy kolejnym zdarzeniu.

Matryca odpowiedzialności

Rola	Najważniejsze zadania	Zastępstwo, które trzeba wyznaczyć
Kierownik podmiotu lub zarząd	Nadzór, decyzje o ryzyku, zapewnienie zasobów, akceptacja komunikacji o wysokim wpływie	Wskazany członek kierownictwa dostępny poza godzinami pracy
Kierownik incydentu	Oś czasu, status, zadania, terminy, koordynacja zespołów	Drugi przeszkolony incident manager
SOC lub IT security	Detekcja, analiza, ograniczenie skutków, logi i dowody	Dyżur techniczny lub zewnętrzny SOC
Właściciel usługi	Ocena wpływu biznesowego, użytkowników i zależności	Zastępca znający proces i klientów
Dział prawny lub compliance	KSC, przepisy sektorowe, umowy, tajemnice, organy ścigania	Zewnętrzny doradca albo druga upoważniona osoba
IOD lub zespół prywatności	Ocena naruszenia danych, ryzyka i obowiązków RODO	Ustalony kontakt awaryjny
Komunikacja	Pracownicy, użytkownicy, media, spójność komunikatów	Osoba zatwierdzona do komunikacji kryzysowej
Zakupy i zarządzanie dostawcami	Eskalacja do dostawcy, egzekwowanie SLA, zebranie raportów	Właściciel umowy lub usługi
Sekretariat zespołu	Kopie zgłoszeń, potwierdzenia, wersje, kalendarz terminów	Druga upoważniona osoba

W małej organizacji jedna osoba może łączyć kilka ról. Nie może to jednak prowadzić do braku zastępstwa albo sytuacji, w której osoba odpowiedzialna za uszkodzony system sama i bez kontroli ocenia prawidłowość własnych działań.

Incydent u dostawcy nie zatrzymuje zegara

Chmura, hosting, operator SOC, dostawca systemu ERP albo firma utrzymująca kopie zapasowe mogą jako pierwsi wykryć incydent. Podmiot objęty KSC nie powinien jednak zakładać, że dostawca wykona za niego wszystkie obowiązki.

Umowa powinna określać:

• obowiązek niezwłocznego powiadomienia o zdarzeniu;
• maksymalny czas pierwszej informacji, krótszy niż terminy zewnętrzne klienta;
• całodobowy kanał i osoby kontaktowe;
• minimalny zakres pierwszego alertu;
• częstotliwość aktualizacji;
• dostęp do logów i materiału dowodowego;
• wsparcie przy zgłoszeniach do CSIRT i UODO;
• zakaz publikowania komunikatów dotyczących klienta bez uzgodnienia, o ile prawo nie wymaga inaczej;
• obowiązek zachowania dowodów;
• raport przyczyn źródłowych i plan działań naprawczych;
• zasady udziału podwykonawców;
• możliwość ćwiczenia procedury.

Jeżeli dostawca informuje klienta dopiero po 24 godzinach od własnego wykrycia, klient może nie mieć już czasu na ocenę i wczesne ostrzeżenie. Dlatego kontraktowy termin powinien tworzyć realny bufor. Jednocześnie dostawca będący samodzielnie podmiotem kluczowym lub ważnym może mieć własny obowiązek raportowania. Obie strony powinny ustalić, kto przekazuje jakie informacje, bez błędnego założenia, że jedno zgłoszenie obejmuje całą relację.

Przegląd procedury warto połączyć z audytem ochrony danych i przepływów informacji, jeżeli dostawcy mają dostęp do danych osobowych lub raport incydentowy wymaga równoległej oceny RODO.

Jak dokumentować decyzję o braku zgłoszenia?

Nie każdy incydent musi zostać zgłoszony jako poważny. Jednak brak zgłoszenia również powinien być wynikiem udokumentowanej analizy.

Notatka może zawierać:

1. opis zdarzenia i usługi;
2. moment pierwszego sygnału, potwierdzenia oraz zakończenia analizy;
3. zastosowaną definicję i progi;
4. liczbę użytkowników, czas, zasięg i zależności;
5. ocenę strat oraz szkód dla innych osób;
6. ocenę możliwego rozwoju zdarzenia;
7. źródła danych i niepewności;
8. decyzję wraz z uzasadnieniem;
9. osoby uczestniczące w ocenie;
10. warunki ponownego otwarcia kwalifikacji.

Co istotne, KSC pozwala dobrowolnie przekazywać informacje o innych incydentach, cyberzagrożeniach, podatnościach i potencjalnych zdarzeniach. Dlatego brak obowiązkowego zgłoszenia nie zawsze oznacza, że organizacja nie powinna kontaktować się z CSIRT.

Sankcje i odpowiedzialność kierownictwa

Niewykonanie obowiązków z art. 11, w tym obowiązków dotyczących zgłaszania, może prowadzić do kary pieniężnej dla podmiotu. Ustawa przewiduje dla podmiotu kluczowego maksymalnie 10 mln euro albo 2 procent przychodów, z zastosowaniem kwoty wyższej, oraz minimalną karę 20 tys. zł. Dla podmiotu ważnego maksymalny poziom wynosi 7 mln euro albo 1,4 procent przychodów, a minimalna kara 15 tys. zł.

W przypadkach naruszeń powodujących szczególnie poważne zagrożenia ustawa pozwala na karę do 100 mln zł. Ponadto kierownik podmiotu może odpowiadać za niewykonanie obowiązków, w tym art. 11. Kara dla kierownika może wynieść do 300 procent wynagrodzenia, a w typowym podmiocie publicznym do 100 procent.

Przepisy przejściowe stanowią, że nowe kary mogą zostać po raz pierwszy nałożone po upływie dwóch lat od wejścia nowelizacji w życie, czyli po 3 kwietnia 2028 roku. Nie oznacza to jednak, że do tej daty raportowanie jest dobrowolne. Obowiązki materialne zaczynają działać według właściwych terminów przejściowych, a sposób reakcji może mieć znaczenie dla kontroli, odpowiedzialności umownej, ubezpieczenia i oceny należytej staranności kierownictwa.

Najczęstsze błędy

Liczenie 72 godzin od ostrzeżenia

Firma wysyła wczesne ostrzeżenie w dwudziestej trzeciej godzinie, a następnie zakłada, że ma kolejne 72 godziny. Tymczasem oba terminy biegną od momentu wykrycia incydentu poważnego.

Czekanie na pełny raport techniczny

Zespół odkłada zgłoszenie do czasu ustalenia sprawcy, kompletnej listy plików i ostatecznej straty. Ustawa pozwala przekazać dane znane i uzupełniać je później.

Brak definicji momentu wykrycia

IT, prawnik i zarząd wskazują trzy różne momenty rozpoczęcia zegara. W dokumentacji brakuje faktów uzasadniających przyjętą datę.

Terminy tylko w dni robocze

Procedura przewiduje eskalację w poniedziałek, jeżeli incydent wystąpił w weekend. Tymczasem ustawowe godziny biegną nieprzerwanie.

Nieaktualny adresat

Dokument wskazuje dawny krajowy CSIRT albo sektorowy zespół bez sprawdzenia komunikatu o zdolności operacyjnej. Z tego względu matryca adresatów powinna mieć właściciela i datę przeglądu.

Jedna osoba z dostępem do S46

Jedyny użytkownik jest na urlopie, nie ma działającego sposobu uwierzytelnienia albo zmienił stanowisko. Organizacja nie testowała zastępstwa.

Mylenie KSC z RODO

Firma zgłasza incydent do CSIRT i uznaje, że nie musi już oceniać naruszenia danych. Inna organizacja robi odwrotnie i wysyła formularz do UODO, ale pomija KSC.

Brak obowiązków dostawcy

Umowa zawiera ogólne zdanie o współpracy przy incydentach, ale nie określa czasu, danych, logów i osoby dostępnej w nocy.

Zbyt szerokie raportowanie tajemnic

Zespół kopiuje do formularza całe raporty techniczne i dane klientów, chociaż część informacji nie jest potrzebna. Informacje chronione należy przekazać w niezbędnym zakresie i odpowiednio oznaczyć.

Brak dowodu wysłania

Organizacja posiada wersję roboczą zgłoszenia, ale nie przechowuje identyfikatora, potwierdzenia, czasu wysłania i nazwiska osoby dokonującej czynności.

Zamknięcie sprawy po przywróceniu systemu

Usługa działa, więc bilet zostaje zamknięty. Nikt nie składa raportu końcowego, nie analizuje przyczyny źródłowej i nie sprawdza wykonania działań naprawczych.

Checklista gotowości przed incydentem

Zakres i odpowiedzialność

• Potwierdziliśmy, czy organizacja jest podmiotem kluczowym albo ważnym.
• Ustaliliśmy datę rozpoczęcia stosowania obowiązków incydentowych.
• Wskazaliśmy usługi i systemy objęte KSC.
• Przypisaliśmy właścicieli usług i zastępców.
• Wyznaczyliśmy kierownika incydentu i całodobowe zastępstwo.
• Zarząd zatwierdził progi decyzyjne i matrycę uprawnień.

Klasyfikacja

• Procedura zawiera aktualną definicję incydentu poważnego.
• Mamy aktualne progi krajowe lub unijne właściwe dla sektora.
• Każdy próg ma właściciela i datę ostatniej weryfikacji.
• Rejestrujemy pierwszy alert, potwierdzenie i moment wykrycia incydentu poważnego.
• Potrafimy ocenić użytkowników, czas, zasięg, zależności i straty.
• Dokumentujemy także decyzję o braku obowiązkowego zgłoszenia.

Kanały i formularze

• Organizacja ma dostęp do S46 i aktualne konta użytkowników.
• Co najmniej dwie osoby potrafią wykonać zgłoszenie.
• Sprawdziliśmy, który CSIRT jest aktualnie właściwy.
• Zachowujemy link i datę komunikatu o zdolności operacyjnej CSIRT sektorowego.
• Mamy formularz ostrzeżenia 24-godzinnego.
• Mamy formularz zgłoszenia 72-godzinnego.
• Mamy wzór sprawozdania z postępu i raportu końcowego.
• Procedura opisuje postępowanie przy niedostępności S46.
• Testowaliśmy logowanie i zachowanie potwierdzenia wysłania.

Współpraca wewnętrzna

• IT, właściciel usługi, prawnik, IOD i komunikacja znają swoje role.
• Terminy wewnętrzne są krótsze niż ustawowe.
• Zatwierdzenie nie wymaga dostępności całego zarządu.
• Mamy jedną kartę incydentu i wspólną oś czasu.
• Równolegle oceniamy KSC, RODO, regulacje sektorowe, umowy i polisę.
• Wiemy, kto kontaktuje się z klientami, użytkownikami i mediami.

Dostawcy i dowody

• Umowy zobowiązują krytycznych dostawców do szybkiego alertu.
• Dostawcy przekazują logi, aktualizacje i raport przyczyn źródłowych.
• Znamy podwykonawców mających znaczenie dla usługi.
• Mamy zasady zabezpieczania dowodów i jednolitą strefę czasową.
• Dostęp do akt incydentu jest ograniczony i rejestrowany.
• Tajemnice prawnie chronione są oznaczane przed przekazaniem.

Testy i doskonalenie

• Przeprowadziliśmy ćwiczenie scenariuszowe poza godzinami pracy.
• Ćwiczenie obejmowało wysłanie próbnego formularza lub bezpieczną symulację.
• Sprawdziliśmy scenariusz incydentu u dostawcy.
• Po ćwiczeniu przypisaliśmy działania naprawcze i terminy.
• Szkolimy pracowników zgłaszających alerty oraz osoby podejmujące decyzje.
• Procedura jest przeglądana po zmianie prawa, sektora, usługi, CSIRT lub systemu.

Pracownicy potrzebują krótkiej instrukcji zgłaszania, natomiast zespół incydentowy i kierownictwo potrzebują ćwiczeń opartych na rolach. W przygotowaniu takich działań pomocne może być szkolenie RODO i bezpieczeństwa dostosowane do procesów organizacji, uzupełnione o scenariusze KSC i pracę na osi czasu.

Praktyczny scenariusz: ransomware w piątek wieczorem

W piątek o 18:05 EDR zgłasza masowe szyfrowanie plików na serwerze aplikacyjnym. O 18:20 SOC potwierdza, że część użytkowników utraciła dostęp do systemu obsługującego usługę objętą KSC. O 19:10 właściciel usługi ustala, że awaria może objąć klientów w trzech województwach, a kopia zapasowa wymaga dodatkowej weryfikacji. Zespół przyjmuje 19:10 jako moment wykrycia incydentu poważnego i zapisuje podstawę tej decyzji.

Do 20:00 kierownik incydentu aktywuje zespół, zabezpiecza oś czasu i wyznacza właścicieli ścieżek KSC oraz RODO. Jednocześnie dostawca hostingu otrzymuje formalną eskalację i polecenie zabezpieczenia logów.

W sobotę o 7:00 gotowy jest projekt wczesnego ostrzeżenia. Nie wskazuje jeszcze sprawcy, ponieważ atrybucja nie została potwierdzona. Zawiera natomiast moment wystąpienia i wykrycia, opis możliwego bezprawnego działania oraz informację, że obecnie nie ustalono wymiaru transgranicznego. O 9:15 ostrzeżenie zostaje wysłane i zapisane wraz z potwierdzeniem. Ustawowa granica przypadałaby w sobotę o 19:10.

W niedzielę zespół potwierdza zakres niedostępności, liczbę użytkowników, prawdopodobny wektor wejścia i skuteczność odtworzenia. Ponadto analiza wykazuje możliwość dostępu do danych osobowych. IOD prowadzi osobny test ryzyka i przygotowuje ewentualne zgłoszenie do Prezesa UODO.

W poniedziałek o 12:30 organizacja wysyła zgłoszenie KSC, opisując wpływ, zasięg, prawdopodobne przyczyny i działania. Ustawowa granica przypadałaby o 19:10. Następnie aktualizuje informacje, współpracuje z CSIRT, komunikuje użytkownikom środki ostrożności i przygotowuje sprawozdanie końcowe.

Ten scenariusz pokazuje trzy ważne zasady. Weekend nie zatrzymuje biegu terminów, dlatego należy uwzględnić również soboty, niedziele i święta. Termin 72 godzin liczy się od tego samego momentu co termin 24 godzin, a nie od wysłania wczesnego ostrzeżenia. Niezależnie od tego zgłoszenie incydentu na podstawie KSC nie zastępuje odrębnej oceny naruszenia zgodnie z RODO.

Podsumowanie

Zgłaszanie incydentów NIS2/KSC w 24 i 72 godziny jest testem gotowości organizacji, a nie tylko obowiązkiem formularzowym. Wczesne ostrzeżenie i zgłoszenie biegną od tego samego momentu wykrycia incydentu poważnego. Dlatego firma musi rozumieć, kiedy zdarzenie osiąga ustawowy próg i kto może podjąć decyzję poza standardowymi godzinami pracy.

Ponadto adresat zgłoszenia może zależeć od okresu przejściowego i zdolności operacyjnej CSIRT sektorowego. Procedura powinna więc zawierać aktualizowaną matrycę adresatów, działające dostępy do S46 oraz instrukcję awaryjną. Samo wskazanie „właściwego CSIRT” nie wystarczy podczas ataku.

Jednocześnie brak pełnych danych nie uzasadnia zwłoki. Ustawa pozwala przekazać informacje znane i uzupełniać je w toku obsługi. Bezpieczna organizacja rozdziela fakty, hipotezy i braki, zachowuje wersje zgłoszeń oraz dokumentuje decyzje.

Wreszcie jeden incydent może uruchomić KSC, RODO, DORA, obowiązki umowne i komunikację z użytkownikami. Najlepszym rozwiązaniem jest wspólna karta incydentu, równoległe ścieżki oceny oraz jedno centrum koordynacji. Dzięki temu prawnicy nie czekają na zamknięcie analizy technicznej, a IT nie próbuje samodzielnie rozstrzygać wszystkich obowiązków regulacyjnych.

FAQ

Źródła

1. ELI – Ustawa z dnia 23 stycznia 2026 r. Dz.U. 2026 poz. 252.
2. Ministerstwo Cyfryzacji – Nowelizacja ustawy o KSC.
3. Rządowe Centrum Legislacji – Publiczny wykaz upoważnień ustawowych, art. 11 ust. 4 KSC.
4. EUR-Lex – Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555.
5. EUR-Lex – Rozporządzenie wykonawcze Komisji (UE) 2024/2690.
6. EUR-Lex – Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679.