NIS2, cosa cambia dal 2026 e come prepararsi senza errori

Dal primo gennaio 2026 si concretizza per molte aziende italiane un passaggio decisivo nella governance della cybersicurezza: la piena attuazione degli obblighi di notifica degli incidenti secondo la Direttiva NIS2 e l’interazione operativa con l’Agenzia per la Cybersicurezza Nazionale (ACN) e il CSIRT Italia.

Esploriamo la norma, le scadenze, i contenuti degli adempimenti e proviamo a fornire una cassetta degli attrezzi pratica per arrivare pronti alla data fatidica.

L’obiettivo è far sì che non si tratti solo di “fare registrazioni”, ma di avere un processo strutturato, operativo, ben integrato nella struttura aziendale: in altre parole, essere davvero pronti.

Perché la NIS2 rende il 2026 un punto di svolta per le aziende

Perché questa scadenza è cruciale per le aziende:

• Responsabilità del top management – La norma attribuisce responsabilità specifiche agli organi di gestione: il consiglio di amministrazione, il dirigente responsabile devono garantire che i processi siano attivi e funzionanti. Non è più un “mestiere dell’IT”, ma una questione strategica.
• Penalità e rischio reputazionale – Il mancato rispetto degli obblighi di notifica e gestione può comportare sanzioni significative, oltre al danno reputazionale, alla perdita di fiducia, a possibili effetti contrattuali e assicurativi.
• Catena del valore e terze parti – I fornitori e partner diventano un fattore critico: se un fornitore non adeguato causa un incidente, la responsabilità può ricadere anche sull’azienda principale. È dunque necessario un approccio “supply-chain” alla sicurezza.
• Tempestività e trasparenza – La logica della notifica rapida significa che le attività aziendali non possono più essere gestite in modalità reattiva disorganizzata: serve un processo definito, testato e collaudato.
• Vantaggio competitivo – Le aziende che arrivano preparate acquisiscono maggiore credibilità nei confronti di clienti, partner e mercati: la compliance diventa un asset.

Comprendere quando un incidente diventa significativo secondo la NIS2

Per “incidente” si intende un evento che compromette la disponibilità, l’autenticità, l’integrità o la riservatezza dei sistemi di rete o informazione, o dei servizi forniti da tali sistemi.

Un incidente diventa “significativo” (e quindi soggetto a obbligo di notifica) quando provoca oppure è in grado di provocare una grave interruzione operativa dei servizi o perdite finanziarie per l’entità; oppure ha effetti su altre persone giuridiche o naturali con significative perdite materiali o immateriali.

La NIS2 e le fasi obbligatorie di notifica: tempistiche e contenuti

Le fasi chiave della notifica in Italia (secondo art. 25 del D.Lgs. 138/2024) sono:

Pre-notifica entro 24 ore

Pre-notifica o informazione senza tardività (entro 24 ore dalla consapevolezza dell’incidente) ad ACN/CSIRT Italia, con una prima valutazione preliminare: indicare se l’incidente può derivare da reato, se ha impatto transfrontaliero.

Notifica formale entro 72 ore

Notifica formale entro un termine massimo (in genere 72 ore) che deve includere la valutazione dell’impatto, le metriche iniziali, la natura dell’incidente.

Report finale e aggiornamenti mensili

Report finale entro un mese dal completamento della gestione dell’incidente: descrizione del tipo di incidente, causa radice, misure di mitigazione adottate, impatto transfrontaliero se noto.

Se l’incidente è ancora in corso, sono richiesti report mensili di progresso.

La “cassetta degli attrezzi” per essere pronti al 1° gennaio 2026 è di seguito un percorso strutturato — passo per passo — con gli strumenti, i documenti, i ruoli, i processi che ogni azienda soggetta a NIS2 dovrebbe attivare e mantenere.

Puoi considerarlo come un kit operativo da personalizzare secondo dimensione aziendale, settore e rischio.

Diagnosi preliminare e gap-analysis: il primo passo verso la compliance NIS2

Il primo passo per un’azienda che intende rispettare la NIS2 entro la deadline del 1° gennaio 2026 consiste nell’acquisire consapevolezza del proprio reale livello di esposizione.

Non si tratta di verificare genericamente se i sistemi informatici siano protetti, ma di mappare con precisione ciò che va difeso: asset digitali, servizi critici, applicazioni core, infrastrutture cloud, interconnessioni di rete, processi che sostengono attività operative e continuità dei servizi.

Questa mappatura non può essere solo inventariata, ma deve essere collegata al valore di business: occorre infatti identificare quali dati e servizi, se compromessi, genererebbero blocchi produttivi, perdite economiche, compromissioni contrattuali o danni reputazionali.

Una mappa statica degli asset non è sufficiente: è indispensabile ricostruire le interdipendenze, incluse quelle con fornitori tecnologici e partner di filiera. Un singolo servizio cloud o un partner inattivo può diventare l’origine di un incidente significativo anche senza che un sistema interno venga violato.

Parallelamente, l’azienda deve definire per sé stessa cosa sia “significativo” ai fini della NIS2.

L’errore più comune è ritenere che la significatività sia determinabile solo “a posteriori”, a incidente avvenuto.

La normativa richiede invece di definire preventivamente le soglie che attivano l’obbligo di notifica: quali metriche determinano l’impatto? Quante ore di interruzione di servizio? Quale volume di clienti coinvolti? Quale perdita economica o reputazionale?

Senza questa definizione documentata, l’azienda rischia di notificare troppo tardi, commettendo un’inadempienza formale anche in presenza di un incidente gestito tecnicamente in modo corretto.

È poi fondamentale verificare se l’organizzazione rientra tra le entità essenziali o entità importanti.

Molte aziende sbagliano ritenendo che la NIS2 si applichi solo alle infrastrutture critiche o alle grandi imprese: in realtà, anche realtà di dimensioni medie o appartenenti a settori non tradizionalmente considerati “sensibili” rientrano nel perimetro se superano determinate soglie dimensionali o se svolgono attività classificate come rilevanti a livello nazionale o europeo.

Conoscere con precisione la propria classificazione non è un elemento burocratico, ma l’anticamera delle responsabilità sanzionatorie e gestionali.

La diagnosi deve chiudersi con una gap-analysis strutturata rispetto ai requisiti richiesti dalla NIS2.

Il punto non è “siamo conformi o non lo siamo?”, bensì “quale distanza ci separa dall’obiettivo?” e, soprattutto, “qual è l’impatto sul business se non colmiamo quel gap in tempo?”.

I controlli richiesti dalla normativa non sono meri requisiti tecnici: si parla di governance, gestione del rischio ICT, continuità operativa, cyber-resilience della supply chain, processi di incident response e notificazione.

Un CEO deve porsi una domanda semplice e strategica: se domani subissimo un attacco cyber con impatto significativo, saremmo realmente in grado di gestirlo e di notificarlo entro i tempi previsti dalla legge?

Questo primo step non è un esercizio teorico, ma l’unica base solida per definire un piano di adeguamento realistico, misurabile e sostenibile.

Le aziende che saltano questa fase si ritrovano poi a rincorrere scadenze, ad acquistare soluzioni inutili o a distribuire responsabilità tecniche senza una visione d’insieme.

Quelle che la affrontano con metodo, invece, ottengono un vantaggio competitivo: maggiore prevedibilità dei rischi, priorità di investimento chiare e una roadmap di compliance che tutela la continuità operativa oltre a rispettare l’obbligo normativo.

Governance NIS2: ruoli, responsabilità e coinvolgimento del top management

Quando si parla di NIS2, è essenziale che il vertice aziendale comprenda che la cybersicurezza non è più un tema delegabile “al reparto IT”.

La Direttiva introduce un paradigma nuovo: la resilienza digitale è un fattore di continuità operativa e quindi un tema di governance strategica.

Se i processi decisionali, di allocazione del budget e di gestione del rischio non includono la cybersecurity, l’azienda non potrà rispettare la NIS2 nemmeno avendo ottime tecnologie.

Nomina del responsabile della sicurezza

Per essere davvero pronti al 1° gennaio 2026, il top management deve definire ruoli e responsabilità con chiarezza.

Serve un responsabile della sicurezza informatica formalmente nominato, con mandato, risorse e autonomia decisionale.

Se il CISO non può approvare budget o non partecipa ai comitati decisionali, resta un ruolo “di nome”: e la responsabilità — in caso di incidente — risale al Consiglio di Amministrazione.

Incident Management Team e flussi decisionali

In parallelo è necessario istituire una struttura di comando in caso di incidente, ossia un Incident Management Team che includa non solo personale tecnico, ma anche responsabili legali, comunicazione, continuità operativa e, se necessario, supply chain e HR.

Questo team non deve attivarsi “se serve”: deve esistere ed essere già addestrato prima dell’incidente, perché il tempo di latenza decisionale è ciò che determina la tempestività della notifica verso ACN/CSIRT.

Infine, la governance richiede accountability: il CdA deve prevedere report periodici sul livello di sicurezza, sugli incidenti intercettati, sui test simulati e sulla maturità dei sistemi strategici.

Un CEO deve poter rispondere a una domanda semplice: se stasera subissimo un attacco ransomware, chi decide, chi firma le comunicazioni, chi notifica, con quali criteri e in quanto tempo?

Se la risposta non è immediata e condivisa da tutti, la governance non è pronta per la NIS2.

Procedure operative conformi alla NIS2: incident response, continuità e notifiche

La tecnologia senza processi non produce né compliance, né resilienza.

Per rispettare la NIS2, un’azienda deve disporre di un corpus documentale aggiornato, non creato per “fare audit”, ma strutturato per essere seguito realmente durante un incidente.

Le tre procedure cardine sono: gestione degli incidenti, business continuity/disaster recovery e notifica degli incidenti.

Una procedura efficace non è un documento teorico: deve chiarire come avviene l’identificazione, la classificazione e la priorità degli incidenti; quando si passa dalla fase di sospetto alla consapevolezza (che fa scattare l’obbligo di notifica); quali figure devono essere coinvolte; come si autorizzano decisioni che hanno impatto operativo ed economico; come vengono registrate e conservate le evidenze.

Molte aziende sottovalutano la necessità di definire in anticipo i criteri di classificazione degli incidenti.

Se non è stabilito con precisione cosa renda un incidente “significativo” ai fini normativi, l’azienda rischia due errori opposti ma ugualmente critici: notificare troppo tardi (con sanzioni), oppure notificare qualsiasi evento (perdendo credibilità e sovraccaricando le autorità).

Il CEO deve pretendere procedure che permettano scelte rapide e difendibili, supportate da metriche oggettive.

Infine, le procedure devono essere allineate con i contratti dei fornitori.

Se durante un attacco l’azienda dipende da servizi cloud o applicazioni esterne, ma il contratto non prevede obblighi di supporto tempestivo, l’intera struttura di risposta crolla.

Per questo motivo la procedura interna e gli SLA contrattuali devono parlarsi: un CEO che firmi contratti ICT senza verificare impatti sulla cybersecurity mette l’azienda in una posizione vulnerabile.

Monitoraggio e rilevamento: l’elemento che abilita la notifica NIS2

Non si può notificare un incidente in 24 o 72 ore se non lo si rileva.

Questo è il passaggio più sottovalutato dalla maggior parte delle aziende.

I cyber attacchi moderni sono progettati per rimanere silenti il più a lungo possibile.

Senza sistemi di logging centralizzato, analisi comportamentale, detection e allerta, gli incidenti vengono scoperti troppo tardi per poter rispettare gli obblighi della NIS2.

Per questo il monitoraggio non è un optional tecnico, ma un pilastro normativo.

I CEO devono comprendere che strumenti come SIEM, EDR, IDS/IPS o piattaforme di threat intelligence non riguardano solo la prevenzione dell’attacco, ma la possibilità stessa di rispettare la tempistica di notifica prevista dalla direttiva.

Il passaggio cruciale è la definizione del momento di “consapevolezza dell’incidente”.

L’azienda deve stabilire ex ante quale evento attiva l’obbligo di notifica: un malware rilevato dagli antivirus non è automaticamente una “consapevolezza”, mentre un blocco di servizio, un’esfiltrazione di dati, un accesso non autorizzato confermato o un allarme proveniente da un partner lo sono.

Per evitare discussioni interne nel panico dell’emergenza, la definizione deve essere scritta, approvata e conosciuta da tutto l’Incident Management Team.

Notifiche NIS2: criteri, responsabilità e documentazione necessaria

Notificare non significa “mandare una comunicazione quando si può”: significa rispettare una procedura scandita nel tempo.

Entro 24 ore dal momento in cui l’azienda acquisisce consapevolezza dell’incidente deve essere emesso un alert preliminare (“early warning”), seguito entro 72 ore da una notifica dettagliata con analisi dell’impatto e informazioni tecniche.

Entro un mese dalla conclusione dell’incidente deve essere depositato un report finale, oppure — se l’incidente è ancora in corso — devono essere inviati report mensili di avanzamento.

Per far funzionare questo meccanismo servono due fattori che molte aziende non hanno: template pronti e autorizzazioni ex ante.

In emergenza, non si possono perdere ore a capire cosa scrivere, chi deve firmare, chi deve autorizzare una comunicazione a un’autorità nazionale.

Il CEO deve assicurarsi che i flussi decisionali siano già stati approvati e che non dipendano da processi burocratici interni.

Miglioramento continuo e audit: cosa richiede davvero la NIS2

La NIS2 non si limita a chiedere che l’incidente sia gestito: pretende che l’organizzazione ne tragga insegnamento.

Dopo la chiusura di ogni evento deve essere eseguita una revisione post-incident con identificazione delle cause radice, verifica delle vulnerabilità che hanno permesso l’attacco, valutazione delle misure correttive, test di efficacia e aggiornamento delle procedure.

Il CEO deve pretendere che ogni incidente produca un miglioramento strutturale: se un’organizzazione affronta due incidenti simili e commette gli stessi errori, questo sarà interpretato dalle autorità come una mancanza di governance.

Documentazione e evidenze di compliance

La NIS2 si basa su un principio molto chiaro: “non esiste compliance senza evidenze documentali”.

È irrilevante dichiarare che qualcosa “è stato fatto”: bisogna dimostrarlo.

Per questo l’azienda deve conservare procedure, registri degli incidenti, log, verbali dei comitati cyber, prove di formazione, report tecnici e report di notifica.

In un’ispezione, l’autorità non chiederà se l’azienda abbia buone intenzioni, ma se sia in grado di documentare cronologicamente la gestione e la notifica dell’incidente.

Quale è il messaggio chiave per i CEO?

La NIS2 non richiede una protezione informatica teorica, ma la capacità di continuare a operare sotto attacco.

Le aziende che saranno pronte il 1° gennaio 2026 non saranno quelle con più software, ma quelle che avranno:
• governance solida,
• processi collaudati,
• ruoli chiari,
• decisioni rapide,
• capacità di notifica tempestiva e documentata.

Chi pensa che la NIS2 sia solo un obbligo legale, farà tardi.
Chi la vede come un percorso di resilienza, sarà già avanti.

Roadmap NIS2: come organizzare il percorso fino al 1° gennaio 2026

Road-map operativa fino al 1° gennaio 2026

Alcuni errori comuni da evitare

• Mancanza di “consapevolezza” dell’incidente: la norma considera come avvenuta la “consapevolezza” dell’incidente quando l’azienda ha acquisito elementi oggettivi, non è solo un sospetto. Se non definito correttamente il momento di trigger, si rischia ritardo nella notifica.
• Procedure testate solo “a tavolino” e non nel mondo reale: senza simulazioni reali, la probabilità che i tempi di notifica vengano sforati aumenta.
• Non coinvolgere il top management: se la responsabilità è solo dell’IT, manca il “mandato” strategico necessario.
• Non considerare le terze parti: molte aziende dimenticano il rischio derivante da fornitori ICT che non sono conformi, e questo può inficiare la capacità di rispettare la notifica.
• Non aggiornare la documentazione: politiche e procedure scritte e mai riviste diventano obsolete e inutili.
• Non conservare le evidenze: in caso di controllo dell’ACN si richiede la prova che la notifica è stata fatta nei tempi e con i contenuti richiesti. Senza evidenze, l’azienda è vulnerabile.

Il 1° gennaio 2026 non è una semplice data sul calendario: è il momento in cui la cybersicurezza aziendale smette di essere solo un tema tecnico e diventa un imperativo normativo e strategico per molte organizzazioni.

Se sei responsabile della sicurezza, del rischio, dell’IT o del business in un’azienda soggetta alla Direttiva NIS2, la domanda fondamentale è: “Siamo davvero pronti?”

L’implementazione di processi strutturati di notifica degli incidenti non rappresenta un’opzione facoltativa, bensì un pilastro fondamentale della resilienza operativa.

Le organizzazioni che adotteranno tali procedure saranno in grado non solo di reagire efficacemente agli eventi critici, ma anche di anticiparli, prevenirli e trasformarli in un’opportunità di rafforzamento e crescita.