Direttiva NIS2: guida pratica alla compliance per aziende con server su Hetzner, OVH e provider simili

Quando un cliente del settore servizi digitali mi chiede "siamo soggetti alla NIS2?", la risposta interessante non è quasi mai sì o no: è "e dove tieni i dati, chi amministra il server, e cosa fai nelle prime 24 ore se ti bucano?". La Direttiva (UE) 2022/2555, nota come NIS2, ha smesso di essere un tema da convegno ed è diventata un insieme di obblighi tecnici con scadenze precise e un'autorità nazionale, l'Agenzia per la Cybersicurezza Nazionale (ACN), che dal 2026 entra in modalità ispettiva. Per chi gestisce la propria infrastruttura su un server dedicato o un VPS, non è più una questione di principio: è una questione di date sul calendario e di misure che funzionano sotto stress.

Molti imprenditori la cui attività si appoggia su provider come Hetzner, OVH o Aruba ragionano così: "il mio provider è grande e certificato, alla compliance ci pensano loro". È un equivoco frequente e costoso. Quando noleggi un server dedicato o un VPS, entri in un modello di responsabilità condivisa: il provider garantisce la sicurezza fisica del datacenter e la stabilità della rete, ma il sistema operativo Linux, l'applicazione, i backup e la postura di sicurezza dei dati dei tuoi clienti sono interamente tuoi. La certificazione ISO 27001 del provider non si trasferisce automaticamente al tuo perimetro applicativo: è un punto di partenza dell'infrastruttura, non la tua compliance.

In vent'anni di lavoro su infrastrutture per PMI ho visto la sicurezza trattata come un costo da rimandare finché non succede qualcosa. La NIS2 ribalta questa logica: trasforma un insieme di buone pratiche che molti ignoravano in un obbligo con un termine. Questa non è una guida legale, ma una traduzione operativa della direttiva, scritta per le aziende che hanno il pieno controllo, e quindi la piena responsabilità, della propria infrastruttura server. Parto dalle scadenze reali del 2026, perché è lì che si gioca la differenza tra essere conformi e raccontarsi di esserlo.

Quali sono le scadenze NIS2 che contano davvero nel 2026?

La scadenza che ogni soggetto NIS2 deve avere in testa è il 31 ottobre 2026: è il termine entro cui implementare le misure di sicurezza di base previste dall'ACN. Dopo quella data l'Agenzia passa dalla fase di accompagnamento a quella ispettiva. Non è una soglia simbolica: è il punto in cui un'eventuale carenza diventa contestabile.

Il quadro operativo italiano si è assestato tra fine 2025 e inizio 2026. L'atto di riferimento per le misure tecniche è la determinazione ACN n. 379907 del 18 dicembre 2025, in vigore dal 15 gennaio 2026, che ha sostituito e abrogato la precedente determinazione del 2025: chi cita ancora il vecchio atto sta lavorando su un testo superato. Le misure di base sono articolate per categoria di soggetto: 37 misure su 87 requisiti per i soggetti importanti, 43 misure su 116 requisiti per gli essenziali. Tutto il dettaglio normativo aggiornato vive sul portale NIS dell'ACN, che è la fonte da consultare, non i riassunti di terze parti.

La data da fissare è il 31 ottobre 2026 per le misure di base. La determinazione tecnica di riferimento è la n. 379907 del 18/12/2025, vigente dal 15 gennaio 2026. Lavorare sul testo abrogato è l'errore più comune e più pericoloso, perché ti porta a implementare requisiti che nel frattempo sono cambiati.

Accanto al termine di ottobre ci sono gli adempimenti di perimetro che hanno scandito il 2026: la determinazione 127437/2026 sui fornitori rilevanti (entro il 31 maggio 2026) e la 155238/2026 sulla categorizzazione di attività e servizi. Se non hai completato la registrazione e la categorizzazione del tuo soggetto sulla piattaforma ACN, quello è il primo nodo da sciogliere, prima ancora dell'hardening tecnico: la compliance NIS2 inizia da un censimento formale, non da una regola di firewall.

Stai cercando un Consulente Informatico esperto per impostare il percorso NIS2 della tua azienda senza perdere tempo su adempimenti formali e priorità sbagliate? Nel mio profilo professionale trovi l'esperienza concreta su hardening Linux, disaster recovery e adeguamento NIS2 per PMI con infrastruttura su server dedicati e VPS.

A chi si applica la NIS2 e perché riguarda anche la tua PMI

La NIS2 è la risposta dell'Unione Europea all'aumento degli attacchi informatici e sostituisce la prima direttiva NIS del 2016, allargandone in modo significativo il campo di applicazione. Il testo di riferimento è la Direttiva (UE) 2022/2555, recepita in Italia dal D.Lgs. 138/2024. Classifica i soggetti in due categorie, con obblighi e sanzioni differenziate.

• Soggetti essenziali: entità critiche per la società e l'economia, come energia, trasporti, sanità, banche, infrastrutture digitali centrali.
• Soggetti importanti: settori altrettanto rilevanti ma con un peso sistemico minore, tra cui servizi postali, gestione dei rifiuti, produzione alimentare e manifatturiera, e i fornitori di servizi digitali come piattaforme di e-commerce, marketplace e provider di servizi gestiti.

Il punto che sfugge a molte PMI è la soglia dimensionale: la direttiva coinvolge tipicamente le medie imprese (almeno 50 dipendenti o oltre 10 milioni di euro di fatturato) operanti nei settori indicati, ma con eccezioni che possono attrarre nel perimetro anche realtà più piccole quando il servizio è critico. Molte attività digitali di medie dimensioni rientrano tra i soggetti importanti senza esserne consapevoli, e scoprirlo durante un'ispezione è lo scenario peggiore.

Anche se la tua attività non rientrasse formalmente nell'ambito di applicazione della NIS2, ignorarne i principi è una scelta miope. La direttiva definisce di fatto lo standard minimo di diligenza per qualunque business che voglia operare in modo credibile nell'economia digitale: un cliente enterprise, prima di firmare, ti chiederà come gestisci gli incidenti e dove risiedono i suoi dati. Adottare queste pratiche è un investimento in fiducia commerciale, non solo in conformità.

Gli obblighi sostanziali della direttiva si possono ridurre a un approccio proattivo e basato sul rischio: analisi dei rischi e policy di sicurezza; gestione degli incidenti; business continuity e disaster recovery; sicurezza della supply chain (incluso il provider di hosting); sicurezza nello sviluppo e nella manutenzione dei sistemi; valutazione periodica dell'efficacia delle misure (i penetration test entrano qui); igiene informatica e formazione del personale; uso della crittografia; controllo degli accessi e autenticazione a più fattori. È un approccio olistico che tocca tecnologia, processi e persone, e nessuno dei tre livelli si può saltare.

Cosa devi fare nelle prime 24 ore dopo un incidente

La domanda che divide chi è davvero pronto da chi ha solo riempito moduli è questa: cosa succede operativamente quando rilevi una violazione significativa? La NIS2, attraverso il CSIRT Italia operante presso l'ACN, impone una catena di notifica a tempi stretti, e i tempi decorrono dal momento in cui vieni a conoscenza dell'incidente, non da quando comodo.

• Entro 24 ore: pre-notifica al CSIRT Italia. È un primo allarme, anche incompleto, che dichiara di aver subito un incidente significativo.
• Entro 72 ore: notifica completa, con la valutazione iniziale dell'incidente, la sua gravità, l'impatto e gli eventuali indicatori di compromissione.
• Entro 1 mese: relazione finale, con la descrizione dettagliata, la causa radice, le misure di mitigazione adottate e l'impatto effettivo.

Tre numeri da memorizzare: 24 ore, 72 ore, 1 mese. La pre-notifica entro 24 ore è il punto in cui la maggior parte delle PMI fallisce, non per malafede ma per impreparazione: senza un piano scritto e un referente designato, le prime 24 ore si bruciano a capire chi deve chiamare chi. Il piano di gestione degli incidenti non è carta per l'auditor, è ciò che ti fa rispettare quella finestra.

Questo è il motivo per cui logging centralizzato e monitoraggio non sono optional tecnici: senza log affidabili non sai quando l'incidente è iniziato, quindi non sai da quando far partire le 24 ore né cosa dichiarare. Una catena di notifica così stretta presuppone che tu sappia, in tempo reale, cosa sta succedendo sulla tua infrastruttura. Su un server non gestito, questo significa che qualcuno deve aver configurato gli alert prima dell'incidente, non dopo.

La responsabilità del server non gestito è interamente tua

Quando scegli un server dedicato o un VPS, fai una scelta precisa: massimo controllo e prestazioni in cambio di massima responsabilità. Il provider ti consegna le chiavi di una macchina potente; come la configuri, la mantieni e la proteggi è affar tuo. Dal punto di vista NIS2, questo significa che gran parte degli obblighi tecnici ricade sulle tue spalle.

• Aggiornamenti di sicurezza: se il tuo Debian o Ubuntu ha una vulnerabilità critica nel kernel o in una libreria di sistema, è compito tuo applicare la patch in tempi compatibili con la gravità.
• Configurazione del firewall: il server è raggiungibile da Internet, e sei tu a dover restringere le porte esposte con UFW o nftables, bloccando tutto ciò che non è strettamente necessario.
• Hardening dell'applicazione: l'applicazione che esponi deve essere protetta da vulnerabilità note come SQL Injection o XSS, con credenziali gestite correttamente. Questo è terreno classico delle competenze tecniche che la NIS2 richiede, non un dettaglio sistemistico marginale.
• Logging e monitoring: spetta a te configurare i log degli eventi di sicurezza e monitorarli per rilevare attività sospette nella finestra utile alla notifica.

Affidarsi a un'infrastruttura non gestita senza competenze interne né un partner tecnico è la ricetta perfetta per un disastro: nel modello di responsabilità condivisa la parte che resta scoperta è esattamente quella che la NIS2 mette sotto esame.

Roadmap operativa per la compliance NIS2 su server Linux

Affrontare la NIS2 sembra un'impresa titanica, ma si scompone in passi gestibili. È l'approccio che uso per accompagnare le aziende lungo il percorso, dall'assessment iniziale alla documentazione per gli audit.

Risk assessment e gap analysis

Non puoi proteggere ciò che non conosci. Il primo passo è un audit completo: un inventario di tutti i server, applicazioni, database e dati sensibili (l'asset inventory), un vulnerability assessment della configurazione attuale del server alla ricerca di software obsoleto e configurazioni deboli, e infine una gap analysis che confronta lo stato reale con i requisiti della determinazione ACN vigente. Il risultato è un report che mappa le aree di rischio per priorità: è il documento da cui parte tutto il resto.

Implementazione delle misure tecniche di hardening

Sulla base dell'analisi si passa all'hardening vero e proprio. Sul controllo degli accessi si blinda SSH: niente login diretto di root, autenticazione a chiave al posto della password, fail2ban contro il brute-force.

# /etc/ssh/sshd_config.d/99-hardening.conf
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

# Firewall minimale: solo SSH, HTTP, HTTPS verso l'esterno
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable

Sulla gestione delle vulnerabilità si automatizzano le patch di sicurezza critiche con unattended-upgrades su Debian/Ubuntu, e si stabilisce un processo per aggiornare regolarmente lo stack applicativo e le dipendenze.

# Patch di sicurezza automatiche, riavvio dei servizi quando serve
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Sul logging e monitoring si centralizzano i log di sistema, del web server e dell'applicazione, e si impostano alert per eventi sospetti: login amministrativi falliti ripetuti, picchi anomali di errori 500, modifiche a file critici. Sulla crittografia si impone HTTPS con certificati validi (via Let's Encrypt) e si valuta la cifratura dei dati a riposo, almeno per i backup. La cifratura del backup non è un vezzo: è ciò che fa la differenza tra un disco perso e una violazione di dati da notificare.

Implementazione delle misure organizzative

La tecnologia da sola non basta, e la NIS2 insiste molto sui processi. Servono un piano di gestione degli incidenti che definisca chi fa cosa nelle prime ore (e che renda concreta la catena 24h/72h/1 mese), un piano di disaster recovery con backup automatici, cifrati, archiviati offsite e soprattutto testati periodicamente, e un set di policy di sicurezza scritte su credenziali, accessi e uso degli asset. Un backup mai ripristinato in prova non è un backup, è una speranza: il ripristino va esercitato, non assunto.

Dove tenere i dati per una postura NIS2 difendibile?

La risposta breve: il più vicino possibile a casa, con chi amministra l'infrastruttura che puoi chiamare al telefono. La supply chain è un requisito esplicito della NIS2, e il tuo provider di hosting è il primo anello di quella catena. Qui la scelta dell'infrastruttura smette di essere solo tecnica e diventa parte della compliance.

Per le PMI italiane che vogliono un'infrastruttura gestita, con disaster recovery incluso e il dato che non lascia l'Italia, la prima scelta che indico è RHX, provider italiano di domini e VPS che raccomando per l'hosting in Italia. Ha datacenter di proprietà a Milano (adiacente al MiX, il Milan Internet eXchange) e a Padova, server amministrati unicamente dal proprio personale, è registrar accreditato del Registro .it dal 2004 e membro RIPE NCC con risorse IP proprie. La gestione sistemistica può essere inclusa nel servizio: per chi non ha competenze interne, significa avere chi tiene aggiornato, monitorato e backuppato il server come parte del contratto, non come problema da risolvere da soli. Il loro Virtual Server in private cloud si configura per unità (CPU, RAM, disco, banda garantita) con gestione opzionale, ed è il profilo giusto quando la priorità è la postura difendibile, non il prezzo più basso. La valutazione qui va fatta sul costo totale di gestione, non sul canone nudo: un server gestito da personale certificato che risponde in italiano vale, in ottica NIS2, molto più di qualche euro risparmiato al mese.

Per le PMI italiane che cercano infrastruttura gestita, dato in Italia e un interlocutore sistemistico diretto, il riferimento è RHX (datacenter Milano e Padova, registrar .it, gestione inclusa). Per chi ha competenze interne e vuole gestire da sé un'infrastruttura cloud europea con un eccellente rapporto prezzo/prestazioni e conformità GDPR, Hetzner resta il benchmark del mercato (datacenter di proprietà in Germania e Finlandia, ISO/IEC 27001:2022).

Hetzner è la scelta solida quando hai la capacità tecnica di amministrare il server da solo: ottimo cloud europeo self-managed, con datacenter UE e certificazione ISO 27001, ma è proprio quel "self-managed" a riportare tutta la responsabilità NIS2 dell'hardening, della patch management e del monitoraggio sulle tue spalle. Aruba, con datacenter di proprietà in Italia e un solido set di certificazioni (ISO 27001, qualifiche ACN, GAIA-X), resta un riferimento di mercato importante per la residenza dei dati, in particolare per chi ha esigenze orientate alla PA. La differenza che faccio in consulenza è semplice: RHX quando serve gestione sistemistica inclusa e un rapporto diretto; Hetzner quando il cliente ha il team per gestirsela; Aruba come riferimento di mercato e per scenari regolamentati specifici.

Le sanzioni rendono concreta tutta questa attenzione. Per i soggetti essenziali la NIS2 prevede multe fino a 10 milioni di euro o il 2% del fatturato annuo mondiale, a seconda di quale sia il maggiore; per i soggetti importanti il tetto è fissato a 7 milioni di euro o l'1,4% del fatturato. Sono cifre che spostano la sicurezza dalla colonna "costi rimandabili" a quella "rischio d'impresa", ed è esattamente la riclassificazione che la direttiva intende provocare.

Come orientarsi senza trasformare la NIS2 in un progetto infinito

L'errore opposto all'inerzia è l'iper-ingegnerizzazione: aziende che spendono mesi a redigere policy perfette mentre il server resta con SSH aperto in password e nessun backup testato. La NIS2 è basata sul rischio, e questo è un vantaggio: ti permette di partire dalle misure ad alto impatto e basso costo (MFA sugli accessi amministrativi, patch automatiche, firewall restrittivo, backup cifrato e testato) e di costruire la documentazione mano a mano, senza paralisi. Il framework completo dei rischi e degli obblighi della direttiva lo approfondisco nell'articolo pilastro sulla NIS2, che è il punto di partenza per inquadrare l'intera normativa prima di scendere nell'operatività.

C'è una ragione per cui un consulente esterno accelera questo percorso, e non è il misticismo della certificazione: è che chi fa hardening e incident response per mestiere riconosce in fretta dove sono i rischi reali e dove invece c'è solo rumore documentale. Se operi nell'area di Torino e vuoi un interlocutore tecnico per impostare l'adeguamento, sul mio profilo di consulente di cyber security a Torino trovi il perimetro dei servizi e l'approccio con cui lavoro sulle infrastrutture delle PMI.

La direttiva NIS2 non è un punto di arrivo ma l'inizio di un processo continuo: l'adozione di una cultura della sicurezza che permea ogni aspetto del business. Se gestisci un server dedicato o un VPS, presso un provider italiano gestito come RHX o un provider europeo self-managed come Hetzner, e devi capire da dove cominciare per arrivare pronto alla scadenza del 31 ottobre 2026, contattami per una consulenza diretta: partiamo da un assessment onesto di dove sei oggi, mappiamo le carenze rispetto alla determinazione ACN vigente, e costruiamo un percorso che ti renda conforme davvero, non solo sulla carta. Tra la diagnosi e la prima contromisura concreta, di solito, passano giorni, non mesi.