Quando ad aprile 2025 l’Agenzia per la cybersicurezza nazionale (ACN) pubblicò le prime indicazioni sulla NIS2 con 43 misure di base, si era puntualizzato che erano solo la punta dell’iceberg. Oggi, con le linee guida complete del 4 settembre, viene espressamente confermato quanto scritto in aprile: non sono 100 le azioni concrete da implementare, ma molte di più se contiamo tutti i punti operativi per i soggetti essenziali.
La chiave per capirlo era semplice: bastava guardare il framework nazionale di cybersecurity 2.0, derivato direttamente dal NIST americano. L’ACN non avrebbe mai potuto limitarsi a 43 misure quando il framework completo ne prevede 108. Era matematicamente impossibile che la versione definitiva non espandesse significativamente i requisiti. Nella nostra esperienza con decine di enti pubblici, chi ha costruito fin da subito sul framework completo oggi deve solo fare piccoli aggiustamenti. Chi si è fermato alle indicazioni minime deve ricominciare.
Indice degli argomenti
La struttura reale delle linee guida: molto più di 43 misure
Le linee guida definitive confermano la struttura che era stata prevista: 6 funzioni principali del framework, non 43 misure ma 43 codici che si espandono in multipli punti operativi, una distinzione netta tra soggetti importanti ed essenziali con requisiti aggiuntivi.
Prendiamo un esempio concreto per capire la portata reale. La misura GV.RR-04 (cybersecurity nelle pratiche HR) prevede:
- Punto 1: Valutazione esperienza e affidabilità del personale
- Punto 2: Valutazione specifica per amministratori di sistema
- Punto 3: Procedure documentate per i punti 1 e 2
- Punto 4 (solo essenziali): Obblighi post-cessazione del rapporto di lavoro
- Punto 5 (solo essenziali): Procedure per il punto 4
Una singola misura si traduce quindi in 3-5 azioni concrete, ognuna con documentazione, procedure e implementazione specifica. Moltiplica questo per 43 misure e si arriva facilmente a oltre 100 punti operativi. Per i soggetti essenziali, considerando le misure aggiuntive come ID.AM-03, PR.AT-02, PR.PS-01, PR.PS-03, PR.IR-03 e RC.CO-03, superiamo abbondantemente le 120 azioni.
Il framework NIST come chiave di lettura anticipata
Già ad aprile era evidente che l’ACN stesse seguendo l’approccio del NIST Cybersecurity Framework. Le 6 funzioni (Govern, Identify, Protect, Detect, Respond, Recover) non sono un’invenzione italiana ma lo standard de facto internazionale. Abbiamo visto questo pattern ripetersi in ogni paese che ha implementato normative simili: si parte con indicazioni minime per non spaventare, poi si arriva inevitabilmente al framework completo.
La funzione GOVERN, introdotta nella versione 2.0 del framework, era il segnale più chiaro. Include aspetti fondamentali come:
- GV.OC (Contesto Organizzativo): comprensione del contesto in cui opera l’organizzazione
- GV.RM (Risk Management Strategy): approccio strategico alla gestione del rischio
- GV.RR (Ruoli e Responsabilità): definizione chiara delle responsabilità in materia di cybersecurity
- GV.PO (Policy): le famose 16 politiche di sicurezza richieste
- GV.SC (Supply Chain): gestione del rischio nella catena di fornitura
Questi elementi erano già tutti presenti nel framework nazionale pubblicato a dicembre 2024. Chi li aveva studiati sapeva che sarebbero diventati requisiti obbligatori.
Gli allegati tecnici necessari: la parte operativa nascosta
Le linee guida richiedono una quantità impressionante di documentazione tecnica. L’Appendice C elenca 11 documenti che devono essere formalmente approvati dagli organi amministrativi e direttivi. Ma questo è solo l’inizio. Nella nostra analisi, per implementare correttamente tutte le misure servono almeno 6 allegati operativi strutturati.
Allegato A – Inventario Asset (per ID.AM-01, 02, 03, 04) Deve contenere non solo l’elenco di hardware e software, ma anche i flussi di rete (solo per essenziali), i servizi cloud, i sistemi rilevanti con classificazione di criticità. Ogni asset deve essere mappato con il suo owner, la criticità per il business, le interdipendenze con altri sistemi. Non è un semplice inventario Excel: è la base per tutta la gestione del rischio.
Allegato B – Organizzazione e Ruoli (per GV.RR-02, GV.RR-04) Va oltre l’organigramma. Serve una matrice RACI completa per tutti i processi di sicurezza, il registro delle deleghe formali, le procedure per la valutazione del personale, e per i soggetti essenziali anche la gestione degli obblighi post-cessazione. Stiamo vedendo molti enti sottovalutare questo aspetto: senza ruoli chiari, tutto il sistema crolla.
Allegato C – Supply Chain (per GV.SC-01, 02, 04, 05, 07) La gestione dei fornitori è uno degli aspetti più complessi. Serve l’anagrafica completa con classificazione del rischio, i requisiti di sicurezza contrattualizzati, il registro delle non conformità, le valutazioni periodiche. Ogni fornitore con accesso ai sistemi deve essere valutato secondo criteri oggettivi e documentati.
Allegato D – Configurazioni e Baseline (per PR.PS-02, PR.PS-06) Le baseline di sicurezza devono essere definite per ogni tipologia di sistema. Windows Server, Linux, apparati di rete, database: ognuno richiede configurazioni specifiche documentate e verificabili. Include anche il registro delle deroghe autorizzate e il tracking della compliance.
Allegato E – Formazione (per PR.AT-01, PR.AT-02) Non basta un generico “piano formazione”. Servono percorsi differenziati per ruolo, tracking delle presenze, valutazione dell’efficacia, certificazioni professionali. Per i soggetti essenziali, anche programmi di security awareness continua con metriche di efficacia.
Allegato F – Rischi e Incidenti (per ID.RA, RS.MA, metriche) Il cuore operativo del sistema. Risk register dettagliato con metodologia chiara, registro vulnerabilità con SLA di remediation, registro incidenti con analisi root cause, KPI di sicurezza (MTTD, MTTR), lessons learned per il miglioramento continuo.
La differenza tra soggetti importanti ed essenziali: non solo quantità
Un errore comune è pensare che la differenza tra soggetti importanti ed essenziali sia solo quantitativa. In realtà, i soggetti essenziali hanno requisiti qualitativamente diversi che richiedono un approccio più maturo.
Le 6 misure esclusive per gli essenziali (ID.AM-03, PR.AT-02, PR.PS-01, PR.PS-03, PR.IR-03, RC.CO-03) introducono concetti avanzati:
- Mappatura completa dei flussi di rete, non solo degli asset
- Programmi di awareness strutturati per tutto il personale
- Secure Software Development Lifecycle (SSDLC)
- Change management formalizzato per le modifiche
- Sistemi di comunicazione di emergenza protetti
- Comunicazione strutturata del ripristino agli stakeholder
Ma anche le misure condivise hanno spesso punti aggiuntivi per gli essenziali. La DE.CM-01 (monitoraggio continuo) per gli importanti richiede 2 punti, per gli essenziali ne richiede 6, includendo correlazione avanzata degli eventi e behavioral analytics.
I documenti da far approvare: il nodo della governance
L’Appendice C delle linee guida è cristallina: 11 documenti devono essere approvati formalmente dagli organi di amministrazione e direttivi; questo significa un coinvolgimento anche formale della Giunta o del Consiglio o comunque dell’organo collegiale apicale dell’organizzazione, non semplici determine dirigenziali.
I documenti richiesti sono:
- Organizzazione per la sicurezza informatica – La struttura, i ruoli, le responsabilità
- Politiche di sicurezza informatica – 16 ambiti distinti, non un documento generico
- Valutazione del rischio – Metodologia e risultati dell’assessment
- Piano di trattamento del rischio – Come si affrontano i rischi identificati
- Piano di gestione delle vulnerabilità – Processi di identificazione e remediation
- Piano di adeguamento – Gap analysis e roadmap di implementazione
- Piano di continuità operativa – Il BCP completo con test documentati
- Piano di ripristino in caso di disastro – DRP con RTO/RPO definiti
- Piano di gestione delle crisi – Crisis management e comunicazione
- Piano di formazione – Programma strutturato per competenze
- Piano gestione incidenti – Incident response con team e procedure
Nella mia esperienza, ottenere queste approvazioni è uno dei colli di bottiglia maggiori. è pertanto opportuno preparare una delibera omnibus con tutti i documenti allegati, preceduta da sessioni informative per gli amministratori.
Le scadenze reali e le priorità di implementazione
Le linee guida parlano di 18 mesi dalla comunicazione di inserimento nell’elenco dei soggetti NIS2. Ma attenzione: alcune misure hanno scadenze implicite molto più stringenti.
Le notifiche degli incidenti, per esempio, devono essere operative immediatamente. Non puoi dire all’ACN “sto ancora implementando” se subisci un ransomware. Stesso discorso per le misure di protezione base: autenticazione forte, backup, patch management. Sono il minimo sindacale che deve essere già operativo.
La raccomandazione, dunque, è di procedere per priorità:
- Immediato (0-3 mesi): Misure di protezione base, processo di notifica incidenti, inventario asset
- Breve termine (3-6 mesi): Organizzazione formale, politiche di sicurezza, valutazione del rischio
- Medio termine (6-12 mesi): Piani operativi (BCP, DRP, IRP), formazione strutturata, gestione fornitori
- Lungo termine (12-18 mesi): Ottimizzazione, metriche avanzate, miglioramento continuo
Gli errori più comuni nell’interpretazione delle linee guida
Abbiamo visto ripetersi sempre gli stessi errori nell’interpretazione delle linee guida. Il primo è considerare le misure come checklist indipendenti invece che come sistema integrato. La GV.SC-07 (valutazione rischio fornitori) è inutile senza la GV.SC-04 (inventario fornitori) che a sua volta dipende dalla GV.SC-01 (processo di procurement sicuro).
Altro errore classico: sottovalutare le clausole basate sul rischio. Quando le linee guida dicono “per almeno i sistemi informativi e di rete rilevanti”, non significa “solo per quelli”. È il minimo, ma l’approccio risk-based potrebbe richiedere di estendere le misure ad altri sistemi.
La confusione tra documentazione e implementazione è forse l’errore più pericoloso. Avere il documento “Piano di gestione incidenti” non significa avere un processo di incident response funzionante. Abbiamo visto enti con documentazione perfetta incapaci di gestire un incidente reale perché mancavano i processi operativi, il team formato, gli strumenti configurati.
Le implicazioni pratiche per gli enti pubblici
Per un Comune medio nel perimetro NIS2, implementare correttamente tutte le misure significa ripensare l’organizzazione IT. Non è solo questione di budget (che pure serve), ma di approccio culturale. Il personale deve essere formato, i processi ridisegnati, la governance rafforzata.
Le aziende sanitarie pubbliche hanno una complessità aggiuntiva: sistemi medicali critici, dati sanitari sensibili, interconnessioni con il FSE. Per loro, le misure NIS2 si sovrappongono ad altri requisiti normativi creando un quadro estremamente complesso.
Gli enti più piccoli paradossalmente potrebbero avere un vantaggio: meno sistemi legacy, processi più snelli, decisioni più rapide. Ma devono superare il gap di competenze, magari attraverso aggregazioni o servizi condivisi. Abbiamo visto Unioni di Comuni implementare la NIS2 in modo più efficace di grandi città proprio per questo approccio collaborativo.
Conclusioni operative: da dove iniziare davvero
Se devi ancora iniziare l’implementazione, il consiglio è di non partire dalla tecnologia ma dalla governance. Definisci chi fa cosa, ottieni il commitment degli organi di indirizzo, alloca le risorse necessarie. Senza questi prerequisiti, ogni sforzo tecnico è destinato a fallire.
Poi procedi con un assessment onesto della situazione attuale. Non quello che vorresti avere o quello che pensi di avere, ma quello che realmente hai. Abbiamo visto gap analysis che sottostimavano del 70% il lavoro necessario. Meglio una brutta verità subito che una bella bugia che emerge durante un incidente o un audit.
Infine, non cercare scorciatoie. Le linee guida NIS2 non sono l’ennesimo adempimento burocratico ma un’opportunità per costruire una vera resilienza cyber. Gli enti che l’hanno capito stanno trasformando un obbligo in vantaggio competitivo, migliorando i servizi e riducendo i rischi operativi.
La strada è lunga ma ora almeno è chiara. Le linee guida complete hanno eliminato ogni ambiguità. Non ci sono più scuse per non iniziare seriamente questo percorso. E ricorda: il cybercrime non aspetta che tu sia pronto. Ogni giorno di ritardo aumenta l’esposizione al rischio del tuo ente e, soprattutto, degli utenti che servi.
Maggiori informazioni su come affrontare la NIS2 in maniera pratica le trovi qui: https://www.scudoc.it/supporto/
