Non sappiamo quanto ci costa un fermo
Misurate l'impatto di un'interruzione partendo dal servizio: clienti, ricavi, obblighi, reputazione, tempo tollerabile e dati persi.
Il problema
Avete un elenco di sistemi e forse una stima del costo per ripararli. Ma se domani si interrompe un servizio, non sapete dire quali attività si fermano, chi resta senza servizio o dopo quanto il danno diventa serio. Il costo dell’apparato non è il costo del fermo.
Come capire se ti riguarda
- Le priorità sono ordinate per valore o complessità dei sistemi, non per impatto sui servizi?
- Direzione e responsabili operativi danno risposte diverse su cosa debba ripartire per primo?
- Avete deciso quanto tempo un servizio può restare fermo e quanti dati o lavoro potete perdere?
- Le stime economiche sono numeri puntuali senza ipotesi o intervalli espliciti?
Se non sapete rispondere, non serve inventare un numero: serve misurare il servizio e dichiarare ciò che manca.
Come risolverlo
- Scegliete un servizio concreto. Descrivete cosa fornisce, a chi e quali attività lo rendono possibile. Non partite dal server. Responsabile: referente del servizio, con la direzione. Evidenza: descrizione approvata del servizio, dei destinatari e delle attività essenziali.
- Tracciate le dipendenze. Elencate persone, applicazioni, dati, infrastrutture, sedi e fornitori senza i quali il servizio si ferma. Segnate le dipendenze note e quelle da verificare. Responsabile: IT e proprietario del servizio, con i fornitori per le informazioni di loro competenza. Evidenza: mappa delle dipendenze, fonte e data di verifica.
- Valutate le conseguenze nel tempo. Considerate impatto economico, clienti, obblighi e reputazione. Chiedete quando il fermo diventa inaccettabile e quanto lavoro o dato si può perdere. Se servono euro, usate ipotesi e intervalli, non falsa precisione. Responsabile: direzione e responsabile del servizio, con IT e amministrazione. Evidenza: analisi di impatto con ipotesi, soglie decise, approvazione e data di riesame.
- Collegate il risultato alle scelte. Usate l’analisi per ordinare le priorità di continuità e ripristino e per verificare se backup, risorse e accordi con i fornitori sono coerenti. Responsabile: direzione per le decisioni; IT e fornitori per i piani tecnici. Evidenza: decisioni, azioni assegnate, prove di ripristino ed esiti.
Cosa fare adesso
- Convocate il responsabile di un servizio che non può fermarsi a lungo.
- Descrivete cosa accade dopo un’ora, un giorno e un periodo più lungo, senza assumere soglie uguali per tutti.
- Registrate le ipotesi e fate approvare le soglie dai responsabili del servizio.
Come evitare che si ripeta
Aggiornate l’analisi quando cambia il servizio, una dipendenza o il contesto. Verificate con esercitazioni e prove di ripristino che i tempi ipotizzati siano realistici. Se una stima è incerta, indicatelo: un’incertezza visibile è più governabile di un numero preciso ma infondato.
Quando chiedere aiuto e a chi
Coinvolgete un professionista di continuità o gestione del rischio quando non riuscite a tradurre le attività in impatti, oppure quando serve coordinare più funzioni e fornitori. Se siete un soggetto NIS e il fermo nasce da un incidente significativo, il Referente CSIRT deve notificarlo al CSIRT Italia tramite il Portale ACN. Le scadenze sono tre: pre-notifica entro 24 ore, notifica entro 72 ore e relazione finale entro un mese. I criteri per capire se un incidente è significativo sono nelle determinazioni ACN.
Dal libro
«Prima ancora di parlare di rischio, c’è da rispondere a una domanda più semplice e più concreta: se un servizio si ferma, quanto fa male?» — *NIS2. La carta che guida*, capitolo 6.
Fonti ufficiali
- ENISA — NIS2 Technical Implementation Guidance
- ACN — Portale NIS
- ACN — Misure di sicurezza e notifica di incidenti
Schede collegate
Abbiamo i backup ma non sappiamo se ripartiamo
Un backup non dimostra che ripartirete: servono priorità, ruoli e prove di ripristino registrate.
Non sappiamo da dove cominciare: i primi 90 giorni
Nei primi 90 giorni date mandato, capite i servizi, scegliete poche priorità e provatele: senza rincorrere ogni cosa insieme.
Non sappiamo quali servizi sono davvero critici
Se tutto è critico, niente lo è. Partire dai servizi, e non dai server, è il modo per capire cosa proteggere per primo.