Àngela Vercher
Marketing Manager Iberia
Àngela Vercher è una marketing manager con esperienza nel settore della compliance e della regolamentazione. In Formalize guida il marketing per l'Iberia, aiutando i professionisti di compliance, rischio e sicurezza a rimanere aggiornati sulla normativa e a trovare soluzioni pratiche alle sfide quotidiane.
Punti chiave:
Dall'11 settembre 2026, i fabbricanti di prodotti con elementi digitali devono inviare un preallarme entro 24 ore da quando vengono a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave che incide sulla sicurezza del loro prodotto.
L'obbligo ricade sui fabbricanti e riguarda i prodotti già presenti sul mercato dell'UE. Il SaaS puro è generalmente al di fuori dell'ambito del CRA, così come i prodotti coperti da norme settoriali proprie, come dispositivi medici e veicoli.
Il CRA aggiunge un obbligo di notifica, non ne sostituisce nessuno. La notifica di violazione entro 72 ore prevista dal GDPR continua ad applicarsi e la NIS2 prevede un proprio preallarme di 24 ore per gli incidenti significativi.
In Spagna la NIS2 non è ancora stata recepita nel diritto nazionale, quindi per ora il quadro di riferimento per la notifica degli incidenti resta il Real Decreto-ley 12/2018.
I team meglio preparati a rispettare questi termini hanno concordato in anticipo come viene classificato un incidente, chi prende la decisione e dove viene registrata.
I titoli recenti della stampa spagnola lo riassumono così: le aziende ora hanno 24 ore per segnalare un attacco informatico. È un titolo efficace, ma semplificato. Il Cyber Resilience Act (CRA), Regolamento (UE) 2024/2847, è in vigore da dicembre 2024, ma il primo obbligo applicabile ai fabbricanti, ovvero quello di notificare determinate vulnerabilità e incidenti, ha effetto solo dall'11 settembre 2026. Gran parte del regolamento, inclusi la marcatura CE e i requisiti essenziali di cibersicurezza, seguirà l'11 dicembre 2027. Ciò che è cambiato a settembre è più circoscritto di "ogni azienda, ogni attacco" e, per certi versi, più impegnativo, perché si aggiunge a obblighi di notifica che molte organizzazioni già hanno.
Cosa è cambiato l'11 settembre
L'articolo 14 del CRA impone ai fabbricanti di notificare due tipi di eventi: le vulnerabilità attivamente sfruttate nei propri prodotti e gli incidenti gravi che incidono sulla sicurezza di tali prodotti. I fabbricanti inviano ogni notifica tramite la piattaforma unica di segnalazione dell'Agenzia dell'Unione europea per la cibersicurezza (ENISA), che la trasmette contemporaneamente a ENISA e al team di risposta agli incidenti di sicurezza informatica (CSIRT) nazionale designato come coordinatore. La piattaforma è entrata in funzione lo stesso giorno in cui è iniziato l'obbligo.
La notifica si articola in tre fasi:
Fase | Termine | Contenuto |
|---|---|---|
Preallarme | Entro 24 ore da quando il fabbricante ne viene a conoscenza | Un primo avviso, con l'indicazione di dove nell'UE il prodotto è disponibile |
Notifica | Entro 72 ore | Maggiori dettagli e una valutazione iniziale |
Relazione finale | 14 giorni dopo la disponibilità di una correzione o di una misura di mitigazione (vulnerabilità), oppure un mese dopo la notifica (incidenti gravi) | Una descrizione completa, la causa e le misure adottate |
I fabbricanti devono inoltre informare gli utenti interessati e, se opportuno, tutti gli utenti, affinché possano proteggersi. L'obbligo, tuttavia, non è retroattivo: secondo le indicazioni della Commissione europea, i fabbricanti non sono tenuti a segnalare retroattivamente gli sfruttamenti di cui erano già a conoscenza prima dell'11 settembre.
A chi si applica e a chi no
L'obbligo delle 24 ore ricade sui fabbricanti di prodotti con elementi digitali, categoria che comprende la maggior parte dell'hardware e del software che si collega a un dispositivo o a una rete. Si applica ai prodotti già presenti sul mercato dell'UE, non solo ai nuovi lanci.
Tre confini sono facili da trascurare:
Il SaaS puro è generalmente escluso. Il CRA regola i prodotti, non i servizi. I servizi cloud utilizzati senza alcun componente installato possono invece rientrare nella direttiva NIS2, a seconda del fornitore; tuttavia, client installabili, agenti o trattamento remoto dei dati da cui un prodotto dipende possono riportare un'offerta nell'ambito di applicazione.
Alcuni settori hanno regole proprie. I prodotti già disciplinati da una normativa UE settoriale specifica, come i dispositivi medici e i veicoli, sono esclusi dal CRA.
Anche i piccoli fabbricanti devono notificare. Secondo la Commissione europea, le microimprese e le piccole imprese non possono essere sanzionate per il mancato rispetto del termine di preallarme di 24 ore, ma l'obbligo si applica loro integralmente.
Per le organizzazioni che acquistano software anziché svilupparlo, l'obbligo di notifica ricade sui loro fornitori. Ciò non lo rende irrilevante: la notifica CRA di un fornitore è esattamente il tipo di segnale che dovrebbe alimentare i processi interni di gestione del rischio dei fornitori e degli incidenti.
Un solo incidente, tre orologi
È qui che il confronto con la normativa sulla protezione dei dati mostra i suoi limiti. Il Regolamento generale sulla protezione dei dati (GDPR) concede alle organizzazioni 72 ore per notificare una violazione dei dati personali, ed è facile leggere il CRA come quella finestra ridotta a 24 ore. In pratica, entrambi i termini corrono in parallelo, attivati da eventi diversi e diretti ad autorità diverse. Aggiungendo la NIS2 per le organizzazioni che rientrano nel suo ambito, un singolo incidente può far partire tre orologi distinti.
Si immagini un'azienda di software di medie dimensioni in Spagna. Un attaccante sfrutta una vulnerabilità in uno dei suoi prodotti installati, la usa per accedere ai sistemi di supporto dell'azienda stessa e copia i dati di contatto dei clienti. Nel giro di poche ore, l'azienda potrebbe trovarsi di fronte a un preallarme CRA per la vulnerabilità sfruttata, a una notifica GDPR per i dati personali coinvolti e, a seconda che rientri o meno nella normativa NIS nazionale, a una notifica per un incidente significativo che colpisce i suoi servizi.
CRA | NIS2 | GDPR | |
|---|---|---|---|
Cosa lo attiva | Una vulnerabilità attivamente sfruttata o un incidente grave che incide sulla sicurezza del prodotto | Un incidente significativo che incide sui servizi di un soggetto rientrante nell'ambito di applicazione | Una violazione dei dati personali che è probabile comporti un rischio per le persone fisiche |
Chi notifica | Fabbricanti di prodotti con elementi digitali | Soggetti essenziali e importanti | Titolari del trattamento |
Primo termine | Preallarme entro 24 ore | Preallarme entro 24 ore | Notifica entro 72 ore |
Destinatario | Piattaforma unica di segnalazione di ENISA, al CSIRT coordinatore e a ENISA | CSIRT nazionale o autorità competente | Autorità di controllo per la protezione dei dati; in Spagna, l'Agencia Española de Protección de Datos (AEPD) |
I termini sono la parte visibile. La parte difficile arriva nella prima ora, quando qualcuno deve decidere quale di questi regimi si applica, sulla base di informazioni incomplete. Tutti e tre gli orologi partono nel momento in cui l'organizzazione viene a conoscenza dell'evento, ma ciascun regime ha una propria visione di ciò di cui occorre essere a conoscenza. È una decisione facile da sottovalutare e, in molte organizzazioni, i criteri per prenderla non sono scritti da nessuna parte.
Il livello aggiuntivo della Spagna
Le organizzazioni spagnole affrontano un'ulteriore complicazione. La Spagna non ha rispettato la scadenza di ottobre 2024 per il recepimento della NIS2 e il disegno di legge destinato a farlo, l'Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, è stato approvato dal Consiglio dei ministri a gennaio 2025 e a inizio settembre 2026 non era ancora stato adottato. A luglio 2026 la Commissione europea ha deferito la Spagna alla Corte di giustizia dell'UE per il ritardo.
Fino all'approvazione della nuova legge, il Real Decreto-ley 12/2018 resta il quadro nazionale per la notifica degli incidenti. I dettagli concreti a livello nazionale, come l'autorità a cui notificare e le relative soglie, saranno definiti solo quando il testo spagnolo sarà definitivo. Questo lascia i team spagnoli a pianificare rispetto a una direttiva il cui contenuto è definito e a una legge nazionale che non possono ancora leggere. Il CRA non ha questo problema: essendo un regolamento dell'UE, si applica direttamente, in Spagna come ovunque nell'UE.
L'UE semplificherà il quadro?
Bruxelles è consapevole delle sovrapposizioni. Nell'ambito delle proposte del Digital Omnibus, la Commissione europea ha proposto un punto di accesso unico per la notifica degli incidenti, basato sulla piattaforma del CRA, in modo che un'unica notifica possa soddisfare più obblighi giuridici contemporaneamente. Al momento della stesura, resta ancora una proposta. E anche se venisse adottata, non stabilirebbe al posto di nessuno quali regimi un incidente attivi, né eliminerebbe la necessità di rispettare il termine applicabile più breve.
Scopri come il tuo team gestirebbe la prima ora
Porta il tuo attuale processo di gestione degli incidenti, per quanto informale sia oggi. Preferiamo analizzare con te uno scenario realistico piuttosto che descriverlo in astratto.
Come si presenta una buona preparazione
Prepararsi significa soprattutto prendere alcune decisioni con calma, prima che il primo incidente reale le imponga. A nostro avviso, cinque sono le più importanti:
Un'unica lista di controllo per tutti e tre i regimi. Un breve insieme di domande che verifica i presupposti di CRA, NIS2 e GDPR in un solo passaggio, invece di tre processi separati che ripartono ogni volta da zero.
Responsabili designati, con sostituti. Qualcuno deve assumersi la decisione di notificare, regime per regime, anche nei fine settimana e nei giorni festivi. Un termine di 24 ore non si ferma né per gli uni né per gli altri.
Lavoro preparatorio svolto in anticipo. Sapere quali prodotti sono disponibili in quali Paesi dell'UE, registrarsi sulla piattaforma di ENISA prima di averne bisogno e mantenere aggiornati i recapiti delle autorità.
Una registrazione di ogni decisione, comprese quelle di non notificare. Quando in seguito un'autorità chiede perché un incidente non è stato notificato, la motivazione deve già esistere, non essere ricostruita a memoria.
Un'esercitazione su uno scenario realistico. Un'esercitazione tabletop basata su un caso come quello descritto sopra mostra rapidamente dove il processo si inceppa.
Come Formalize supporta questo processo
Nessuna piattaforma può decidere al posto tuo se un incidente sia soggetto a notifica, e noi non presentiamo notifiche per tuo conto. Ciò che Formalize fa è raccogliere in un unico posto il lavoro preparatorio, così la prima ora non viene spesa a cercarlo:
Registri degli incidenti con responsabili e scadenze designati, incluse le motivazioni alla base di ogni decisione di notifica.
Le policy e i controlli alla base della gestione degli incidenti, con responsabilità chiare, documentate e mantenute aggiornate.
Il tuo lavoro su NIS2 e GDPR nello stesso sistema, invece che in strumenti separati che richiedono ciascuno un proprio aggiornamento.
Registri dei fornitori collegati alla gestione del rischio, in modo che la notifica di sicurezza di un fornitore abbia un luogo in cui confluire.
Sei una società di consulenza che sta sviluppando servizi sul Cyber Resilience Act per i propri clienti? Stiamo lavorando insieme a partner che mettono a disposizione competenze tecniche e il Formalize Partner Program è il punto da cui iniziare.
Questo articolo ha finalità puramente informative e non costituisce consulenza legale.