NIS-2: L’incertezza giuridica non è una scusa

Di cosa si tratta davvero

La discussione su NIS-2 ruota spesso attorno a regolamenti di dettaglio e questioni interpretative. Comprensibile – ma pericoloso. Il punto centrale è già chiaro: le aziende di importanza essenziale per l’economia e la società devono professionalizzare in modo dimostrabile la propria sicurezza IT e la governance. Chi oggi sceglie di “aspettare e vedere” rischia esattamente ciò che NIS-2 intende prevenire: interruzioni più lunghe, reazioni a catena nella catena di fornitura e responsabilità del management senza prove solide di misure adeguate.

L’essenza di NIS-2 in cinque punti

• Responsabilità della direzione: Direzione/Consiglio di amministrazione sono esplicitamente tenuti a conoscere i rischi, approvare le misure e verificarne l’efficacia.

• Controlli basati sul rischio: Non una religione delle checklist, ma misure adeguate e documentate su identità, endpoint, reti, applicazioni e dati.

• Obblighi di notifica & Incident Reporting : Gli incidenti gravi devono essere notificati nei termini previsti e in modo qualificato – senza panico, ma con fatti.

• Sicurezza della supply chain: Le terze parti non sono “esterne”, ma parte della vostra superficie di attacco. Controlli minimi e prove vengono richiesti contrattualmente.

• Applicazione & sanzioni: La “sicurezza su carta” non basta. Mancanza di governance e processi inefficaci sono sanzionabili – indipendentemente dalle buone intenzioni.

Chi è coinvolto – direttamente, indirettamente, tramite contratti

Molte aziende rientrano direttamente nel campo di applicazione; altre subiscono NIS-2 attraverso i clienti: grandi committenti e operatori richiedono prove e diritti di audit, anche se formalmente non siete “in ambito”. In modo realistico esistono tre categorie:

1. Direttamente coinvolti (entità essenziali/importanti): obblighi formali e contatto con le autorità.

2. Indirettamente coinvolti (fornitori/servizi critici): obblighi contrattuali di prova, audit, standard minimi.

3. Di fatto coinvolti: nessuna classificazione formale, ma dipendenza da clienti che trasferiscono i requisiti NIS-2.

Errori comuni – e la risposta realistica

• “Servono prima le linee guida definitive.” – Falso. I controlli attesi sono best practice da anni: MFA resistente al phishing, patch SLO, segmentazione, backup con verifica d’integrità, processo di Incident Reporting.

• “Certificato = fatto.” – No. I certificati aiutano, ma non sostituiscono processi operativi o controlli sulla supply chain.

• “Ci pensa l’IT.” – Solo in parte. NIS-2 è governance : decisioni di rischio, budget, contratti, escalation – responsabilità del management.

• “Siamo troppo piccoli/irrilevanti.” – Finché un’interruzione non colpisce un cliente molto rilevante. Allora valgono le sue regole – immediatamente.

Dal testo normativo alla pratica – cosa significa “adeguato”

Iniziate dove il fallimento costa di più: identità, superfici di attacco esterne e ripristino. “Adeguato” significa: documentato, ripetibile, verificato.

Elementi fondamentali che contano:

• Prima le identità: MFA resistente al phishing (es. Passkeys/FIDO2) per ruoli critici, privilegi just-in-time, disattivazione dei protocolli legacy deboli.

• Patch SLO invece di “patchiamo regolarmente”: vulnerabilità critiche esposte su Internet risolte in giorni, interne con scadenze chiare; escalation automatizzata in caso di ritardo.

• Segmentazione & hardening: separazione delle zone critiche, workstation amministrative rafforzate, blocco predefinito degli strumenti di scripting rischiosi.

• Backup con prova: offline/immutabili, test di ripristino cronometrati con verifica d’integrità – documentati e ripetibili.

• Percorso di notifica e comunicazione: Incident Reporting esercitato con ruoli, scadenze, canali di contatto (interni/esterni) e linee guida legali.

• Protezione contrattuale della supply chain: controlli minimi (MFA, patch SLO, logging), obblighi di test, scadenze di notifica, diritti di audit.

Piano minimo senza drammi

Non tutto insieme, ma con coerenza e con prove.

Mappa dei rischi & responsabilità (delibera del management):
Quali processi sono critici? Quali vettori di attacco sono realistici? Chi decide in caso di deviazioni? Documentare e approvare formalmente.

Inserire i controlli nel manuale operativo (non solo nelle slide):
Per ogni controllo (es. MFA, patch SLO, test di ripristino) un runbook di una pagina: obiettivo, trigger, passi, responsabile, prove. Breve ma operativo.

Raccogliere e versionare le prove:
Ticket, log, screenshot, registri dei test. Senza prova, non è successo. Tutto centralizzato, verificabile, reperibile.

Supply chain a livelli:
Desk review per tutti, audit remoto per “alto”, test mirati per “critico”. Prove mancanti ⇒ scadenza, escalation, se necessario limitazione dell’accesso.

Cosa viene misurato – e come

I KPI non sostituiscono i controlli, ma rendono visibile il progresso – e misurabili le lacune. Pochi indicatori chiari con conseguenze definite:

• Copertura MFA (resistente al phishing) per ruoli critici.

• Conformità ai Patch SLO in base all’esposizione (Internet vs. interno).

• Tempo di ripristino & integrità per i due processi aziendali più importanti.

• Maturità degli incidenti: tempo alla prima valutazione, tempo alla notifica, completezza della notifica iniziale.

• Solidità della supply chain: percentuale di partner critici con prove/test superati e canale di contatto 24/7 funzionante.

Importante: Ogni deviazione richiede una conseguenza definita (es. escalation, blocco delle modifiche, revisione aggiuntiva). Reporting senza azione è solo burocrazia.

Consigli pratici per dirigenti scettici

• Chiedete prove, non intenzioni. “Mostratemi l’ultimo protocollo di ripristino con timestamp.”

• Priorità dove il tempo è denaro. Un ripristino stabile riduce i costi di inattività – e convince gli assicuratori.

• Collegate il budget all’impatto. Meno strumenti, più processi solidi.

• Rendetelo auditabile. Ciò che non è reperibile, di fatto non esiste – soprattutto sotto NIS-2.

Conclusione: Agire vale più delle scuse

NIS-2 non è un fine in sé, ma un catalizzatore per una governance solida. Chi oggi mette in ordine processi, prove e catena di fornitura ottiene un doppio vantaggio: meno rischio quotidiano e meno stress quando conta davvero. Aspettare la chiarezza perfetta è una strategia – ma non una buona. I requisiti sono noti, il percorso è realizzabile. Iniziate ora – e documentate di averlo fatto.”

FAQ sul post del blog

Cosa disciplina concretamente NIS-2 per le aziende?

NIS-2 impone responsabilità chiare alla direzione, prove verificabili di efficacia e controlli strutturati sulla supply chain. Le misure di sicurezza IT devono essere documentate, testate e dimostrabili alle autorità.

Quali processi devono essere esercitati regolarmente secondo NIS-2?

Un processo di incident reporting funzionante, procedure di ripristino testate con verifica di integrità e canali di comunicazione definiti con le autorità devono essere esercitati e documentati regolarmente.

È sufficiente un certificato per essere conformi a NIS-2?

No. Un certificato da solo non basta. Sono fondamentali processi operativi, controlli documentati e prove verificabili.

Chi è responsabile dell’implementazione di NIS-2?

La responsabilità spetta alla direzione aziendale in collaborazione con sicurezza e area legale. NIS-2 è una questione di governance, non solo IT.

Quali sono i primi passi rapidi per adeguarsi a NIS-2?

Creare runbook operativi, istituire un repository centrale delle evidenze e introdurre un modello strutturato a livelli per la supply chain con audit e controlli minimi.