NIS2: il minimo ACN non si compra, si dimostra

La stagione delle slide sulla NIS2 è finita. Per molte imprese inserite da ACN nell’elenco dei soggetti NIS nella prima tornata, i diciotto mesi per mettere in piedi le misure di sicurezza di base stanno per esaurirsi. Attenzione però: non esiste una data unica valida per tutti. Il conto parte dalla comunicazione con cui l’Agenzia ha notificato all’organizzazione l’inserimento nell’elenco, quindi va verificato caso per caso.

Il dettaglio conta per la pianificazione, ma non cambia la sostanza. Molte aziende arrivano alla scadenza con il firewall nuovo, le licenze rinnovate e un raccoglitore di procedure, e restano senza risposta davanti alla domanda più semplice: come si dimostra che quelle misure sono davvero adottate?

La risposta non è un altro acquisto. È la capacità di collegare ogni misura a un responsabile, a una configurazione verificabile, a una prova recente e a una decisione presa consapevolmente. La determinazione ACN n. 164179 del 14 aprile 2025 fissa una base minima comune: non trasforma la sicurezza in un catalogo prodotti e non sostituisce l’analisi del rischio che la NIS2 chiede a ciascuna organizzazione.

La buona notizia, per chi lavora in una PMI, è che quasi tutto ciò che serve è già in casa. Va solo reso visibile.

1. La scadenza cambia da azienda ad azienda, la responsabilità no

Nel regime di prima applicazione gli obblighi decorrono dalla comunicazione ACN, non da un giorno segnato sul calendario nazionale. Il primo documento da recuperare, quindi, non è il preventivo del fornitore: è la comunicazione ricevuta dall’Agenzia, insieme alla registrazione sul portale e all’aggiornamento periodico dei dati che il decreto richiede a inizio anno.

Da lì si ricostruisce la cronologia. Il decreto legislativo 4 settembre 2024, n. 138, che recepisce la NIS2 in Italia, tiene distinti gli obblighi di gestione del rischio da quelli di notifica degli incidenti, con tempistiche diverse. La determinazione ACN traduce poi quegli obblighi in specifiche di base differenziate tra soggetti essenziali e soggetti importanti.

Il punto che sfugge più spesso è che «di base» non vuol dire né facoltativo né sufficiente in ogni situazione. Vuol dire che ACN ha fissato un pavimento comune. Se l’azienda gestisce impianti complessi, dati particolarmente delicati o dipendenze critiche da pochi fornitori, fermarsi al pavimento può essere del tutto inadeguato rispetto al rischio reale.

La direttiva su questo è esplicita: l’articolo 21 chiede misure tecniche, operative e organizzative adeguate e proporzionate, con un approccio che consideri tutti i rischi. Nell’elenco compaiono gestione degli incidenti, continuità operativa, backup e ripristino in caso di disastro, sicurezza della catena di fornitura, controllo degli accessi e autenticazione a più fattori dove appropriata.

Tradotto: non si chiude la pratica dicendo «abbiamo implementato i controlli ACN». Bisogna sapere su quali sistemi, con quale copertura, rispetto a quali rischi e con quali eccezioni consapevolmente accettate.

2. «Adottata» non vuol dire «comprata»

Una misura è comprata quando esiste un ordine. È installata quando compare nell’inventario. È adottata quando entra nel modo in cui l’azienda lavora tutti i giorni e quando qualcuno può dimostrarne il funzionamento senza improvvisare.

Prendiamo il backup, che è il caso più frequente. Avere una piattaforma che fa copie notturne non prova affatto che l’azienda sappia rimettere in piedi i servizi. Servono una copertura documentata dei sistemi (compresi i SaaS, che quasi nessuno include), una politica di conservazione, protezioni contro cancellazione e cifratura ostile, e test di ripristino con esito scritto da qualche parte. RPO e RTO devono rispecchiare quanto l’azienda può stare ferma davvero, non i valori predefiniti del software.

Stesso discorso per le identità. Comprare licenze MFA non significa aver protetto gli accessi se restano fuori gli account amministrativi, le utenze condivise di reparto o le procedure di emergenza mai provate. Un elenco aggiornato degli account privilegiati, la traccia delle revisioni e la prova che un accesso viene revocato lo stesso giorno in cui una persona esce dall’azienda dicono molto più di una schermata del prodotto.

Anche le procedure possono essere perfettamente scritte e operativamente inutili. Un piano di risposta agli incidenti salvato solo sul file server colpito dal ransomware non è un piano. Una matrice di escalation con dentro persone che non lavorano più in azienda non è una misura adottata. Un numero di reperibilità mai chiamato è una riga in un documento.

La NIS2 sposta l’attenzione dal possesso al funzionamento. Non pretende strutture enormi: una PMI può documentare benissimo processi semplici, spesso meglio di un gruppo con dieci livelli di governance. Pretende però coerenza fra ciò che si dichiara, ciò che è configurato e ciò che succede quando si fa una prova.

3. La prova che manca quasi mai è tecnica

La maggior parte delle aziende ha già gran parte delle tecnologie necessarie. Quello che manca è una catena di evidenze leggibile anche da chi non amministra i sistemi ogni giorno.

Per ogni misura conviene tenere un fascicolo minimo, breve e aggiornato:

• il perimetro: sedi, servizi, applicazioni, identità e fornitori coperti;
• chi risponde della misura in azienda e chi la esegue operativamente;
• la regola approvata, con le eccezioni e il motivo per cui esistono;
• la prova tecnica: configurazioni esportate, log, report, ticket, verbali di test;
• ogni quanto si verifica e qual è stato l’ultimo esito;
• cosa manca ancora, con priorità, responsabile e decisione presa.

Non è burocrazia. È il modo più economico per evitare che tutta la conoscenza resti nella testa del tecnico interno o dentro il portale del fornitore. Se il system integrator cambia la persona che segue il cliente, il fascicolo permette all’azienda di restare in controllo. Se capita un incidente, riduce il tempo per capire cosa era previsto e cosa non ha funzionato.

Un’avvertenza sul formato: le evidenze devono essere esportabili. Un report che esiste solo nella dashboard SaaS del vendor non è una prova sotto il controllo dell’azienda. Va conservata una copia con data, ambito e risultato, in un archivio protetto ma raggiungibile anche quando il sistema principale è giù — compresi i contatti di emergenza, che non possono stare solo sulla posta aziendale.

Non servono migliaia di screenshot. Servono poche prove capaci di rispondere a domande concrete. Chi ha rivisto l’elenco degli amministratori, e quando? Qual è l’ultimo database ripristinato per davvero? Quali sistemi non mandano log da nessuna parte? Quale fornitore può entrare da remoto, con che credenziali e in quali orari? Quanto tempo è passato fra la rilevazione dell’ultima anomalia e la sua presa in carico?

Ultima nota utile a chi ha già investito in certificazioni: una ISO/IEC 27001 aiuta a strutturare il sistema di gestione, ma non dimostra automaticamente l’adozione delle specifiche ACN. Perimetri e controlli vanno confrontati uno a uno, e la certificazione di una sede o di una linea di servizio non copre l’intero sistema informativo aziendale.

4. La direzione non può delegare la firma al firewall

L’articolo 20 della direttiva affida agli organi di gestione il compito di approvare le misure di gestione del rischio e di vigilare sulla loro attuazione, oltre a prevedere una formazione adeguata per chi guida l’organizzazione. Nessuno chiede all’amministratore delegato di configurare un SIEM. Si chiede però che la sicurezza smetta di essere una voce delegata integralmente all’esterno.

La prova di questa responsabilità non è una firma su una policy scritta dal consulente: è un processo decisionale riconoscibile. La direzione riceve informazioni sintetiche, capisce dove sono le carenze principali e approva priorità, budget ed eventuali rischi che si decide di tenersi.

Due pagine a trimestre valgono più di cento pagine di assessment. Bastano pochi indicatori legati alla continuità del business: copertura MFA, account privilegiati non revisionati, sistemi fuori supporto, vulnerabilità critiche oltre i tempi previsti, esito dell’ultimo test di ripristino, fornitori senza alternativa praticabile.

Il passaggio che fa davvero la differenza sono le eccezioni. In ogni PMI esistono un macchinario con il PC di controllo che non si può aggiornare, un gestionale legacy, un collegamento remoto storico. Nasconderli produce una conformità finta; registrarli permette di decidere contromisure realistiche — segmentazione di rete, accesso mediato, logging rafforzato, un piano di sostituzione con una data.

È anche il terreno su cui un system integrator italiano di dimensioni umane può valere più di un grande contratto impersonale: conosce l’ambiente, accompagna le prove, risponde al telefono quando serve. A una condizione: che consegni configurazioni, documentazione ed evidenze in un formato che resti all’azienda. La vicinanza operativa è un vantaggio; la dipendenza senza documentazione è solo un altro lock-in.

5. Anche chi è fuori perimetro riceverà le domande

La NIS2 non si ferma al confine dell’organizzazione registrata. L’articolo 21 include espressamente la sicurezza della catena di fornitura e dei rapporti con i fornitori diretti, e chiede di tenere conto delle vulnerabilità specifiche di ciascuno e della qualità delle sue pratiche di sicurezza.

Risultato pratico: una software house, un MSP o una PMI manifatturiera che non è soggetto NIS riceverà comunque questionari, clausole contrattuali e richieste di verifica dai clienti che lo sono. Non è un’estensione automatica degli obblighi; è la conseguenza della responsabilità che grava sul cliente nel governo della propria filiera.

Le richieste ragionevoli riguardano accesso remoto, gestione delle vulnerabilità, tempi di comunicazione degli incidenti, separazione dei dati fra clienti, continuità del servizio e uso di subfornitori. Quelle meno ragionevoli provano a scaricare genericamente «ogni responsabilità NIS2» sul fornitore, senza descrivere servizi, perimetri e livelli attesi: si negoziano, non si firmano.

Per la PMI fornitrice la mossa intelligente non è compilare ogni volta un questionario da zero, ma preparare una volta sola un pacchetto di evidenze riutilizzabile: architettura del servizio, ruoli e modalità di accesso, ciclo di patching, processo di gestione degli incidenti, esito dei test di backup, elenco delle dipendenze critiche, contatti di escalation. Le informazioni più sensibili si condividono a livelli, senza distribuire dettagli che aumenterebbero il rischio. Chi arriva preparato accorcia le trattative e, molto spesso, vince la gara contro concorrenti che ancora rispondono a mano.

Attenzione ai contratti. Se il cliente pretende comunicazione tempestiva degli incidenti, il fornitore deve sapere quali eventi fanno scattare l’obbligo, verso quale contatto e con quali informazioni minime. Formule come «immediatamente» generano contenziosi proprio nel momento peggiore. Tempi, canali e responsabilità vanno resi compatibili con il processo di notifica che il soggetto NIS deve rispettare.

6. Il minimo utile: una verifica che attraversa un servizio dall’inizio alla fine

In queste settimane la scelta peggiore è aprire un progetto monumentale. La scelta utile è prendere un servizio critico — quello che se si ferma ferma l’azienda — e attraversarlo tutto: chi ne risponde, su quale infrastruttura gira, quali identità lo governano, dove stanno i dati, come si fa il backup, dove finiscono i log, quali fornitori sono coinvolti, cosa si fa se si rompe di sabato sera. Se non si riesce a farlo per un servizio solo, allargarlo a tutta l’azienda produrrà soltanto più documenti incompleti.

Primo passaggio: confrontare le specifiche ACN applicabili con l’ambiente reale e marcare ogni misura come operativa, parziale o assente. «Operativa» deve voler dire che esiste una prova recente. «Parziale» deve dire cosa manca, non «in corso di adeguamento».

Secondo passaggio: provare le funzioni che contano in crisi. Ripristinare un sistema davvero, revocare un account privilegiato, recuperare i contatti di emergenza senza usare la posta aziendale, leggere i log di un accesso remoto, simulare la telefonata al fornitore. Mezza giornata di prove fa emergere più problemi di un assessment compilato a tavolino.

Terzo passaggio: portare alla direzione un quadro leggibile. Non tutto si risolve insieme, ma tutto deve essere visibile e ordinato per impatto e probabilità. L’approvazione delle priorità è ciò che trasforma un elenco tecnico in una decisione aziendale.

Quarto: conservare il risultato. Verbali, report dei test, esportazioni delle configurazioni, decisioni sulle eccezioni. Sono la memoria operativa dell’azienda: utili durante una verifica, indispensabili quando cambia una persona, quando un fornitore diventa irraggiungibile o quando si lavora sotto pressione.

I testi da tenere sul tavolo sono tre: la direttiva (UE) 2022/2555, in particolare gli articoli 20, 21 e 23; il decreto legislativo 4 settembre 2024, n. 138; la determinazione ACN n. 164179 del 14 aprile 2025 con le relative specifiche di base. Vanno letti insieme alla comunicazione che ACN ha inviato all’azienda, perché è quella a stabilire qualifica e decorrenze nel caso concreto.

La scadenza non dovrebbe lasciare un faldone da archiviare. Dovrebbe lasciare qualcosa di più utile: sapere quali servizi reggono, quali dipendenze possono bloccarli e chi interviene quando gli strumenti di tutti i giorni smettono di funzionare. È la differenza fra aver comprato sicurezza e averla adottata.