Tre risposte alla domanda "La direttiva NIS2 ci riguarda?"
Quando la direttiva (UE 2022/2555) è stata recepita in Italia con il D.Lgs. 138/2024 (in vigore dal 16 ottobre 2024, con l'ACN come autorità competente), la maggior parte delle piccole e medie imprese ha fatto una rapida verifica: non operiamo nei settori dell'energia, delle banche o della sanità; abbiamo meno di 50 dipendenti; la NIS2 non è un nostro problema. Dopodiché, la questione è stata archiviata.
Le risposte oneste, tuttavia, sono tre, e soltanto una di queste è un "no":
Sì, si rientra nel campo di applicazione. Se si opera in uno dei settori elencati e si hanno dimensioni medie (dai 50 dipendenti in su, oppure un fatturato superiore a 10 milioni di euro), si è considerati soggetti essenziali (Allegato I) o importanti (Allegato II). Inoltre, alcune categorie sono incluse a prescindere dalle dimensioni: i fornitori di servizi DNS, i prestatori di servizi fiduciari e (quella che quasi nessuno si aspetta) i fornitori di servizi di gestione TIC, che comprendono MSP e MSSP. Se un'azienda vende servizi IT o di sicurezza gestiti ad altre imprese, la NIS2 la riguarda in modo diretto.
Non ancora. Se l'impresa è effettivamente al di fuori dei settori e delle soglie previste, al momento la direttiva non impone obblighi diretti. È bene, però, mettere per iscritto questa conclusione: deve trattarsi di una decisione documentata, non di una svista, e andrà riesaminata ogni volta che l'azienda cresce o aggiunge un nuovo ramo d'azienda.
Indirettamente, tramite terzi. Questo è il caso più frequente, nonché quello che sfugge a molte aziende. I clienti che rientrano nel perimetro della direttiva sono obbligati dall'Articolo 21 a mettere in sicurezza la propria catena di fornitura: ciò si traduce in valutazioni sulla sicurezza dei fornitori, clausole di notifica degli incidenti, diritti di audit e rinnovi contrattuali che ora includono questionari sulla sicurezza informatica. Anche i rinnovi delle assicurazioni cyber richiedono le medesime garanzie. Non è necessario che la NIS2 si applichi direttamente a un'azienda per cambiare ciò che i clienti esigono da essa.
Il vero nodo della questione: l'Articolo 20
Le misure di sicurezza previste dall'Articolo 21 (analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, MFA, crittografia, igiene informatica) sono l'aspetto su cui si concentra la maggior parte delle sintesi. Rappresentano il lavoro operativo. Ma la clausola che ha cambiato le carte in tavola nei consigli di amministrazione è l'Articolo 20:
Gli organi di amministrazione e direttivi devono approvare le misure di gestione dei rischi di sicurezza informatica, supervisionarne l'attuazione e possono essere ritenuti responsabili per eventuali inadempienze. I vertici aziendali devono inoltre ricevere una formazione sufficiente a comprendere i rischi. Gli Stati membri possono imporre divieti temporanei di esercizio delle funzioni dirigenziali per i soggetti essenziali in caso di gravi non conformità. In Italia, il decreto attuativo lega le violazioni alla responsabilità dirigenziale, disciplinare e amministrativa, con sanzioni che arrivano fino a 10 milioni di euro o al 2% del fatturato globale per i soggetti essenziali, e a 7 milioni o all'1,4% per quelli importanti.
Delegare il lavoro internamente è esplicitamente consentito: il legislatore italiano lo conferma nelle proprie FAQ. Ciò che non può essere delegata è la responsabilità. La firma in calce al documento di valutazione dei rischi appartiene al consiglio di amministrazione, così come ne derivano le conseguenze in caso di errori.
Le scadenze con cui non si può negoziare
Quando si verifica un incidente significativo, le tempistiche sono rigide: preallarme all'autorità entro 24 ore dal momento in cui se ne viene a conoscenza, notifica completa entro 72 ore, una relazione finale entro un mese. In Italia, questo significa rivolgersi all'ACN e al CSIRT Italia.
Occorre interpretare queste scadenze in termini operativi, poiché definiscono ciò che l'assetto di sicurezza deve essere in grado di fare: rilevare che sta accadendo qualcosa di grave, informare tempestivamente una persona autorizzata a decidere e produrre una notifica strutturata di notte, magari di domenica, nell'arco di una sola giornata. Se l'organizzazione attuale si limita a "il fornitore IT esterno ci manda un'e-mail quando qualcosa sembra non andare", non sarà possibile rispettare queste tempistiche. Non si tratta di una critica, ma di una lacuna da colmare prima che un incidente la metta in luce.
L'esternalizzazione: il modello giusto, applicato correttamente
Per un'azienda dai 50 ai 200 dipendenti, mantenere una funzione di sicurezza completa all'interno ha poco senso. L'esternalizzazione è la scelta più logica: nessuno assume un team permanente di penetration tester, un SOC operativo 24 ore su 24 e uno specialista in conformità per una sola sede. L'Articolo 20 prevede che la direzione si avvalga di fornitori esterni, ove opportuno. La direttiva insiste unicamente sul fatto che il loro utilizzo non riduce le responsabilità in capo all'azienda.
Ecco cosa si può delegare:
- Monitoraggio e rilevamento continui (MDR/SOC) - Valutazioni periodiche delle vulnerabilità e penetration test - Attività di rafforzamento (hardening): configurazioni, programmi di patching, correzioni dell'architettura - Contratti di pronto intervento (incident-response retainer): contenimento e analisi forense quando qualcosa va storto - Raccolta di prove di conformità mappate in base ai framework richiesti dal mercato o dagli auditor
Ecco cosa rimane in capo all'azienda, a prescindere da chi si assuma:
- La conoscenza del proprio patrimonio: l'inventario degli asset e dei sistemi. Nessuno può fare l'inventario al posto dell'azienda; le informazioni esistono solo nelle menti di chi ci lavora e nei contratti - L'accettazione del rischio. Quando il fornitore fa notare che "risolvere questa vulnerabilità costa X", qualcuno all'interno dell'azienda deve prendere la decisione di accettare, mitigare o trasferire il rischio. Quella decisione spetta all'impresa - L'obbligo di segnalazione. L'onere legale di notificare l'incidente all'autorità è dell'azienda, non del fornitore - La supervisione dell'esternalizzazione stessa, che ai sensi dell'Articolo 21 è letteralmente una delle misure richieste
Il contratto è l'elemento decisivo
La distanza tra "abbiamo esternalizzato la sicurezza" e "siamo effettivamente in grado di rispettare le tempistiche della NIS2" si gioca interamente sulle clausole scritte nel contratto con il fornitore. Sono cinque i punti che fanno la differenza:
1 · Notifica delle violazioni in ore, non in giorni. Il fornitore deve impegnarsi a comunicare il sospetto di un incidente significativo nel giro di poche ore (a una sola cifra). Se il suo SLA prevede 48 o 72 ore, il cronometro normativo avrà già superato la prima scadenza ancor prima che l'azienda ne venga informata.
2 · Prove, non rassicurazioni. Report, log e risultati devono essere forniti in un formato che possa essere consegnato a un auditor, a un cliente o all'autorità, senza dover chiedere al fornitore di produrre documenti nel bel mezzo di un incidente.
3 · Una divisione delle responsabilità chiara e schematica. Il fornitore rileva, contiene e rimedia. L'azienda accetta il rischio, prende le decisioni e invia le notifiche. Scoprire un'ambiguità in questa divisione nel bel mezzo di un incidente avviene nel momento peggiore possibile.
4 · Nuovi test inclusi. Una correzione che non è mai stata verificata è solo una dichiarazione d'intenti, non un risultato. Il retest deve rientrare nel perimetro del contratto.
5 · Trasferimento della documentazione. Tutto ciò che il fornitore costruisce (runbook, configurazioni, decisioni architetturali) resta di proprietà dell'azienda, che potrà consegnarlo al fornitore successivo. Nessun vincolo di esclusività (lock-in), perché cambiare partner a contratto in corso non dovrebbe mai significare ricominciare da zero.
Probabilmente anche il fornitore rientra nella direttiva
Ecco il risvolto che chiude il cerchio: gli MSP e gli MSSP, ovvero le società a cui le piccole e medie imprese tipicamente affidano l'IT e la sicurezza, sono a loro volta soggetti essenziali ai sensi della NIS2, rientrando nella categoria della gestione dei servizi TIC. Hanno quindi i loro obblighi: registrazione, misure di rischio, e lo stesso vincolo delle 24 ore.
È un aspetto da sfruttare a proprio vantaggio. Occorre chiedere al fornitore quale sia la sua posizione rispetto alla NIS2: se è registrato presso l'ACN, quali misure di sicurezza adotta, come gestisce gli incidenti al proprio interno e se è in grado di mostrarne le prove. Un fornitore che prende sul serio gli obblighi della direttiva è un partner migliore. Un fornitore che non sa fornire una risposta non è soltanto un anello debole: fa parte della superficie di attacco dell'azienda e, da oggi, anche del suo profilo di conformità.
Trenta giorni, una pagina
Per un'azienda dai 50 ai 200 dipendenti che desidera passare da un vago "pensiamo di essere a posto" a una posizione solida e difendibile, quattro settimane sono sufficienti:
Settimana 1, Perimetro. Si mappano le attività aziendali rispetto ai settori e alle soglie previste. Si mette per iscritto la conclusione, qualunque essa sia. Un "non rientriamo nel perimetro" privo di documentazione è indistinguibile da una casella lasciata in bianco quando un cliente o un auditor chiede conto della situazione.
Settimana 2, Inventario. Sistemi, dati, dipendenze e ogni singolo fornitore che abbia accesso all'infrastruttura. Si individuano quali clienti rientrano nella direttiva e cosa richiedono già i loro contratti.
Settimana 3, Analisi dei divari (Gap assessment). Si valuta lo stato attuale rispetto alle aree di intervento dell'Articolo 21: analisi dei rischi, gestione degli incidenti, continuità operativa, backup, sicurezza della catena di fornitura, acquisizione sicura, valutazione dell'efficacia, igiene informatica, crittografia, gestione degli accessi e degli asset, MFA. La maggior parte delle aziende scopre che le lacune si concentrano in tre o quattro di questi ambiti.
Settimana 4, Piano e firma. Un piano di rimedio con responsabili e date, unito alla discussione sull'Articolo 20: formazione dei dirigenti, approvazione formale delle misure di rischio e nomina di una persona incaricata di decidere sulle segnalazioni.
Una sintesi scomoda
La vera innovazione della NIS2 non risiede nell'elenco dei controlli: le PMI più attente ne applicavano già la maggior parte. La vera novità è l'Articolo 20: la responsabilità in materia di sicurezza si è spostata dal reparto IT al consiglio di amministrazione, portando con sé conseguenze sul piano personale.
Esternalizzare l'esecuzione rimane il modello corretto per quasi tutte le piccole e medie imprese. Nessuno dovrebbe creare un team di sicurezza completo per un solo sistema di produzione. Ma il confine è ora tracciato dalla legge: il contratto determina chi svolge il lavoro; la direttiva stabilisce chi ne risponde. Affidarsi a un buon fornitore risolve la prima metà dell'equazione; per risolvere la seconda, occorre smettere di fingere che il passaggio di consegne trasferisca anche la responsabilità.
Eseguiamo revisioni di sicurezza a perimetro fisso pensate esattamente per questa situazione: vulnerabilità classificate in base alla loro reale sfruttabilità, correzioni implementate e prove tecniche da poter consegnare ad auditor e clienti, mappate sulle aree di controllo NIS2, SOC 2 e ISO 27001 citate nei contratti. Due settimane, prezzo fisso, nuovi test (retest) inclusi.
Per l'aspetto tecnico dei controlli, è possibile leggere la nostra guida su come ottenere la conformità SOC 2 e ISO senza un budget aziendale.