NIS2 Compliance Deadline 31 Ottobre 2026: La Mia Checklist Misure di Sicurezza di Base, Risk Assessment e Incident Response Plan per PMI Italiane

Mancano poco più di due settimane al 31 ottobre 2026: il deadline decisivo per l’implementazione delle misure di sicurezza di base NIS2 in Italia. Se gestisci una PMI nel nostro Paese e non hai ancora avviato il percorso di conformità, devo essere franco: il tempo stringe maledettamente.

Nella mia esperienza come System Administrator, ho guidato decine di aziende italiane attraverso questi adempimenti, e vi dico con certezza che moltissimi non saranno pronti. Non per mancanza di competenza, ma perché NIS2 non è solo IT: è governance, processi, documentazione, training – insomma, un cambio culturale che non si improvvisa all’ultimo minuto.

In questo articolo vi condivido la mia checklist operativa, basata su ciò che ho visto funzionare realmente sul campo: dalla verifica dello status di registrazione presso l’ACN (Agenzia per la Cybersicurezza Nazionale), al gap analysis delle 10 misure di sicurezza, fino alla costruzione di un Incident Response Plan che regga un audit.

Cosa è cambiato: il vostro 31 ottobre 2026 si avvicina

In Italia, le organizzazioni in scope devono implementare le misure di sicurezza di base definite dall’ACN entro il 31 ottobre 2026. Non è più una progettualità vaga – è un obbligo operativo con date ferme.

Seguendo i deadline iniziali per la gestione degli incidenti e l’allineamento della governance, il prossimo step comporta l’implementazione delle misure di sicurezza baseline definite dall’ACN, da completare entro il 31 ottobre 2026. Gli ultimi mesi di luglio e agosto 2026 vi hanno visto impegnati su governance (allineamento al 31 marzo) e processi di segnalazione (dal 1 gennaio). Ora si concretizza tutto nell’operatività concreta.

Se siete nel settore critico (energia, trasporti, sanità, finanza, infrastrutture digitali) oppure nel settore «importante» (manifattura, servizi postali, gestione rifiuti, e-commerce, provider ospitati) e avete più di 50 dipendenti o fatturato annuo superiore a €10 milioni, siete in scope. Punto.

Le 10 misure di sicurezza di base NIS2 che non potete rimandare

Article 21 del NIS2 obbliga le entità essenziali e importanti a implementare misure appropriate e proporzionate di gestione del rischio di cybersecurity, che si articolano in dieci aree. Non sono suggerimenti: sono obblighi.

1. Analisi del rischio e politiche di sicurezza dei sistemi informativi

Servono una policy documentata e regolarmente revisionata che copra il vostro paesaggio dei rischi – asset, minacce, vulnerabilità e piani di mitigazione. Questo è il fondamento su cui poggia tutto il resto.

Nel mio caso, ho creato per una PMI di 80 dipendenti (settore manifatturiero) un Risk Register strutturato in Excel con queste colonne: Asset ID, Asset Description, Threat, Vulnerability, Current Controls, Residual Risk, Owner, Mitigation Plan, Target Date. Inizialmente mi è parso laborioso, ma quando è arrivato l’audit ACN nel 2025, quella documentazione mi ha fatto risparmiare settimane di lavoro retroattivo.

2. Incident handling – il cuore operativo

Le entità devono implementare procedure e capacità per la gestione degli incidenti, coprendo prevenzione, detection, analisi, contenimento, risposta e recupero. Questa misura deve essere letta insieme all’Article 23, che impone rigorosi timeline di segnalazione alle autorità competenti e ai CSIRT.

Per un incidente significativo, le entità devono presentare un’early warning entro 24 ore, una notifica più completa entro 72 ore e un rapporto finale entro un mese.

Veniamo al dunque: è qui che molte PMI falliscono. Non per cattiva volontà, ma perché non hanno mai definito criteri espliciti di che cosa sia un «incidente significativo» né chi contatti CSIRT (in Italia, il CSIRT civile) a mezzanotte di domenica.

Nel mio piano tipo per PMI, ho sempre incluso:

• Incident Response Team (IRT) designato: nome, cognome, ruolo, mail, telefono personale di almeno 3-4 persone (IT Manager, Security Lead, CTO, CEO).
• Tabella di severity: Critical (data breach confirmato, RCE attivo), High (tentativo di accesso non autorizzato rilevato), Medium (malware rilevato su singolo endpoint), Low (alert di login sospetto).
• Playbook testato: per ogni categoria di incidente, step-by-step che il team segue (esempio: malware detection → isolamento host → forensic → notification).
• Timeline planning: entro 4 ore dalla detection, preliminary assessment; entro 20 ore, early warning all’ACN se significativo; entro 72 ore, rapporto completo.

3. Continuità aziendale e gestione delle crisi

Backup immutable, RTO/RPO definiti, piani di disaster recovery testati almeno una volta l’anno.

Ho visto PMI che non avevano idea del tempo che impiegavano a ripristinare i dati da backup. Quelle che l’hanno misurato (e documentato) hanno ottenuto il voto pieno in audit.

4–10. Accesso privilegiato, crittografia, MFA, supply chain security, training

Sono obbligatori processi di joiners/movers/leavers, RBAC e – crucialmente – MFA o autenticazione continua per l’accesso ai sistemi sensibili. MFA non è facoltativo per le entità coperte da NIS2.

Nella mia esperienza, le PMI spesso hanno implementato MFA solo per VPN o mail. Ma NIS2 richiede MFA/multi-factor per accesso privilegiato ai sistemi critici. Se il vostro DBA accede al database di produzione con sola password, siete fuori conformità.

La mia procedura passo-passo: come vi organizzo il percorso fino al 31 ottobre

Passo 1: Verificate lo stato sulla piattaforma ACN

La prima cosa è accedere a portale.acn.gov.it e verificare:

• Siete registrati come entità in scope?
• La categoria (essenziale o importante) è corretta?
• Il vostro referente tecnico e il responsabile della governance sono nel sistema?

Un’azione prioritaria è verificare la registrazione sul portale dell’ACN e l’accuratezza dei dati. Sembrerebbe banale, ma ho trovato casi in cui l’azienda risultava in scope ma con email di contatto sbagliata. Risultato: non ricevevano comunicazioni critiche.

Passo 2: Gap analysis strutturata delle 10 misure

Condurre un’analisi del gap rispetto alle misure di baseline dell’ACN: governance e risk analysis, incident management, business continuity and backups, supply chain security, MFA, encryption, e training.

Ho sviluppato un template Excel con 3 colonne per ogni misura:

1. Stato attuale: «Implementato», «Parziale», «Assente»
2. Gap identificato: descrizione specifica
3. Azioni e timeline: cosa fare, entro quando, a carico di chi

Esempio – MFA:

Misura: Multi-Factor Authentication
Stato attuale: Parziale (MFA su VPN, no su AD/privilegi)
Gap: Amministratori accedono a DC con sola password; accesso a database senza MFA
Azione: Implementare Windows Hello for Business + TOTP su accessi privilegiati; pilot su 5 admin entro settembre, rollout completo entro ottobre

Passo 3: Implementate le misure ad alta priorità per prime

Tra le azioni prioritarie: training dei corpi dirigenti (obbligatorio, con responsabilità personale) e implementazione di monitoraggio 24/7 (senza visibilità continua, è impossibile rispettare i timeline di notifica).

Cronologia tipica che consiglio:

• Agosto 2026 (subito): Governance approval, IRT formation, training C-level
• Agosto-settembre: MFA, encryption keys, backup testing
• Settembre-inizio ottobre: Supply chain security assessment, incident response tabletop drills
• Fino al 31 ottobre: Last-minute remediation e documentazione finale

Passo 4: Documentate tutto, ovunque, sempre

Non basta avere il Incident Response Plan: dovete dimostrare che esiste, che è stato testato, che i team lo conoscono.

Nel mio toolkit, per ogni misura raccolgo:

• Policy document: firmato da management
• Evidence di implementazione: screenshot di configurazioni, log di audit, evidence di test
• Training records: chi ha ricevuto training, quando, su cosa
• Audit trail: changelog di revisioni della policy

Ho visto aziende con infrastrutture solide che hanno fallito audit perché non riuscivano a mostrare la documentazione. Incredibile, ma vero.

Incident Response Plan: la procedura che vi salva dalla multa

L’IRP deve mostrare step chiari e ripetibili per il contenimento, l’eradicazione e il recupero. Le policy generiche non sono sufficienti. Le attività devono essere registrate, testate ad intervalli pianificati, e tutte le prove documentate.

Struttura minima che consiglio:

A. Incident Detection & Alerting

Strumenti: SIEM (anche gratuito come Wazuh), EDR (CrowdStrike, Defender ATP, SentinelOne), log aggregation (ELK, Splunk).

Esempio playbook:

• Alert anomalia SIEM → team notificato via Slack + SMS
• Triage: analyst verifica in 30 min se falso positivo o reale
• Se reale: escalation a incident commander, avvio playbook

B. Incident Triage & Severity Assessment

Definire cosa costituisce un incidente significativo sulla base dell’impatto sulla delivery dei servizi, sulla sensibilità dei dati, sulla criticità dei sistemi e su soglie specifiche NIS2.

Matrice che ho testato:

• CRITICAL: Qualunque dato sensibile (PII, dati finanziari, segreti commerciali) confermato leaked OR RCE attivo su asset critico → early warning IMMEDIATE (entro 4 ore)
• HIGH: Tentativo di accesso non autorizzato al database OR malware su 3+ endpoint → early warning entro 12 ore
• MEDIUM: Malware isolato su singolo PC, nessuna lateral movement → notifica interno, no regulatory reporting
• LOW: False positive elevato, anomalia comportamentale senza confirma → log, no escalation

C. Containment & Eradication

Per ogni tipo di incidente, deve esistere un playbook documentato.

Esempio – malware con potenziale data exfiltration:

1. Isolamento di rete (VLAN isolata, revoca credenziali)
2. Forensic imaging del device
3. Root cause analysis (come è entrato? via phishing? accesso privilegiato compromesso?)
4. Eradication (patching, reimaging, credenziali reset)
5. Monitoring post-remediation per 2 settimane

D. Notification & Reporting

La notifica segue 3 fasi: early warning nelle 24 ore dall’incidente, rapporto completo entro 72 ore dettagliando la violazione e le misure di mitigazione, rapporto finale entro un mese con gli sforzi di recupero e i miglioramenti a lungo termine.

Template che utilizzo (semplificato):

EARLY WARNING (24h): Incidente #2026-XXXX. Sospetto malware su server di produzione. Causato da atto malevolo confermato. Potenziale cross-border impact (clienti UE colpiti). Status: containment in corso.

FULL NOTIFICATION (72h): [dettagli di analisi, dati toccati, timeline precisa, first indicators of compromise, preliminary mitigation]

FINAL REPORT (30 days): [root cause analysis completa, lezioni apprese, control improvements, evidence di test e recovery]

Implementare un processo pratico di notifica: definire chi segnala cosa al CSIRT entro le finestre di 24 ore e 72 ore.

E. Post-Incident Review & Lessons Learned

Non è opzionale. Ogni incidente deve generare una lezione.

Ho visto PMI che, dopo un breach, han messo una patch mancante su un asset critico e nient’altro. Risultato: un anno dopo, stesso vettore di attacco. Disastro.

Il mio template di lessons learned obbliga a:

• Identificare i control failures che hanno permesso l’incidente
• Proporre remediation (patch, policy update, training aggiuntivo, procurement tool)
• Assegnare owner e deadline
• Aggiornare il risk register
• Comunicare a C-suite (il board deve sapere cosa è accaduto e come l’azienda ha risposto)

Passo 5: Testing e Tabletop Exercises

Le organizzazioni devono assicurarsi di avere robusti meccanismi per il rilevamento, la segnalazione e la risposta ai cyber incident. Questo include la formazione di un dedicated incident response team e la conduzione di regolari drill e simulazioni per assicurare che tutti i team member conoscano il loro ruolo.

Ho condotto nel 2025 una simulazione tabletop per una PMI di telco: abbiamo immaginato un attacco ransomware su data center critico, con timeline di notifica reali. Risultato: il 90% del team non sapeva cosa fare nei primi 30 minuti. Dopo la simulazione, abbiamo riscritto processi e fatto training. Al vero incident (sì, è capitato 4 mesi dopo), la risposta è stata 6 ore più veloce rispetto alle stime iniziali.

Consiglio: almeno 2 tabletop exercises all’anno, una di cui documentate tutto (per l’audit).

Il Risk Assessment Framework: non è uno sforzo una tantum

La gestione del rischio è una pietra miliare della conformità NIS2. Le PMI devono condurre valutazioni regolari del rischio per identificare vulnerabilità nelle loro reti e sistemi informativi. Queste valutazioni devono coprire fattori interni ed esterni che potrebbero compromettere la sicurezza, seguite da step azionabili per mitigare i rischi identificati.

La parola chiave è regolare. Non basta fare un assessment nel 2024 e dire «done». NIS2 richiede revisioni periodiche (almeno annuali, meglio semi-annuali).

Nella mia procedura, il framework si articola in:

1. Asset Inventory & Criticality Ranking

Dove sono i vostri dati sensibili? Chi li tratta? Quali sistemi sono critici per il business?

Strumento: spreadsheet o CMDB (tool gratuiti: open-source Snipe-IT).

2. Threat Modeling

Per ogni asset critico, quali sono le minacce reali? Attori esterni? Insider risk? Malware?

Fonte: uso di vulnerability scanning automatico e behavioral pattern analysis per identificare pattern di minaccia.

3. Vulnerability Assessment

Scanner: OpenVAS (gratuito), Nessus (freemium), Qualys (enterprise). Per app: OWASP ZAP, Burp Community.

4. Control Assessment

Per ogni vulnerabilità, quali controlli già mitigano? MFA riduce il rischio di accesso non autorizzato? Firewall riduce l’exposizione di asset?

5. Residual Risk Calculation

Rischio = Probabilità × Impatto. Se il rischio residuale è ancora «alto», va mitigato (con nuovi controlli, con accettazione conscia di management, o con trasferimento di rischio via assicurazione cyber).

6. Treatment Plan & Follow-up

Chi fa cosa, entro quando, con quale budget, e chi verifica che sia stato fatto?

Novità importante: il risk register deve essere revisionato e aggiornato almeno semestralmente, con evidence documentata di review da parte di management.

Misure di sicurezza di base: il minimo operativo per il 31 ottobre

Non è realistico implementare tutto perfettamente in poche settimane. Però, ci sono misure must-have entro il 31 ottobre e misure «va bene se migliori entro il 2027».

Una buona parte delle misure NIS2 un’azienda può gestirle in-house: backup, MFA, training e policy di base sono alla portata di chiunque abbia un minimo di struttura.

Le priorità (realistiche):

FAQ

La nostra azienda ha 45 dipendenti e fatturato €8 milioni. Siamo in scope NIS2?

Se hai una PMI in un settore coperto con 50 o più dipendenti o fatturato superiore a €10 milioni, allora sei in scope. Nel vostro caso, il calcolo dipende dal vostro settore. Se siete in manifattura, sanità, energia, trasporti, finanza, infrastrutture digitali o e-commerce, verificate se rientrate in «entità importante» secondo l’ACN. La soglia di «importanza» può includere aziende più piccole se forniscono servizi critici. Consultate il portale ACN con i vostri dati legali.

Abbiamo un piano di disaster recovery, ma non testato da 3 anni. Basta per il 31 ottobre?

No. Le organizzazioni devono preparare un piano di continuità aziendale strutturato che includa procedure di recupero del sistema e d’emergenza per minimizzare il downtime. Un piano sulla carta che non è stato testato è peggio di niente: agli occhi dell’auditor, dimostra che non sapete se funziona. Entro il 31 ottobre, conducete almeno un test (anche virtuale / tabletop), documentate risultati, tempi di recovery, e gap. Questo vi salva almeno dall’accusa di negligenza totale.

Non abbiamo ancora un Incident Response Team designato. Come facciamo in 2 settimane?

Definite chi segnala cosa al CSIRT entro le finestre di 24 ore e 72 ore. Minimo: IT Manager + un rappresentante della direzione + un responsabile legal/comunicazione. Non serve una struttura elaborata. Serve un documento firmato, con i nomi, i contatti, e una chiara escalation. Inoltre, almeno il responsabile della direzione deve aver ricevuto training su NIS2 (anche un corso online di 4 ore certificato) – questa è obbligatoria per responsabilità personale ex Article 20: il management deve essere addestrato e deve formalmente supervisionare e approvare le misure di gestione del rischio di cybersecurity dell’organizzazione.

MFA su tutti gli accessi, o solo privilegiati?

MFA non è facoltativo per le entità coperte da NIS2. Questo include sistemi interni, accesso remoto e account privilegiati. Nella pratica, per una PMI, parto da: VPN + accesso privilegiato (admin, DBA, domain admin) + accesso a dati sensibili (database, file server contenente PII). Se poi riuscite a mettere MFA su tutti gli accessi ai sistemi interni (via Okta, Entra, Keycloak), ancora meglio – ma è il 20% che fa la differenza, non il 100%.

Quale strumento open-source consigliate per SIEM e Incident Response automation?

Per SIEM: Wazuh (open-source, agent-based, scalabile). Per EDR: Velociraptor (forense distribuita) o Osquery (monitoring endpoint). Per ticket automation: TheHive + Cortex (SOAR open-source). Per playbook: Ansible + custom Python. Sono tutti free e community-supportati. Se avete budget ridotto e competenze interne limitate, meglio partire con policy + manual playbook ben documentato piuttosto che tool complesso non mantenuto.

Conclusione: 31 ottobre non è la fine, è l’inizio

Nel mio lavoro con dozzine di PMI, ho visto che le aziende che rispettano il 31 ottobre 2026 non sono quelle che implementano tutto perfettamente – sono quelle che completano il 70% con documentazione solida e governance formale. Il resto, gli audit e i miglioramenti continui, arrivano dopo.

Chi è in scope deve coprire 10 aree di sicurezza (Article 21), essere in grado di notificare incidenti all’ACN entro 24/72 ore/1 mese, e avere le misure di baseline operative entro il 31 ottobre 2026. Non conformarsi rischia multedi fino a €10 milioni o 2% del fatturato mondiale, oltre alla responsabilità personale dei dirigenti.

Ecco il mio ultimo consiglio: iniziate oggi. Se avete struttura IT interna, usate la mia checklist per un self-assessment veloce. Se non l’avete, contattate un partner specializzato in NIS2 (audit firm, MSP, consulente cyber) – non è caro quanto sembra e vi evita rischi legali enormi.

Vi consiglio anche di consultare: il mio articolo su Plesk Security Hardening e WAF AI-assistito se ospitate ambienti Plesk, oppure Android Mobile Enterprise Security se dovete proteggere device aziendali.

Il 31 ottobre arriverà. Che siate pronti o no, NIS2 non aspetta. Ditemi nei commenti se avete dubbi sulla vostra situazione specifica – sono qui per aiutare.