Czym różni się incydent od naruszenia ochrony danych?

Dlaczego to pytanie w ogóle powstaje

Pierwsze źródło wątpliwości jest językowe. W większości organizacji słowo „incydent” oznacza wszystko, co poszło nie tak w systemach — od nieudanego logowania po zatrzymanie produkcji. Tak nazywa się kolejka w systemie zgłoszeń, tak nazywa się procedura i tak mówi się na spotkaniu. Ustawa nadaje temu słowu znaczenie węższe i przypisuje mu konkretne obowiązki, więc od momentu, w którym organizacja podlega przepisom o krajowym systemie cyberbezpieczeństwa, ta sama nazwa opisuje dwie różne rzeczy.

Drugie źródło jest pojęciowe. Obie definicje mówią o bezpieczeństwie, więc brzmią jak dwa określenia tego samego stanu rzeczy. Punkt ciężkości mają jednak inny. Incydent opisuje wpływ zdarzenia na system informacyjny, naruszenie opisuje wpływ zdarzenia na dane osobowe. To rozróżnienie decyduje o tym, czy w danej sprawie w ogóle powstaje obowiązek wobec organu ochrony danych.

Trzecie źródło jest organizacyjne i najbardziej praktyczne. Kwalifikacja zapada zwykle na jednym spotkaniu i prowadzi ją jedna rola — najczęściej ktoś z zespołu bezpieczeństwa albo z działu IT. Jeżeli ta osoba zamknie sprawę jednym rozstrzygnięciem, druga ścieżka nie zostaje odrzucona świadomie, tylko po prostu nikt jej nie otwiera. Widać to później po dokumentacji. Jest opis techniczny zdarzenia i nie ma śladu oceny czy zdarzenie dotknęło danych osobowych.

Co trzeba ustalić przed decyzją

Co każde z tych pojęć obejmuje

Ustawa o krajowym systemie cyberbezpieczeństwa (KSC) definiuje incydent jako zdarzenie, które ma lub może mieć niekorzystny wpływ na bezpieczeństwo systemów informacyjnych. Samo bezpieczeństwo systemów informacyjnych ustawa opisuje jako odporność tych systemów na zdarzenia naruszające poufność, integralność, dostępność i autentyczność przetwarzanych danych lub związanych z nimi usług. Systemem informacyjnym jest przy tym system teleinformatyczny albo grupa urządzeń i oprogramowania przeznaczonych do przetwarzania danych — wraz z danymi przetwarzanymi w postaci elektronicznej. Punktem odniesienia są zatem system i usługa, którą ten system obsługuje.

RODO definiuje naruszenie ochrony danych osobowych jako naruszenie bezpieczeństwa prowadzące do przypadkowego lub niezgodnego z prawem zniszczenia, utracenia, zmodyfikowania, nieuprawnionego ujawnienia lub nieuprawnionego dostępu do danych osobowych. Punktem odniesienia są tu dane, a nie system, w którym się znajdują. Nośnik nie ma znaczenia — definicja obejmuje dane przesyłane, przechowywane i przetwarzane w dowolny inny sposób.

W poradniku o naruszeniach Prezes UODO rozkłada tę definicję na trzy warunki, które muszą wystąpić łącznie: zdarzenie jest incydentem bezpieczeństwa, dotyczy przetwarzanych danych osobowych i może doprowadzić do jednego z wymienionych następstw. Trzeci warunek bywa czytany zbyt wąsko. Wystarczy, że skutek jest możliwy — zgubiony nośnik z danymi jest naruszeniem także wtedy, gdy nikt do tych danych nie sięgnął.

Potrzebne jest tu jedno zastrzeżenie terminologiczne, bo bez niego oba dokumenty wyglądają na sprzeczne. „Incydent bezpieczeństwa”, o którym mówi poradnik, to pojęcie ogólne i obejmuje również zdarzenia poza systemami teleinformatycznymi. „Incydent” w rozumieniu ustawy o KSC jest pojęciem węższym i odnosi się wyłącznie do bezpieczeństwa systemów informacyjnych. Każde naruszenie ochrony danych jest więc incydentem bezpieczeństwa w tym pierwszym, ogólnym sensie, ale nie każde jest incydentem w rozumieniu ustawy.

Z tego wynikają dwa typowe rozjazdy. Odparta próba ataku, zablokowane połączenie do systemu produkcyjnego albo awaria środowiska, w którym nie ma danych osobowych, mieszczą się w definicji incydentu, a naruszeniem nie są. W drugą stronę: zagubiona teczka z dokumentacją pracowniczą, pożar archiwum albo przesyłka doręczona pod niewłaściwy adres są naruszeniem ochrony danych, choć nie dotykają żadnego systemu informacyjnego.

Część wspólna jest przy tym większa, niż się zwykle zakłada. Skoro bezpieczeństwo systemów informacyjnych obejmuje poufność przetwarzanych danych, to zdarzenie naruszające poufność danych osobowych w systemie spełnia zwykle obie definicje naraz. Rozdzielanie kwalifikacji nie służy więc temu, żeby wybrać jedną z nich, tylko temu, żeby nie przeoczyć drugiej.

Kogo dotyczy każdy z tych obowiązków

To pytanie rozstrzyga się przed oceną zdarzenia, nie po niej. Obowiązki dotyczące obsługi i zgłaszania incydentów wiążą wyłącznie podmioty kluczowe i podmioty ważne, czyli organizacje spełniające przesłanki kwalifikacji z ustawy o KSC. Obowiązki dotyczące naruszeń wiążą każdego administratora danych i każdy podmiot przetwarzający, niezależnie od wielkości, sektora i wpisu do jakiegokolwiek wykazu.

W praktyce oznacza to układ niesymetryczny. Większość organizacji ma obowiązki naruszeniowe zawsze, a obowiązki incydentowe dopiero po zakwalifikowaniu. Organizacje, które nie mają rozstrzygniętego statusu na piśmie, zwykle zaczynają od ustalenia zakresu obowiązków w NIS2 i KSC, zanim zaczną łączyć obie ścieżki w jedną procedurę.

Do tego dochodzą przepisy przejściowe, bez których obraz jest nieprawdziwy. Nowelizacja ustawy o KSC weszła w życie 3 kwietnia 2026 r. Podmioty, które spełniły przesłanki uznania za podmiot kluczowy albo ważny z tym dniem, realizują obowiązki z rozdziału 3 ustawy — w tym obsługę i zgłaszanie incydentów — w terminie 12 miesięcy, czyli do 3 kwietnia 2027 r. Podmioty, które wcześniej były operatorami usług kluczowych, zgłaszają incydenty poważne według nowych przepisów w terminie 6 miesięcy od wejścia nowelizacji w życie — dla nich reguły zmieniają się z początkiem października 2026 r. Obowiązki wynikające z RODO żadnego okresu dostosowawczego nie mają i biegną niezależnie od tego harmonogramu.

Od którego momentu liczy się czas

Każdy z reżimów wyznacza własny punkt startowy i to jest najczęstsze źródło błędu w dokumentacji. Terminy wobec właściwego CSIRT biegną od wykrycia incydentu poważnego. Termin wobec Prezesa UODO biegnie od stwierdzenia naruszenia, czyli od chwili, w której administrator uzyskał wystarczającą pewność, że doszło do zdarzenia dotyczącego danych osobowych.

Te momenty rzadko wypadają w tej samej godzinie. Wykrycie jest ustaleniem technicznym i zapada wcześnie. Stwierdzenie wymaga wiedzy o tym, jakich danych zdarzenie dotyczyło, więc zapada po analizie. Jedna wspólna data w rejestrze oznacza, że jeden z terminów policzono błędnie. Kolejność czynności w pierwszej dobie i sposób jej dokumentowania opisuję w osobnym materiale o reakcji na incydent.

Jaki próg uruchamia zgłoszenie

Progi także są zbudowane inaczej i nie da się ich stosować zamiennie. Zgłoszeniu podlega incydent poważny, a progi uznania incydentu za poważny określa Rada Ministrów w rozporządzeniu, odrębnie dla sektorów i podsektorów. Z tej delegacji wyłączone są podmioty, dla których progi ustaliła Komisja Europejska w rozporządzeniu wykonawczym. Kryteria mają charakter ilościowy: liczba użytkowników dotkniętych zakłóceniem, czas oddziaływania incydentu na usługę, zasięg geograficzny oraz inne czynniki właściwe dla sektora.

Jest tu luka, o której warto wiedzieć. Do czasu wydania nowych przepisów wykonawczych obowiązują dotychczasowe, jednak nie dłużej niż przez 12 miesięcy od wejścia nowelizacji w życie. Aktem obowiązującym jest rozporządzenie Rady Ministrów z 31 października 2018 r., wydane jeszcze pod rządami pierwotnej ustawy. Zawiera progi dla sześciu sektorów dawnych operatorów usług kluczowych — od energii i transportu po infrastrukturę cyfrową — i posługuje się pojęciem usługi kluczowej, którego nowelizacja już nie używa. Dla podmiotów z sektorów dodanych nowelizacją progu wyrażonego w przepisach wykonawczych dziś więc nie ma. To ocena stanu, a nie brzmienie przepisu; lukę ma zamknąć nowe rozporządzenie.

Po stronie RODO żadnej tabeli progów nie ma. Zgłoszenie jest regułą, od której administrator może odstąpić wyłącznie wtedy, gdy z jego oceny wynika, że naruszenie najprawdopodobniej nie będzie skutkowało ryzykiem naruszenia praw lub wolności osób. Ocena jest jakościowa i dotyczy skutków dla ludzi, a nie skali zakłócenia usługi. Sam mechanizm tej oceny opisuję w materiale o progu zgłoszenia naruszenia.

Praktyczna konsekwencja jest taka, że zdarzenie poniżej progu incydentu poważnego bywa naruszeniem wymagającym zgłoszenia, a incydent poważny bywa zdarzeniem, które danych osobowych w ogóle nie dotknęło. Wynik jednej oceny nie przesądza wyniku drugiej.

Co zawiera każde ze zgłoszeń

Najłatwiej zobaczyć różnicę, porównując wymaganą treść. Zgłoszenie incydentu poważnego opisuje wpływ zdarzenia na świadczenie usługi: którą usługę objęło, ilu użytkowników dotknęło, jaki był zasięg geograficzny i czy wpłynęło na świadczenie usług przez inne podmioty. Dochodzą do tego przyczyny, przebieg i podjęte działania zapobiegawcze oraz naprawcze.

Zgłoszenie naruszenia do Prezesa UODO opisuje co innego. Charakter naruszenia wraz z kategoriami i przybliżoną liczbą osób oraz wpisów danych, dane kontaktowe inspektora ochrony danych, możliwe konsekwencje naruszenia i zastosowane środki zaradcze. Pierwsze zgłoszenie mówi o usłudze, drugie o osobach. Wspólna jest właściwie tylko chronologia zdarzenia, dlatego treści jednego nie da się przepisać do drugiego bez pominięcia większości wymaganych informacji.

Jak wygląda różnica w skrócie

Wymiar	Incydent — ustawa o KSC	Naruszenie — RODO
Przedmiot ochrony	Bezpieczeństwo systemów informacyjnych i ciągłość usługi	Dane osobowe oraz prawa i wolności osób
Warunek zaistnienia	Wpływ na bezpieczeństwo systemu — realny albo możliwy	Zdarzenie dotyczy danych osobowych i może doprowadzić do ich zniszczenia, utraty, zmiany, ujawnienia albo nieuprawnionego dostępu
Znaczenie nośnika	Wyłącznie system informacyjny	Dowolny nośnik, także papierowy
Kogo dotyczy	Podmioty kluczowe i podmioty ważne	Administratorzy i podmioty przetwarzające
Początek biegu terminu	Wykrycie incydentu	Stwierdzenie naruszenia
Próg zgłoszenia	Progi ilościowe z rozporządzenia Rady Ministrów	Ocena ryzyka dla praw i wolności osób
Adresat zgłoszenia	Właściwy CSIRT	Prezes UODO, a przy wysokim ryzyku również osoby
Kto prowadzi kwalifikację	Zespół bezpieczeństwa, na odpowiedzialność kierownika podmiotu	Administrator, w praktyce przy udziale IOD
Gdzie zostaje ślad	Rejestrowane incydenty udostępniane właściwemu CSIRT	Dokumentacja naruszeń obejmująca również niezgłoszone

Tabela porządkuje pojęcia, ale nie zastępuje oceny konkretnego zdarzenia. Rozstrzyga to, co zdarzenie realnie objęło, a nie to, jak zostało nazwane w pierwszym zgłoszeniu wewnętrznym.

Gdzie zapisuje się wynik obu kwalifikacji

Każdy reżim wymaga własnego śladu. Podmiot kluczowy lub ważny zapewnia właściwemu CSIRT dostęp do informacji o rejestrowanych incydentach w zakresie niezbędnym do realizacji jego zadań. Administrator dokumentuje wszelkie naruszenia ochrony danych wraz z okolicznościami, skutkami i podjętymi działaniami zaradczymi, a dokumentacja ma pozwolić organowi nadzorczemu zweryfikować, czy przepisy były przestrzegane. Obowiązek dokumentowania obejmuje również naruszenia, których organizacja nie zgłosiła.

Jeden system zgłoszeń obsłuży oba obowiązki tylko wtedy, gdy ma rozdzielone pola: osobno moment wykrycia i moment stwierdzenia, osobno klasyfikację incydentu i kwalifikację naruszenia, osobno uzasadnienie każdej z dwóch decyzji. Wspólny rekord z jedną datą i jednym statusem wygląda porządnie do pierwszego pytania organu o to, kiedy i na jakiej podstawie organizacja rozstrzygnęła sprawę.

Cztery układy jednego zdarzenia

Sytuacja	Incydent w rozumieniu KSC	Naruszenie w rozumieniu RODO	Co z tego wynika
Zakłócenie pracy systemu sterowania procesem technologicznym, w którym nie są przetwarzane dane osobowe	Tak	Nie	Obsługa i rejestracja po stronie KSC, klasyfikacja według progów; brak obowiązków wobec organu ochrony danych
Zaszyfrowanie systemów obsługujących klientów przez oprogramowanie wymuszające okup	Tak	Tak	Dwie ścieżki równolegle, dwa terminy liczone od różnych momentów, dwa zgłoszenia o innej treści
Zagubienie papierowej dokumentacji zawierającej dane osobowe	Nie	Tak	Wyłącznie ścieżka RODO: ocena ryzyka dla osób, decyzja o zgłoszeniu, wpis do dokumentacji naruszeń
Zdarzenie u dostawcy przetwarzającego dane w imieniu organizacji	Po stronie dostawcy, jeżeli podlega ustawie	Po stronie organizacji jako administratora	Dostawca zgłasza naruszenie administratorowi, a decyzję o zgłoszeniu do organu podejmuje administrator

Ostatni wiersz pokazuje coś co w praktyce sprawia najwięcej kłopotu. Obie kwalifikacje mogą powstać u dwóch różnych podmiotów w związku z jednym zdarzeniem. Umowa powierzenia powinna wtedy wyznaczać czas i kanał powiadomienia bo bez tego administrator dowiaduje się o sprawie na końcu łańcucha.

Najczęstsze błędy

• Kwalifikacja przeprowadzona przez jedną rolę. Zespół bezpieczeństwa zamyka sprawę jako incydent o niskiej istotności a informacja nigdy nie trafia do inspektora ochrony danych. Brakuje wtedy nie tyle zgłoszenia ile samej oceny czy było co zgłaszać.
• Przenoszenie progów między reżimami. Ocena naruszenia liczbą dotkniętych użytkowników usługi zamiast ryzyka dla osób prowadzi do systematycznego zaniżania wyniku bo zdarzenie o niewielkim zasięgu potrafi objąć szczególne kategorie danych osobowych.
• Wspólny rejestr bez rozdzielonych pól. Jedna data, jeden status i jedno uzasadnienie oznaczają, że jednego z dwóch obowiązków dokumentacyjnych organizacja nie wykonała.
• Przepisywanie treści jednego zgłoszenia do drugiego. Opis wpływu na usługę nie odpowiada na pytania o kategorie i liczbę osób ani o możliwe konsekwencje dla nich, więc zgłoszenie zbudowane w ten sposób jest niepełne od początku.
• Wniosek, że brak kwalifikacji do KSC zwalnia z obowiązków naruszeniowych. Reżimy mają różne zakresy podmiotowe. Organizacja spoza wykazu podmiotów kluczowych i ważnych podlega RODO w pełnym zakresie.
• Traktowanie okresu przejściowego w KSC jak zawieszenia wszystkich obowiązków. Terminy dostosowawcze dotyczą wyłącznie obowiązków z ustawy o KSC. Obowiązek zgłoszenia naruszenia biegnie przez cały ten czas bez zmian.

Wnioski i dalsze kroki

Po każdym zdarzeniu trzeba zadać dwa pytania osobno: czy zdarzenie wpłynęło albo mogło wpłynąć na bezpieczeństwo systemów informacyjnych oraz czy dotknęło danych osobowych albo mogło do tego doprowadzić. Odpowiedź na pierwsze nie przesądza odpowiedzi na drugie, a rozstrzygnięcie jednego reżimu nie zamyka drugiego. Organizacja, która zadaje tylko jedno z tych pytań, nie tyle podejmuje złą decyzję, ile w ogóle nie podejmuje drugiej.

Przed kolejnym zdarzeniem warto przesądzić cztery rzeczy. Kto zadaje drugie pytanie i w którym momencie obsługi sprawy. Jak zbudowany jest rejestr, żeby pomieścił dwa momenty, dwie kwalifikacje i dwa uzasadnienia. Skąd pochodzą progi klasyfikacji incydentu i według jakich kryteriów oceniane jest ryzyko dla osób. Od kiedy obowiązki z ustawy o KSC realnie wiążą organizację, biorąc pod uwagę przepisy przejściowe.

Rozdzielenie obu kwalifikacji nie zwiększa liczby procedur. Zwykle prowadzi do jednej procedury, w której dwie decyzje mają nazwanych właścicieli i osobne miejsca w dokumentacji — i to ta zmiana, a nie skala samego zdarzenia, decyduje później o tym, co organizacja potrafi wykazać.

Materiały powiązane

• Co zrobić po wykryciu incydentu? — kolejność działań w pierwszej dobie, zabezpieczenie śladów i równoległy bieg terminów.
• Czy każde naruszenie ochrony danych trzeba zgłosić? — próg zgłoszenia i ocena ryzyka dla praw i wolności osób.
• Czy każda organizacja podlega NIS2? — kwalifikacja podmiotu przesądzająca o tym, czy obowiązki incydentowe w ogóle powstają.
• Co powinien zawierać rejestr naruszeń ochrony danych? — co zapisać po kwalifikacji zdarzenia, także wtedy, gdy naruszenia nie stwierdzono.

Źródła

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 4 pkt 12, art. 33 i art. 34, tekst skonsolidowany — EUR-Lex: eur-lex.europa.eu (dostęp: 19.08.2026)
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa, art. 2 pkt 3d, 5, 7 i 14, art. 11, art. 12 i art. 12a, tekst ujednolicony — Kancelaria Sejmu, ISAP: isap.sejm.gov.pl (dostęp: 19.08.2026)
• Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252), art. 32 i art. 33 — przepisy przejściowe, Dziennik Ustaw: dziennikustaw.gov.pl (dostęp: 19.08.2026)
• Rozporządzenie Rady Ministrów z dnia 31 października 2018 r. w sprawie progów uznania incydentu za poważny (Dz.U. 2018 poz. 2180) — Kancelaria Sejmu, ELI: api.sejm.gov.pl (dostęp: 19.08.2026)
• Poradnik dotyczący naruszeń ochrony danych osobowych, wersja z 20 lutego 2025 r. — Urząd Ochrony Danych Osobowych: uodo.gov.pl (dostęp: 19.08.2026)
• Inne obowiązki i przepisy związane z naruszeniami — Urząd Ochrony Danych Osobowych: uodo.gov.pl (dostęp: 19.08.2026)