Uno spettro si aggira per l’Europa, quello del NIS2.
Anche se non ci saranno nazioni che lo useranno come pietra miliare per fondare un nuovo ordine economico, prepariamoci a vederne delle belle.
A chi lavora nell’IT — developer, sysadmin, cloud architect, DevOps o un responsabile di prodotto — negli ultimi mesi sarà capitato almeno una volta di sentire questa frase:
“Dobbiamo adeguarci alla NIS2.”
E puntualmente, nella testa di molti scatta un riflesso quasi automatico: “Ok, un’altra normativa. Un’altra cosa da firmare. Un’altra tabella da compilare. Un altro Excel che finisce dimenticato in SharePoint.”
Solo che… questa volta non funziona così.
Perché NIS2 non è una checklist burocratica da spuntare e archiviare. È un cambio di approccio: porta la cybersecurity dentro l’operatività quotidiana dell’azienda, trasformandola da “tema tecnico” a tema di resilienza, continuità e gestione del rischio.
In pratica: non chiede solo di essere sicuri. Ti chiede di saper dimostrare che siete sicuri, di sapere cosa fare quando qualcosa va storto, e di gestire il rischio anche fuori dai confini del proprio datacenter o del cloud account. Perché oggi l’attacco più pericoloso raramente arriva dal “buco” più ovvio: aspettatevelo piuttosto da un’integrazione, da una dipendenza, da un fornitore, da un servizio SaaS o da un vostro dipendente efficientissimo che per fare prima ha dato in pasto all’LLM di turno tutto il vostro data lake aziendale.
In questo articolo vediamo che cos’è la NIS2, chi riguarda, cosa cambia davvero rispetto al passato e soprattutto cosa significa in pratica per i team tech, senza farla diventare una visita dall’azzeccagarbugli.
Perché l’Europa ha sentito il bisogno di fare NIS2
È facile raccontarla come una “NIS1 migliorata”, ma sarebbe riduttivo. NIS2 nasce dall’evidenza che molte organizzazioni — anche quelle considerate importanti — hanno affrontato la sicurezza in modo frammentario. Un po’ di strumenti, un po’ di procedure, qualche progetto fatto bene e altri lasciati a metà, con un risultato che spesso non è misurabile e non è stabile e alla fine si finisce sui giornali.
Il problema, poi, non è solo che gli attacchi aumentano. È che aumentano i punti di ingresso. Oggi puoi avere un’infrastruttura interna ben gestita e comunque trovarti nei guai perché un fornitore, un servizio SaaS o una dipendenza software introduce un rischio che non avevi davvero messo a fuoco. In altre parole, la sicurezza “non è più chiusa dentro casa tua”.
Ed è qui che NIS2 alza l’asticella: non ti chiede soltanto di proteggere un perimetro. Ti chiede di ragionare su come la tua organizzazione affronta il rischio, inclusa la rete di servizi e fornitori su cui ormai si regge qualsiasi azienda digitale.
“Ma riguarda anche noi?” La domanda che si fanno tutti
Una cosa che ho notato spesso è che molte aziende iniziano la conversazione su NIS2 cercando subito una risposta binaria: “ci riguarda o no?”. Ed è una domanda sensata, perché nessuno vuole investire mesi su un tema che in teoria potrebbe non essere applicabile.
Ma la risposta reale non è così netta. Anche perché NIS2 non produce solo effetti diretti. Produce un’onda lunga. Se un’azienda rientra nel perimetro, comincerà a chiedere garanzie e standard più alti anche ai suoi fornitori. E quel processo non è “opzionale”: diventa inevitabile.
Questo significa che anche se tu non sei formalmente dentro, potresti trovarti coinvolto perché lavori per chi è dentro. O perché gestisci un pezzo critico della loro operatività. O perché fornisci servizi digitali, hosting, sviluppo, supporto, infrastruttura, monitoring. In pratica: se fai parte del mondo che tiene in piedi servizi, dati e processi, per dirla come il poeta, meglio non chiedersi per chi suona la campana.
Cosa cambia davvero: non la teoria, la sostanza
La differenza più percepibile, rispetto a come molte organizzazioni hanno gestito la sicurezza fino a ieri, è che NIS2 spinge su un concetto molto semplice: non basta dire “abbiamo fatto sicurezza”. Serve dimostrare che la sicurezza è gestita come un sistema.
Questo si traduce in alcune conseguenze abbastanza tangibili.
La prima è che la sicurezza diventa trasversale. Non è più “il progetto della security” o “il progetto dell’IT”. Deve diventare una parte della governance. Vuol dire che il management non può rimanere spettatore. E questa cosa, in molte aziende, cambia davvero la dinamica, perché il tema smette di essere solo tecnico e diventa decisionale: budget, priorità, responsabilità, rischio accettabile.
La seconda è che aumenta l’attenzione sugli incidenti. Non nel senso di “dovete evitare ogni incidente” , ma dovete sapere cosa fare quando succede. Perché la parte che spesso distrugge un’azienda non è l’attacco in sé, ma la confusione con cui viene gestito. Ore perse per capire chi deve decidere. Messaggi contraddittori. Sistemi spenti a caso. Ripartenze premature. Fornitori chiamati quando ormai è tardi. E intanto il servizio resta giù.
La terza è quella che probabilmente pesa di più: la supply chain. In un mondo dove tutto è interconnesso, la domanda “quanto è sicuro il nostro fornitore?” diventa una domanda operativa. Non un tema da procurement. Perché se quel fornitore ha un accesso privilegiato al tuo ambiente, o gestisce un pezzo del tuo flusso, allora il suo rischio è il tuo rischio.
Il punto più frainteso: “risk management” non è un documento
Quando si parla di NIS2, uno dei concetti più ripetuti è la gestione del rischio. E proprio perché è ripetuto così tanto, rischia di diventare un’etichetta vuota. Molti lo associano subito a una tabella di probabilità e impatto, con valori da 1 a 5 e colori dal verde al rosso.
Ma la gestione del rischio, per un team tech, è una cosa molto più concreta. È la capacità di rispondere a una serie di domande che spesso diamo per scontate, finché non ci costringono a guardarle in faccia.
Ad esempio: sappiamo davvero quali asset abbiamo? Conosciamo cosa è in produzione, cosa è “temporaneamente in uso da sei mesi”, cosa è stato creato da un team e lasciato lì perché funzionava? Sappiamo quante credenziali esistono e dove sono finite? Sappiamo quali account hanno privilegi troppo elevati rispetto a quello che dovrebbero fare?
E ancora: il patching è sotto controllo o è una cosa che dipende dall’eroe di turno che ogni tanto si ricorda di aggiornare? I backup esistono, ma li abbiamo mai ripristinati davvero, o ci fidiamo del fatto che “tanto il job è verde”? Quando un sistema cade, sappiamo ripartire in tempi ragionevoli o la ripartenza è un evento traumatico?
Sono domande semplici, ma sono quelle che fanno davvero la differenza tra sicurezza “dichiarata” e sicurezza “reale”.
Incident reporting: la parte che mette ansia, ma serve
Tra i vari punti della NIS2, quello che spesso genera più tensione è la gestione e notifica degli incidenti. È normale, perché tocca una zona delicata: ammettere che qualcosa è successo, tracciarlo, comunicarlo. Nessuno ama farlo. Nessuno ama esporsi. Nessuno ama dover dire “non eravamo pronti”.
Eppure il problema è proprio questo: molte aziende non sono pronte non perché sono incompetenti, ma perché non hanno mai strutturato la risposta. E senza struttura, un incidente diventa un caos.
La cosa importante è capire che la gestione incidenti non è un esercizio da “grandi enterprise”. È semplicemente la versione più matura di una cosa che già facciamo tutti: intervenire quando qualcosa va storto. Solo che qui bisogna farlo con una chiarezza maggiore.
Chi decide che è un incidente e non “un glitch”? Chi autorizza azioni drastiche? Chi parla con i fornitori? Chi verifica se ci sono dati coinvolti? Chi gestisce la comunicazione interna? Chi raccoglie evidenze mentre altri stanno cercando di far ripartire tutto?
Se non hai mai definito queste cose prima, non le farai bene nel momento peggiore possibile.
La supply chain: dove oggi si vincono (o si perdono) le partite
Una delle frasi che si sentono spesso è “noi siamo sicuri”. E magari lo siete davvero, nel vostro perimetro. Ma se usate servizi esterni — e li usiamo tutti — la sicurezza non è più una proprietà interna. È un ecosistema.
Il problema non è nemmeno “il fornitore è cattivo”.I fornitori sono tanti, e ognuno ha la sua postura, i suoi processi, i suoi tempi. Alcuni sono maturi, altri sono fragili, altri sono molto bravi ma non comunicano, altri comunicano bene ma hanno pratiche deboli.
NIS2 rende questo tema inevitabile: dovrai iniziare a ragionare su quali terze parti sono davvero critiche e che tipo di accesso hanno. Perché se un servizio esterno ha privilegi elevati nel tuo ambiente, non puoi trattarlo come un dettaglio.
Questa parte, per molte aziende, sarà la più difficile non perché è complessa tecnicamente, ma perché è scomoda culturalmente. Significa mettere regole dove prima c’era fiducia implicita. Significa chiedere evidenze dove prima bastava “tranquilli, siamo certificati”. Significa governare un pezzo di rischio che fino a ieri era “non visto”.
NIS2 e team tech: non è un freno, è un cambio di livello
Se lavori in DevOps o Cloud, potresti leggere NIS2 e pensare: “ok, altre regole, altre limitazioni”. Ma c’è un modo più interessante di guardarla.
Molte delle cose che NIS2 spinge a fare sono, in realtà, le stesse cose che ti rendono la vita meno infernale quando hai sistemi in produzione. Perché la sicurezza, quando è fatta bene, non è burocrazia. È qualità ingegneristica.
Osservabilità migliore significa anche troubleshooting migliore. Gestione credenziali migliore significa anche meno incidenti da errori banali. Hardening automatizzato significa anche ambienti più consistenti. Processi chiari di rilascio e patching significano anche meno “deploy del terrore”.
NIS2 può essere vista come una spinta — anche politica — a portare le organizzazioni in una dimensione più adulta. A smettere di vivere di improvvisazione e a costruire sistemi che reggono davvero.
Da dove partire (senza trasformarla nell’ennesima “iniziativa infinita”)
La tentazione, quando un tema come NIS2 arriva sul tavolo, è quella di reagire con un progetto enorme: comitati, deliverable, roadmap infinite. Ma spesso il modo migliore per bruciare un’iniziativa è proprio quello.
Il punto non è fare tutto e subito. Il punto è iniziare a muovere l’azienda in una direzione coerente.
In molte realtà conviene partire da due o tre cose estremamente concrete, che hanno un impatto enorme e che spesso rivelano subito dove sono i veri problemi. Ad esempio capire come sono gestiti gli accessi privilegiati, capire se i backup sono davvero ripristinabili, capire se esiste un minimo di piano incidenti che non sia solo “chiamate Marco, lui sa”.
Una volta fatto questo, tutto il resto diventa progressione. Perché la maturità non arriva con un documento. Arriva con abitudini, routine, automatismi e decisioni ripetute nel tempo.
Conclusione: NIS2 non ti chiede di essere perfetto, ti chiede di essere pronto
C’è un equivoco che vale la pena chiarire: NIS2 non ti chiede di non subire mai incidenti. Ti chiede di essere in grado di affrontarli senza collassare.
E come se non bastasse, essere soggetti a un audit per controllare lo stato dell’arte, da aziende che forniscono servizi vitali, è un incubo da cui è difficile risvegliarsi sani.
Arrivare preparati fa una differenza enorme.
Essere pronti significa avere una postura chiara, sapere quali sono i rischi più probabili, sapere dove sono i punti fragili, sapere come intervenire quando qualcosa succede. Significa non scoprire in emergenza chi ha accesso a cosa. Significa non accorgersi in crisi che “il backup era su quel server che è stato cifrato anche lui”. Significa non perdere ore a decidere chi deve decidere.
Alla fine, la vera promessa della NIS2 non è “più compliance”. È una cosa molto più utile: aziende che, quando qualcosa va storto, restano in piedi.
E nel 2026, per chi lavora nel tech, questa è la differenza tra un incidente gestibile e un disastro.
