Applicabilità: soggetti NIS che validano la documentazione di gestione incidenti nell'ambito degli obblighi di base.
Una revisione documentale NIS2 sulla gestione incidenti deve verificare prima tre elementi: integrità del processo end-to-end, prontezza di notifica allineata ai requisiti legali e accountability di governance. Gli obblighi di notifica incidenti sono già in vigore, mentre le milestone più ampie degli obblighi di base proseguono verso ottobre 2026: la qualità documentale impatta quindi direttamente sia il rischio ispettivo sia l'efficacia operativa.
Punti Chiave
- Valutare un solo documento incidenti non basta; il controllo reale è la catena completa da rilevamento a ripristino e reporting di governance.
- La prontezza notifica va verificata con tempistiche e contenuti concreti (24 ore, 72 ore, 1 mese, oltre a flussi intermedi/mensili ove applicabili).
- L'assenza di baseline sui livelli di servizio e di criteri di classificazione può bloccare l'identificazione coerente degli incidenti significativi.
- La documentazione di ripristino è spesso dettagliata sul backup ma debole su RTO/RPO, ordine di ripristino e integrazione con la gestione crisi.
Ambito di Questo Articolo
Questo articolo copre:
- Un modello pratico di revisione per la documentazione di gestione incidenti negli obblighi di base NIS2.
- I gap documentali ad alto impatto più frequenti in scenari di audit anonimizzati.
- Un workflow di remediation per trasformare i finding in backlog gestito.
Questo articolo non copre:
- Finding identificativi di cliente.
- Template proprietari completi e matrici di scoring dettagliate.
Framework Ufficiale di Riferimento
| Fonte | Perché è rilevante nella revisione |
|---|---|
| D.Lgs. 138/2024 | Definisce gli obblighi legali NIS2, inclusi responsabilità di governance e notifica incidenti. |
| Determinazione ACN sugli obblighi di base | Definisce misure baseline e mappatura documentale usate nei controlli di readiness. |
| Guida ACN alla lettura delle specifiche di base | Chiarisce la logica evidenziale attesa e l'interpretazione applicativa. |
| Guida ACN alla notifica degli incidenti informatici | Fornisce indicazioni operative per il disegno del processo di notifica. |
| ACN - Modalità e specifiche di base NIS | Fornisce il contesto di attuazione e la timeline delle milestone baseline. |
Cosa Deve Validare la Revisione (5 Domini di Controllo)
| Dominio di controllo | Cosa verificare | Pattern di failure frequente | Riferimenti principali |
|---|---|---|---|
| 1. Copertura delle fasi processo | Preparazione, rilevamento/analisi, risposta, ripristino e miglioramento post-incidente sono documentati e collegati. | Le fasi sono elencate ma le procedure mancano o sono delegate a materiale esterno non integrato localmente. | D.Lgs. 138/2024; Guida ACN |
| 2. Prontezza notifica | Il pacchetto di reportistica copre pre-notifica (24h), notifica completa (72h), relazione finale (1 mese) e aggiornamenti strutturati. | Esiste la struttura 24h/72h/30gg ma non sono formalizzate relazioni intermedie/mensili. | D.Lgs. 138/2024, art. 25; guida notifica ACN |
| 3. Transizioni end-to-end | Gli artefatti di rilevamento attivano esplicitamente il workflow di risposta; la risposta collega esplicitamente ripristino/continuità/crisi. | Riferimenti unidirezionali interrompono tracciabilità di escalation e ripristino. | Determinazione ACN; guida ACN |
| 4. Accountability ruoli | Punto di contatto, referente CSIRT/sostituti, ruoli operativi e ownership di governance/board sono mappati in modo esplicito. | I ruoli operativi sono presenti, ma accountability di governance o ownership escalation sono ambigue. | D.Lgs. 138/2024, art. 23; determinazione ACN |
| 5. Integrazione ripristino e crisi | Le procedure di ripristino includono priorità, target RTO/RPO, ordine di ripristino e governance comunicazioni di crisi. | Il backup è documentato, ma continuità operativa e governance di crisi restano sottodefinite. | Determinazione ACN; guida ACN |
Punti di Controllo per la Notifica (art. 25)
| Punto di controllo | Tempistica attesa | Domanda minima di review |
|---|---|---|
| Pre-notifica | Entro 24 ore | Esistono trigger espliciti, owner e dataset minimo per la prima comunicazione? |
| Notifica completa | Entro 72 ore | Esiste un processo documentato per arricchimento tecnico (sistemi coinvolti, indicatori, impatto)? |
| Relazione finale | Entro 1 mese | Esiste una struttura post-incidente per root cause, consolidamento impatti e azioni correttive? |
| Relazioni intermedie | Durante il ciclo dell'incidente | Sono documentati cadenza, owner e formato degli aggiornamenti? |
| Report mensile di avanzamento | Se l'incidente resta aperto | Esiste un processo ricorrente con accountability e tracciabilità evidenze? |
Gap Strutturali ad Alto Impatto Osservati negli Audit (Anonymized)
- La documentazione di monitoraggio richiama capacità SIEM/SOC ma non definisce triage e criteri di classificazione della significatività.
- I criteri di incidente significativo sono dichiarati a livello di principio ma non tradotti in logica decisionale misurabile.
- Tempistiche e template di notifica sono definiti in un artefatto di governance ma non integrati nel documento principale di risposta incidenti mappato ai requisiti baseline.
- Le procedure di ripristino contengono dettaglio infrastrutturale ma non includono target RTO/RPO e sequenza di ripristino.
- Gli obblighi di gestione crisi sono citati ma non operativizzati con composizione comitato, criteri di attivazione e workflow di de-escalation.
- Le matrici ruolo assegnano responsabilità operative ma mantengono gli organi di governance come destinatari passivi, con possibile disallineamento rispetto all'accountability legale.
Workflow Pratico di Revisione e Remediation in 7 Passi
- Costruire la mappa della catena di processo dal rilevamento alla chiusura e identificare transizioni mancanti.
- Validare i controlli di notifica rispetto alle tempistiche e agli artefatti richiesti dall'art. 25.
- Testare la logica di classificazione della significatività incidenti rispetto a soglie documentate.
- Riconciliare le matrici ruolo tra documenti di governance e documenti operativi.
- Consolidare i cross-reference affinché ogni passaggio critico abbia link a monte e a valle.
- Validare la completezza del ripristino (RTO/RPO, ordine di ripristino, percorso comunicazione).
- Convertire i finding in backlog remediation prioritizzato con owner, data target ed evidenza di chiusura.
Pacchetto Minimo di Evidenze per Chiudere i Finding Critici
| Evidenza | Perché serve |
|---|---|
| Mappa processo incidenti unificata con ownership ruoli | Dimostra continuità operativa e chiarezza di governance. |
| Playbook notifica con template 24h/72h/1 mese | Dimostra readiness legale e ripetibilità esecutiva. |
| Criteri classificazione significatività con soglie misurabili | Dimostra oggettività nelle decisioni di escalation e notifica. |
| Matrice ripristino con RTO/RPO e sequenza di recovery | Dimostra pianificazione di resilienza oltre il solo backup. |
| Protocollo governance crisi (attivazione, comunicazioni, de-escalation) | Dimostra integrazione tra risposta incidenti e governance esecutiva. |
FAQ
Un documento governance è sufficiente se la procedura operativa incidenti è debole?
No. Governance e operatività devono essere integrate. Un framework governance solido non compensa l'assenza di procedure operative nel documento di risposta incidenti mappato ai requisiti baseline.
Il pacchetto 24h/72h/1 mese basta da solo?
Non sempre. Va verificato se relazioni intermedie e mensili sono richieste e realmente operativizzate nel set documentale.
Il referente CSIRT può essere esterno al soggetto?
Sul piano operativo può essere strutturato in modelli di gruppo, ma la responsabilità di governance resta in capo agli organi di amministrazione e direttivi del soggetto, secondo il perimetro normativo.
Cosa fare se i criteri di classificazione sono incompleti?
Va trattato come finding prioritario. Senza criteri misurabili, le decisioni di significatività e i trigger di notifica diventano incoerenti.
Conclusione
La revisione documentale della gestione incidenti è un controllo di readiness, non un esercizio formale. Il valore sta nel dimostrare che rilevamento, risposta, ripristino e comunicazioni di governance operano come un sistema unico e tracciabile. Un approccio di audit strutturato aiuta a ridurre rischio regolatorio e rework prima dell'aumento della pressione ispettiva.
Letture correlate
- Compliance Documentation Audit per gli Obblighi di Base NIS2: panoramica del metodo
- Piano NIS2 di gestione incidenti e notifica CSIRT: guida pratica per un documento RS.MA-01 approvabile
- Prioritizzazione dei Finding NIS2: dalla gap list all'esecuzione remediation
- Servizio Aegister NIS2 Compliance