Era un giovedì mattina quando il responsabile IT di una PMI manifatturiera del Bergamasco mi chiamò con la voce che conosco bene: quella di chi ha appena scoperto che qualcosa è andato storto. Un ransomware aveva cifrato i server di produzione nella notte, e l'azienda non sapeva da dove cominciare. Non avevano un piano di incident response, non sapevano chi doveva fare cosa, non sapevano se erano obbligati a notificare l'incidente al Garante. Tre giorni dopo, avevano capito tutto — a caro prezzo. Questo articolo ti spiega cosa prevede la ISO/IEC 27035, come costruire un piano che funzioni e cosa devi sapere sugli obblighi di notifica.
Cos'è ISO 27035 e il framework di incident management
La ISO/IEC 27035 è la norma internazionale di riferimento per la gestione degli incidenti di sicurezza delle informazioni. Si articola in più parti: la 27035-1 definisce i principi, la 27035-2 le linee guida per la pianificazione, la 27035-3 le operazioni di risposta. Non è certificabile autonomamente, ma è un componente fondamentale di un ISMS conforme alla ISO 27001 (Annex A, controlli 5.24-5.28).
La premessa è corretta: la domanda non è se la tua organizzazione subirà un incidente di sicurezza, ma quando. Un piano di incident response ben costruito fa la differenza tra un'organizzazione che gestisce l'incidente in modo ordinato, limita i danni e riprende l'operatività in tempi ragionevoli, e una che si trova in stato di caos, perde dati critici e subisce danni reputazionali che durano anni.
Le 5 fasi: pianificazione, rilevamento, valutazione, risposta, lesson learned
La ISO 27035 struttura la gestione degli incidenti in cinque fasi interconnesse — non un processo lineare che si esaurisce dopo la risoluzione, ma un ciclo che alimenta il miglioramento continuo.
Fase 1: Pianificazione e preparazione. La più importante e la più trascurata. Comprende: policy per la gestione degli incidenti, creazione del CSIRT, documentazione delle procedure operative, predisposizione degli strumenti (ticketing, canali sicuri, accessi ai log) e formazione del personale. Un piano che nessuno ha mai letto e mai testato non vale quanto la carta su cui è scritto.
Fase 2: Rilevamento e segnalazione. Copre i meccanismi di detection (SIEM, IDS/IPS, monitoraggio endpoint, alert) e i canali per segnalare un potenziale incidente. La norma sottolinea che la segnalazione deve essere semplice e non punire chi la fa in buona fede: dove i dipendenti temono ripercussioni, gli incidenti vengono scoperti tardi con danni già gravi.
Fase 3: Valutazione e decisione. La triage: valutare la natura dell'evento, classificarlo per gravità, determinare se è un falso positivo o un incidente reale, e decidere quale livello di risposta attivare. La ISO 27035 prevede una scala di classificazione che guida le decisioni sull'escalation.
Fase 4: Risposta. La fase operativa: contenimento immediato (isolare i sistemi compromessi), eradicazione (rimuovere la causa), ripristino (riportare i sistemi alla normale operatività in modo sicuro e verificato). Include anche la forensic analysis, fondamentale per capire cosa è successo e raccogliere evidenze per eventuali azioni legali o notifiche alle autorità.
Fase 5: Lessons learned. Ogni incidente è un'opportunità di apprendimento. La post-incident review deve essere documentata, identificare cosa ha funzionato e cosa no, e produrre azioni correttive concrete. Va condotta entro un tempo ragionevole dall'incidente, quando i dettagli sono ancora freschi.
Incident Response Team: ruoli, competenze, autorità
Il CSIRT (Computer Security Incident Response Team) non è necessariamente dedicato a tempo pieno: molte PMI hanno un CSIRT virtuale, composto da persone con altri ruoli che vengono attivate in caso di incidente. L'importante è che ruoli, responsabilità e formazione siano definiti prima che si verifichi l'incidente.
Un CSIRT tipico comprende: un coordinatore (gestisce comunicazione e decisioni), analisti tecnici (detection, containment, forensics), un punto di contatto per le comunicazioni esterne (clienti, autorità, media) e un referente legale/compliance (gestisce obblighi normativi e notifiche).
Per le organizzazioni più grandi o con rischi elevati, il SOC (Security Operations Center) è la versione strutturata e permanente: monitoraggio 24/7 degli eventi di sicurezza, in modalità interna, esterna (SOC as a Service) o ibrida. I contatti con le autorità esterne (CSIRT nazionale, forze dell'ordine) devono essere stabiliti prima di un incidente reale: chiamare il CERT Nazionale per la prima volta nel mezzo di un attacco non è una strategia vincente.
Classificazione degli incidenti e livelli di severità
Un sistema di classificazione ben definito è prerequisito per qualsiasi risposta efficace. La ISO 27035 non prescrive una tassonomia specifica, ma indica i criteri per costruirne una adatta al proprio contesto. Una classificazione tipica su quattro livelli:
- Bassa severità: impatta un singolo utente o sistema, nessun dato sensibile coinvolto, risolvibile senza escalation.
- Media severità: impatta un dipartimento o un servizio, possibile coinvolgimento di dati personali, richiede coinvolgimento del responsabile della sicurezza.
- Alta severità: impatta servizi critici, dati sensibili quasi certamente coinvolti, richiede attivazione completa del CSIRT e notifiche al management.
- Critica: interruzione di servizi essenziali, compromissione dell'intera infrastruttura, obblighi di notifica a Garante e/o ACN, potenziale attivazione del Business Continuity Plan.
ISO 27035 e obblighi normativi: GDPR (72h), NIS2, DORA
Un singolo incidente può generare obblighi di notifica paralleli verso autorità diverse, con scadenze e contenuti differenti.
GDPR — 72 ore al Garante: l'art. 33 impone la notifica al Garante entro 72 ore da quando il titolare viene a conoscenza della violazione di dati personali, salvo che sia improbabile che presenti rischi per gli interessati. Le 72 ore decorrono dal momento di ragionevole certezza della violazione. Se necessario, è possibile fare una notifica parziale e integrarla. L'art. 34 prevede anche la comunicazione diretta agli interessati in caso di rischio elevato per i loro diritti.
NIS2 — notifica ad ACN: i soggetti essenziali e importanti ai sensi della NIS2 (D.Lgs. 138/2024) devono notificare gli incidenti significativi all'Agenzia per la Cybersicurezza Nazionale con tre step: pre-alert entro 24 ore, notifica completa entro 72 ore, rapporto finale entro un mese.
DORA — settore finanziario: il Regolamento DORA (applicabile dal gennaio 2025) impone requisiti specifici di incident response per banche, assicurazioni e fornitori di servizi finanziari critici, con notifiche agli organi di vigilanza (Banca d'Italia, IVASS) per gli incidenti ICT significativi.
Playbook e procedure operative: esempi pratici
Un playbook di incident response è una serie di procedure predefinite per gestire tipi specifici di incidenti. Riduce il tempo di risposta, elimina l'improvvisazione e garantisce che anche sotto stress il team segua i passi corretti nell'ordine corretto.
Un playbook per un incidente ransomware include: criteri di rilevamento, azioni immediate di contenimento (quali sistemi isolare e in quale ordine), verifica dello stato dei backup, valutazione dell'obbligo di notifica GDPR e NIS2, comunicazione interna verso il management, comunicazione esterna verso i clienti impattati e roadmap di ripristino con priorità per i sistemi critici.
Ogni playbook deve essere testato con esercitazioni periodiche. Un tabletop exercise — simulazione a tavolino in cui il team discute le azioni in uno scenario ipotetico — è il modo più efficiente per identificare lacune senza aspettare un incidente reale. La norma raccomanda almeno un'esercitazione annuale; per organizzazioni con rischi elevati, la frequenza dovrebbe essere semestrale.
FAQ
La ISO 27035 è certificabile?
No, non autonomamente. I suoi requisiti sono però incorporati nella ISO 27001, che è certificabile. Un audit ISO 27001 verifica anche l'adeguatezza delle procedure di gestione degli incidenti descritte dalla 27035.
Quante volte devo testare il piano di incident response?
La norma non prescrive una frequenza specifica, ma la prassi prevede almeno un'esercitazione annuale. Per organizzazioni con rischi elevati, la frequenza dovrebbe essere semestrale, alternando tabletop exercise e drill più operativi.
Cosa faccio se non so se un incidente comporta dati personali?
In caso di dubbio, tratta l'incidente come se comportasse dati personali finché non puoi escluderlo con certezza. Avvia la valutazione del rischio per gli interessati il prima possibile e documenta il processo decisionale.
Come si coordina la ISO 27035 con la ISO 22301 (business continuity)?
Le procedure delle due norme devono essere coordinate: chi decide quando attivare il BCP, come le due catene di comando si interfacciano, come si gestisce la comunicazione verso i clienti. Le organizzazioni più mature costruiscono un Crisis Management Framework integrato che comprende incident response (27035) e continuità operativa (22301).