Perché alcune aziende superano gli incidenti e altre no? Non budget o dimensione, ma maturità, governance e scelte organizzative fanno la differenza. Quando l’attacco è già in corso, i sistemi sono cifrati, la produzione si ferma, la cybersecurity smette di essere un insieme di strumenti e diventa capacità organizzativa. Conta sapere quali processi sono più esposti, quali sistemi li sostengono, chi decide le priorità di ripristino, quali backup sono utilizzabili e quali partner possono intervenire con tempi già contrattualizzati.
Il NIST Cybersecurity Framework 2.0, riferimento internazionale per la gestione del rischio cyber, ha inserito la funzione “Govern” accanto a Identify, Protect, Detect, Respond e Recover: una scelta che riflette il peso della governance nella resilienza operativa.
Indice degli argomenti
La maturità organizzativa nell’incident response
Andrea Coli, Incident Response Manager di Cyberoo, spiega che “parlando di maturità organizzativa ci riferiamo ad aziende che hanno processi di gestione di tutta la parte IT consolidati”. Il rischio, ricordiamo, non è solo cyber: “Le infrastrutture e le aziende attive ventiquattr’ore su ventiquattro sono soggette a diverse tipologie di incidenti, ma in tutti i casi una governance efficace offre la via d’uscita più rapida dall’incidente – aggiunge –. Nella nostra esperienza abbiamo notato che chi ha governance è stato resiliente e ha assorbito il colpo dell’incidente reagendo con tempi e modi che permettessero di ripartire in tempi compatibili con le esigenze di business”.
Il punto è operativo prima ancora che tecnologico. Un’azienda può avere soluzioni avanzate, ma se non conosce la propria infrastruttura, se non ha una mappa dei servizi critici, se non sa quali applicazioni tengono in piedi produzione, amministrazione, logistica o risorse umane, la risposta all’incidente parte in ritardo. La prima domanda non riguarda solo il malware: riguarda cosa va salvato per primo e quali dipendenze impediscono di rimettere in piedi i servizi.
La stessa Agenzia dell’Unione europea per la cybersicurezza, nel report ENISA Threat Landscape 2025, ha analizzato 4.875 incidenti osservati tra luglio 2024 e giugno 2025. Il dato conferma che la gestione degli incidenti non è più un tema eccezionale, ma una componente ordinaria della continuità aziendale.
Backup governati, non solo backup disponibili
Coli aggiunge: “La differenza tra un’azienda che torna operativa subito dopo un incidente e l’azienda che fa più fatica è la resilienza del backup. Chi governava i processi di backup è ripartito certo con qualche problema, ma in modo più rapido. La differenza sostanziale è svolgere test periodici. Se invece nell’emergenza si scopre che un restore non ha funzionato o i backup sono stati cancellati perché fatti su un’infrastruttura debole e non performante, lo scenario è diverso”.
Il backup, quindi, non coincide con la copia dei dati. È un processo da governare: frequenza, segregazione, immutabilità, test di restore, responsabilità, tempi di ripristino, coerenza tra dati e applicazioni. La CISA, nella guida StopRansomware, raccomanda backup offline, cifrati e sottoposti a test regolari di disponibilità e integrità in scenari di disaster recovery. Il dettaglio è decisivo perché molti attacchi non colpiscono solo i sistemi in produzione, ma cercano anche di raggiungere copie e repository di salvataggio: “Nello scenario di un attacco ransomware in cui l’azienda si trova completamente bloccata, durante le attività di incident response vengono analizzati anche i supporti di backup. L’attaccante può mantenere l’accesso all’ambiente per giorni prima della cifratura, creando persistenze o backdoor che possono finire nelle copie di salvataggio. Ripristinare direttamente i server senza le opportune verifiche rischia quindi di reintrodurre la compromissione: prima del ritorno in produzione sono necessarie analisi e attività di bonifica. In condizioni favorevoli, con backup efficienti e un’infrastruttura correttamente mappata, una media impresa può tornare pienamente operativa nell’arco di circa una settimana”, aggiunge Coli.
Dunque il ripristino deve avvenire su un ambiente pulito, dopo il triage dei sistemi coinvolti e la verifica delle immagini e dei backup. Ripristinare macchine compromesse senza averle analizzate può riportare in produzione persistenze, backdoor o configurazioni già manipolate dagli attaccanti. La velocità di recovery dipende dalla qualità dei backup, ma anche dalla capacità di distinguere ciò che è recuperabile da ciò che deve essere bonificato.
Ruoli, fornitori e contratti: la governance è nei dettagli
Ci possono tuttavia essere problemi “legati alla disponibilità di risorse e alla presenza di system integrator. Le aziende che non hanno un’adeguata copertura contrattuale col system integrator, lato SLA, con disponibilità contrattualizzata, possono avere problemi nel reperire gli esperti quando necessario”, precisa Coli. È uno dei passaggi più sottovalutati. Durante un incidente, il tempo non si perde solo nella diagnosi tecnica, ma anche nel recuperare contatti, autorizzazioni, accessi, disponibilità dei fornitori, clausole di reperibilità e limiti contrattuali. Le aziende che lavorano oltre l’orario del team IT devono sapere prima chi interviene di notte, nei weekend o durante le festività. La continuità operativa non può dipendere da accordi informali.
La maggior parte degli incidenti “accade sempre quando si è più deboli e disorganizzati, per esempio sotto le feste. La governance qui fa la differenza, bisogna sapere chi sono gli attori da ingaggiare al momento della compromissione. Il concetto di incidente nella sua accezione più ampia è solo una questione di quando, il se non è da considerare: accadrà, più o meno grave ma accadrà e andrà gestito”, aggiunge Coli.
La preparazione passa da una mappatura realistica dei processi aziendali e dei sistemi informatici che li supportano. Serve conoscere quali server e applicativi sono associati ai processi più critici, quali interruzioni genererebbero i danni maggiori, chi è process owner e chi ha autorità decisionale in emergenza. Per le organizzazioni con produzione continua, servizi online o presidi oltre il turno ordinario, la reperibilità deve essere parte del modello operativo.
Patch, vulnerabilità e NIS2
La resilienza passa anche dalla manutenzione ordinaria. Ambienti applicativi, sistemi esposti, componenti soggetti ad aggiornamento e piattaforme dipendenti da vendor devono essere gestiti con patching, configurazioni corrette e competenze specialistiche. L’improvvisazione tecnica diventa debito operativo: può restare invisibile per mesi, fino al giorno in cui una vulnerabilità o una configurazione debole apre la strada alla compromissione.
La direttiva NIS2, recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138, rafforza proprio questo passaggio: misure di gestione del rischio, notifica degli incidenti, responsabilità degli organi di amministrazione e maggiore consapevolezza organizzativa. Per le imprese incluse nel perimetro, l’IT assume un ruolo più esposto nella dimostrazione dei livelli di sicurezza e nella capacità di documentare processi, controlli e risposte.
I backup fanno la differenza tra una ripartenza governabile e la perdita di anni di patrimonio documentale. Per questo devono essere definiti tempi di ripristino chiari, testati e comunicabili al business. Senza questa informazione, l’azienda non sa stimare l’impatto reale dell’incidente.
Il ruolo dell’incident response retainer
Il modello retainer, descritto anche nell’offerta di incident response di Cyberoo, formalizza in anticipo l’accesso al team specialistico. Il valore non sta solo nella priorità di intervento, ma nella conoscenza preliminare dell’ambiente: infrastruttura, contatti, procedure, perimetro, punti critici. Quando l’incidente arriva, questa preparazione riduce la fase di orientamento e consente di lavorare subito su contenimento, analisi, bonifica e ripristino.
Spiega Coli che “le aziende dovrebbero dotarsi di un contratto per il servizio di incident response retainer che permette l’accesso diretto al team di incident response con tempi contrattualizzati. In questo modo gestire l’incidente è più semplice: il team conosce l’infrastruttura, l’azienda chiamerà direttamente il team di incident response per un intervento rapido ed efficace”. Lavorare on demand, soprattutto nei periodi in cui la disponibilità di specialisti è più limitata, può non garantire un intervento tempestivo. “Avere un servizio di incident response contrattualizzato riduce i tempi necessari per attivare il team e avviare le attività di contenimento, analisi e ripristino. Con un Incident Response Plan strutturato, una conoscenza preventiva dell’infrastruttura, backup verificati e SLA definiti, i servizi essenziali possono essere ripristinati molto più rapidamente rispetto a uno scenario gestito senza preparazione”, conclude Coli.
Insomma, la resilienza non si misura il giorno dell’attacco, si costruisce prima. Backup testati, contratti adeguati, ruoli definiti, processi mappati e governance IT matura trasformano l’incident response da reazione emergenziale a capacità aziendale. Chi conosce il proprio ambiente riparte prima, chi lo scopre durante la crisi paga il costo del ritardo.
Articolo realizzato in partnership con Cyberoo
Partecipa alla community