# Terminy zgłaszania incydentów (FAQ)

> 35 pytań o temat: Terminy zgłaszania incydentów, prostym językiem: co sprawdzić, co pokazuje NetSenX i czego czujnik nie widzi.

Source page: https://netsenx.com/pl/faq/reporting

## Od kiedy biegnie termin 24 godzin w NIS2?

Od chwili, gdy podmiot dowiedział się o poważnym incydencie, a nie od momentu, w którym incydent się zaczął. Art. 23 ust. 4 liczy od tej chwili zarówno wczesne ostrzeżenie (24 godziny), jak i zgłoszenie incydentu (72 godziny).

https://netsenx.com/pl/faq/when-does-the-nis2-24-hour-clock-start

## Co musi zawierać wczesne ostrzeżenie NIS2?

Zgodnie z art. 23 ust. 4 lit. a wczesne ostrzeżenie wskazuje, w stosownych przypadkach, czy istnieje podejrzenie, że poważny incydent został spowodowany działaniem bezprawnym lub złośliwym, i czy może mieć wpływ transgraniczny. Szczegóły przychodzą w zgłoszeniu 72-godzinnym.

https://netsenx.com/pl/faq/what-has-to-be-in-a-nis2-early-warning

## Czy sprawozdanie końcowe składa się miesiąc po incydencie?

Nie: miesiąc po wysłaniu zgłoszenia incydentu. Jeśli incydent wtedy nadal trwa, składa się sprawozdanie z postępów, a sprawozdanie końcowe w ciągu miesiąca od zakończenia obsługi incydentu.

https://netsenx.com/pl/faq/is-the-final-report-due-one-month-after-the-incident

## Czy dostawców usług zaufania obowiązują inne terminy?

Tak. Dostawca usług zaufania zgłasza poważne incydenty, które wpływają na świadczenie jego usług zaufania, w ciągu 24 godzin od powzięcia wiadomości, a nie 72 godzin.

https://netsenx.com/pl/faq/are-the-deadlines-different-for-trust-service-providers

## Jak szybko trzeba zgłosić naruszenie danych według RODO?

Zgodnie z art. 33 RODO administrator zgłasza naruszenie ochrony danych osobowych organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin po stwierdzeniu naruszenia, chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem dla osób. Zgodnie z art. 34, gdy naruszenie może powodować wysokie ryzyko, trzeba bez zbędnej zwłoki zawiadomić osoby, których dotyczy. NetSenX przygotowuje dla IOD zgłoszenie z art. 33; decyzja i wysłanie pozostają po Twojej stronie.

https://netsenx.com/pl/faq/how-fast-must-a-gdpr-breach-be-reported

## Czego wymaga CRA, gdy podatność jest wykorzystywana?

Art. 14 aktu o cyberodporności zobowiązuje producentów produktów z elementami cyfrowymi do zgłaszania aktywnie wykorzystywanych podatności w ich produktach oraz poważnych incydentów wpływających na bezpieczeństwo tych produktów, w kilku etapach. Etapy, ich terminy i odbiorców zgłoszeń określa rozporządzenie (UE) 2024/2847, art. 14. Te obowiązki zgłoszeniowe obowiązują od 11 września 2026 r. Dotyczą producentów, a nie firm, które tylko korzystają z produktów, choć własny incydent użytkownika może nadal podlegać zgłoszeniu na podstawie NIS2 lub RODO.

https://netsenx.com/pl/faq/what-does-the-cra-require-when-a-vulnerability-is-exploited

## Czy DORA nas dotyczy?

DORA, czyli rozporządzenie w sprawie operacyjnej odporności cyfrowej (rozporządzenie (UE) 2022/2554), stosuje się od 17 stycznia 2025 r. do podmiotów finansowych, takich jak banki, ubezpieczyciele, firmy inwestycyjne i instytucje płatnicze, oraz do wyznaczonych na jego podstawie kluczowych zewnętrznych dostawców usług ICT. Art. 19 wymaga od podmiotów finansowych zgłaszania poważnych incydentów związanych z ICT właściwemu organowi: zgłoszenia wstępnego, sprawozdania pośredniego i sprawozdania końcowego; terminy określają standardy techniczne przyjęte na podstawie art. 20. Dla podmiotu finansowego zasady DORA dotyczące incydentów ICT mają pierwszeństwo przed ogólnymi zasadami NIS2. Jeśli świadczysz usługi ICT dla podmiotu finansowego, DORA dociera do Ciebie przez umowę: art. 30 wymienia postanowienia, które takie umowy muszą zawierać, w tym pomoc przy incydentach, prawa audytu i plany wyjścia. Od klientów finansowych należy spodziewać się szczegółowych pytań i klauzul umownych.

https://netsenx.com/pl/faq/does-dora-apply-to-us

## Co jest poważnym incydentem w rozumieniu NIS2?

Incydent, który spowodował lub może spowodować poważne zakłócenia operacyjne usług albo straty finansowe dla firmy, lub który wpłynął albo może wpłynąć na inne osoby lub organizacje, wyrządzając im znaczne szkody majątkowe lub niemajątkowe. To kryterium z art. 23 ust. 3, a zgłaszać trzeba tylko poważne incydenty. „Może spowodować” oznacza, że nie czeka się, aż szkoda nastąpi. Dla niektórych dostawców cyfrowych, takich jak dostawcy chmury, DNS i usług zarządzanych, rozporządzenie wykonawcze (UE) 2024/2690 określa dokładniejsze progi; dla pozostałych wytyczne mogą publikować przepisy i organy krajowe. Z góry, w procedurze obsługi incydentów, warto ustalić, jakich kryteriów się używa, na przykład niedostępność usług przez określony czas, dotknięte dane klientów czy udział przestępcy, i kto podejmuje decyzję. NetSenX śledzi terminy, gdy decyzja zapadnie; sama decyzja należy do Ciebie.

https://netsenx.com/pl/faq/what-counts-as-a-significant-incident-under-nis2

## Czy nieudany lub zablokowany atak podlega zgłoszeniu na gruncie NIS2?

Zwykle nie jako poważny incydent, ale może, a zgłosić go można dobrowolnie. Obowiązek z art. 23 obejmuje poważne incydenty: te, które spowodowały lub mogły spowodować poważne zakłócenia, straty finansowe albo znaczne szkody dla innych. Atak zatrzymany, zanim przyniósł jakikolwiek skutek, zwykle nie spełnia tego kryterium, choć taki, który był bardzo blisko, na przykład ransomware wykryty, gdy dotarł już do serwera kopii zapasowych, może je spełnić. NIS2 rozróżnia też zdarzenia potencjalnie niebezpieczne i poważne cyberzagrożenia, a art. 30 pozwala zgłaszać je dobrowolnie, co pomaga CSIRT ostrzegać innych. Każde takie zdarzenie warto zapisać w rejestrze incydentów z uzasadnieniem, by później móc wyjaśnić, dlaczego je zgłoszono lub nie. NetSenX przechowuje alerty stojące za każdą decyzją.

https://netsenx.com/pl/faq/is-a-blocked-attack-reportable-under-nis2

## Jak mały zespół może dotrzymać 24-godzinnego terminu wczesnego ostrzeżenia z NIS2?

Przygotowując z wyprzedzeniem te części, które nie zależą od incydentu. Wczesne ostrzeżenie z art. 23 ust. 4 lit. a) jest krótkie: informuje, że doszło do poważnego incydentu, oraz, w stosownych przypadkach, czy podejrzewa się, że jest wynikiem działań bezprawnych lub złośliwych, i czy może mieć skutki transgraniczne. Szczegóły przychodzą w zgłoszeniu po 72 godzinach. Dlatego warto mieć jednostronicowy szablon, kanał zgłoszeń i dane logowania do krajowego CSIRT lub organu, wskazaną osobę i zastępcę uprawnionych do wysyłki oraz wewnętrzną zasadę, kto decyduje, że incydent jest poważny. Raz w roku przeprowadzić próbę. Małe zespoły najwięcej czasu tracą na ustalanie, co się stało, więc alerty muszą docierać do kogoś także w nocy i w weekendy. NetSenX uruchamia zegar terminów dla każdego incydentu i trzyma alerty z czasem, urządzeniami i miejscami docelowymi w jednym miejscu.

https://netsenx.com/pl/faq/how-can-a-small-team-meet-the-nis2-24-hour-deadline

## Co powinniśmy mieć gotowe, zanim minie 24-godzinny termin z NIS2?

Krótką listę faktów, gotowy kanał i osobę uprawnioną do wysłania. Do samego wczesnego ostrzeżenia potrzebne są: czas uzyskania wiedzy o incydencie; prosty opis tego, czego dotyczy do tej pory; informacja, czy podejrzewa się działanie złośliwe lub bezprawne; oraz czy mogą być dotknięte inne kraje. Do zgłoszenia po 72 godzinach trzeba od razu zbierać: wagę i skutki, dotknięte systemy i usługi, wskaźniki kompromitacji, takie jak złośliwe adresy czy skróty plików, oraz podjęte działania. Od pierwszej minuty warto prowadzić bieżącą oś czasu z tym, kto co zrobił. Trzeba sprawdzić, czy chodzi o dane osobowe, bo równolegle może biec termin zgłoszenia z RODO. NetSenX daje sieciową część tej osi czasu: pierwsze nietypowe połączenie, zaangażowane urządzenia, miejsca docelowe i wolumeny oraz terminy z art. 23 liczone od zapisanego momentu uzyskania wiedzy.

https://netsenx.com/pl/faq/what-should-we-have-ready-before-the-nis2-24-hour-deadline

## Czy musimy informować własnych klientów o incydencie NIS2?

Czasem tak. Zgodnie z art. 23 ust. 1, w stosownych przypadkach, podmioty objęte dyrektywą bez zbędnej zwłoki informują odbiorców swoich usług o poważnych incydentach, które mogą niekorzystnie wpłynąć na świadczenie tych usług. Zgodnie z art. 23 ust. 2, tam gdzie ma to zastosowanie, podmioty informują też odbiorców, których może dotyczyć poważne cyberzagrożenie, o tym, co mogą zrobić w odpowiedzi, a w stosownych przypadkach także o samym zagrożeniu. Takie informowanie mogą też nakazać organy. Szczegóły określa prawo krajowe: w Niemczech BSI może nakazać poinformowanie odbiorców (§ 35 ust. 1 BSIG), a podmioty z sektorów takich jak finanse, infrastruktura cyfrowa i zarządzanie usługami ICT muszą informować ich o poważnych cyberzagrożeniach (§ 35 ust. 2). Umowy i RODO mogą dodawać własne obowiązki. Szablon komunikatu dla klientów warto przygotować w ramach planu reagowania.

https://netsenx.com/pl/faq/do-we-have-to-tell-customers-about-a-nis2-incident

## Czy atak ransomware trzeba zgłosić na podstawie RODO?

Często tak, jeśli dotyczył danych osobowych, nawet gdy nic nie zostało skradzione. RODO w art. 4 pkt 12 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. Zaszyfrowanie przez ransomware czyni dane niedostępnymi, co jest naruszeniem dostępności, a atakujący często kopiują dane przed szyfrowaniem. Zgodnie z art. 33 administrator zgłasza naruszenie organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin od stwierdzenia, chyba że jest mało prawdopodobne, by skutkowało ryzykiem dla osób, na przykład gdy świeża kopia zapasowa szybko wszystko odtworzyła, a nic nie opuściło sieci. Uzasadnienie trzeba udokumentować w obu przypadkach. NetSenX może pokazać, czy przed szyfrowaniem z monitorowanych urządzeń wychodziły nietypowe wysyłki, co ma znaczenie dla tej oceny.

https://netsenx.com/pl/faq/do-we-have-to-report-ransomware-under-the-gdpr

## Jeśli skradzione dane były zaszyfrowane, czy nadal trzeba zgłaszać naruszenie?

Być może organowi, ale często nie osobom, których dotyczy. Art. 34 ust. 3 lit. a) RODO stanowi, że osób nie trzeba zawiadamiać, jeśli administrator zastosował środki, takie jak szyfrowanie, uniemożliwiające odczytanie danych osobom nieuprawnionym. Zgłoszenie do organu nadzorczego z art. 33 to osobna kwestia: jest potrzebne, chyba że jest mało prawdopodobne, by naruszenie skutkowało ryzykiem dla osób, a to zależy od siły szyfrowania, tego, czy klucz także wyciekł, i tego, czy dane są nadal dostępne dla firmy. Jeśli klucz był na tym samym skradzionym laptopie albo szyfrowanie było słabe, dane trzeba traktować jako ujawnione. Warto zapisać, które dane były szyfrowane, w jaki sposób i gdzie były klucze. Dowody z sieci o tym, co i kiedy wyszło, pomagają inspektorowi ochrony danych podjąć decyzję.

https://netsenx.com/pl/faq/if-stolen-data-was-encrypted-must-we-still-notify

## Nie zdążymy ze zgłoszeniem z RODO w 72 godziny. Czy można zgłaszać etapami lub później?

Tak, etapami, a później tylko z uzasadnieniem. Art. 33 ust. 4 RODO pozwala przekazywać informacje stopniowo, bez zbędnej dalszej zwłoki, jeśli nie da się ich przekazać wszystkich jednocześnie, a art. 33 ust. 1 wymaga, by zgłoszeniu po upływie 72 godzin towarzyszyło wyjaśnienie przyczyn opóźnienia. Nie trzeba więc czekać na pełny obraz: w terminie warto wysłać zgłoszenie wstępne z tym, co wiadomo, charakterem naruszenia, prawdopodobnymi konsekwencjami, dotychczasowymi działaniami i danymi kontaktowymi inspektora ochrony danych, a potem uzupełniać je w miarę ustalania faktów. Trzeba zapisać, kiedy stwierdzono naruszenie i dlaczego część informacji przyszła później. Organy nadzorcze zwykle udostępniają formularze online umożliwiające uzupełnienia; w Polsce jest to formularz UODO. NetSenX przygotowuje zgłoszenie z art. 33 dla inspektora ochrony danych na podstawie danych o incydencie; wysłanie należy do Ciebie.

https://netsenx.com/pl/faq/we-cannot-meet-72-hours-can-we-notify-in-phases

## Kiedy zaczyna biec 72-godzinny termin zgłoszenia z RODO?

W chwili, gdy administrator stwierdzi naruszenie ochrony danych osobowych, a nie wtedy, gdy naruszenie się zaczęło. Art. 33 ust. 1 liczy 72 godziny od stwierdzenia naruszenia. Wytyczne Europejskiej Rady Ochrony Danych uznają, że administrator ma tę wiedzę, gdy z rozsądnym stopniem pewności wie, że doszło do incydentu bezpieczeństwa, który naruszył dane osobowe. Krótkie wstępne dochodzenie, by to ustalić, jest dopuszczalne, ale musi być szybkie; nie można opóźniać stwierdzenia przez to, że się nie sprawdza. Podmiot przetwarzający, który wykryje naruszenie, musi bez zbędnej zwłoki poinformować administratora (art. 33 ust. 2), a termin administratora zwykle biegnie od chwili, gdy się o tym dowie. Dlatego w rejestrze incydentów trzeba zapisać dokładny czas, w którym ktoś uznał, że chodzi o dane osobowe. NetSenX pozwala zapisać ten moment dla każdego incydentu i przechowuje alerty pokazujące, kiedy zaczęła się aktywność.

https://netsenx.com/pl/faq/when-does-the-gdpr-72-hour-clock-start

## Jeden incydent, kilka zgłoszeń: jak łączą się NIS2, RODO i DORA?

Każdy akt ma własne zgłoszenie, adresata i termin, a jeden incydent może uruchomić kilka. Poważny incydent w podmiocie objętym NIS2 trafia do CSIRT lub właściwego organu zgodnie z art. 23 NIS2; jeśli dotyczy danych osobowych, administrator zgłasza go też organowi ochrony danych zgodnie z art. 33 RODO; podmiot finansowy zgłasza poważne incydenty ICT na podstawie art. 19 DORA zamiast NIS2; a producent produktu może mieć obowiązki z aktu o cyberodporności, zob. rozporządzenie (UE) 2024/2847, art. 14. Niektóre systemy krajowe mają jeden portal, ale nie należy zakładać, że jedno zgłoszenie obejmuje wszystko. Warto prowadzić jeden zapis incydentu i z niego tworzyć każde zgłoszenie, żeby fakty się zgadzały. Art. 35 NIS2 każe też organom NIS2 informować organy ochrony danych o naruszeniach, o których się dowiedzą. NetSenX śledzi terminy NIS2 i przygotowuje projekt zgłoszenia z art. 33 RODO z tych samych danych o incydencie.

https://netsenx.com/pl/faq/one-incident-several-reports-nis2-gdpr-dora

## Czym jest poważny incydent związany z ICT według DORA?

Takim, który podmiot finansowy klasyfikuje jako poważny według kryteriów z art. 18 DORA i przyjętych na jego podstawie standardów technicznych. Art. 18 wymienia kryteria takie jak liczba i znaczenie klientów lub kontrahentów finansowych, których dotyczy incydent, kwota lub liczba objętych nim transakcji, wpływ na reputację, czas trwania i przestój usług, zasięg geograficzny, utrata danych wpływająca na dostępność, autentyczność, integralność lub poufność, krytyczność dotkniętych usług oraz skutki ekonomiczne. Standardy przekładają je na progi. Zgłaszać na podstawie art. 19 trzeba tylko poważne incydenty; poważne cyberzagrożenia można zgłaszać dobrowolnie. Klasyfikację warto wbudować w procedurę obsługi incydentów, żeby decyzja była szybka, powtarzalna i udokumentowana, oraz uzgodnić z dostawcami ICT, jak przekażą potrzebne fakty. Klienci finansowi będą tego oczekiwać także od swoich dostawców.

https://netsenx.com/pl/faq/what-is-a-major-ict-incident-under-dora

## Jakie są terminy zgłaszania incydentów w DORA?

Określają je standardy techniczne przyjęte na podstawie art. 20 DORA, a nie sam tekst rozporządzenia, więc dokładne godziny i dni trzeba sprawdzić w tych standardach i wytycznych właściwego organu. Art. 19 ust. 4 ustala kolejność: zgłoszenie wstępne, sprawozdanie pośrednie, gdy tylko status pierwotnego incydentu istotnie się zmieni lub zmieni się jego obsługa na podstawie nowych informacji, następnie stosowne aktualizacje, oraz sprawozdanie końcowe po zakończeniu analizy przyczyn źródłowych. Standardy określają też treść i wzory. Ponieważ terminy są powiązane z chwilą wykrycia incydentu i zaklasyfikowania go jako poważnego, szybkość klasyfikacji ma takie samo znaczenie jak szybkość pisania. Jeśli jesteś dostawcą ICT dla podmiotu finansowego, umowa najpewniej wymaga powiadomienia klienta na tyle szybko, by mógł dotrzymać tych terminów.

https://netsenx.com/pl/faq/what-are-the-dora-incident-reporting-deadlines

## Gdzie składa się zgłoszenia podatności na podstawie aktu o cyberodporności?

Przez jednolitą platformę zgłoszeń, którą ENISA prowadzi na potrzeby aktu o cyberodporności. Zgodnie z art. 14 rozporządzenia (UE) 2024/2847 producenci produktów z elementami cyfrowymi zgłaszają przez tę platformę aktywnie wykorzystywane podatności swoich produktów i poważne incydenty wpływające na ich bezpieczeństwo; zgłoszenie trafia do CSIRT wyznaczonego jako koordynator w państwie głównej siedziby producenta oraz do ENISA. Etapy, terminy i treść zgłoszeń: zob. rozporządzenie (UE) 2024/2847, art. 14. Obowiązki te dotyczą producentów, w tym firm programistycznych wprowadzających produkty na rynek UE, a nie firm, które tylko z produktów korzystają. Użytkownicy mogą po tym samym zdarzeniu mieć własne zgłoszenia z NIS2 lub RODO. Firma tworząca oprogramowanie powinna z wyprzedzeniem zbudować proces obsługi podatności i ustalić, kto ma dostęp do platformy.

https://netsenx.com/pl/faq/where-are-cra-vulnerability-reports-submitted

## Czy oprócz regulatora powinniśmy zgłosić cyberincydent policji?

Często tak, ale to decyzja odrębna od zgłoszeń regulacyjnych. Atak ransomware, kradzież danych, oszustwo czy wymuszenie to zwykle przestępstwa, a zawiadomienie organów ścigania może pomóc przy roszczeniach z ubezpieczenia, przy próbie cofnięcia oszukańczego przelewu przez bank i w śledztwach łączących sprawę z innymi; niektórzy ubezpieczyciele proszą o numer zgłoszenia na policji. Zawiadomienie policji nie zastępuje zgłoszeń do CSIRT, właściwego organu ani organu ochrony danych, a one nie zastępują zawiadomienia. W wielu krajach działają wyspecjalizowane jednostki do walki z cyberprzestępczością lub formularze online. Przed złożeniem warto uzgodnić z prawnikami i firmą reagowania na incydenty, jakie dowody przekazać i jak je zabezpieczyć, żeby nie zniszczyć tego, czego potrzebują śledczy. Wczesne ostrzeżenie z NIS2 i tak pyta, czy podejrzewa się działanie bezprawne lub złośliwe; ta odpowiedź i zawiadomienie policji powinny być spójne.

https://netsenx.com/pl/faq/should-we-report-a-cyber-incident-to-the-police

## Jakie informacje powinno zawierać zgłoszenie incydentu do organów?

Podstawy są wszędzie te same: co się stało, kiedy, czego dotyczyło, jak poważne jest, co zrobiono i z kim się kontaktować. Zgodnie z art. 23 ust. 4 NIS2 wczesne ostrzeżenie informuje, czy podejrzewa się działanie złośliwe lub bezprawne i czy incydent może mieć skutki transgraniczne; zgłoszenie po 72 godzinach dodaje wstępną ocenę wagi i skutków oraz, jeśli są dostępne, wskaźniki kompromitacji; a sprawozdanie końcowe dodaje szczegółowy opis, rodzaj zagrożenia lub przyczynę źródłową, działania łagodzące i skutki transgraniczne. Zgodnie z art. 33 ust. 3 RODO zgłoszenie naruszenia opisuje jego charakter, kategorie i przybliżoną liczbę osób i wpisów, prawdopodobne konsekwencje, podjęte środki i dane kontaktowe inspektora ochrony danych. Fakty i przypuszczenia trzeba wyraźnie rozdzielać. NetSenX dostarcza z sieci czasy, urządzenia, miejsca docelowe i wolumeny.

https://netsenx.com/pl/faq/what-should-an-incident-report-contain

## Czy trzeba zgłaszać incydent, który został już rozwiązany?

Tak, jeśli był poważny albo stanowił naruszenie ochrony danych osobowych podlegające zgłoszeniu; usunięcie problemu nie znosi obowiązku. Art. 23 NIS2 wiąże obowiązek zgłoszenia z poważnym incydentem, niezależnie od tego, czy nadal trwa, a terminy biegną od uzyskania o nim wiedzy. Jeśli dopiero teraz okazało się, że zeszłomiesięczna awaria była atakiem, zegar rusza w chwili tego odkrycia i należy zgłosić incydent niezwłocznie, wyjaśniając przebieg zdarzeń. Na gruncie RODO naruszenie, które może powodować ryzyko dla osób, trzeba zgłosić nawet po jego opanowaniu; opanowanie może obniżyć ryzyko i wpłynąć na treść zgłoszenia. Rozwiązany incydent można zwykle zgłosić od razu w jednym zgłoszeniu ze znanymi już faktami, ale trzeba trzymać się formatu właściwego organu. Daty wystąpienia, uzyskania wiedzy i rozwiązania warto zapisywać osobno.

https://netsenx.com/pl/faq/can-we-report-an-incident-that-is-already-resolved

## Co zmniejsza karę z RODO po naruszeniu ochrony danych?

Głównie to, co zrobiono przed naruszeniem i po nim: szybkie zgłoszenie, rzeczywiste łagodzenie skutków i współpraca. Art. 83 ust. 2 RODO wymienia czynniki, które biorą pod uwagę organy, w tym charakter, wagę i czas trwania naruszenia, umyślność lub nieumyślność, działania podjęte w celu zminimalizowania szkody dla osób, wcześniej wdrożone środki techniczne i organizacyjne, wcześniejsze naruszenia, stopień współpracy z organem, kategorie danych oraz sposób, w jaki organ dowiedział się o naruszeniu, w szczególności czy zostało zgłoszone. Za najpoważniejsze naruszenia kary mogą sięgnąć 20 mln EUR lub 4% całkowitego światowego rocznego obrotu zgodnie z art. 83 ust. 5. W praktyce: zgłosić na czas z faktami, pokazać istniejące zabezpieczenia, szybko opanować naruszenie, poinformować osoby, gdy jest to wymagane, i dokumentować każdy krok. NetSenX pomaga w osi czasu i w projekcie zgłoszenia z art. 33 dla inspektora ochrony danych.

https://netsenx.com/pl/faq/what-reduces-a-gdpr-fine-after-a-data-breach

## Czy NetSenX może przygotować zgłoszenie naruszenia z art. 33 RODO?

Tak, jako projekt dla inspektora ochrony danych; decyzja i wysłanie pozostają po Twojej stronie. Na podstawie danych o incydencie NetSenX przygotowuje projekt z tym, co pokazuje sieć: kiedy wykryto problem oraz których urządzeń i miejsc docelowych dotyczył. Art. 33 ust. 3 wymaga też informacji, które masz tylko Ty, czyli kategorie i przybliżoną liczbę osób i wpisów, prawdopodobne konsekwencje, podjęte środki i dane kontaktowe inspektora. Dowody z sieci mają granice: NetSenX widzi połączenia, wolumeny i miejsca docelowe, a nie to, które pliki czy rekordy wyszły, więc inspektor musi uzupełnić treść z innych źródeł. Projekt oszczędza czas w piątkowy wieczór, gdy biegnie 72-godzinny termin, i utrzymuje spójność faktów ze zgłoszeniami NIS2. Trzeba go sprawdzić, uzupełnić i samodzielnie złożyć w organie nadzorczym.

https://netsenx.com/pl/faq/can-netsenx-prepare-a-gdpr-article-33-notification

## Czy dziennik audytu narzędzia bezpieczeństwa pomaga przy ogólnych kontrolach IT?

Tak, w części kontroli dotyczącej samego narzędzia. Biegli rewidenci badający sprawozdania finansowe oraz audytorzy ISO lub SOC 2 testują ogólne kontrole IT: kto ma dostęp do systemów, jak zmiany są zatwierdzane i zapisywane oraz jak monitoruje się działanie i incydenty. Dziennik audytu narzędzia bezpieczeństwa dostarcza dowodów dla jego własnego wycinka: kto ma konta, kto zmienił ustawienia wykrywania lub zasady powiadomień, kto zamknął alert lub podjął w jego sprawie decyzję, i kiedy. W każdym planie NetSenX prowadzi taki dziennik audytu, z okresem przechowywania rosnącym wraz z planem. Nie zapisuje zmian w ERP, serwerach plików ani innych systemach, które potrzebują własnych logów. Warto wyeksportować wyciąg za okres badania i zestawić go z przeglądami uprawnień i zgłoszeniami zmian, by audytor zobaczył jedną spójną całość.

https://netsenx.com/pl/faq/does-a-security-tools-audit-log-help-with-it-general-controls

## Jak udowodnić, kto i kiedy zmienił ustawienie bezpieczeństwa?

Dziennikiem audytu, który zapisuje każdą zmianę, osobę, która jej dokonała, i czas, przechowywanym tam, gdzie nie da się go po cichu zmienić. W przypadku własnych systemów oznacza to włączenie rejestrowania zmian w zaporach, usługach katalogowych, konsolach chmurowych i narzędziach bezpieczeństwa, przesyłanie logów do centralnego miejsca z ograniczonym dostępem i łączenie zmian z zatwierdzonymi zgłoszeniami. Wspólne konta administratorów uniemożliwiają dowód, więc każda osoba powinna mieć własne imienne konto z uwierzytelnianiem wieloskładnikowym. Logi trzeba przeglądać pod kątem nieoczekiwanych zmian, zwłaszcza poza godzinami pracy. W samym NetSenX dziennik audytu w każdym planie zapisuje, kto zmienił ustawienia wykrywania, zasady powiadomień lub skład zespołu i kto decydował w sprawie alertów, ze znacznikami czasu; wyciąg można wyeksportować dla audytora. Obejmuje zmiany w NetSenX, a nie ustawienia innych systemów.

https://netsenx.com/pl/faq/how-do-we-prove-who-changed-a-security-setting

## Jak pokazać audytorowi, które części sieci są monitorowane?

Prostym opisem zasięgu popartym dowodami, z uwzględnieniem luk. Warto wypisać każdą lokalizację i segment sieci, czy obserwuje go sensor lub agent, od kiedy i co obejmuje, a potem zaznaczyć to, czego się nie obserwuje, na przykład Wi-Fi dla gości, oddział czy środowisko chmurowe, i jak jest to obsługiwane w inny sposób. Do tego dowody: lista sensorów, niedawny alert z każdego monitorowanego segmentu i mapa sieci. Audytorzy bardziej ufają uczciwemu opisowi ze znanymi lukami niż twierdzeniu o pełnym zasięgu, które upada przy pierwszym pytaniu. W NetSenX jeden agent na porcie lustrzanym przełącznika (SPAN) lub TAP-ie sieciowym obserwuje cały segment, a panel pokazuje, które agenty działają gdzie; ruch w segmencie, którego się nie kopiuje, pozostaje poza widokiem, i NetSenX nie udaje, że jest inaczej.

https://netsenx.com/pl/faq/how-do-we-show-an-auditor-which-parts-of-the-network-are-monitored

## Czego nie zobaczy wykrywanie sieciowe, jeśli segment nie jest kopiowany do sensora?

Wszystkiego, co dzieje się wyłącznie w tym segmencie. Sensor widzi ruch, który otrzymuje; jeśli port przełącznika nie jest do niego kopiowany, a na hostach nie działa agent, połączenia między urządzeniami w tym segmencie, na przykład atakujący przechodzący z komputera na stojący obok serwer plików, pozostają niewidoczne. Może być nadal widać ruch opuszczający segment przez monitorowany punkt, na przykład do internetu lub innej lokalizacji, ale wewnętrzne kroki włamania to często właśnie to, czego trzeba. Decyzję warto oprzeć na ryzyku: najpierw kopiować segmenty z serwerami, administracją, finansami, HR i produkcją, potem resztę. Tam, gdzie kopiowanie jest niepraktyczne, agenta można uruchomić na samych ważnych hostach. NetSenX pokazuje, które segmenty obserwują jego sensory i agenty, więc luki są widoczne.

https://netsenx.com/pl/faq/what-does-network-detection-miss-if-a-segment-is-not-mirrored

## Co powinien zawierać rejestr incydentów na potrzeby audytu NIS2?

Tyle, by odtworzyć każdy incydent i każdą decyzję bez odwoływania się do czyjejś pamięci. Przy każdym wpisie: unikalny numer; kiedy incydent się zaczął, kiedy i czym został wykryty oraz kiedy uznano go za poważny lub nie; krótki opis oraz dotknięte systemy, usługi i dane; ocena wagi i kto jej dokonał; czy go zgłoszono, komu i kiedy, z kopiami zgłoszeń; kroki powstrzymania, usunięcia i odtworzenia z czasami i osobami odpowiedzialnymi; przyczyna źródłowa; wnioski i zmiany, które nastąpiły. Warto rejestrować też zdarzenia potencjalnie niebezpieczne, z powodem niezgłoszenia. Rejestr powinien być odporny na manipulacje i mieć kontrolę dostępu. NetSenX automatycznie dostarcza część sieciową: alerty z czasem, urządzeniami i miejscami docelowymi, terminy NIS2 dla każdego incydentu i dziennik audytu, kto co zdecydował.

https://netsenx.com/pl/faq/what-should-an-incident-log-contain-for-a-nis2-audit

## Jak pokazać audytorowi, co postanowiliśmy przy każdym alercie bezpieczeństwa?

Zapisem, który łączy każdy alert z decyzją, osobą, czasem i uzasadnieniem. Audytorzy chcą widzieć, że alerty nie znikają: każdy został przejrzany, zakwalifikowany jako niegroźny, badany lub jako incydent i zamknięty z wyjaśnieniem. Arkusz kalkulacyjny wystarczy przy kilku alertach, ale przy większej liczbie przestaje działać i łatwo go uzupełnić po fakcie. Gdzie się da, warto korzystać z procesu w samym narzędziu, pisać krótkie uzasadnienia zamiast jednowyrazowych statusów i co kwartał przeglądać próbkę zamkniętych alertów, by sprawdzić jakość decyzji. W NetSenX decyzje analityków przy alertach są zapisywane w dzienniku audytu w każdym planie, z informacją, kto i kiedy zdecydował; od planu Starter można wyeksportować dla audytora raporty PDF.

https://netsenx.com/pl/faq/how-do-we-show-an-auditor-what-we-decided-on-each-alert

## Jak długo trzeba przechowywać dokumentację incydentów bezpieczeństwa?

NIS2 nie określa jednego okresu przechowywania, więc trzeba ustalić go samemu i zapisać uzasadnienie. Kilka przepisów wskazuje ten sam kierunek. RODO wymaga od administratorów dokumentowania każdego naruszenia ochrony danych osobowych (art. 33 ust. 5), by organ mógł zweryfikować przestrzeganie przepisów, co oznacza przechowywanie zapisu tak długo, jak taka kontrola może rozsądnie nastąpić. Organy nadzoru NIS2 mogą żądać dowodów dawnych incydentów i zgłoszeń, ubezpieczyciele mogą badać szkodę długo po zdarzeniu, a terminy przedawnienia roszczeń umownych i odszkodowawczych w wielu krajach liczy się w latach. Przepisy sektorowe i krajowe mogą wyznaczać własne okresy. Częste podejście to przechowywanie rejestru incydentów i zgłoszeń przez kilka lat, a surowych logów krócej, z usuwaniem niepotrzebnych już danych osobowych. Okres historii alertów i dziennika audytu w NetSenX zależy od planu; to, co trzeba przechowywać dłużej, warto wyeksportować.

https://netsenx.com/pl/faq/how-long-must-we-keep-security-incident-records

## Czy mapę sieci dla audytora można wygenerować automatycznie z ruchu?

Tak, dla monitorowanych segmentów, i często jest dokładniejsza niż rysowany schemat. Mapa zbudowana z obserwowanego ruchu pokazuje, jakie urządzenia istnieją, jakie nazwy ogłaszają i kto z kim rozmawia, w tym połączenia, których nikt nie udokumentował, na przykład stację roboczą łączącą się z serwerem, z którym nie powinna, albo zdalną sesję dostawcy. Nie pokazuje tego, co nie wysyła ruchu, segmentów bez sensora ani zamierzonego projektu, więc warto zachować schemat architektury i sprawdzać go obserwowaną mapą. W każdym planie NetSenX buduje taką mapę z monitorowanego ruchu, z datą pierwszego i ostatniego pojawienia się każdego urządzenia. Przed pokazaniem jej zewnętrznemu audytorowi warto zastanowić się, co ujawnia: nazwy urządzeń mogą zawierać imiona i nazwiska pracowników, a mapa opisuje wewnętrzną strukturę, więc lepiej pokazać ją na ekranie lub na podstawie umowy o poufności.

https://netsenx.com/pl/faq/can-a-network-map-be-generated-automatically-for-an-auditor

## Czy trzeba dokumentować naruszenia ochrony danych, których nie zgłaszamy?

Tak. Art. 33 ust. 5 RODO wymaga od administratora dokumentowania każdego naruszenia ochrony danych osobowych, w tym okoliczności, skutków i podjętych działań zaradczych, niezależnie od tego, czy zostało zgłoszone organowi nadzorczemu. Chodzi o to, by organ mógł później zweryfikować przestrzeganie przepisów, w tym decyzję, że naruszenie raczej nie powodowało ryzyka dla osób. Przy każdym naruszeniu warto więc zapisać, co się stało, jakich danych i osób dotyczyło, dlaczego uznano zgłoszenie za potrzebne lub nie, kto i kiedy zdecydował oraz co zmieniono. Rejestr naruszeń powinien być oddzielny od rejestru incydentów bezpieczeństwa, ale z nim powiązany. Organy mogą zażądać go przy kontroli lub po skardze, a brak zapisu niezgłoszonego naruszenia wygląda gorzej niż samo naruszenie. NetSenX przechowuje dowody z alertów stojące za każdym wpisem przez okres przewidziany w planie.

https://netsenx.com/pl/faq/must-we-document-data-breaches-we-do-not-report

## Kiedy trzeba powiadomić osoby, których dotyczy naruszenie ochrony danych?

Gdy naruszenie może powodować wysokie ryzyko naruszenia ich praw lub wolności. Art. 34 RODO wymaga wtedy od administratora zawiadomienia ich bez zbędnej zwłoki, jasnym i prostym językiem, z opisem charakteru naruszenia, prawdopodobnych konsekwencji, podjętych lub proponowanych środków oraz danymi kontaktowymi inspektora ochrony danych. Wysokie ryzyko oznacza zwykle dane, które mogą wyrządzić realną szkodę, jak dokumenty tożsamości, dane bankowe lub o zdrowiu, hasła czy informacje umożliwiające oszustwa. Art. 34 ust. 3 wymienia wyjątki: dane zostały uniemożliwione do odczytu, na przykład silnym szyfrowaniem; późniejsze środki sprawiają, że wysokie ryzyko nie jest już prawdopodobne; albo indywidualne zawiadomienia wymagałyby niewspółmiernego wysiłku, i wtedy stosuje się komunikat publiczny. Organ nadzorczy może też nakazać poinformowanie osób. Trzeba im powiedzieć, co zrobić, na przykład zmienić hasła albo uważać na phishing.

https://netsenx.com/pl/faq/when-must-we-tell-affected-people-about-a-data-breach

Informacja ogólna, nie porada prawna. Przepisy krajowe mogą uzupełniać cytowane tu akty UE, na przykład o terminy, formularze czy kanały zgłoszeń: sprawdź przepisy swojego kraju.

FAQ: https://netsenx.com/pl/faq