NIS 2 e il tuo sito web: cosa deve fare concretamente uno sviluppatore per metterti in regola
Settore: Cybersecurity & Compliance · A chi serve: PMI, PA, aziende con applicazioni web · Risultato atteso: sistema conforme, documentato e verificabile
Quando ho iniziato a ricevere le prime domande su NIS 2 dai clienti, la maggior parte di loro credeva che fosse roba da grandi aziende. Sistemi bancari, ospedali, infrastrutture critiche. Non il loro sito, non la loro applicazione.
Poi gli spiegavo che gestivano un gestionale online con dati di clienti e fornitori, o che il loro e-commerce processava pagamenti e indirizzi. E la conversazione cambiava.
Cos'è NIS 2, in una frase utile
La Direttiva NIS 2 (Direttiva UE 2022/2555, recepita in Italia con il D.Lgs. 138/2024) obbliga le organizzazioni che operano in settori critici a dimostrare di avere misure tecniche e organizzative adeguate per proteggere i propri sistemi informativi.
Non è una questione di intenzioni. È una questione di evidenze: se arriva un'ispezione dell'ACN, devi mostrare cosa hai fatto, come lo hai documentato e quando.
L'autorità competente in Italia è l'Agenzia per la Cybersicurezza Nazionale (ACN). La registrazione è obbligatoria entro il primo trimestre di ogni anno per i soggetti rientranti nella direttiva.
A chi si applica davvero
I settori ad alta criticità includono energia, trasporti, banche, sanità, infrastrutture digitali, pubblica amministrazione. Ma la lista degli "altri settori critici" è più lunga di quanto molti pensino: distribuzione alimentare, produzione industriale, servizi postali, fornitori di servizi digitali, organizzazioni di ricerca.
Il criterio principale è la dimensione: medie e grandi imprese (più di 50 dipendenti o fatturato superiore a 10 milioni di euro) nei settori indicati. Con alcune eccezioni che includono anche soggetti più piccoli.
Se non sei sicuro di rientrare, la risposta giusta non è ignorare la questione: è verificarlo.
Il problema che vedo più spesso
Molte aziende hanno siti e applicazioni web costruiti negli anni, stratificati, con logiche di autenticazione datate, backup non verificati, dipendenze non aggiornate.
Non perché nessuno ci abbia pensato. Ma perché quando un sistema funziona, non lo tocca nessuno. Fino a quando qualcosa va storto, o arriva una norma che ti obbliga a guardare sotto il cofano.
È la stessa dinamica che ho trovato lavorando con PMI su gestionali Excel e sistemi legacy: funziona, finché non funziona più. E quando smette di funzionare, di solito è nel momento peggiore.
Cosa richiede NIS 2 in termini tecnici concreti
La direttiva non prescrive tecnologie specifiche, ma indica aree precise di intervento. Tradotto in lavoro da sviluppatore, questo significa:
Autenticazione e controllo degli accessi Autenticazione a più fattori (MFA) per i sistemi esposti. Gestione granulare dei permessi: ogni utente accede solo a ciò che gli serve. Niente account condivisi, niente password di default lasciate in produzione.
Crittografia I dati sensibili devono essere cifrati sia in transito (HTTPS, certificati aggiornati) che a riposo. Questo include backup e database. Non basta avere un lucchetto verde sul browser.
Gestione delle vulnerabilità e aggiornamenti Monitoraggio attivo delle dipendenze, aggiornamenti regolari di framework, CMS, librerie. Una Laravel con tre major version di ritardo non è una questione estetica: è una superficie di attacco documentata.
Backup e continuità operativa Backup automatizzati, verificati, conservati in posizione separata dal sistema principale. E un piano di ripristino che sia stato testato almeno una volta. Avere il backup sul server che potrebbe rompersi non conta.
Incident response e notifica Procedure documentate per rilevare, gestire e notificare gli incidenti. NIS 2 prevede tempi stretti: notifica preliminare entro 24 ore dalla scoperta, notifica completa entro 72 ore. Senza un sistema di monitoring, non sai nemmeno che c'è stato un incidente.
Sicurezza della supply chain Se la tua applicazione si integra con servizi di terze parti (API esterne, CRM, gateway di pagamento, piattaforme cloud), quella dipendenza fa parte del tuo perimetro di rischio. Va mappata e gestita.
Documentazione Tutto quanto sopra deve essere documentato. Non basta avere fatto le cose: devi poter dimostrare di averle fatte, quando, e come vengono monitorate nel tempo.
Come si traduce in un progetto reale
Quando affronto un adeguamento NIS 2, il punto di partenza è sempre un audit tecnico del sistema esistente: autenticazione, dipendenze, infrastruttura, backup, logging.
Da lì si costruisce una lista di interventi prioritizzati. Non tutto va fatto subito e non tutto costa uguale. Alcune cose si risolvono in poche ore (aggiornamento certificati, attivazione MFA), altre richiedono progettazione (refactoring dell'autenticazione, sistema di monitoring, procedure di incident response).
L'obiettivo non è arrivare alla perfezione teorica. È arrivare a un sistema difendibile, documentato e migliorabile nel tempo.
Cosa porta a casa un'azienda da un percorso come questo
Non parlo solo di compliance. Parlo di risultati concreti:
- Riduzione del rischio di data breach e interruzioni operative
- Controllo reale su chi accede a cosa nel tuo sistema
- Visibilità sullo stato di salute dell'infrastruttura
- Documentazione che vale anche in caso di audit o sinistro
- Fondamenta solide per qualsiasi sviluppo futuro
- Sanzioni evitate: fino a 10 milioni di euro o il 2% del fatturato per le entità essenziali inadempienti
E, cosa che spesso viene sottovalutata: la fiducia dei tuoi clienti. Un'azienda che gestisce dati con criteri seri è un'azienda con cui vale la pena lavorare.
Stai pensando che il tuo sistema potrebbe non essere in regola?
Probabilmente hai ragione. La maggior parte dei siti e delle applicazioni web costruiti prima del 2024 hanno qualcosa da sistemare.
La cosa peggiore che puoi fare è aspettare che il problema si presenti da solo — che sia un incidente, un'ispezione o un cliente che ti chiede garanzie che non puoi dare.
→ Raccontami com'è fatto il tuo sistema
Facciamo insieme un audit iniziale e capiamo da dove partire. Nessun impegno. Solo una conversazione tecnica concreta.