Siamo a luglio 2026: le scadenze NIS2 in Italia non sono più una minaccia lontana, ma una realtà operativa che incalza. La Agenzia per la Cybersicurezza Nazionale (ACN) ha già avviato i controlli, i primi incident response playbook sono stati testati, e le imprese critiche in scope stanno scoprendo che avere una procedura scritta non è la stessa cosa che poter eseguire una notifica CSIRT in 24 ore sotto pressione. Nel mio lavoro con clienti di settori critici – energia, sanità, infrastrutture digitali – ho visto come la teoria della compliance si scontra rapidamente con la realtà operativa.
In questo articolo condivido la procedura che ho implementato per aziende in compliance readiness: dalle prime 24 ore dell’early warning, alla notifica qualificata a 72 ore, fino alla security assessment e al remediation roadmap (piano di adeguamento) che ACN si aspetta di vedere. Non è una checklist teorica: è il sistema che funziona quando il clock inizia a correre a mezzanotte con un incidente reale.
NIS2 Luglio 2026: Lo Stato Reale della Conformità in Italia
Comincio con il contesto: ACN’s first-application timeline states 9 months (January 2026) for significant-incident notification obligations and 18 months (October 2026) for baseline security-measure adoption. Questo significa che siamo già nella fase calda per l’incident reporting – il primo gennaio 2026 era il deadline per attivare la capacità di notificare incidenti significativi in 24 ore.
La realtà? 84% of in-scope organisations are not NIS2 compliant — and 11% do not even know what NIS2 is. With Belgium opening its audit window and Germany’s BSI tracking 18,500 companies that missed their deadline, 2026 is the year enforcement becomes real. In Italia, la situazione è diversa per settore: le aziende di energia e sanità sono ben avanti, le amministrazioni pubbliche ancora indietro.
Qui entra in gioco la strategia operativa. Non potrete implementare tutte le dieci misure di Article 21 in tre mesi – ma dovete avere l’incident response capability ora, perché la notifica di incidente significativo non è opzionale e non conosce proroghe.
Fase 1: Definire Cosa Significa “Incidente Significativo” per la Vostra Organizzazione
La maggior parte dei miei clienti mi dice: “Abbiamo una procedura di incident response”. Puntualmente, quando chiedo “E come classificate un incidente significativo?”, la risposta è un silenzio imbarazzato, o peggio, una risposta vaga.
“Significant” under NIS2 means: the incident has caused or is capable of causing severe operational disruption or financial loss, or it has affected or is capable of affecting other persons by causing considerable material or non-material damage. Questa definizione è corretta dal punto di vista normativo, ma non è operazionale. A livello pratico, durante un incidente, non avete tempo per dibattiti filosofici sulla “severità”.
Ecco cosa ho fatto per i miei clienti: abbiamo costruito una matrice di significatività con criteri numerici e osservabili. Eccone un esempio:
- Downtime superiore a 4 ore di un sistema critico → Significativo
- Dati di più di 100 persone esfiltrati o compromessi → Significativo
- Danno finanziario stima > 50.000 euro → Significativo
- Attacco ritenuto malicious (IDS alert confermato, pattern noto, TTPs malevole) → Significativo fino a prova contraria
- Cross-border impact (incidente colpisce servizi in altri paesi EU) → Significativo
Questa matrice va approvata dal CdA e resa operativa al primo livello di SOC/IR team. Non aspettate il momento dell’incidente per discuterne. Ho visto incidenti veri dove 3 ore sono state perse discutendo se fosse “abbastanza grave” per notificare: nel frattempo il clock NIS2 stava già correndo.
Fase 2: La Procedura delle 24 Ore – Early Warning Qualification
Unlike the single-notification model under GDPR or the ad hoc approach of the original NIS Directive, NIS2 incident reporting follows a strict three-stage process: a 24-hour early warning, a 72-hour incident notification, and a one-month final report. Cominciamo dalle prime 24 ore.
L’early warning non è una indagine completa – è una notifica di massima allerta al CSIRT. In pratica, 2-3 ore dopo che il vostro SOC ha rilevato l’incidente, dovete avere qualcosa da dire alle autorità. Ecco la procedura che funziona:
T+0 (Detection) – Moment of Awareness
Il SOC rileva l’anomalia e la documenta. Cruciale: registrate l’ora esatta di detection in un log centrale e immutabile. Questa è l’ora di “awareness” da cui parte il clock di 24 ore. Niente chat di Slack, niente email – un sistema di record centrale.
T+15 minuti – Escalation ed Early Classification
L’incident commander (IC) riceve un alert strutturato che contiene:
- Timestamp di detection
- Sistemi interessati (best effort, non è completo)
- Tipo di incidente (ransomware, DDoS, data exfiltration, account compromise, ecc.)
- Attacco sospetto di essere malicious? (Y/N)
- Cross-border? (Y/N)
- Threshold classification raggiunto? (Applicate la vostra matrice di significatività)
Se il threshold è raggiunto → avviate il clock di escalation. L’IC e il legal team (chi approva la notifica) devono essere coinvolti entro i prossimi 30 minuti.
T+2 ore – Early Warning Drafting
A questo punto avete già 2 ore di investigazione. L’early warning deve contenere (ma come best-effort, la completezza arriva dopo):
- Identificativo dell’entità (codice ACN e categoria: essential/important)
- Timestamp di awareness
- Categoria di incidente (confidentiality, integrity, availability)
- Sottocategoria (ransomware, DDoS, account takeover, ecc.)
- Sospetto di attività illecita o malicious? (Yes/No) – questo cambia il flusso di investigazione
- Cross-border? (Yes/No) – se sì, dovrete notificare in parallelo ad altri CSIRT
- Stima preliminare di sistemi/dati interessati (range: 1-10 sistemi, 0-1000 persone, ecc.)
- Azioni di contenimento già intraprese (opzionale ma apprezzato)
Ho incluso nel nostro playbook un template pre-compilato (disponibile nel sistema di ticketing in modalità read-only) che riduce il tempo di drafting da 40 minuti a 10 minuti di revisione.
T+20 ore – Verifica e Submissione
Prima della sottomissione al CSIRT Italia, il documento passa a legal, IR lead e CISO. In Italia, il canale è il portale ACN (portale.acn.gov.it). Assicuratevi di avere credenziali configurate e testate prima di un incidente reale. Ho visto team che non riuscivano nemmeno a loggarsi al portale quando è arrivato il momento di notificare.
NIS2 requires traceability. This means: the entire incident response must be documented as it happens – not reconstructed after the fact. Ogni comunicazione, decisione, e timedelta deve rimanere tracciata nel sistema centrale. Non usate note personali o file locali.
Fase 3: La Notifica a 72 Ore – Incident Notification Qualified
A 72 ore dal momento di awareness, il vostro report deve essere significativamente più dettagliato. Within 72 hours of becoming aware of the incident, the entity must submit a more substantive incident notification. This updates and expands on the early warning and must contain: An initial assessment of the incident, including its severity and impact · The indicators of compromise (IoCs) where available.
Qui è dove il flusso di investigazione diventa mission-critical. Normalmente, fra T+24h e T+72h, dovete avere:
- Timeline preliminare: quando l’attaccante ha iniziato? Quando è stato rilevato il primo IoC? (Spesso ci sono giorni di differenza – questo lo dite nel report)
- Scope completo: quali sistemi, utenti, segmenti di rete
- IoCs tecnici: IP indirizzi dell’attaccante, domini usati, hash di file, YARA rules se disponibili
- Valutazione di severity: ho usato una scala CVSS-like (Critical, High, Medium, Low) basata su confidentiality/integrity/availability impact
- TTPs osservate: technology tactics and procedures – quali tool ha usato? Lateral movement? Data exfiltration? (Usate il MITRE ATT&CK framework come linguaggio comune)
- Root cause, se noto: phishing link? VPN non patchata? Ecc. Se non lo sapete ancora, dite “under investigation”
A questo punto, molti team scoprono che non hanno la visibility per rispondere a queste domande. E qui casca il palco: avere un SIEM, un EDR, un threat intelligence feed non è opzionale se volete essere NIS2-compliant. Non potete farlo con log files in formato CSV manuale.
Nel mio setup per i clienti di taglia media (500-5000 persone, settori critici):
- Elastic Stack per log aggregation (è open source e scalabile)
- Wazuh per EDR e file integrity monitoring (FIM)
- Suricata/Zeek per network detection (su architetture edge)
- Collegamento a threat intelligence feeds (ABUSE.ch, Shodan, Censys, o iscrizioni a servizi commerciali)
Ho scritto in precedenza su come collegare Plesk a Elastic/Splunk per real-time malware pattern detection multi-tenant – gli stessi principi si applicano qui, ma a livello enterprise.
Fase 4: Security Assessment – Gap Analysis Contro Article 21
Mentre state ancora indagando su un incidente, ACN inizia a chiedervi: “Come è successo? Avete un vulnerability management formale? Un patch management? Supply chain risk assessment?”
Questo è il momento in cui la “readiness” si trasforma in compliance reale. Article 21 of the NIS2 Directive defines ten categories of risk management measures that affected entities must implement. These are not optional recommendations but legally binding obligations. For critical infrastructure operators, the requirements cover the full spectrum of cybersecurity, from governance and risk assessment to incident response and supply chain security.
Le dieci misure di Article 21 sono:
- Risk Management – valutazione formale dei rischi e del loro trattamento
- Asset Management – inventario dei sistemi critici IT e OT
- Access Control – MFA obbligatorio, Zero Trust principles
- Cryptography – encryption at rest e in transit per dati critici
- Physical Security – controllo accesso fisico ai data center e server room
- Supply Chain Security – vetting dei vendor e monitoraggio continuo
- Incident Response – playbook, IR team, recovery procedures
- Business Continuity & Disaster Recovery – backup immutabili, failover testati
- Security Operations Monitoring – SIEM, SOC 24/7, log retention
- Cybersecurity Awareness Training – phishing simulations, formazione obbligatoria
Per una security assessment NIS2-compliant, ho sviluppato una procedura in quattro fasi:
Assessment Phase 1: Scoping & Classification
Identificare quale categoria di entità siete: essential o important. NIS2 organizes covered sectors into two categories that determine supervision intensity and penalty exposure. Essential entities operate in 11 highly critical sectors while important entities operate in 7 other critical sectors. In Italia, If you operate in critical sectors such as energy, health, or certain manufacturing areas, you are likely in scope and must register with the ACN.
Consultate il decisional tree ACN (disponibile su portale.acn.gov.it) per confermarlo.
Assessment Phase 2: Gap Analysis Strutturata
Contro ogni misura di Article 21, compilate una matrice di conformità:
- Current State: cosa avete oggi? (Documented/Partially/Not Implemented)
- Target State: cosa richiede NIS2? (Use ENISA Technical Implementation Guidance come riferimento)
- Gap: quale è la distanza?
- Remediation Owner: chi è responsabile di chiuderla?
- Timeline: quando?
- Evidence Required: cosa ACN cercherà per verificarlo? (Policy documents? Audit logs? Test reports?)
Per ogni gap che non riuscite a chiudere entro il deadline di ottobre 2026 (18 mesi from notification), dovete documentare perché e un piano d’azione alternativo. Questo diventa parte del vostro piano di adeguamento (remediation roadmap) da sottoporre a ACN.
Assessment Phase 3: Risk Assessment Completo
Every entity must establish and maintain a comprehensive information security risk management framework. This includes documented security policies, a risk register covering all critical systems and processes, and regular risk assessments. For a water works, this means not only IT systems like SCADA and process control networks but also operational technology (OT) environments that control water treatment, distribution, and monitoring. The risk management framework must be approved by the management body and reviewed at least annually.
Per le infrastrutture critiche, il mio approccio è:
- Asset Discovery: inventario completo di tutti i sistemi IT e OT (non è uno schema Excel – usate tools di discovery come Nessus, Qualys, o Shodan API)
- Threat Modeling: per ogni asset critico, quali minacce può subire? (Ransomware? DDoS? Insider? Supply chain compromise?)
- Risk Scoring: probabilità × impatto = risk score (usate una scala 1-5 per entrambe le dimensioni)
- Treatment Decision: accettate il rischio? O implementate controlli per ridurlo?
- Monitoring & Review: quando rivediamo? (Minimo annuale, ma per settori critici suggerisco semestrale)
Questo diventa il vostro risk register – il documento che ACN chiederà di vedere durante una revisione.
Assessment Phase 4: Validation & Board Sign-Off
NIS2 requires the management body to approve and oversee the cybersecurity risk management framework. This means your executive board or managing directors must be formally involved. Non è una firma simbolica: deve essere un processo documentato dove il CdA approva sia la strategia di risk management che il piano di adeguamento.
Nella mia esperienza con clienti pubblici, questo è il collo di bottiglia. I board riunioni sono rare, le firme lente. Soluzione: create una governance committee interna (CISO + direttori di business units critiche) che si riunisce mensilmente e riporta al CdA trimestralmente.
Procedura di Remediation Roadmap (Piano di Adeguamento)
Una volta completata la gap analysis, dovete consegnare un piano di adeguamento a ACN entro il deadline di ottobre 2026. The remediation roadmap is mandatory under NIS2 Appendix C (ID.IM-01). This guide covers how to consolidate gaps, prioritize actions, align milestones to October 2026, and build a board-approvable plan with closure evidence.
Struttura del piano:
- Executive Summary (1 pagina): cosa siete, dove siete vulnerabili, cosa farete
- Gap Inventory (tabella): lista di tutti i gap identificati, organizzati per Article 21 measure
- Remediation Actions (lista dettagliata):
- Gap ID (es. “GAP-101: Multi-factor authentication not deployed on VPN”)
- Misura NIS2 interessata (es. “Article 21.2 – Access Control”)
- Descrizione dell’azione correttiva
- Owner
- Timeline (inizio, completion date)
- Budget stimato (opzionale ma apprezzato)
- Evidence di completamento (cosa userete per provare che è fatto?)
- Timeline Gantt: visualizzazione delle dipendenze e della sequenza
- Board Approval Statement: firma del CdA che approva il piano
Ho aiutato aziende di 200-2000 persone a completare questo in 6-8 settimane con un processo strutturato. Senza struttura? Sei mesi di back-and-forth con ACN.
FAQ
Se scopriamo un incidente a luglio 2026, come facciamo in pratica a notificarlo in 24 ore se non siamo ancora completamente compliant?
Non è un conflitto. L’incident response capability (Article 25) è il primo deadline – gennaio 2026. La conformità completa a tutte le dieci misure di Article 21 è ottobre 2026. Se scoprite un incidente prima di ottobre, dovete comunque notificare in 24 ore, anche se il vostro framework di risk management non è ancora finito. ACN non vi scusa la notifica perché non avete implementato la MFA. I due obblighi sono indipendenti.
Il portale ACN è lento/non funziona – che succede se non riusciamo a sottomettere in tempo?
If the incident clearly exceeds the threshold in the first hour, do not wait — the 24-hour clock has already started. Se il portale è down, documentate il tentativo (screenshot dell’errore, timestamp, etc.) e contattate il CSIRT Italia per email/telefono in parallelo. La comunicazione deve iniziare entro 24 ore, anche se la forma non è perfetta. Una notifica via email a csirt@csirt.gov.it + ticket nel portale appena possibile è sempre meglio che silenzio totale.
Cos’è che ACN controllerà durante un audit oltre al piano di adeguamento?
Every Italian regulated entity under NIS 2 is subject to surprise audits, multi-sector reviews, and instant regulator evidence calls. Prepararsi per un audit significa avere:
- Documentazione di governance (board minutes che approvano cybersecurity strategy)
- Risk register aggiornato (con ultime revisioni datate)
- Inventory di tutti i sistemi critici IT/OT
- Logs di accesso (almeno 12 mesi indietro)
- Records di penetration test / vulnerability scans
- Incident response drills e tabletop exercise (con attestazione di partecipazione)
- Supplier risk assessments
- Training records (chi ha completato la formazione di cybersecurity awareness?)
Tutto in un repository centralizzato e tracciato, non sparse in 50 folder di email.
Compliance NIS2 costa quanto per un’azienda di 500 persone?
Dipende da dove partite. Se avete già un CISO, un security team, e una basic ISMS:
- Security Assessment + Gap Analysis: 30-50k euro (interno o esterno)
- Remediation (tools, training, process): 100-300k euro (secondo i gap)
- Governance & Planning: 20-30k euro
Se partite da zero? Aggiungete il costo di un CISO a tempo pieno (60-80k/anno) e di un security engineer (50-65k/anno) per almeno 2 anni. Non è una spesa una tantum – è operativa.
Abbiamo una cloud infrastructure multi-tenant (tipo Plesk). Come gestiamo NIS2 se i clienti sono distribuiti geograficamente?
Qui entra in gioco la shared responsibility model. Potete leggere il mio articolo precedente su NIS2 Directive Hosting Provider Compliance per dettagli, ma in breve:
- Voi (provider) siete responsabili di: infrastructure security, logging, incident detection, supply chain
- I vostri clienti sono responsabili di: application security, data classification, access control policies, incident response
- Un incidente che colpisce il vostro infrastructure deve essere notificato da voi a CSIRT Italia entro 24 ore, indipendentemente da dove siano i clienti
Assicuratevi che i vostri SLA con i clienti includano breach notification obligations bilaterali.
Conclusione: Non Rimandare il 72-Hour Clock
NIS2 a luglio 2026 non è più una minaccia teorica. For Italian organisations, the path forward is clear: register (if you have not already — do it immediately), assess your gaps against ACN’s published obligations, implement governance and incident reporting by January 2026, complete all technical measures by October 2026, and build the annual compliance rhythm that Italy’s unique re-registration cycle demands. The organisations that start now will find the task manageable. Those that wait until the enforcement deadline approaches will face a compressed timeline, a competitive market for compliance expertise, and a regulator that has made clear its intention to supervise actively.
La procedura che ho condiviso funziona perché separa ciò che è urgente (incident response) da ciò che è importante (compliance roadmap). Potete costruire il vostro security assessment e il remediation roadmap over time. Ma il 24-hour early warning? Quello deve funzionare ora. Se il vostro SOC non è configurato per notificare un incidente significativo entro 24 ore, la curva di conformità inizia negativa – e ACN se ne accorgerà.
Nel mio lavoro con centinaia di clienti critici, ho visto che le aziende che vincono sono quelle che non aspettano il primo incidente reale per testare il playbook. Fate un tabletop exercise oggi. Scoprirete i buchi. Riparateli. Quando il clock inizierà a correre, sarete pronti.