misure di sicurezza di base

NIS2, la vera scadenza è prima del 31 ottobre



Indirizzo copiato

Dal 31 ottobre 2026 l’ACN potrà verificare le misure NIS2 adottate dalle imprese in perimetro. Il nodo non sarà solo avere policy e procedure, ma dimostrare con evidenze continue che i processi funzionano da tempo

Pubblicato il 28 ago 2026

Andrea Cabras

CEO & Founder. Ichnos Security



nis 2
AI Questions Icon
Chiedi all'AI
Riassumi questo articolo
Approfondisci con altre fonti


C’è un fraintendimento diffuso sul 31 ottobre 2026. La maggior parte delle imprese in perimetro NIS2 legge quella data come un termine di adempimento: entro il 31 ottobre le misure di sicurezza di base devono essere adottate; dunque, c’è tempo fino al 31 ottobre per adottarle. La lettura corretta è però un’altra: il 31 ottobre non è la data entro cui si diventa conformi, ma è la data a partire dalla quale l’Agenzia per la Cybersicurezza Nazionale può verificare che lo si sia. Non è la chiusura di una finestra di lavoro; è l’apertura di una finestra ispettiva.

La differenza sembra sottile, ma sposta il problema da un piano all’altro. Se il 31 ottobre fosse un termine di adempimento, la domanda sarebbe tecnica: le misure ci sono? Poiché invece è l’inizio della fase di verifica, la domanda diventa probatoria: le misure sono dimostrabili? E qui, per esperienza diretta, posso dire in totale onestà che gran parte delle imprese ha costruito conformità, non difendibilità. Ha quindi i documenti, non le evidenze.

Le evidenze NIS2 non si scrivono: maturano

Un’ispezione non valuta le intenzioni e non valuta nemmeno, in senso stretto, i documenti. Valuta evidenze: registrazioni che dimostrano che una misura non solo esiste sulla carta, ma opera nella realtà, con continuità, da un tempo apprezzabile. E le evidenze hanno una proprietà che le distingue radicalmente dalle policy: incorporano il tempo. Una policy si scrive in pochi giorni o in una settimana; l’evidenza che quella policy viene applicata richiede mesi di funzionamento del processo che essa descrive.

Vediamo qualche esempio concreto. La misura sulla gestione delle vulnerabilità non si dimostra con la procedura di vulnerability management: si dimostra con i cicli di scansione eseguiti, i finding aperti, le remediation tracciate con date e responsabili, le eccezioni motivate e approvate. La misura sul backup non si dimostra con la policy di backup: si dimostra con i test di ripristino effettuati, verbalizzati, con esito e con data. La revisione periodica degli accessi si dimostra con le revisioni fatte, non con le dichiarazioni che verranno fatte. La formazione si dimostra con registri di erogazione ed eventi distribuiti nel tempo, non con un piano formativo approvato la settimana prima della verifica.

Il punto è che un’evidenza datata ottobre dimostra che a ottobre qualcosa è successo. Non dimostra operatività, dimostra un evento. L’operatività, che è ciò che la Determinazione ACN n. 379907/2025 richiede quando parla di misure implementate e funzionanti, è una serie di eventi coerenti nel tempo. E una serie, per definizione, non si produce in un giorno.

Ispezione ACN NIS2 e falso rifugio della ricostruzione a posteriori

A questo punto qualcuno obietta, di solito non ad alta voce: le evidenze mancanti si possono ricostruire. Si può, in teoria. Ma chiunque abbia esperienza di audit sa riconoscere un impianto documentale ricostruito: tutti i documenti in versione 1.0, tutti approvati nello stesso trimestre, nessuna non conformità mai rilevata, nessuna eccezione mai gestita, nessuna revisione che abbia mai modificato nulla. Un sistema che funziona davvero produce finding, deviazioni, azioni correttive, verbali in cui qualcosa non torna, e questa è la prova più convincente di autenticità. Un archivio perfetto non è un sistema maturo: è una scenografia, una messa in scena.

C’è poi un banco di prova che non ammette ricostruzioni: la notifica degli incidenti, operativa dal 15 gennaio 2026. La capacità di rilevare, qualificare e notificare un incidente significativo nei termini previsti si fonda su log, timeline, registri delle decisioni. O quei meccanismi stavano già girando quando l’incidente è avvenuto, o le informazioni semplicemente non esistono. È il caso limite che rende visibile la regola generale: la traccia o nasce contestualmente al fatto, o non nasce.

L’errore più diffuso: produrre documenti invece di accumulare tracce

Ed è qui che arrivo al punto che mi preme davvero. La gran parte delle organizzazioni che osservo si sta preparando, ma nel modo sbagliato. Sta scrivendo policy di gestione del rischio, procedure di incident response, piani di continuità: scaffali interi di documentazione, spesso ben fatta, mappata sui requisiti degli allegati tecnici. È un lavoro necessario in quanto le policy servono, e la loro assenza è essa stessa una non conformità, ma è la parte del lavoro che si può fare in qualunque momento, anche a ottobre. Ciò che non si può fare a ottobre è avere alle spalle sei mesi di funzionamento.

L’inversione di priorità è quasi sempre la stessa: si perfeziona il documento prima di attivare il processo, quando la logica probatoria vorrebbe l’esatto contrario. Meglio una procedura imperfetta che gira da marzo, con i suoi verbali e le sue registrazioni, che una procedura impeccabile approvata a settembre e mai eseguita. La prima è una misura operativa con margini di miglioramento; la seconda è un’intenzione ben formattata.

Prepararsi all’ispezione, quindi, non significa produrre documenti entro il 31 ottobre. Significa attivare oggi i meccanismi che generano tracce come sottoprodotto naturale del loro funzionamento: calendarizzare i riesami e tenerli, con verbale; eseguire i test di ripristino, non pianificarli soltanto; far girare il ciclo delle vulnerabilità e lasciare che il ticketing racconti la storia; erogare la formazione e registrarla; revisionare gli accessi e firmare la revisione. Il criterio pratico è uno solo, e vale per ciascuna delle misure di base: per ogni controllo, chiedersi non “abbiamo il documento?” ma “dove lascia traccia, e da quando?”. Se la risposta alla seconda domanda è “da nessuna parte” o “da ieri”, quel controllo, agli occhi di un verificatore, non esiste ancora.

L’aritmetica del calendario verso le verifiche ACN

Chiudo con un conto elementare. Da metà luglio al 31 ottobre ci sono poco più di tre mesi: tre cicli mensili di vulnerability management, tre riesami, forse due test di ripristino, una revisione trimestrale degli accessi, un’esercitazione di incident response. Non è molto, ma è una storia: un sistema che a novembre può mostrare tre mesi di funzionamento documentato racconta qualcosa di credibile. Chi invece rimanda a settembre, che è il mese in cui, tradizionalmente, i progetti di compliance italiani si risvegliano, arriverà alla finestra ispettiva con al massimo qualche settimana di tracce, e nessuna quantità di lavoro documentale potrà compensare la differenza. Perché il tempo è l’unica risorsa di questo percorso che non si può comprare, delegare o recuperare: la difendibilità è una funzione del tempo, e la variabile scorre da sola. L’unica decisione che resta da prendere è quando iniziare a farla lavorare a proprio favore.

Partecipa alla community

guest

0 Commenti
Più recenti
Più votati
Inline Feedback
Vedi tutti i commenti

Articoli correlati

0
Lascia un commento, la tua opinione conta.x