Sulla base della ricerca del Dr. iur. Dr. rer. pol. Fabian M. A. Teichmann

Sono le 3 del mattino. Il dipartimento IT si accorge che gli aggressori sono penetrati attivamente nei sistemi aziendali da ore. Il consiglio d'amministrazione viene svegliato. È allora che sorge una domanda alla quale, in quel momento, nessuno sa rispondere con precisione: chi dobbiamo informare, quando e con quale preavviso?

Nella pratica, questa è esattamente la situazione in cui molte aziende si rendono conto di non aver mai compreso appieno gli obblighi di notifica previsti dalla legislazione europea in materia di cybersicurezza. Infatti, con la DORA, la NIS-2 e il Cyber Resilience Act (CRA), esistono oggi tre diversi quadri normativi dell'UE che prevedono tutti obblighi di notifica in caso di incidenti informatici, con scadenze diverse, destinatari diversi, autorità diverse e fattori scatenanti diversi. Teichmann ha analizzato sistematicamente questa complessa situazione in diverse pubblicazioni scientifiche. I risultati sono di estrema rilevanza per qualsiasi azienda che rientri nell'ambito di applicazione di più di uno di questi regolamenti.

Perché esistono tre diversi regimi di notifica

L'emergere di obblighi di notifica paralleli non è un errore del legislatore europeo, bensì l'espressione di tre diverse logiche di regolamentazione.

La NIS-2 si rivolge ai gestori, ovvero alle aziende che gestiscono servizi e infrastrutture critiche. L'obiettivo è quello di garantire che le interruzioni di questi servizi vengano segnalate tempestivamente alle autorità di vigilanza, in modo che queste possano valutare e coordinare i rischi sistemici. La NIS-2 è intersettoriale e si basa sui gestori (Teichmann, Neue Cybersicherheitspflichten durch das NIS-2-Umsetzungsgesetz, K&R 2026, pagg. 26–32).

La DORA si rivolge alle imprese finanziarie, ossia a un settore specifico con una rilevanza sistemica particolare. La logica è la medesima della NIS-2, ma i requisiti sono più severi e dettagliati. I dissesti finanziari possono destabilizzare l'intero sistema economico, motivo per cui il legislatore impone in questo caso standard più rigorosi (Teichmann, Digital Operational Resilience Act – EU-weit einheitliche IT-Sicherheitsregeln für Finanzinstitute, BB 2025, pagg. 2760–2770).

Il CRA, invece, si rivolge ai produttori di prodotti connessi, ovvero non ai gestori, bensì ai produttori della tecnologia stessa. Se una vulnerabilità in un prodotto viene attivamente sfruttata, il produttore deve segnalarlo affinché le autorità possano reagire e avvertire gli altri utenti dello stesso prodotto (Teichmann, Cyber Resilience Act – Produktsicherheit, SBOM und Herstellerhaftung entlang des Lebenszyklus, CCZ 2025, pagg. 165–171).

Il problema sorge quando la stessa azienda ricopre più ruoli contemporaneamente, il che accade molto frequentemente nella pratica. Una banca che sviluppa e gestisce il proprio software può rientrare contemporaneamente nell'ambito di applicazione della DORA come impresa finanziaria, della NIS-2 come entità essenziale e del CRA come produttore. In questo scenario, tre diversi obblighi di notifica con scadenze differenti si sovrappongono parallelamente.

Gli obblighi di notifica nel dettaglio: chi segnala cosa, quando e a chi

NIS-2: il modello standard in tre fasi. La NIS-2 ha introdotto la procedura di notifica in tre fasi, che oggi rappresenta il modello di riferimento per tutta la legislazione europea sulla cybersicurezza. Entro 24 ore dal momento in cui si viene a conoscenza di un incidente significativo, deve essere inviata una notifica preventiva (early warning) al BSI. Questa notifica iniziale non deve contenere un'analisi completa; è sufficiente indicare che si è verificato un incidente significativo e fornire una prima valutazione sulla possibilità che si tratti di un atto doloso. Entro 72 ore deve seguire la notifica vera e propria dell'incidente, con una prima valutazione. Entro e non oltre un mese dalla notifica iniziale deve essere presentata una relazione finale. Un incidente è considerato significativo se ha causato o è in grado di causare gravi interruzioni operative o perdite finanziarie significative; il parametro di riferimento è quindi l'impatto potenziale, non solo il danno già verificatosi (Teichmann, Die neue 24-Stunden-Meldepflicht für Cyberangriffe nach ISG, Jusletter, 29 settembre 2025).

DORA: più severo, più rapido e specifico per il settore finanziario. La DORA adotta il modello base a tre fasi, ma lo inasprisce sotto diversi aspetti. L'inasprimento cruciale riguarda la prima scadenza: entro quattro ore dalla classificazione dell'incidente come grave, deve essere inviata una notifica iniziale alla BaFin, non più entro 24 ore. Ciò presuppone che l'impresa finanziaria disponga di processi interni di classificazione efficienti che consentano tale valutazione in tempi brevi. La DORA definisce le soglie sulla base di criteri finanziari specifici: numero e percentuale di clienti e transazioni interessati, impatto geografico, durata del disservizio, danno reputazionale e perdite finanziarie. Entro 72 ore segue la relazione intermedia ed entro un mese la relazione finale, analogamente alla NIS-2. Poiché la DORA si configura come lex specialis rispetto alla NIS-2, la notifica alla BaFin sostituisce in linea di principio quella al BSI; le due autorità si coordinano tra loro (Teichmann, Harmonisierung von Incident-Reporting-Meldefristen nach DORA, NIS2 und CRA, ZRFC 2026, pagg. 81–88).

CRA: una logica completamente diversa. Il CRA introduce un obbligo di notifica che si discosta strutturalmente da NIS-2 e DORA. Non si tratta di interruzioni operative, ma di vulnerabilità del prodotto. Ai sensi dell'art. 14 CRA, i produttori di prodotti connessi devono segnalare le vulnerabilità attivamente sfruttate entro 24 ore dal momento in cui ne vengono a conoscenza al BSI e, parallelamente, all'Agenzia dell'Unione europea per la cibersicurezza (ENISA). Entro 72 ore segue una notifica più completa ed entro 14 giorni (non un mese come per NIS-2 e DORA) una relazione finale. La differenza strutturale fondamentale: le notifiche CRA riguardano le vulnerabilità del prodotto, non gli incidenti nel proprio esercizio aziendale. Un produttore, quindi, non deve effettuare la notifica perché è stato egli stesso vittima di un attacco, ma perché il suo prodotto è stato o potrebbe essere la porta d'accesso per un attacco a qualcun altro (Teichmann, CCZ 2025, pagg. 165–171).

Il problema del coordinamento: quando si applicano contemporaneamente tutti e tre i regimi

La vera sfida sorge in scenari in cui un'azienda è soggetta a più regimi contemporaneamente. L'esempio classico è quello di una software house che sviluppa soluzioni di sicurezza per le banche e opera essa stessa come fornitore di servizi IT critici nel settore finanziario. In caso di grave incidente di sicurezza, questa azienda può trovarsi contemporaneamente interessata come entità NIS-2 con l'obbligo di notifica al BSI entro 24 ore, come produttore CRA con l'obbligo di notifica di una vulnerabilità di prodotto attivamente sfruttata entro 24 ore a BSI ed ENISA, e come fornitore terzo di servizi TIC ai sensi della DORA con l'obbligo di informare le imprese finanziarie interessate, le quali a loro volta devono effettuare la notifica alla BaFin entro quattro ore (Teichmann, ZRFC 2026, pagg. 81–88).

Cosa c'è di identico e cosa no

Il fattore scatenante differisce fondamentalmente. La NIS-2 fa scattare l'obbligo di notifica in caso di un incidente di sicurezza significativo che interrompe l'attività operativa. La DORA lo attiva in caso di un grave incidente TIC con un impatto finanziario concreto. Il CRA lo fa scattare in caso di una vulnerabilità del prodotto attivamente sfruttata, indipendentemente dal fatto che il produttore stesso sia colpito a livello operativo.

La prima scadenza varia: 24 ore per NIS-2 e CRA, quattro ore per la DORA. Per le imprese finanziarie, la scadenza DORA è quindi la più severa e non decorre dal momento dell'individuazione dell'incidente, bensì dal momento della sua classificazione interna come grave.

L'autorità di notifica è diversa: NIS-2 e CRA notificano al BSI, la DORA alla BaFin. Le notifiche CRA vanno inoltrate anche all'ENISA a livello europeo. La relazione finale è dovuta dopo un mese per NIS-2 e DORA, mentre per il CRA già dopo 14 giorni. Inoltre, anche il contenuto si differenzia: NIS-2 e DORA si concentrano sull'incidente operativo, mentre il CRA sulla vulnerabilità del prodotto e sullo stato della patch.

Il GDPR come quarto livello

Oltre a DORA, NIS-2 e CRA, esiste un quarto obbligo di notifica che si applica a molti incidenti informatici: il Regolamento generale sulla protezione dei dati. Se sono interessati dati personali (il che avviene nella maggior parte degli attacchi ai sistemi aziendali), ai sensi dell'art. 33 del GDPR sussiste l'obbligo di notifica all'autorità di controllo competente per la protezione dei dati personali entro 72 ore. La notifica ai sensi del GDPR corre parallelamente a quelle sulla sicurezza informatica e ha come destinatario un'autorità specifica. Il coordinamento è necessario affinché non vengano inviate informazioni contraddittorie a diverse autorità. Teichmann sottolinea che molte aziende sottovalutano questa struttura parallela e, in caso di emergenza, si complicano la vita con obblighi di comunicazione tra loro contrastanti (Teichmann, CCZ 2025, pagg. 165–171).

Cosa significa questo nella pratica

Ogni azienda deve innanzitutto comprendere a quali regimi è soggetta. Non si tratta di una questione banale: una software house di medie dimensioni che sviluppa prodotti per clienti industriali e agisce al contempo come fornitore di servizi IT per entità NIS-2 può rientrare in tutti e tre i quadri normativi.

Il processo di notifica deve essere definito preventivamente e con precisione. Chi decide se un incidente debba essere notificato? Chi è responsabile della notifica? Quale modello viene utilizzato? Queste decisioni non possono essere prese per la prima volta in una situazione di crisi, soprattutto a fronte di scadenze di sole quattro ore.

La comunicazione con le diverse autorità deve essere coordinata. Se un incidente fa scattare contemporaneamente una notifica NIS-2 al BSI, una notifica DORA alla BaFin e una notifica GDPR all'autorità per la protezione dei dati, queste notifiche devono essere coerenti tra loro. Informazioni contraddittorie possono minare la fiducia delle autorità di vigilanza.

Infine, tutte le notifiche, i fatti sottostanti e la cronologia delle decisioni devono essere documentati in modo a prova di audit. Successivamente a un incidente, le autorità verificheranno se i termini di notifica sono stati rispettati, e l'onere della prova spetta all'azienda (Teichmann, ZRFC 2026, pagg. 81–88).

Conclusione: conoscere la complessità prima che l'orologio inizi a scorrere

DORA, NIS-2 e CRA condividono lo stesso obiettivo fondamentale: informare rapidamente le autorità quando si verifica un incidente informatico o viene sfruttata una vulnerabilità. Tuttavia, i percorsi per raggiungere questo obiettivo differiscono in termini di scadenze, autorità coinvolte, fattori scatenanti e contenuti.

La ricerca di Teichmann dimostra che chi inizia a comprendere queste differenze solo nel momento in cui si verifica l'emergenza ha già perso in partenza. La scadenza di quattro ore della DORA, quella di 24 ore della NIS-2, il termine di 14 giorni per la relazione finale del CRA non sono norme giuridiche astratte. Sono requisiti operativi che devono essere già integrati e consolidati oggi in ogni azienda interessata.

Tutti i riferimenti bibliografici si riferiscono a pubblicazioni scientifiche del Dr. iur. Dr. rer. pol. Fabian M. A. Teichmann. La bibliografia completa è documentata nell'elenco delle pubblicazioni (aggiornato a maggio 2026).