---
title: "Zgłaszanie incydentów w DORA i NIS2: telefon, zanim skończy się czas"
description: "DORA daje 4 godziny od klasyfikacji. NIS2 daje 24 godziny od powzięcia wiedzy. Żaden zegar nie zatrzymuje się w nocy. Oto jak zamienić alerty z wykrywania w dzwoniący telefon dzięki Echobell."
date: 2026-07-31
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - zgłaszanie incydentów DORA
  - zgłaszanie incydentów NIS2
  - terminy regulacyjne
  - alerty telefoniczne
  - alertowanie dyżurów
---

# Zgłaszanie incydentów w DORA i NIS2: telefon, zanim skończy się czas

Każdy unijny termin zgłoszenia incydentu zaczyna biec od czegoś, co zauważa maszyna, i biegnie dalej, gdy Twój zespół śpi. Jeśli alert uruchamiający zegar przychodzi jako ciche powiadomienie push o 02:40 w niedzielę, zdążysz spalić jedną czwartą okna raportowania z DORA, zanim jakikolwiek człowiek go przeczyta. Ten przewodnik pokazuje, jak postawić przed swoim procesem raportowania prawdziwe, dzwoniące połączenie telefoniczne dzięki [Echobell](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-dora-nis2-incident-reporting-alerts-pl&mt=8) — tak, aby zegar i Twoja reakcja ruszały mniej więcej w tym samym momencie.

Skalę tego zjawiska już zmierzono, nie trzeba jej zgadywać. 3 czerwca 2026 roku trzy Europejskie Urzędy Nadzoru opublikowały pierwszy ogólnounijny przegląd poważnych incydentów ICT zgłoszonych na podstawie DORA: **3383 poważne incydenty** w 2025 roku, średnio **0,18 na objęty przepisami podmiot finansowy**, przy czym **około jedna trzecia** miała skutki transgraniczne ([EBA](https://www.eba.europa.eu/publications-and-media/press-releases/esas-publish-first-report-dora-major-ict-related-incidents), [ESMA](https://www.esma.europa.eu/press-news/esma-news/esas-publish-first-report-dora-major-ict-related-incidents)). Szczegół, który powinien ukształtować Twoje alertowanie: tylko **10%** dotyczyło cyberbezpieczeństwa. Głównymi przyczynami były awarie systemów i zdarzenia zewnętrzne.

Inaczej mówiąc, zdarzenia uruchamiające regulacyjny zegar to w przeważającej mierze te nudne — nieudane wdrożenie, martwa zależność, awaria dostawcy. Dokładnie to, co Twój monitoring i tak wychwytuje o 3 w nocy i dostarcza na telefon z włączonym trybem Nie przeszkadzać.

## Czego naprawdę wymagają zegary raportowania

**Trzy reżimy, trzy różne momenty startu — i wszystkie odmierzają czas rzeczywisty.** Oto, co mówią obowiązujące teksty.

| Reżim | Pierwszy termin | Następnie | Na koniec |
| --- | --- | --- | --- |
| **DORA** (podmioty finansowe w UE) | Zgłoszenie wstępne w ciągu **4 godzin** od zaklasyfikowania incydentu jako poważnego i nie później niż **24 godziny** od powzięcia o nim wiedzy | Raport pośredni najpóźniej **72 godziny** po zgłoszeniu wstępnym | Raport końcowy nie później niż **miesiąc** po (ostatnim) raporcie pośrednim |
| **NIS2** (podmioty kluczowe i ważne w UE) | Wczesne ostrzeżenie bez zbędnej zwłoki, a w każdym razie w ciągu **24 godzin** od powzięcia wiedzy o poważnym incydencie | Zgłoszenie incydentu w ciągu **72 godzin** od powzięcia wiedzy | Raport końcowy nie później niż **miesiąc** po zgłoszeniu incydentu |
| **SEC Item 1.05** (spółki giełdowe w USA) | Formularz 8-K co do zasady w ciągu **czterech dni roboczych** od uznania incydentu za istotny | — | — |

Terminy z DORA wynikają z rozporządzenia delegowanego Komisji (UE) 2025/301 — regulacyjnego standardu technicznego dotyczącego treści i terminów zgłoszeń, opublikowanego 20 lutego 2025 roku i uzupełniającego [rozporządzenie (UE) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) ([Komisja Europejska](https://finance.ec.europa.eu/regulation-and-supervision/financial-services-legislation/implementing-and-delegated-acts/digital-operational-resilience-regulation_en), [tekst artykułu 5](https://www.springlex.eu/en/packages/dora/rts-ir-regulation/article-5/)). Sama DORA jest stosowana od 17 stycznia 2025 roku ([ESMA](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora)).

Terminy z NIS2 znajdują się w art. 23 ust. 4 [dyrektywy (UE) 2022/2555](https://eur-lex.europa.eu/eli/dir/2022/2555/oj); państwa członkowskie miały ją transponować do 17 października 2024 roku ([Komisja Europejska](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive)). Termin SEC wynika z zasad ujawniania informacji o cyberbezpieczeństwie przyjętych 26 lipca 2023 roku ([SEC](https://www.sec.gov/newsroom/press-releases/2023-139)).

## Dlaczego termin zgłoszenia to tak naprawdę problem z obudzeniem ludzi

**Bo żaden z tych zegarów nie jest przywiązany do Twoich godzin pracy.** DORA liczy czas od klasyfikacji i od powzięcia wiedzy przez podmiot. NIS2 liczy od powzięcia wiedzy przez podmiot. SEC liczy od stwierdzenia istotności. To, czy dany moment liczy się jako „powzięcie wiedzy", jest oceną prawną, którą wydaje Twój dział compliance — ale żaden z tych tekstów nie resetuje zegara dlatego, że pierwsza osoba, która zobaczyła alert, akurat spała.

Policz to od końca na najciaśniejszej ścieżce z DORA. Masz 4 godziny od chwili zaklasyfikowania incydentu jako poważnego, a klasyfikacja nie nastąpi, zanim spojrzy na niego człowiek. Jeśli wykrycie następuje o 02:40, nikt nie potwierdza alertu do 08:00, a klasyfikacja zajmuje kolejne 90 minut analizy, zgłoszenie wstępne wysyłasz około 11:00 — mieścisz się w zewnętrznym limicie 24 godzin, ale ponad osiem godzin z tego pułapu poszło wyłącznie na sen. Skróć lukę potwierdzenia, a każdy kolejny krok zyska oddech.

To nie jest argument za alertowaniem o większej liczbie rzeczy. To argument za tym, aby jedna wąska klasa alertów — te, które realnie mogą stać się podlegające zgłoszeniu — była fizycznie niemożliwa do przespania. Cała reszta powinna pozostać cicha. (Jeśli Twój zespół już się w tym topi, zacznij od [walki ze zmęczeniem alertami](/pl/blog/fix-alert-fatigue-developer-guide), zanim dołożysz głośniejszy kanał.)

## Czy weekend daje dodatkowy czas?

**Trochę, w ramach DORA — i całkiem możliwe, że akurat nie Tobie.** Rozporządzenie delegowane (UE) 2025/301 pozwala podmiotowi finansowemu, którego termin przypada w weekend albo w dzień ustawowo wolny w jego państwie członkowskim, złożyć zgłoszenie do południa następnego dnia roboczego. Ale ten sam przepis odbiera to udogodnienie instytucjom kredytowym, kontrahentom centralnym i operatorom systemów obrotu, a także podmiotom kluczowym i ważnym w rozumieniu NIS2. Właściwe organy mogą je odebrać również innym podmiotom o znaczeniu systemowym ([artykuł 5](https://www.springlex.eu/en/packages/dora/rts-ir-regulation/article-5/), [podsumowanie Advisera](https://advisera.com/cdr-2025-301/time-limits-for-the-initial-notification-and-for-the-intermediate-and-final-reports/)).

Organizacje najbardziej narażone na niedzielny nocny incydent to więc dokładnie te, które nie dostają weekendowej ulgi. Artykuł 23 NIS2 w ogóle nie przewiduje przedłużenia weekendowego. Planuj tak, jakby zegar w sobotę biegł dokładnie tak samo jak we wtorek, a ewentualne przedłużenie traktuj jako bonus, a nie zapas.

## Jak postawić dzwoniący telefon przed procesem raportowania

Echobell robi jedną rzecz: zamienia webhook lub e-mail w połączenie telefoniczne — prawdziwe, dzwoniące i wibrujące połączenie, które przebija się przez tryb Skupienia w iOS i tryb Nie przeszkadzać tak jak telefon od kogoś z rodziny (zobacz [omijanie trybu Skupienia w iOS przy krytycznych alertach](/pl/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)). Staje między systemem, który wykrywa incydent, a człowiekiem, który musi uruchomić zegar.

### Krok 1 — utwórz kanał Calling zarezerwowany dla incydentów podlegających zgłoszeniu

Utwórz kanał w Echobell i ustaw jego typ powiadomienia na **Calling**. To on sprawia, że telefon dzwoni, zamiast dostarczyć ciche powiadomienie ([typy powiadomień](/pl/docs/notification)). Nadaj mu nazwę nieznoszącą wątpliwości — „Incydent do zgłoszenia — pobudka" — i nie używaj go do niczego innego. Skopiuj adres URL webhooka ze szczegółów kanału; wygląda on tak: `https://hook.echobell.one/t/<channel-token>`. Traktuj go jak sekret.

### Krok 2 — skieruj swój system wykrywania na ten webhook

Cokolwiek zauważy incydent, wysyła żądanie HTTP na adres URL kanału. Echobell ma gotowe przewodniki dla [Grafany](/pl/docs/developer/grafana), [Prometheus Alertmanagera](/pl/docs/developer/prometheus), [Uptime Kuma](/pl/docs/developer/uptime-kuma) i [UptimeRobot](/pl/docs/developer/uptimerobot); wszystko inne, co potrafi wysłać JSON metodą POST, obsłużysz według [przewodnika po webhookach](/pl/docs/webhook). Przydatny payload niesie tyle informacji, by podjąć wstępną decyzję klasyfikacyjną bez otwierania laptopa:

```json
{
  "title": "Reportable candidate: {{service}}",
  "message": "{{service}} down since {{started_at}} — client-facing: {{client_impact}}",
  "externalLink": "https://status.internal.example/incident/{{id}}"
}
```

Zmienna `externalLink` staje się klikalnym odnośnikiem we wpisie powiadomienia, więc osoba, która odbierze połączenie, trafia prosto do incydentu.

### Krok 3 — użyj warunków, aby dzwoniły tylko realne kandydatury

**Połączenie telefoniczne wywoływane przez każde ostrzeżenie przestaje być połączeniem, a staje się szumem tła.** [Warunki](/pl/docs/conditions) w Echobell filtrują po wartościach zmiennych z logiką AND/OR, więc możesz wymagać na przykład `severity == "critical"` **oraz** `client_impact == true`, zanim kanał do kogokolwiek zadzwoni. Wszystko poniżej tej poprzeczki kieruj do osobnego kanału Time-Sensitive lub Normal. Kanał incydentów podlegających zgłoszeniu powinien dzwonić kilka razy w roku, a nie co tydzień.

### Krok 4 — obejmij systemy, które wysyłają tylko e-maile

Wiele kanałów statusu dostawców, narzędzi do monitorowania nadużyć i podmiotów zewnętrznych powiadamia wyłącznie pocztą — a to ma znaczenie w DORA, gdzie awarie po stronie dostawców są wprost objęte przepisami. Każdy kanał Echobell może mieć własny adres, więc reguła przekazywania zamieni takie wiadomości w połączenia ([wyzwalacze e-mail](/pl/docs/email-trigger), [konfiguracja e-mail na połączenie](/pl/docs/email-to-call)).

### Krok 5 — dodaj do kanału osoby odpowiedzialne za terminy

Inżynieria wykrywa incydent; termin jest na głowie działu compliance, oficera dyżurnego albo inspektora ochrony danych. Udostępnij kanał, a każda osoba subskrybująca wybierze własny poziom pilności: inżynier na dyżurze dostanie połączenie, a druga osoba w kolejce alert czasowo krytyczny. Włącz **ponawianie nieudanych połączeń**, aby połączenie zablokowane przez tryb Skupienia zostało powtórzone.

### Krok 6 — przetestuj przy włączonym trybie Nie przeszkadzać

Co najmniej raz na kwartał wyślij testowy webhook przy włączonym trybie Nie przeszkadzać na każdym istotnym telefonie. Nieprzetestowana ścieżka eskalacji to założenie, a z założeń powstają analizy poincydentalne.

## Czego Echobell nie robi

Precyzja jest tu ważniejsza niż gdziekolwiek indziej, bo mowa o procesie regulowanym.

**Echobell:** zamienia webhook lub e-mail w dzwoniące połączenie, alert czasowo krytyczny albo zwykłe powiadomienie push; przebija się przez tryb Skupienia w iOS i tryb Nie przeszkadzać przy alertach Calling; filtruje warunkami i szablonami; dostarcza ten sam alert do współdzielonego kanału zespołu.

**Echobell nie:**

- **Nie klasyfikuje incydentów.** Nie ma zdania na temat tego, czy coś jest „poważne" w rozumieniu DORA, „istotne" w rozumieniu NIS2 czy „materialne" według zasad SEC. To oceny podejmowane przez ludzi na podstawie kryteriów z odpowiednich przepisów.
- **Nie składa niczego nigdzie.** Nie wysyła zgłoszeń do właściwego organu, do CSIRT-u ani do SEC. Doprowadza człowieka do momentu, w którym może to zrobić.
- **Nie jest Twoim systemem dokumentacji ani GRC.** Te reżimy wymagają dokumentacji, rejestrów i dowodów, których aplikacja alertująca nie wytwarza. Echobell celowo przechowuje treść i historię powiadomień wyłącznie na Twoim urządzeniu, a na serwerze trzyma tylko konta, kanały i subskrypcje ([model prywatności](/pl/docs/features)) — świetnie dla minimalizacji danych, bezużytecznie jako ślad audytowy.
- **Nie ma poświadczenia zgodności.** Nie towarzyszy mu żaden certyfikat, raport z audytu ani umowna SLA. Jeśli wprowadzasz go do regulowanego procesu, przeprowadź go przez własny proces zarządzania ryzykiem dostawców ICT jak każde inne narzędzie i utrzymuj kanał, który od niego nie zależy.
- **Nie gwarantuje dostarczenia.** Połączenie zależy od infrastruktury push, sieci i naładowanego telefonu. Traktuj je jako warstwę, która radykalnie skraca czas potwierdzenia alertu, a nie jako mechanizm kontrolny, który pokażesz w audycie.

Uczciwe postawienie sprawy: Twój obowiązek regulacyjny nie zmienia się od tego, która aplikacja dzwoni na Twój telefon. Połączenie zmienia liczbę godzin między tym, co zauważy maszyna, a decyzją człowieka — a przy czterogodzinnym zegarze te godziny to niemal cały budżet.

## FAQ

### Czy używanie Echobell czyni nas zgodnymi z DORA lub NIS2?

Nie. Zgodność zależy od Twojego ładu korporacyjnego, procesu klasyfikacji, dokumentacji i faktycznych zgłoszeń do właściwego organu lub CSIRT-u. Echobell skraca jedynie odstęp między wykryciem a potwierdzeniem przez człowieka. To jeden z elementów procesu, a nie sam proces.

### Kiedy dokładnie rusza czterogodzinny zegar z DORA?

Przy klasyfikacji. Zgodnie z rozporządzeniem delegowanym (UE) 2025/301 zgłoszenie wstępne należy złożyć w ciągu czterech godzin od zaklasyfikowania incydentu jako poważnego, a w każdym razie nie później niż 24 godziny od chwili powzięcia o nim wiedzy przez podmiot. To dwa odrębne ograniczenia i trzeba spełnić oba — dlatego szybka decyzja klasyfikacyjna liczy się tak samo jak szybki alert.

### Czy wczesne ostrzeżenie z NIS2 musi zawierać pełne szczegóły incydentu?

Nie. Artykuł 23 ust. 4 dyrektywy (UE) 2022/2555 celowo czyni 24-godzinne wczesne ostrzeżenie wstępnym: chodzi o to, czy incydent jest podejrzewany o bezprawne lub złośliwe pochodzenie oraz czy może mieć skutki transgraniczne. Pełniejszy obraz jest wymagany w zgłoszeniu po 72 godzinach, a analiza przyczyn źródłowych — w raporcie końcowym miesiąc później.

### Nasz monitoring i tak wysyła e-mail do inżyniera na dyżurze. Czy to nie wystarczy?

Wystarczy, gdy ktoś nie śpi i patrzy. E-maile i standardowe powiadomienia push są wyciszane przez tryby Skupienia, tryb Nie przeszkadzać i harmonogramy snu — czyli dokładnie w tych warunkach, w nocy i w weekend, gdy zegar jest najmniej wyrozumiały. Luka nie jest w wykrywaniu, tylko w potwierdzeniu.

### Czy compliance i inżynieria mogą dostać ten sam alert?

Tak. Udostępnij kanał, a każda subskrybująca osoba otrzyma to samo wyzwolenie i wybierze własny typ powiadomienia. Typowy układ: inżynier na dyżurze subskrybuje jako Calling, a dyżurny oficer compliance jako Calling dla kanału incydentów podlegających zgłoszeniu i Time-Sensitive dla wszystkiego innego.

### Czy połączenie naprawdę przebije się przez tryb Nie przeszkadzać?

Typ powiadomienia Calling w Echobell jest pomyślany tak, aby dzwonić mimo trybu Skupienia w iOS i trybu Nie przeszkadzać, a ustawienie ponawiania nieudanych połączeń powtarza próby zablokowane przez tryb Skupienia. Zanim na tym polegniesz, sprawdź to na faktycznym urządzeniu każdej osoby dyżurującej — ustawienia i wersje systemu bywają różne.

### Czy to działa tylko na iOS?

Nie. Echobell jest dostępny na iOS oraz na Androidzie w Google Play (zobacz [ogłoszenie o premierze na Androida](/pl/blog/echobell-android-release)). Zachowanie alertów w formie połączenia różni się między platformami, więc testuj na urządzeniach, które osoby dyżurujące faktycznie noszą przy sobie.

### Jakie dane umieszczać w payloadzie webhooka?

Jak najmniej. Wysyłaj identyfikator i odnośnik zamiast danych klientów czy szczegółów incydentu — użyj zmiennej `externalLink`, aby wskazać wpis incydentu w systemie zbudowanym do przechowywania takich informacji. Zadaniem alertu jest kogoś obudzić, a nie zrobić mu odprawę.

---

## Powiązane

- [Awarie chmury to nowa normalność: jak mimo to dostawać alerty](/pl/blog/cloud-outage-alerts)
- [Alerty telefoniczne, gdy Twoje API przestaje odpowiadać](/pl/blog/phone-call-alerts-api-downtime)
- [Koniec życia Opsgenie: wyłączenie w 2027 roku i alternatywy](/pl/blog/opsgenie-end-of-life-alternatives)
- [Jak omijać tryb Skupienia w iOS przy krytycznych alertach](/pl/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)
- [Przewodnik po integracji przez webhooki](/pl/docs/webhook)
- [Przewodnik po warunkach](/pl/docs/conditions)