---
title: "Il conto alla rovescia di 24 ore del CRA parte l'11 settembre 2026: assicurati che qualcuno risponda"
description: "Dall'11 settembre 2026 il Cyber Resilience Act europeo dà ai fabbricanti 24 ore per inviare un'allerta precoce, da un browser e senza API di segnalazione. Ecco come trasformare quel trigger in una telefonata con Echobell, e che cosa un avviso più rumoroso non risolve comunque."
date: 2026-08-21
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - Cyber Resilience Act
  - segnalazioni CRA
  - segnalazione degli incidenti
  - divulgazione delle vulnerabilità
  - avvisi con chiamata
---

# Fai squillare un telefono per l'allerta precoce di 24 ore del CRA prima che scada il tempo

L'**11 settembre 2026** entrano in applicazione gli obblighi di segnalazione del Cyber Resilience Act europeo. Da quella data, un fabbricante che viene a conoscenza di una vulnerabilità attivamente sfruttata in un prodotto con elementi digitali — o di un incidente grave che ne colpisce uno — ha **24 ore** per inviare un'allerta precoce al proprio CSIRT coordinatore e all'ENISA ([Commissione europea](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting), [regolamento (UE) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng)).

Questa scadenza ha una caratteristica che quasi nessun'altra scadenza di conformità ha: corre su ore reali. Nessuna deroga per i giorni lavorativi, nessuna pausa nel fine settimana, nessuna tolleranza mentre chi è responsabile delle segnalazioni è su un aereo. E la piattaforma da cui si invia, la Single Reporting Platform dell'ENISA, è un modulo web: "in questa fase non sarà fornita alcuna interfaccia di programmazione" ([FAQ ENISA](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions)). Serve una persona designata che acceda e prema invio.

Questo fa della regola delle 24 ore un problema di allertamento prima ancora che di scartoffie. Questa guida mostra come portare il momento in cui vieni a conoscenza del fatto fino a un telefono che squilla, usando [Echobell](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-cra-24-hour-reporting-alerts-it&mt=8), ed è onesta sulla parte più grande della preparazione al CRA, quella che nessuno strumento di notifica può toccare.

## Che cosa comincia esattamente l'11 settembre 2026?

**I fabbricanti di prodotti con elementi digitali devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi attraverso un'unica piattaforma europea, seguendo un conto alla rovescia scaglionato che parte nel momento in cui ne vengono a conoscenza.** Tutto il resto del CRA — marcatura CE, requisiti essenziali dell'allegato I, valutazione della conformità — si applica dall'11 dicembre 2027. Gli obblighi di segnalazione arrivano quindici mesi prima e riguardano anche i prodotti già sul mercato, non solo quelli che immetterai dopo quella data ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/reporting.html)).

L'articolo 14 definisce due percorsi paralleli con la stessa struttura:

| Fase | Vulnerabilità attivamente sfruttata — art. 14(2) | Incidente grave — art. 14(4) |
| --- | --- | --- |
| Allerta precoce | Entro **24 ore** dalla presa di conoscenza | Entro **24 ore** dalla presa di conoscenza |
| Notifica | Entro **72 ore** dalla presa di conoscenza | Entro **72 ore** dalla presa di conoscenza |
| Relazione finale | Non oltre **14 giorni** da quando è disponibile una misura correttiva o di attenuazione | Entro **un mese** dalla notifica a 72 ore |

Il testo dice "senza indebito ritardo e in ogni caso entro 24 ore da quando il fabbricante ne è venuto a conoscenza" ([articolo 14](https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_14.html)). Ventiquattro ore sono il limite massimo, non l'obiettivo.

L'articolo 14(5) fissa l'asticella per "grave": un incidente lo è quando pregiudica, o è in grado di pregiudicare, la capacità del prodotto di proteggere la disponibilità, l'autenticità, l'integrità o la riservatezza di dati o funzioni sensibili o importanti, oppure quando ha portato o può portare all'introduzione o all'esecuzione di codice malevolo. Quel "è in grado di" pesa: puoi essere tenuto a segnalare prima che a un cliente sia successo davvero qualcosa.

L'articolo 14(8) aggiunge un secondo obbligo che corre in parallelo: devi informare anche gli utenti colpiti del prodotto della vulnerabilità o dell'incidente e, se necessario, delle misure correttive che possono adottare. È un destinatario diverso dal CSIRT, su un percorso tutto suo.

## Chi è davvero tenuto a farlo?

**I fabbricanti di prodotti con elementi digitali, ovunque siano stabiliti, più i gestori di software open source, in misura più circoscritta.** Un'azienda con sede fuori dall'UE che vende nell'Unione non sfugge all'obbligo: il regolamento si aspetta che sia un operatore economico nell'UE a rispondere degli obblighi rilevanti ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/explained.html)).

Segnali al CSIRT designato come coordinatore nello Stato membro in cui hai lo stabilimento principale nell'Unione e, contemporaneamente, all'ENISA — ma l'invio è **uno solo**, attraverso la Single Reporting Platform, che lo instrada a entrambi ([Commissione europea](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)).

I gestori di software open source rientrano in un sottoinsieme ben delimitato: l'obbligo dell'articolo 14(1) si applica nella misura in cui partecipano allo sviluppo di prodotti con elementi digitali, e l'articolo 14(3) e (8) si applicano nella misura in cui gli incidenti gravi riguardano i sistemi informatici e di rete che mettono a disposizione per quello sviluppo. Se gestisci un progetto molto diffuso, leggi l'articolo 24 insieme all'articolo 14, invece di dare per scontato uno dei due estremi.

L'articolo 15 consente inoltre le segnalazioni volontarie — di vulnerabilità, minacce informatiche, incidenti e quasi incidenti — da parte dei fabbricanti e di chiunque altro. Le segnalazioni volontarie non creano nuovi obblighi, ma passano dalla stessa piattaforma e portano con sé lo stesso problema: qualcuno deve essere sveglio.

## Perché una scadenza di 24 ore è un problema di allertamento?

**Perché il conto alla rovescia parte da quando vieni a conoscenza del fatto, e la conoscenza arriva raramente in orario d'ufficio.** Il trigger è un fatto che raggiunge la tua organizzazione, non una decisione che la tua organizzazione prende.

Guarda da dove arriva di solito quel fatto. Un ricercatore di sicurezza scrive a `security@` alle 23:40 di un sabato. Un cliente a valle apre un ticket in cui descrive uno sfruttamento in corso. Un feed CVE o KEV si accende su un componente che distribuisci. Il tuo EDR segnala l'esecuzione di codice in un sistema di build. L'analisi di DLA Piper sulla preparazione al regolamento evidenzia proprio la variante legata alla catena di fornitura: spesso i fabbricanti non sono i primi a saperlo, e le informazioni arrivano tramite importatori, distributori, ricercatori o fornitori di componenti ([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)).

Ognuno di questi percorsi finisce in una notifica che la tua configurazione attuale con ogni probabilità consegna in silenzio: un'email in una casella condivisa, un messaggio in un canale Slack che di notte non guarda nessuno, un ticket in una coda che viene smistata il lunedì. Nessuna di loro fallisce. Vengono consegnate correttamente, a nessuno.

Tre dettagli rendono il buco più largo di quanto sembri:

- **Non c'è nessuna API.** L'ENISA dice chiaramente che in questa fase non saranno fornite API per la segnalazione. Non puoi lasciare che sia uno script a inviare l'allerta precoce mentre tutti dormono.
- **L'accesso si configura persona per persona, e in anticipo.** I rappresentanti autorizzati si registrano con un account EU Login, e il CSIRT designato come coordinatore ne convalida i poteri dopo il primo accesso. C'è un rappresentante principale e un sostituto di riserva, e l'invito al sostituto scade dopo sette giorni ([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)). Se l'unica persona che può inviare la segnalazione è irraggiungibile, alla scadenza non importa.
- **La fascia sanzionatoria è quella alta.** L'articolo 64 colloca la violazione degli obblighi degli articoli 13 e 14 nella fascia delle sanzioni amministrative pecuniarie "fino a 15 000 000 EUR o, se l'autore della violazione è un'impresa, fino al 2,5 % del fatturato mondiale totale annuo dell'esercizio precedente, se superiore" ([articolo 64](https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_64.html)).

Una precisazione onesta sull'ultimo punto, perché cambia i conti per i team piccoli: l'articolo 64 esclude dalle sanzioni amministrative pecuniarie i fabbricanti che sono microimprese o piccole imprese **per il mancato rispetto del termine** dell'articolo 14(2)(a) o 14(4)(a), cioè proprio dell'allerta precoce di 24 ore. L'obbligo di segnalare resta, e l'esenzione non si estende alla notifica a 72 ore né al resto dell'articolo 14. Leggi l'articolo e fatti consigliare, invece di affidarti a un post su un blog per capire dove si colloca la tua azienda.

## Che cosa contiene davvero l'allerta precoce di 24 ore?

**Pochissimo, ed è proprio questo il punto.** Le indicazioni dell'ENISA descrivono un piccolo insieme di campi obbligatori nella fase di allerta precoce: tipo di segnalazione (vulnerabilità o incidente), livello della segnalazione, momento della segnalazione, dati di chi segnala, nome del fabbricante o del gestore, il prodotto, un titolo e, per gli incidenti, se si sospettano atti illeciti o malevoli. Tra i campi facoltativi di questa fase ci sono un ID CVE o un ID EUVD.

Il quadro tecnico più completo — la natura generale della vulnerabilità o dell'exploit, una prima valutazione, le misure correttive e di attenuazione — appartiene alla notifica a 72 ore, non alle prime 24 ore.

L'allerta precoce, quindi, non è un progetto di ricerca: è un modulo breve che una persona preparata compila in pochi minuti. Il vincolo non è il modulo, ma il fatto che una persona registrata, autorizzata e sveglia lo venga a sapere in tempo. Questo è un problema di instradamento delle notifiche, e oggi si risolve.

## Come metto un telefono che squilla davanti al conto alla rovescia di 24 ore?

Echobell trasforma una chiamata webhook o un'email in un avviso che squilla e vibra come una telefonata in arrivo: è così che passa attraverso la Full Immersion e il Non disturbare di iOS (vedi [come aggirare la Full Immersion di iOS](/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)). La configurazione qui sotto si affianca al processo di ticketing e al PSIRT che avete già: non li sostituisce.

### Passo 1 — Crea un canale con chiamata riservato ai casi CRA

Nell'app crea un canale e imposta il tipo di notifica su **Chiamata** ([tipi di notifica](/docs/notification)). Chiamalo in base alla decisione che innesca, non alla sorgente dei dati: "CRA — il conto alla rovescia di 24 ore potrebbe essere partito" è meglio di "Avvisi di sicurezza".

Questo canale deve restare silenzioso. Se squilla per ogni advisory, ogni scansione fallita e ogni aggiornamento di dipendenza, le persone smetteranno di rispondere e avrai bruciato in rumore il tuo unico canale rumoroso. Manda tutto il resto altrove: la [guida contro l'alert fatigue](/blog/fix-alert-fatigue-developer-guide) spiega come dividere.

Copia l'URL webhook del canale dai suoi dettagli; ha questa forma: `https://hook.echobell.one/t/<channel-token>`. Trattalo come un segreto, perché chi ce l'ha può far squillare i telefoni del tuo team ([guida ai webhook](/docs/webhook)).

Imposta modelli leggibili su una schermata di blocco alle 02:00, da qualcuno mezzo addormentato:

```
Titolo: Possibile segnalazione CRA — {{product}}
Corpo: {{kind}} — {{summary}} (noto dalle {{time}} UTC)
```

`{{time}}`, `{{date}}`, `{{hour}}` e le altre [variabili di sistema per il tempo](/docs/template) vengono sempre inserite in UTC, quindi la notifica registra un orario anche se chi la invia se n'è dimenticato. Quell'orario non è una prova legale di quando è iniziata la conoscenza, ma è un punto di riferimento utile quando poi ricostruirai la cronologia.

### Passo 2 — Punta i tuoi percorsi di rilevamento sul canale

Qualsiasi sistema in grado di chiamare un webhook può attivare il canale. I campi che invii diventano variabili del modello:

```bash
curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "vulnerabilità attivamente sfruttata",
    "summary": "segnalazione di un ricercatore, exploit funzionante allegato",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'
```

La variabile speciale `externalLink` diventa un link cliccabile nel record della notifica, così chi risponde alla chiamata si trova a un tocco dal ticket che contiene i dettagli.

Vale la pena collegare, grosso modo in ordine di frequenza con cui sono il primo segnale:

- **La coda di ingresso del vostro PSIRT o della sicurezza** — un webhook quando un caso viene etichettato come candidato CRA.
- **GitHub security advisories e avvisi Dependabot** sui repository che costruiscono i prodotti che distribuite ([integrazione GitHub](/docs/developer/github)).
- **Il vostro SIEM, EDR o WAF**, per i rilevamenti sull'infrastruttura di build, di rilascio o di firma — l'articolo 14(5) copre esplicitamente gli incidenti che potrebbero portare all'introduzione di codice malevolo.
- **I feed di intelligence sulle vulnerabilità** che già consultate, filtrati sui componenti che compaiono nei vostri SBOM.

### Passo 3 — Usa le condizioni perché squillino solo i candidati plausibili

**È questo il passo che tiene credibile il canale.** Le [condizioni](/docs/conditions) di Echobell valutano le stesse variabili e le stesse intestazioni HTTP che usi nei modelli, e il canale scatta solo quando l'espressione è vera:

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

Oppure filtra su un'intestazione, se il sistema che invia non può dare forma al corpo della richiesta:

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

Fissa la soglia su "una persona competente dovrebbe dare un'occhiata entro un'ora", non su "questo è sicuramente da segnalare". Decidere se l'articolo 14 si applica è una valutazione che richiede una persona con i fatti davanti; il compito del canale è portare in fretta quella persona ai fatti. Filtrare troppo, qui, è l'errore costoso: una segnalazione mai avviata è peggio di una chiamata di cui non avevi bisogno.

### Passo 4 — Intercetta i sistemi che inviano solo email

Il primo contatto dall'esterno arriva quasi sempre via email: il ricercatore, il cliente, il CSIRT nazionale, il fornitore di componenti. Ogni canale Echobell può avere un proprio indirizzo, quindi una sola regola di inoltro su `security@` trasforma quei messaggi in chiamate ([trigger via email](/docs/email-trigger)).

I trigger via email espongono `from`, `to`, `subject`, `text` e `html` come variabili, così puoi filtrare senza analizzare niente:

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

Chiedi a chi vi segnala abitualmente le vulnerabilità e ai fornitori chiave di usare un marcatore concordato nell'oggetto, poi filtra su quello. È un piccolo dettaglio contrattuale che trasforma una casella non strutturata in un segnale instradabile.

### Passo 5 — Metti sul canale tutti i rappresentanti registrati

Condividi il canale con tutte le persone che possono davvero inviare la segnalazione: il rappresentante autorizzato principale, il sostituto di riserva e il responsabile della sicurezza che può prendere la decisione sull'articolo 14. Ogni iscritto sceglie il proprio tipo di notifica, così chi è di turno può stare su **Chiamata** mentre il resto del gruppo sta su **Urgente**.

È tutto qui il senso dell'esercizio. La SRP richiede una persona fisica registrata e convalidata. Se in azienda è registrata una persona sola, la tua scadenza di 24 ore ha un singolo punto di rottura, con tanto di batteria del telefono.

### Passo 6 — Fai le prove prima dell'11 settembre, non dopo

Due prove, entrambe da fare questo mese:

1. **Il percorso dell'avviso.** Lancia il `curl` qui sopra con il Non disturbare davvero attivo, sul telefono che starà effettivamente sul comodino di qualcuno. Attiva **Riprova chiamata non riuscita** nell'app, così una chiamata che fallisce una volta viene ritentata. Un percorso di escalation non testato è solo un'ipotesi.
2. **Il percorso di invio.** Ripercorri una segnalazione sulla carta, seguendo le guide passo passo dell'ENISA su registrazione e invio, aggiornate fino ad agosto 2026 ([ENISA SRP](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp)). Create adesso gli account EU Login, verificate quale CSIRT è il vostro coordinatore e mandate presto l'invito al rappresentante sostituto: scade dopo sette giorni.

La seconda prova ha un intoppo che conviene conoscere: nelle indicazioni ENISA di luglio l'URL pubblico della piattaforma era ancora indicato come "da fornire al lancio", quindi un vero test end-to-end non era ancora possibile ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/news/enisa-srp-step-by-step-instructions-31-july-2026.html)). L'ENISA si è impegnata a rendere la piattaforma operativa entro l'11 settembre 2026. Prova tutto quello che dipende da te e non trasformare lo stato della piattaforma in un motivo per rimandare il tuo.

## Che cosa Echobell non fa

Essere precisi qui conta più del solito, perché il tema è regolatorio:

- **Non ti rende conforme.** Echobell è un canale di notifica. Delimitare il perimetro dei prodotti, gestire un processo di trattamento delle vulnerabilità, decidere se l'articolo 14 si applica, registrarsi alla SRP e inviare nei termini restano tutti compiti tuoi. Nessuno strumento di allertamento ha mai assolto un obbligo di segnalazione.
- **Non invia niente.** Non esiste un'API attraverso cui inviare la segnalazione e, se esistesse, non sarebbe Echobell a chiamarla. Echobell fa squillare un telefono; il resto lo fa una persona registrata.
- **Non è un orario legalmente valido.** La variabile `{{time}}` registra quando il trigger è arrivato a Echobell, in UTC. Quando è iniziata la "presa di conoscenza" è una questione di fatto che riguarda la tua organizzazione, e a documentarla è il vostro registro degli incidenti, non una notifica push.
- **Non ha politiche di escalation né presa in carico.** Non esiste un "se non risponde nessuno entro dieci minuti, chiama la persona successiva", non ci sono turni, non c'è traccia di chi ha preso in carico che cosa. Per questo serve una piattaforma di incident management: vedi le [alternative a Opsgenie](/blog/opsgenie-end-of-life-alternatives).
- **Non può garantire la consegna.** Una chiamata dipende dall'infrastruttura push, dalla rete e da un telefono carico. Consideralo il livello che accorcia la distanza tra un fatto che arriva e una persona che lo sa, non un controllo da esibire in un audit.
- **Non tiene conto dell'ora locale.** Le variabili di tempo integrate sono solo in UTC e non seguono l'ora legale. Le condizioni che delimitano una finestra oraria vanno corrette a mano due volte l'anno.

## FAQ

### Usare Echobell ci rende conformi al CRA?

No. Il CRA impone obblighi ai fabbricanti, e nessuna app di notifica può assolverli. Quello che Echobell affronta è una modalità di fallimento precisa: l'allerta precoce di 24 ore salta perché la persona che avrebbe potuto inviarla lo scopre solo il giorno lavorativo successivo. È un fallimento reale e frequente, ma è una parte di un programma di conformità molto più ampio.

### Quando parte davvero il conto alla rovescia di 24 ore?

Quando il fabbricante viene a conoscenza della vulnerabilità attivamente sfruttata o dell'incidente grave. Il regolamento non definisce un momento esatto, e la conoscenza dipende dai fatti e dalla rapidità con cui si riescono ad accertare ([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)). In pratica questo depone a favore di un triage rapido e documentato: più tempo passa tra l'arrivo di un segnale e la sua valutazione, più diventa difficile spiegarlo dopo.

### Siamo una piccola azienda. Siamo esentati?

Dalla segnalazione no. L'articolo 64 esclude microimprese e piccole imprese dalle sanzioni amministrative pecuniarie, ma specificamente per il mancato rispetto del termine di 24 ore dell'articolo 14(2)(a) o 14(4)(a). L'obbligo di segnalare resta, la notifica a 72 ore e la relazione finale non sono toccate, e le definizioni di microimpresa e piccola impresa non sono qualcosa che si dà per scontato. Consideralo un'attenuazione ristretta, non un lasciapassare.

### La nostra casella di sicurezza è presidiata in orario d'ufficio. Non basta?

Solo se sei disposto a perdere fino a due terzi della finestra in un normale fine settimana. Una segnalazione che arriva venerdì alle 18:00 ti lascia una scadenza alle 18:00 di sabato. Il presidio in orario d'ufficio è un'ottima impostazione predefinita per tutto il resto; il conto alla rovescia di 24 ore è esattamente il caso che non copre.

### Compliance, ufficio legale e sviluppo possono ricevere lo stesso avviso?

Sì, e dovrebbero. Condividete un solo canale e ogni iscritto viene avvisato dallo stesso trigger, scegliendo la propria urgenza. Chi conferma lo sfruttamento e chi invierà il modulo devono partire nello stesso minuto, non uno dopo l'altro.

### Aiuta con l'obbligo di informare gli utenti previsto dall'articolo 14(8)?

Indirettamente. L'articolo 14(8) impone di informare gli utenti colpiti della vulnerabilità o dell'incidente e, se necessario, delle misure correttive. Questa è comunicazione verso i clienti e richiede i vostri canali. Echobell può svegliare chi è responsabile di quella comunicazione insieme a chi è responsabile dell'invio, così i due filoni di lavoro partono insieme.

### Segnaliamo già ai sensi di NIS2 o DORA. È la stessa cosa?

No, anche se gli schemi si assomigliano. NIS2 e DORA impongono obblighi ai soggetti in base al settore e alla criticità; il CRA li impone ai fabbricanti in base ai prodotti che immettono sul mercato dell'UE. Una stessa organizzazione può essere soggetta a tutti e tre, con scadenze e destinatari diversi. Se anche quei regimi vi riguardano, vedi [gli avvisi per le segnalazioni di incidenti DORA e NIS2](/blog/dora-nis2-incident-reporting-alerts) — e tieni presente che il livello di allertamento si può condividere anche quando gli obblighi non lo sono.

### La chiamata passa davvero attraverso il Non disturbare?

Le notifiche con chiamata vengono consegnate come avvisi in stile telefonata, ed è proprio questo a farle passare attraverso la Full Immersion su iOS. Non è magia: dipende comunque dalle impostazioni del sistema, dalla rete e da un telefono carico. Provala sul dispositivo vero, con la Full Immersion davvero attiva, prima di farci affidamento — e attiva **Riprova chiamata non riuscita**.

### Vale solo per iOS?

No. Echobell c'è per iOS e per [Android su Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid) ([rilascio Android](/blog/echobell-android-release)). Il comportamento degli avvisi in stile telefonata cambia da una piattaforma all'altra, quindi fai le prove sul dispositivo che chi risponde porterà davvero con sé.

### Che cosa mettiamo nel payload del webhook?

Il minimo indispensabile per decidere se alzarsi: il prodotto, il tipo di segnale, una riga di contesto e un `externalLink` al ticket che contiene i dettagli. Echobell tiene i contenuti e la cronologia delle notifiche sul dispositivo e sul server solo account, canali e iscrizioni ([modello di privacy](/docs/features)), ma con materiale sensibile per la sicurezza l'abitudine giusta resta inviare un puntatore, non la sostanza.

---

## Contenuti correlati

- [Avvisi per le segnalazioni di incidenti DORA e NIS2](/blog/dora-nis2-incident-reporting-alerts)
- [Come risolvere l'alert fatigue](/blog/fix-alert-fatigue-developer-guide)
- [Come aggirare la Full Immersion di iOS per gli avvisi critici](/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)
- [Alternative a Opsgenie dopo la fine del supporto](/blog/opsgenie-end-of-life-alternatives)
- [Guida all'integrazione dei webhook](/docs/webhook)
- [Trigger via email](/docs/email-trigger)
- [Guida alle condizioni](/docs/conditions)