Article. What i write

NIS2: oltre la conformità, riscrivere la strategia cyber

Pubblicato il 4 gennaio 2026
Vincenzo Calabro' | NIS2: oltre la conformità, riscrivere la strategia cyber

Introduzione: oltre la burocrazia

Per molti, le normative sulla sicurezza informatica, come la NIS, evocano immagini di burocrazia complessa: una serie di adempimenti da rispettare per evitare sanzioni. Questa percezione è comprensibile, ma superficiale. Se si analizzassero con attenzione le linee guida ufficiali dell'Agenzia per la Cybersicurezza Nazionale (ACN), si scoprirebbe qualcosa di inaspettato: non un semplice manuale di regole, ma un vero e proprio trattato di strategia.
Questi documenti forniscono un modello per una strategia di sicurezza moderna che sfida molte delle convinzioni più comuni sulla gestione del rischio cyber. I principi in essi contenuti non servono solo a raggiungere la conformità, ma a costruire una postura di sicurezza matura, resiliente e allineata agli obiettivi di business.
Questo articolo ha lo scopo di svelare le cinque lezioni più significative e controintuitive che emergono dalle direttive ACN. Sono state inserite in una lista chiara e accessibile, pensata per chiunque voglia andare oltre il mero adempimento normativo e trasformare un obbligo di legge in un vantaggio strategico.

La cybersecurity non è (solo) un problema dell'IT, ma del CdA

Una delle rivelazioni più potenti delle linee guida ACN è l'attribuzione chiara e inequivocabile della responsabilità ultima in materia di cybersecurity. La normativa stabilisce in modo esplicito che i documenti fondamentali della strategia di sicurezza non sono semplici documenti tecnici, ma decisioni aziendali che richiedono l'approvazione formale da parte dei massimi livelli dirigenziali.
Questo requisito eleva la cybersecurity da costo operativo, tipicamente delegato alla funzione IT, a una responsabilità fondamentale di governance, al pari della conformità finanziaria o legale. Ciò impone di affrontare la cybersecurity in termini di rischio d'impresa, budget e responsabilità legali, obbligando gli amministratori a comprendere e assumersi le proprie responsabilità in merito ai risultati, anziché delegarle a un reparto tecnico. Il messaggio è chiaro: la sicurezza informatica è una questione di business che deve essere compresa, gestita e approvata dai dirigenti aziendali.
Secondo quanto previsto, documenti importanti come le Politiche di sicurezza informatica (GV.PO-01), il Piano di trattamento del rischio (ID.RA-06), il Piano di continuità operativa (ID.IM-04) e persino il Piano per la gestione degli incidenti (RS.MA-01) devono essere approvati dagli organi amministrativi e direttivi.

Un "incidente" non è necessariamente un attacco hacker

Nell'immaginario comune, un "incidente informatico" da notificare alle autorità è quasi sempre sinonimo di un attacco malevolo esterno: un ransomware, un'intrusione o un'esfiltrazione di dati da parte di un hacker. La direttiva NIS, invece, adotta un approccio molto più ampio e strategico.
Le linee guida chiariscono che un incidente soggetto a notifica può derivare non solo da azioni intenzionali, ma anche da "eventi di natura accidentale". Ciò include guasti hardware, malfunzionamenti dei sistemi o errori umani che compromettono la disponibilità, l'integrità o la riservatezza dei servizi. Ad esempio, l'indisponibilità prolungata di un servizio critico a causa di un aggiornamento fallito può costituire un incidente da notificare, esattamente come un attacco DDoS.
Questa distinzione è fondamentale perché sposta l'attenzione dalla sola difesa contro gli avversari esterni a una visione olistica della resilienza operativa. Ciò impone un cambio di paradigma negli investimenti, che non possono più concentrarsi solo su strumenti focalizzati sulla minaccia (come i firewall), ma devono estendersi a capacità orientate alla resilienza, quali backup e ripristino robusti, sistemi ridondanti e procedure di failover testate.

Il tempo non parte dall'attacco, ma dal momento in cui te ne accorgi

La normativa NIS prevede scadenze molto stringenti per la notifica: una pre-notifica entro 24 ore e una notifica completa entro 72 ore. Istintivamente, si potrebbe pensare che il cronometro inizi a ticchettare dal momento in cui l'attaccante viola i sistemi. La realtà, come specificato nelle linee guida, è però leggermente diversa e ha implicazioni operative enormi.
Il conteggio delle ore non inizia dal momento in cui si verifica l'incidente, ma da quando l'organizzazione ne viene a conoscenza. Tale evidenza può derivare da un allarme dei sistemi di monitoraggio, dalla segnalazione di un utente all'help desk o da una comunicazione esterna (ad esempio, da parte del CSIRT Italia).
"L’acquisizione dell’evidenza è tipicamente successiva al verificarsi dell’incidente e definisce il momento a partire dal quale decorrono i termini per la trasmissione della pre-notifica (24 ore) e della notifica (72 ore)."
Questo dettaglio sposta il peso strategico dalla difesa perimetrale alle capacità di detection e di internal reporting. Tuttavia, interpretare questo punto come un incentivo ad avere scarse capacità di rilevamento sarebbe un grave errore strategico. Un divario significativo tra il momento in cui si verifica un evento e quello in cui viene scoperto non è un vantaggio legale, ma una grave falla nella postura di sicurezza. Ciò espone l'azienda a un danno operativo maggiore e a un'analisi più severa da parte delle autorità, che valuteranno l'adeguatezza delle misure di monitoraggio a prescindere dal momento in cui è scattato l'obbligo formale di notifica.

Non è necessario proteggere tutto allo stesso modo

Un'altra sorpresa positiva all'interno dei regolamenti governativi è l'adozione esplicita di un approccio basato sul rischio. Invece di imporre un costoso modello "one-size-fits-all", la normativa permette e incoraggia le organizzazioni a concentrare le proprie risorse dove il rischio è maggiore.
Il concetto chiave è quello di "sistemi informativi e di rete rilevanti", definiti come quei sistemi la cui compromissione avrebbe un impatto significativo sulla fornitura dei servizi essenziali. Le linee guida consentono di applicare alcune delle misure di sicurezza più onerose in termini di costi e complessità esclusivamente a questi sistemi critici.
Un esempio concreto fornito dalla normativa è la misura PR.DS-11 che richiede di verificare periodicamente l'utilizzabilità dei backup tramite test di ripristino. Tale adempimento può essere limitato ai soli "sistemi informativi e di rete rilevanti". Ciò dimostra una notevole maturità normativa: si riconosce che non tutti gli asset aziendali hanno lo stesso valore e che una difesa efficace è una difesa proporzionata.

La minaccia più grande potrebbe già avere le chiavi di casa

La direttiva NIS formalizza un concetto noto da tempo agli esperti di sicurezza: non tutte le minacce provengono dall'esterno. Le normative affrontano direttamente la minaccia interna (insider threat) definendo una specifica tipologia di incidente da notificare per i soggetti essenziali: l'"abuso dei privilegi concessi" (IS-4).
Ma cosa significa esattamente? Le linee guida lo spiegano in modo molto chiaro: si ha un abuso quando un utente, pur avendo l'autorizzazione tecnica per accedere a determinati dati (e quindi le credenziali corrette), lo fa per scopi illeciti o per ragioni non legate alla propria mansione lavorativa, violando così le politiche aziendali. Un esempio è la "consultazione di banche dati da parte di personale che ha l'autorizzazione tecnica ad accedervi, ma in violazione delle politiche aziendali".
Questa definizione codifica l'idea che un incidente di sicurezza non è solo la conseguenza della violazione di una difesa, ma anche del tradimento della fiducia. Le organizzazioni, quindi, non devono limitarsi a gestire l'accesso, ma devono anche monitorare le attività di chi si trova già all'interno. Questo focus normativo sull'abuso dei privilegi rende l'adozione di principi moderni come lo Zero Trust e di robusti programmi di Identity & Access Management (IAM) non solo una buona pratica, ma una necessità strategica.

Conclusione: un manuale di strategia, non solo di regole

In questa ottica, le linee guida dell'ACN per la direttiva NIS non sono più un semplice elenco di adempimenti, ma un vero e proprio framework per sviluppare una strategia di cybersecurity matura, consapevole e strategica. Ci insegnano a considerare la sicurezza come una funzione di governance, a definire il rischio in termini operativi, a dare la priorità alla capacità di rilevamento e a non sottovalutare mai le minacce interne.
La direttiva NIS non è un esame da superare, ma una masterclass sponsorizzata dallo Stato sulla resilienza informatica. Le organizzazioni che interiorizzano queste lezioni non solo otterranno la conformità, ma acquisiranno anche un vantaggio competitivo tangibile, grazie a una maggiore resilienza operativa e alla fiducia degli stakeholder.
Alla luce di questi punti, qualsiasi azienda può trarre vantaggio da queste linee guida e trasformare la sicurezza informatica da un costo tecnico da minimizzare a un pilastro strategico del proprio business da gestire ai massimi livelli.