---
title: "Zegar 24 godzin z CRA rusza 11 września 2026: zadbaj, by ktoś odebrał"
description: "Od 11 września 2026 unijny Cyber Resilience Act daje producentom 24 godziny na wczesne ostrzeżenie — w przeglądarce, bez API do zgłoszeń. Oto jak zamienić ten wyzwalacz w połączenie telefoniczne z Echobell i czego głośniejszy alert wciąż nie naprawi."
date: 2026-08-21
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - Cyber Resilience Act
  - raportowanie CRA
  - zgłaszanie incydentów
  - ujawnianie podatności
  - alerty telefoniczne
---

# Spraw, by 24-godzinne wczesne ostrzeżenie z CRA zadzwoniło, zanim skończy się czas

**11 września 2026** zaczynają obowiązywać obowiązki raportowe unijnego Cyber Resilience Act. Od tego dnia producent, który dowie się o aktywnie wykorzystywanej podatności w produkcie z elementami cyfrowymi — albo o poważnym incydencie dotyczącym takiego produktu — ma **24 godziny** na wysłanie wczesnego ostrzeżenia do koordynującego CSIRT-u i do ENISA ([Komisja Europejska](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting), [rozporządzenie (UE) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng)).

Ten termin ma cechę, której większość terminów zgodnościowych nie ma: liczy się według zegara ściennego. Nie ma wyłączenia dla dni roboczych, nie ma pauzy na weekend ani okresu przejściowego, gdy osoba odpowiedzialna za zgłoszenia akurat leci samolotem. A platforma, przez którą się zgłasza — Single Reporting Platform prowadzona przez ENISA — to formularz internetowy, bo „na tym etapie nie zostaną udostępnione żadne interfejsy programistyczne (API)” ([FAQ ENISA](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions)). Zalogować się i wysłać zgłoszenie musi konkretna, wskazana z imienia osoba.

To sprawia, że zasada 24 godzin jest problemem alertowania, zanim stanie się problemem papierkowej roboty. Ten przewodnik pokazuje, jak skierować moment powzięcia wiedzy na dzwoniący telefon przy użyciu [Echobell](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-cra-24-hour-reporting-alerts-pl&mt=8), i uczciwie mówi o tej dużej części przygotowań do CRA, której żadne narzędzie do powiadomień nie dotyka.

## Co dokładnie zaczyna się 11 września 2026?

**Producenci produktów z elementami cyfrowymi muszą zgłaszać aktywnie wykorzystywane podatności i poważne incydenty przez jedną unijną platformę, według etapowego harmonogramu liczonego od chwili powzięcia wiedzy.** Cała reszta CRA — oznakowanie CE, wymagania zasadnicze z załącznika I, ocena zgodności — obowiązuje od 11 grudnia 2027. Raportowanie wchodzi piętnaście miesięcy wcześniej i dotyczy produktów już obecnych na rynku, a nie tylko tego, co wprowadzisz po tej dacie ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/reporting.html)).

Artykuł 14 definiuje dwie równoległe ścieżki o tym samym kształcie:

| Etap | Aktywnie wykorzystywana podatność — art. 14 ust. 2 | Poważny incydent — art. 14 ust. 4 |
| --- | --- | --- |
| Wczesne ostrzeżenie | W ciągu **24 godzin** od powzięcia wiedzy | W ciągu **24 godzin** od powzięcia wiedzy |
| Zgłoszenie | W ciągu **72 godzin** od powzięcia wiedzy | W ciągu **72 godzin** od powzięcia wiedzy |
| Raport końcowy | Nie później niż **14 dni** po udostępnieniu środka naprawczego lub łagodzącego | W ciągu **miesiąca** od zgłoszenia 72-godzinnego |

Przepis mówi „bez zbędnej zwłoki, a w każdym razie w ciągu 24 godzin od powzięcia przez producenta wiedzy o niej” ([artykuł 14](https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_14.html)). Dwadzieścia cztery godziny to górna granica, a nie cel.

Artykuł 14 ust. 5 wyznacza próg „poważnego” incydentu: kwalifikuje się on, gdy negatywnie wpływa lub może negatywnie wpłynąć na zdolność produktu do ochrony dostępności, autentyczności, integralności lub poufności wrażliwych albo istotnych danych lub funkcji, albo gdy doprowadził lub może doprowadzić do wprowadzenia bądź wykonania złośliwego kodu. Sformułowanie „może” ma znaczenie — obowiązek zgłoszenia może powstać, zanim cokolwiek naprawdę wydarzy się po stronie klienta.

Artykuł 14 ust. 8 dokłada drugi obowiązek biegnący równolegle: musisz również poinformować użytkowników dotkniętych produktem o podatności lub incydencie, a w razie potrzeby o środkach naprawczych, które mogą podjąć. To odrębny odbiorca niż CSIRT i osobna ścieżka.

## Kogo to naprawdę dotyczy?

**Producentów produktów z elementami cyfrowymi, niezależnie od miejsca siedziby, a w węższym zakresie także opiekunów oprogramowania open source.** Firma spoza UE sprzedająca na rynek unijny nie uniknie tego obowiązku; rozporządzenie oczekuje, że za odpowiednie obowiązki odpowie podmiot gospodarczy w UE ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/explained.html)).

Zgłaszasz do CSIRT-u wyznaczonego jako koordynator w państwie członkowskim, w którym masz główne miejsce prowadzenia działalności w Unii, oraz jednocześnie do ENISA — ale wysyłasz zgłoszenie **raz**, przez Single Reporting Platform, która kieruje je do obu adresatów ([Komisja Europejska](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)).

Opiekunowie oprogramowania open source są objęci określonym podzbiorem obowiązków: art. 14 ust. 1 stosuje się w zakresie, w jakim uczestniczą w tworzeniu produktów z elementami cyfrowymi, a art. 14 ust. 3 i 8 — w zakresie, w jakim poważne incydenty dotyczą sieci i systemów informatycznych udostępnianych przez nich na potrzeby tego tworzenia. Jeśli opiekujesz się szeroko używanym projektem, przeczytaj art. 24 razem z art. 14, zamiast zakładać którąkolwiek skrajność.

Artykuł 15 dopuszcza też zgłoszenia dobrowolne — podatności, cyberzagrożeń, incydentów i zdarzeń o mało brakujących skutkach — zarówno przez producentów, jak i przez kogokolwiek innego. Dobrowolne zgłoszenia nie tworzą nowych obowiązków, ale dotyczy ich ta sama platforma i ten sam problem „ktoś musi nie spać”.

## Dlaczego termin 24 godzin to problem alertowania?

**Bo zegar rusza w chwili powzięcia wiedzy, a wiedza rzadko przychodzi w godzinach pracy.** Wyzwalaczem jest fakt docierający do organizacji, a nie decyzja, którą organizacja podejmuje.

Zobacz, skąd zwykle bierze się ten fakt. Badacz bezpieczeństwa pisze na `security@` o 23:40 w sobotę. Klient z dalszej części łańcucha zakłada zgłoszenie serwisowe opisujące wykorzystanie podatności. Kanał CVE albo KEV zapala się przy komponencie, który dostarczasz. Twój własny EDR sygnalizuje wykonanie kodu w systemie budowania. Analiza gotowości przygotowana przez DLA Piper wprost wskazuje wariant łańcucha dostaw: producenci często nie dowiadują się pierwsi, a informacje docierają przez importerów, dystrybutorów, badaczy albo dostawców komponentów ([DLA Piper](https://www.dlapiper.com/en-us/insights/publications/2026/08/the-cras-24-hour-rule-preparing-for-the-cyber-resilience-acts-september-2026-reporting-obligations)).

Każda z tych dróg kończy się powiadomieniem, które Twoja obecna konfiguracja dostarcza zapewne po cichu — e-mailem we wspólnej skrzynce, wiadomością na kanale Slacka, którego nocą nikt nie ogląda, zgłoszeniem w kolejce segregowanej w poniedziałek. Żadne z nich nie zawodzi. Dostarczają poprawnie — nikomu.

Trzy szczegóły pogłębiają tę lukę bardziej, niż się wydaje:

- **Nie ma API.** ENISA jasno stwierdza, że na tym etapie nie udostępni interfejsów programistycznych do zgłoszeń. Żaden skrypt nie wyśle za Ciebie wczesnego ostrzeżenia, gdy wszyscy śpią.
- **Dostęp konfiguruje się z góry i dla konkretnych osób.** Upoważnieni przedstawiciele rejestrują się kontem EU Login, a wyznaczony CSIRT koordynujący potwierdza ich umocowanie po pierwszym dostępie. Jest przedstawiciel główny i zapasowy, a zaproszenie dla zapasowego wygasa po siedmiu dniach ([FAQ ENISA](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions), [cyberresilienceact.eu](https://www.cyberresilienceact.eu/news/enisa-srp-step-by-step-instructions-31-july-2026.html)). Jeśli jedyna osoba, która może wysłać zgłoszenie, jest nieosiągalna, termin i tak biegnie.
- **Kary są z górnego przedziału.** Artykuł 64 umieszcza naruszenie obowiązków z art. 13 i 14 w przedziale administracyjnych kar pieniężnych „do 15 000 000 EUR lub, w przypadku przedsiębiorstwa, do 2,5% jego łącznego rocznego światowego obrotu za poprzedni rok obrotowy, w zależności od tego, która z tych kwot jest wyższa” ([artykuł 64](https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_64.html)).

Jedno uczciwe zastrzeżenie do ostatniego punktu, bo zmienia rachunek dla małych zespołów: art. 64 wyłącza producentów będących mikroprzedsiębiorstwami lub małymi przedsiębiorstwami z administracyjnych kar pieniężnych **za niedotrzymanie terminu** z art. 14 ust. 2 lit. a) lub art. 14 ust. 4 lit. a) — czyli akurat 24-godzinnego wczesnego ostrzeżenia. Obowiązek zgłoszenia pozostaje, a wyłączenie nie obejmuje zgłoszenia 72-godzinnego ani reszty art. 14. Przeczytaj przepis i zasięgnij porady, zamiast wierzyć wpisowi na blogu w kwestii tego, gdzie plasuje się Twoja firma.

## Co właściwie zawiera 24-godzinne wczesne ostrzeżenie?

**Bardzo niewiele — i o to chodzi.** Wytyczne ENISA opisują niewielki zestaw pól obowiązkowych na etapie wczesnego ostrzeżenia: typ zgłoszenia (podatność albo incydent), poziom zgłoszenia, czas zgłoszenia, dane zgłaszającego, nazwę producenta lub opiekuna, produkt, tytuł, a przy incydentach informację, czy podejrzewa się działania bezprawne bądź złośliwe. Pola opcjonalne na tym etapie obejmują identyfikator CVE albo EUVD.

Pełniejszy obraz techniczny — ogólny charakter podatności lub sposobu jej wykorzystania, wstępna ocena, środki naprawcze i łagodzące — należy do zgłoszenia 72-godzinnego, a nie do pierwszych 24 godzin.

Wczesne ostrzeżenie nie jest więc projektem badawczym. To krótki formularz, który przygotowana osoba wypełni w kilka minut. Wąskim gardłem nie jest formularz. Jest nim to, czy osoba zarejestrowana, upoważniona i przytomna dowie się na czas. A to problem routingu powiadomień, który da się rozwiązać już dziś.

## Jak postawić dzwoniący telefon przed 24-godzinnym zegarem?

Echobell zamienia wywołanie webhooka albo e-mail w alert, który dzwoni i wibruje jak połączenie przychodzące — dlatego przebija się przez tryb Skupienia i Nie przeszkadzać w iOS (zobacz [omijanie trybu Skupienia w iOS](/pl/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)). Poniższa konfiguracja działa obok Twojego obecnego systemu zgłoszeń i procesu PSIRT — nie zastępuje ich.

### Krok 1 — utwórz kanał typu połączenie zarezerwowany dla kandydatów do zgłoszenia CRA

W aplikacji utwórz kanał i ustaw typ powiadomień na **połączenie** ([typy powiadomień](/pl/docs/notification)). Nazwij go od decyzji, którą wyzwala, a nie od źródła danych: „CRA — mógł ruszyć zegar 24h” jest lepsze niż „Alerty bezpieczeństwa”.

Ten kanał musi pozostać cichy. Jeśli będzie dzwonił przy każdym biuletynie, każdym nieudanym skanie i każdej aktualizacji zależności, ludzie przestaną odbierać, a Ty zmarnujesz swój jedyny głośny kanał na szum. Resztę kieruj gdzie indziej — podział opisuje [przewodnik po zmęczeniu alertami](/pl/blog/fix-alert-fatigue-developer-guide).

Skopiuj adres URL webhooka kanału z jego szczegółów; wygląda tak: `https://hook.echobell.one/t/<channel-token>`. Traktuj go jak sekret, bo każdy, kto go ma, może rozdzwonić telefony Twojego zespołu ([przewodnik po webhookach](/pl/docs/webhook)).

Ustaw szablony czytelne z ekranu blokady o 2:00 dla osoby na wpół przytomnej:

```
Title: Possible CRA report — {{product}}
Body: {{kind}} — {{summary}} (aware since {{time}} UTC)
```

`{{time}}`, `{{date}}`, `{{hour}}` i pozostałe [systemowe zmienne czasu](/pl/docs/template) są zawsze wstrzykiwane w UTC, więc powiadomienie zapisuje znacznik czasu nawet wtedy, gdy nadawca o nim zapomniał. Ten znacznik nie jest prawnym dowodem na moment powzięcia wiedzy, ale przydaje się jako punkt odniesienia, gdy później odtwarzasz oś czasu.

### Krok 2 — skieruj ścieżki wykrywania na ten kanał

Kanał może wywołać każdy system potrafiący odpytać webhook. Wysyłane pola stają się zmiennymi szablonu:

```bash
curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "actively exploited vulnerability",
    "summary": "researcher report, working exploit attached",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'
```

Specjalna zmienna `externalLink` zamienia się w klikalny odnośnik w zapisie powiadomienia, więc odebranie połączenia dzieli osobę reagującą jedno dotknięcie od zgłoszenia ze szczegółami.

Warto podpiąć następujące źródła, mniej więcej w kolejności tego, jak często są pierwszym sygnałem:

- **Twoją kolejkę PSIRT lub wejściową kolejkę bezpieczeństwa** — webhook w chwili oznaczenia zgłoszenia jako kandydata do CRA.
- **Zalecenia bezpieczeństwa GitHuba i alerty Dependabota** w repozytoriach budujących dostarczane produkty ([integracja z GitHubem](/pl/docs/developer/github)).
- **Twój SIEM, EDR albo WAF** przy wykryciach dotyczących infrastruktury budowania, wydawania lub podpisywania — art. 14 ust. 5 wprost obejmuje incydenty mogące prowadzić do wprowadzenia złośliwego kodu.
- **Kanały informacji o podatnościach**, z których już korzystasz, przefiltrowane do komponentów występujących w Twoich zestawieniach SBOM.

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

**To krok, który utrzymuje wiarygodność kanału.** [Warunki](/pl/docs/conditions) w Echobell operują na tych samych zmiennych i nagłówkach HTTP co szablony, a kanał uruchamia się tylko wtedy, gdy wyrażenie jest prawdziwe:

```
craCandidate == true && confirmed == true
```

Albo oprzyj je na nagłówku, jeśli system wysyłający nie może zmienić treści żądania:

```
header["x-cra-severity"] == "reportable"
```

Ustaw próg na poziomie „kompetentna osoba powinna spojrzeć na to w ciągu godziny”, a nie „to na pewno podlega zgłoszeniu”. Ocena, czy art. 14 ma zastosowanie, jest decyzją wymagającą człowieka znającego fakty; zadaniem kanału jest szybko doprowadzić tego człowieka do faktów. Kosztownym błędem jest tu nadmierne filtrowanie, bo zgłoszenie, którego nigdy nie zacząłeś, jest gorsze niż niepotrzebny telefon.

### Krok 4 — obsłuż systemy wysyłające wyłącznie e-maile

Większość pierwszych kontaktów spoza firmy przychodzi e-mailem — od badacza, klienta, krajowego CSIRT-u, dostawcy komponentu. Każdy kanał Echobell może mieć własny adres, więc jedna reguła przekazywania na `security@` zamienia te wiadomości w połączenia ([wyzwalacze e-mail](/pl/docs/email-trigger)).

Wyzwalacze e-mail udostępniają jako zmienne `from`, `to`, `subject`, `text` i `html`, więc filtrujesz bez parsowania czegokolwiek:

```
subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")
```

Poproś stałych zgłaszających i kluczowych dostawców o używanie ustalonego znacznika w temacie, a potem dopasowuj się do niego. To drobiazg umowny, który zamienia nieustrukturyzowaną skrzynkę w sygnał nadający się do routingu.

### Krok 5 — dopisz do kanału każdego zarejestrowanego przedstawiciela

Udostępnij kanał wszystkim, którzy faktycznie mogą wysłać zgłoszenie: głównemu upoważnionemu przedstawicielowi, jego zapasowemu zastępcy oraz osobie kierującej bezpieczeństwem, która podejmie decyzję w sprawie art. 14. Każdy subskrybent wybiera własny typ powiadomień, więc osoba na dyżurze może mieć ustawione **połączenie**, a reszta grupy — **czasowo krytyczne**.

O to właśnie w tym wszystkim chodzi. SRP wymaga zarejestrowanego, zweryfikowanego człowieka. Jeśli w Twojej firmie zarejestrowana jest dokładnie jedna osoba, Twój 24-godzinny termin ma pojedynczy punkt awarii z baterią w telefonie.

### Krok 6 — przećwicz przed 11 września, a nie po

Dwie próby, obie warte przeprowadzenia jeszcze w tym miesiącu:

1. **Ścieżka alertu.** Wywołaj powyższe polecenie `curl` przy naprawdę włączonym trybie Nie przeszkadzać, na telefonie, który faktycznie będzie leżał komuś na szafce nocnej. Włącz w aplikacji **ponawianie nieudanych połączeń**, aby połączenie, które raz się nie uda, zostało ponowione. Nieprzetestowana ścieżka eskalacji to założenie.
2. **Ścieżka zgłoszenia.** Przejdź zgłoszenie na sucho, korzystając z instrukcji rejestracji i wysyłki ENISA krok po kroku, aktualizowanych do sierpnia 2026 ([ENISA SRP](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp)). Załóż teraz konta EU Login, ustal, który CSIRT jest Twoim koordynatorem, i wcześnie wyślij zaproszenie dla przedstawiciela zapasowego — wygasa po siedmiu dniach.

Druga próba ma haczyk, o którym warto wiedzieć: według lipcowych wytycznych ENISA publiczny adres platformy wciąż figurował jako „zostanie podany przy uruchomieniu”, więc pełne testy od początku do końca nie były jeszcze możliwe ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/news/enisa-srp-step-by-step-instructions-31-july-2026.html)). ENISA zadeklarowała, że platforma będzie działać do 11 września 2026. Przećwicz wszystko, na co masz wpływ, i nie traktuj gotowości platformy jako powodu do odkładania własnej.

## Czego Echobell nie robi

Precyzja ma tu większe znaczenie niż zwykle, bo temat jest regulacyjny:

- **Nie zapewnia zgodności z przepisami.** Echobell jest kanałem powiadomień. Określenie zakresu produktów, prowadzenie procesu obsługi podatności, decyzja o zastosowaniu art. 14, rejestracja w SRP i terminowe zgłoszenie należą do Ciebie. Żadne narzędzie alertujące nigdy nie wypełniło obowiązku sprawozdawczego.
- **Niczego nie zgłasza.** Nie ma API, przez które można by zgłaszać, a gdyby było, to nie Echobell by je wywoływało. Ono dzwoni na telefon; resztę robi zarejestrowany człowiek.
- **Nie jest prawnym znacznikiem czasu.** Zmienna `{{time}}` zapisuje moment, w którym wyzwalacz dotarł do Echobell, w UTC. To, kiedy zaczęło się „powzięcie wiedzy”, jest kwestią faktów po stronie Twojej organizacji, a dokumentuje ją Twój rejestr incydentów, a nie powiadomienie push.
- **Nie ma polityk eskalacji ani potwierdzeń.** Nie istnieje „jeśli nikt nie odbierze w dziesięć minut, zadzwoń do kolejnej osoby”, nie ma rotacji dyżurów ani śladu audytowego, kto co potwierdził. Do tego potrzebujesz platformy incydentowej — zobacz [alternatywy dla Opsgenie](/pl/blog/opsgenie-end-of-life-alternatives).
- **Nie gwarantuje dostarczenia.** Połączenie zależy od infrastruktury push, sieci i naładowanego telefonu. Traktuj je jako warstwę skracającą czas między dotarciem faktu a wiedzą człowieka, a nie jako mechanizm kontrolny, który pokażesz podczas audytu.
- **Nie śledzi czasu lokalnego.** Wbudowane zmienne czasu działają wyłącznie w UTC i nie uwzględniają zmiany czasu. Warunki wyznaczające okno czasowe wymagają ręcznej korekty dwa razy w roku.

## FAQ

### Czy korzystanie z Echobell czyni nas zgodnymi z CRA?

Nie. CRA nakłada obowiązki na producentów i żadna aplikacja do powiadomień ich nie wypełni. Echobell adresuje jeden konkretny tryb awarii: przegapione 24-godzinne wczesne ostrzeżenie, bo osoba, która mogła je wysłać, dowiedziała się dopiero następnego dnia roboczego. To realny i częsty problem, ale stanowi jedynie fragment znacznie większego programu zgodności.

### Kiedy właściwie rusza zegar 24 godzin?

Gdy producent poweźmie wiedzę o aktywnie wykorzystywanej podatności albo o poważnym incydencie. Rozporządzenie nie definiuje dokładnego momentu, a powzięcie wiedzy zależy od faktów i od tego, jak szybko da się je ustalić ([DLA Piper](https://www.dlapiper.com/en-us/insights/publications/2026/08/the-cras-24-hour-rule-preparing-for-the-cyber-resilience-acts-september-2026-reporting-obligations)). W praktyce przemawia to za szybką i udokumentowaną segregacją zgłoszeń: im dłuższa przerwa między dotarciem sygnału a jego oceną, tym trudniej to później wytłumaczyć.

### Jesteśmy małą firmą. Czy jesteśmy zwolnieni?

Nie ze zgłaszania. Artykuł 64 wyłącza mikroprzedsiębiorstwa i małe przedsiębiorstwa z administracyjnych kar pieniężnych wyłącznie za niedotrzymanie 24-godzinnego terminu z art. 14 ust. 2 lit. a) lub art. 14 ust. 4 lit. a). Obowiązek zgłoszenia pozostaje, zgłoszenie 72-godzinne i raport końcowy są nienaruszone, a definicji mikroprzedsiębiorstwa i małego przedsiębiorstwa nie należy zakładać na wyczucie. Traktuj to jako wąskie złagodzenie, a nie przepustkę.

### Nasza skrzynka bezpieczeństwa jest obsługiwana w godzinach pracy. Czy to nie wystarczy?

Tylko jeśli godzisz się stracić nawet dwie trzecie okna w zwykły weekend. Zgłoszenie przychodzące w piątek o 18:00 zostawia Ci termin na sobotę do 18:00. Monitorowanie w godzinach pracy jest dobrym domyślnym rozwiązaniem dla wszystkiego innego; zegar 24 godzin to dokładnie ten przypadek, którego nie obejmuje.

### Czy zgodność, dział prawny i inżynieria mogą dostać ten sam alert?

Tak i powinny. Udostępnij jeden kanał, a wszyscy subskrybenci dostaną powiadomienie przy tym samym wyzwoleniu, każdy z własnym poziomem pilności. Inżynier potwierdzający wykorzystanie podatności i osoba, która wyśle formularz, muszą zacząć w tej samej minucie, a nie po kolei.

### Czy pomaga to w obowiązku informowania użytkowników z art. 14 ust. 8?

Pośrednio. Artykuł 14 ust. 8 wymaga poinformowania dotkniętych użytkowników o podatności lub incydencie i, w razie potrzeby, o środkach naprawczych. To komunikacja z klientami i wymaga Twoich własnych kanałów. Echobell może obudzić osoby odpowiedzialne za tę komunikację w tym samym momencie co osoby odpowiedzialne za zgłoszenie, więc oba nurty prac ruszą razem.

### Zgłaszamy już w ramach NIS2 albo DORA. Czy to to samo?

Nie, choć konstrukcje są podobne. NIS2 i DORA nakładają obowiązki na podmioty ze względu na sektor i krytyczność; CRA nakłada obowiązki na producentów ze względu na produkty wprowadzane na rynek UE. Jedna organizacja może podlegać wszystkim trzem reżimom, z różnymi zegarami i różnymi adresatami. Jeśli te reżimy również Cię dotyczą, zobacz [alerty o zgłaszaniu incydentów w DORA i NIS2](/pl/blog/dora-nis2-incident-reporting-alerts) — i zwróć uwagę, że warstwę alertowania można współdzielić nawet wtedy, gdy obowiązki są odrębne.

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

Powiadomienia typu połączenie są dostarczane jako alerty w formie rozmowy telefonicznej i właśnie to pozwala im przebić się przez tryb Skupienia w iOS. To nie magia: nadal zależy od ustawień systemu, sieci i naładowanego telefonu. Przetestuj to na docelowym urządzeniu, z faktycznie włączonym trybem Skupienia, zanim na tym polegniesz — i włącz **ponawianie nieudanych połączeń**.

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

Nie. Echobell jest dostępny na iOS oraz na [Androida przez Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid) ([wydanie 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ądzeniu, które osoba reagująca faktycznie będzie nosić.

### Co umieścić w payloadzie webhooka?

Minimum potrzebne do decyzji, czy wstawać: produkt, rodzaj sygnału, jedna linijka kontekstu i `externalLink` prowadzący do zgłoszenia ze szczegółami. Echobell trzyma treść i historię powiadomień na urządzeniu, a na serwerze wyłącznie konta, kanały i subskrypcje ([model prywatności](/pl/docs/features)), ale przy materiałach wrażliwych z obszaru bezpieczeństwa właściwym nawykiem i tak jest wysyłanie wskaźnika, a nie samej treści.

---

## Powiązane materiały

- [Alerty o zgłaszaniu incydentów w DORA i NIS2](/pl/blog/dora-nis2-incident-reporting-alerts)
- [Jak wyleczyć zmęczenie alertami](/pl/blog/fix-alert-fatigue-developer-guide)
- [Jak omijać tryb Skupienia w iOS przy krytycznych alertach](/pl/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)
- [Alternatywy po zakończeniu wsparcia Opsgenie](/pl/blog/opsgenie-end-of-life-alternatives)
- [Przewodnik po integracji z webhookami](/pl/docs/webhook)
- [Wyzwalacze e-mail](/pl/docs/email-trigger)
- [Przewodnik po warunkach](/pl/docs/conditions)