CRA, NIS2 e GDPR: quando un incidente vale tre

Dal 11 settembre 2026 un singolo incidente informatico può aprire fino a tre percorsi di notifica distinti: uno sotto il Cyber Resilience Act (CRA), uno sotto NIS2 e uno sotto GDPR. Per un’azienda questo non è un dettaglio giuridico: significa dover reagire molto in fretta, con ruoli chiari, prove raccolte bene e decisioni tracciate, perché inviare una segnalazione su un canale non sostituisce automaticamente le altre.

Cosa cambia dall’11 settembre 2026

La data da segnare è l’11 settembre 2026. Da quel giorno si applicano gli obblighi di incident reporting previsti dall’articolo 14 del Regolamento (UE) 2024/2847, cioè il Cyber Resilience Act.

In pratica, i fabbricanti di prodotti con elementi digitali dovranno notificare:

• le vulnerabilità attivamente sfruttate;
• gli incidenti gravi che incidono sulla sicurezza del prodotto.

Il punto importante è che questi obblighi partono prima del resto dell’impianto CRA. Secondo quanto richiamato nelle fonti, la piena applicazione degli altri adempimenti principali — come valutazione di conformità, documentazione tecnica e marcatura CE — arriverà solo l’11 dicembre 2027. In altre parole, il reporting entra in vigore con circa quindici mesi di anticipo rispetto alla conformità completa.

Per molte aziende questo cambia l’ordine delle priorità: non basta pensare al CRA come a un progetto di prodotto da completare nel 2027. Serve già nel 2026 una capacità operativa di classificare un evento, collegarlo a una specifica versione del prodotto, capire quali componenti sono coinvolti e sapere in quali Stati membri il prodotto è stato reso disponibile.

Perché un solo incidente può generare tre notifiche diverse

L’errore più pericoloso è pensare che, siccome si parla sempre dello stesso incidente, esista una sola comunicazione valida per tutti. Non è così.

Le tre normative proteggono interessi diversi e si applicano a soggetti diversi:

• CRA: guarda alla sicurezza del prodotto con elementi digitali e agli obblighi del fabbricante;
• NIS2: riguarda la resilienza operativa e gli obblighi dei soggetti essenziali o importanti;
• GDPR: si attiva quando l’evento comporta violazione dei dati personali, per esempio accesso non autorizzato, perdita, alterazione o indisponibilità.

Lo stesso fatto tecnico può quindi essere letto in tre modi diversi. Un exploit su una funzione del prodotto può essere, contemporaneamente:

• una vulnerabilità attivamente sfruttata da notificare ai sensi del CRA;
• un incidente significativo, se l’azienda rientra nel perimetro NIS2 e l’evento supera le soglie previste;
• un data breach, se sono coinvolti dati personali.

Le scadenze possono perfino assomigliarsi, con riferimenti a 24 o 72 ore, ma non bisogna farsi ingannare. Cambiano i presupposti, i destinatari, il contenuto della notifica e il soggetto responsabile della decisione.

Il percorso CRA: tempi stretti e piattaforma unica europea

Per il CRA, le fonti indicano un meccanismo articolato in più passaggi:

• preallarme entro 24 ore;
• notifica entro 72 ore;
• relazione finale con tempistiche diverse a seconda del tipo di evento.

Le comunicazioni passeranno attraverso la Single Reporting Platform gestita da ENISA e indirizzate al CSIRT coordinatore. Questa centralizzazione aiuta sul piano operativo europeo, ma non elimina gli altri obblighi normativi.

Un altro aspetto rilevante è che gli obblighi di segnalazione possono riguardare anche prodotti già immessi sul mercato prima della piena applicazione del CRA. Inoltre, secondo le linee guida della Commissione del 27 luglio 2026 richiamate dalla fonte, il dovere di reporting può continuare anche oltre il periodo di supporto del prodotto. Questo significa che una versione non più aggiornata potrebbe non ricevere nuove correzioni, ma se il fabbricante viene a conoscenza di una compromissione attiva potrebbe comunque doverla segnalare.

Per chi sviluppa, integra o commercializza tecnologie digitali, questo punto è decisivo: la visibilità sui componenti software e sulle versioni distribuite smette di essere un esercizio documentale e diventa un requisito operativo.

NIS2 e GDPR restano autonomi

La novità del CRA non assorbe NIS2 e GDPR. Anche se esiste una piattaforma unica per il flusso CRA, gli altri due binari restano separati.

Per la NIS2, conta la qualifica dell’organizzazione e la valutazione dell’incidente secondo i criteri propri della direttiva. Non tutte le aziende sono coinvolte allo stesso modo, ma chi rientra tra i soggetti essenziali o importanti deve considerare il tema come parte della governance, non solo come reazione tecnica.

Per il GDPR, la domanda è diversa: l’evento ha comportato una violazione di dati personali? Se sì, si apre il percorso privacy, con la necessità di valutare il rischio per i diritti e le libertà delle persone coinvolte e di decidere se notificare all’autorità e, nei casi previsti, anche agli interessati.

Il messaggio pratico è semplice: il SOC o il reparto IT possono rilevare l’evento, ma non possono essere lasciati soli a decidere. Serve un raccordo strutturato fra sicurezza, legale, DPO, responsabili di prodotto e direzione.

Il vero problema non è la notifica: è il coordinamento interno

Quando arriva il primo segnale — un log anomalo, un advisory del fornitore, una patch in preparazione, una segnalazione di un cliente — il tempo utile si misura in ore. In quel momento non si può improvvisare.

Le aziende più esposte non sono necessariamente quelle con più tecnologia, ma quelle in cui nessuno sa rispondere subito a domande come:

• quale prodotto o servizio è coinvolto;
• quali versioni sono esposte;
• quali clienti o sedi lo utilizzano;
• se ci sono componenti terzi interessati;
• se l’incidente ha toccato dati personali;
• chi decide la qualificazione finale dell’evento;
• chi firma e invia le notifiche.

È qui che entrano in gioco processi spesso sottovalutati: inventario degli asset, distinta base software, registri dei trattamenti, procedure di escalation, raccolta delle evidenze, reperibilità dei fornitori e tracciamento delle decisioni.

In pratica, non servono tre indagini separate. Serve una sola ricostruzione tecnica dell’evento, fatta bene e rapidamente, da cui poi derivano decisioni giuridiche diverse e notifiche differenti.

Cosa significa per la tua azienda

Per una PMI italiana, anche se non fabbrica software in senso stretto, la notizia conta per almeno tre motivi.

Primo: molte aziende usano, integrano, personalizzano o rivendono prodotti digitali. Potrebbero quindi essere coinvolte nella gestione dell’incidente come anello della catena informativa.

Secondo: se l’azienda rientra o rientrerà nel perimetro NIS2, il coordinamento con il CRA diventa un tema organizzativo reale.

Terzo: quasi ogni incidente serio oggi tocca, direttamente o indirettamente, dati personali e quindi il GDPR.

Ecco le azioni più utili da fare adesso, senza aspettare settembre:

1. Mappa ruoli e responsabilità
   Definisci prima dell’incidente chi valuta l’evento sul piano tecnico, chi lo qualifica sul piano legale, chi coinvolge il DPO e chi invia le comunicazioni.

2. Costruisci una procedura unica di triage
   Alla prima segnalazione deve partire un flusso standard con checklist chiare: prodotto coinvolto, versioni, clienti impattati, dati personali, servizi critici, evidenze disponibili.

3. Aggiorna l’inventario dei sistemi e del software
   Se non sai con precisione dove si trova un componente vulnerabile, rispettare scadenze di 24 o 72 ore diventa molto difficile. Qui un buon governo degli endpoint e degli asset è fondamentale, anche con servizi di desktop IT management.

4. Rivedi il piano di risposta agli incidenti
   Il piano deve includere il raccordo tra sicurezza, NIS2 e privacy, non solo il contenimento tecnico. Se manca questa parte, il rischio non è solo operativo ma anche regolatorio.

5. Verifica backup e recupero
   Un incidente grave spesso porta con sé indisponibilità dei sistemi, dubbi sull’integrità dei dati e necessità di ripristino rapido. Soluzioni di remote backup ben gestite riducono i tempi di fermo e aiutano a ricostruire cosa è successo.

6. Controlla la documentazione privacy
   Registro dei trattamenti, ruoli, fornitori e procedure di data breach devono essere allineati alla realtà operativa. In caso contrario, il percorso GDPR si complica proprio quando il tempo manca. Se serve, conviene fare una verifica del proprio impianto di conformità GDPR.

7. Coinvolgi fornitori e partner
   Se usi software di terzi, servizi cloud, appliance o piattaforme gestite, accertati che i contatti di escalation siano aggiornati e che i contratti prevedano tempi di collaborazione compatibili con gli obblighi di notifica.

Non è solo compliance: è governo del rischio

Il tema può sembrare normativo, ma in realtà riguarda la capacità dell’azienda di prendere decisioni corrette sotto pressione. Le imprese che arrivano preparate non sono quelle che conoscono a memoria le sigle, ma quelle che hanno già deciso come trasformare un segnale tecnico in una risposta coordinata.

Da settembre 2026, per chi fabbrica prodotti con elementi digitali, il CRA accorcia drasticamente i tempi. Per chi è soggetto a NIS2 o gestisce dati personali, il quadro si allarga ulteriormente. Il punto centrale non è evitare la pluralità delle notifiche, ma gestirla senza confusione, senza ritardi e senza vuoti di responsabilità.

Domande frequenti

Se notifico un incidente tramite la piattaforma CRA, sono coperto anche per NIS2 e GDPR?

No. La Single Reporting Platform centralizza il flusso CRA verso ENISA e CSIRT, ma NIS2 e GDPR restano percorsi autonomi con regole, soglie e destinatari diversi.

Il CRA riguarda solo i nuovi prodotti immessi sul mercato dopo il 2026?

No necessariamente. Le fonti indicano che gli obblighi di segnalazione possono riguardare anche prodotti già immessi sul mercato prima della piena applicazione del regolamento.

Una PMI che non sviluppa software deve preoccuparsi comunque?

Sì, se usa o integra prodotti digitali critici, se rientra nel perimetro NIS2 o se un incidente può coinvolgere dati personali. Anche senza essere fabbricante, la preparazione interna resta essenziale.