Timeline incidenti NIS2 Title 13 — il playbook pratico

Il countdown non parte nel momento in cui il tuo SOC apre l'alert. Parte nel momento in cui un osservatore competente concluderebbe che avresti dovuto sapere. In pratica:

• Avvia subito il tuo log timeline interno appena hai awareness, catturando il timestamp del primo segnale (umano o automatico).
• Se sospetti che il ritardo di detection sia parte del problema, documenta le cause (gap sensore, cadenza batch SIEM, ecc.) per includerle nell'analisi post-incidente.
• Notifica al DPO designato e al legale in parallelo al SOC — ognuno ha obblighi paralleli che possono aggiungere notifiche (art. 33 GDPR, DORA per finance, settoriali se applicabili).

Obiettivo: filare l'early warning ad ACN/CSIRT Italia prima che scada l'ora 24 dal punto "avresti dovuto sapere".

Contenuto minimo dell'early warning: - Data e ora di rilevamento incidente (o inizio stimato). - Classificazione preliminare: tipo incidente (intrusione, ransomware, esfiltrazione, DoS, compromissione supply-chain, ecc.). - Scope iniziale: quale servizio essenziale o importante è coinvolto, spread geografico, numero stimato di utenti impattati. - Se è sospettato impatto cross-border. - Una singola email e telefono di point-of-contact.

Cosa NON serve a 24h: root cause completa, lista IOC completa, attribuzione. L'early warning è preliminare per design — sotto-comunicare è peggio che sopra-comunicare in questa fase.

Failure mode comune a questo gate: aspettare "allineamento" interno prima di filare. Il decreto non contempla quel ritardo; si aspetta l'early warning anche se l'investigation interna è ancora attiva.

Obiettivo: filare la notifica completa entro ora 72.

Aggiunte obbligatorie sul contenuto rispetto all'early warning: - Valutazione impatto aggiornata (severità, impatto customer-facing, impatto su processi business, stima impatto finanziario dove disponibile). - Indicatori di compromissione: IP, domini, hash, TTP in notazione MITRE ATT&CK. - Ipotesi iniziale di root-cause (vulnerabilità sfruttata, vettore initial access, percorso laterale). - Azioni di containment già prese; azioni di remediation in corso. - Se sono stati impattati dati personali (e quindi è scattato l'art. 33 GDPR). - Se l'incidente è sospettato come intenzionale (criminale vs statuale) — questo cambia la stakeholder list a valle.

Failure mode: filare esattamente a 72h con ipotesi vestite da conclusioni. ACN si aspetta ipotesi preliminari oneste, chiaramente flaggate come tali. Rimangiarsi una conclusione confidente al report di 1 mese è peggio che flaggere l'incertezza in anticipo.

Obiettivo: filare il report finale entro 1 mese dal "avresti dovuto sapere".

Contenuto del report finale: - Root cause verificata (o spiegazione dettagliata del perché non è determinabile). - Lista IOC completa con attribuzione dove la confidenza è appropriata. - Status remediation completo: quali fix sono in produzione, quali ancora in volo, target date per il resto. - Lessons learned: cambi di processo, cambi di controllo, cambi di tooling. - Cross-reference alle altre notifiche depositate (art. 33 GDPR, DORA, settoriali, law-enforcement).

È qui che la chain di evidenza mostra la sua qualità. Se ogni artefatto è stato firmato al momento della scrittura e la chain è verificabile, il report finale è in gran parte un documento di sintesi con puntatori. Se gli artefatti sono stati assemblati a mano da tool disparati, il report finale richiede settimane di riconciliazione cross-tool che il team non ha staffato a metà di una incident response.

Su tutte e tre le submission, pianifica di avere pronto (firmato, datato, con chain-of-custody):

• Cronologia alert SOC (con timestamp originali, niente edit manuali).
• Export telemetria del sistema di detection sulla finestra incidente più 7 giorni precedenti.
• Log azioni di containment (block firewall, disabilitazione account, isolamento sistema) con timestamp.
• Log azioni di remediation (patch applicate, configurazioni cambiate, eventi rebuild) con timestamp e approvers.
• Lista IOC con provenance (da dove arriva ogni indicatore).
• Documento di root-cause analysis con version history.
• Log comunicazioni (allo staff, ai clienti, ai regolatori, alle forze dell'ordine).

Se uno qualsiasi di questi è prodotto da assemblaggio manuale durante la incident response, il conflitto di bandwidth è immediato. Lezione operativa dalle organizzazioni peer: avere un Trust Center o equivalente che pre-firma tutto in continuo, così il playbook diventa "export, review, firma, invia".

Un singolo incidente spesso fa scattare più di un regime di notifica. Combinazioni comuni:

• Breach dati paziente in ospedale: NIS2 Title 13 + art. 33 GDPR + possibile notifica AgID se cloud-resident.
• Disruption sistema trading in banca: DORA artt. 17-22 + NIS2 Title 13 + notifica settoriale Banca d'Italia.
• Breach PA: NIS2 Title 13 + art. 33 GDPR + notifica Garante + possibile notifica PSNC se in perimetro.

In ogni caso, la base evidenza è la stessa. Le notifiche sono summary diversi dello stesso record sottostante. Costruirla una volta — ed esportare per regime — è drammaticamente più facile che far girare tracce evidenza in parallelo. Le implementazioni Trust Center moderne lo supportano; gli strumenti GRC legacy tipicamente no.