Quando un ransomware “va a segno” il problema non è più evitare l’impatto, perché l’impatto è già iniziato. Il problema diventa governarlo contenendo la propagazione, preservando la possibilità di ripristino e mantenendo in funzione i processi essenziali mentre si ricostruisce un perimetro pulito. In questo scenario resilience e SecOps non possono restare due domini paralleli, uno strategico e uno operativo, ma devono convergere in un unico sistema di risposta guidato da priorità, prove e tempi misurabili.
Il primo elemento da considerare è la finestra temporale. Nelle intrusioni ransomware il tempo di permanenza medio dell’attaccante nella rete prima della fase di impatto, il cosiddetto “dwell time”, è indicato da molti report in 5-6 giorni (ma spesso è l’attaccante che notifica direttamente la compromissione) e questo fa capire come l’impostazione delle SecOps andrebbe spostato dal solo obiettivo di “vedere tutto” (peraltro sempre più sfidante) a quello di predisporre le condizioni per ridurre il tempo che interviene tra il primo segnale e quello di contenimento e isolamento dei percorsi di escalation.
La continuità si difende con priorità di servizio, non ripristinando tutto
Un altro aspetto da puntualizzare è che la continuità di business non coincide con rimettere in funzione tutto. Un’organizzazione che tenta di recuperare i sistemi in ordine casuale o seguendo la pressione dei singoli “owner” applicativi consuma tempo e aumenta il rischio.
Serve una gerarchia di servizi con dipendenze esplicite e un concetto di “minimum viable business” che stabilisca quali processi devono restare operativi anche se in modalità degradata, quali possono fermarsi in modo controllato e quali devono essere ricostruiti solo dopo il ripristino di identità, rete e dati.
RTO (Recovery time objective, cioè il tempo massimo accettabile di indisponibilità) e RPO (Recovery point objective, cioè la perdita massima di dati accettabile espressa come “punto” di ripristino) non sono sufficienti se non collegati a un ordine reale di riattivazione e a un modello operativo di emergenza. Durante un ransomware la scelta più complessa non è tecnica ma organizzativa: decidere cosa isolare subito cosa congelare per preservare integrità e prove e cosa mantenere attivo per non interrompere la catena del valore. Se questa decisione non è stata preparata prima, le attività di SecOps che dovrebbero orchestrare una risposta rapida su isolamento, congelamento e continuità dei servizi restano ostacolate dall’assenza di ruoli, priorità e regole decisionali già definite, con l’effetto di rendere la risposta tecnica lenta, frammentata o incoerente.
SecOps come regia della crisi tecnica
Nel ransomware contemporaneo la sequenza tipica è progressiva: accesso iniziale, furto o abuso di credenziali, movimento laterale, persistenza, individuazione dei backup, esfiltrazione, preparazione dell’impatto e, solo dopo, cifratura o sabotaggio. A ciò si aggiunge il rischio crescente di violazioni con coinvolgimento di terze parti, raddoppiato tra il 2024 e il 2025 (dal 15% al 30% delle violazioni totali) secondo il 2025 Data Breach Investigations Report di Verizon.
Questo aspetto allarga il perimetro di contenimento, perché implica interrompere flussi e trust verso fornitori SaaS, repository, strumenti di gestione remota e canali amministrativi.
Un errore frequente nelle prime ore è il contenimento impulsivo che blocca l’attaccante ma interrompe anche la capacità di comprendere cosa stia accadendo. La risposta deve mantenere telemetria e controllo mentre isola altrimenti la ricostruzione diventa cieca.
Questo richiede scelte architetturali da effettuare prima dell’incidente, non mentre l’azienda è già in difficoltà: registrare ciò che accade in modo sicuro e non alterabile; usare strumenti di monitoraggio che continuino a funzionare anche se vengono compromessi gli account; prevedere accessi di emergenza controllati, da usare solo in caso di necessità; avere un canale alternativo di comunicazione, per coordinarsi se posta elettronica e strumenti interni non sono disponibili.
Il contenimento efficace tende a ruotare su tre obiettivi: impedire ulteriore escalation, soprattutto sull’identità; proteggere i repository di ripristino; ridurre la variabilità, impedendo nuove compromissioni durante la risposta. In molte organizzazioni questo porta a una modalità temporanea di esercizio, cioè una riduzione controllata della superficie esposta, con blocco delle amministrazioni non essenziali, disattivazione dei trust non necessari e congelamento dei cambiamenti non legati alla fase di recovery.
La continuità si costruisce prima del giorno zero
Il tema backup non riguarda la presenza di copie ma la possibilità di ripristinarle con fiducia e tempi compatibili con il business. I dati più recenti indicano una resilienza in miglioramento ma ancora fragile. Secondo Sophos, (The State of Ransomware in Enterprise 2025), nel segmento entreprise il costo medio di ripristino dopo un ransomware, escluso l’eventuale riscatto, è pari a 1,84 milioni di dollari e il 47% delle organizzazioni è tornato operativo entro una settimana. L’uso dei backup per recuperare i dati è sceso al 53%, minimo su quattro anni, segnale evidente della difficoltà di fidarsi del ripristino o della mancata compromissione dei repository. La continuità dipende, infatti, dalla capacità di poter effettuare azioni di ripristino in un ambiente che non reintroduca la compromissione. In molte organizzazioni mature questo significa predisporre una clean room, cioè un ambiente di ripristino segregato, un perimetro separato, con identità e policy minime, dove validare l’integrità di sistemi e dati, prima della reimmissione in produzione. Il ripristino diretto può essere più rapido ma è più rischioso se non si ha certezza di aver eliminato persistenza e credenziali compromesse.
La progettazione immutabile diventa quindi una scelta di modello che preveda: copie istantanee e blocco immutabile dei dati, con conservazione non modificabile; separazione delle credenziali di amministrazione dei backup; rete di backup isolata o fortemente segmentata; monitoraggio sui tentativi di cancellazione dei cataloghi; capacità di ricostruzione da immagini golden e infrastruttura come codice, per ridurre tempi ed errori durante la crisi.
Senza controllo degli accessi non esiste ripartenza
Molte risposte ransomware falliscono non per assenza di backup, ma per perdita di fiducia nell’identità. Se Active Directory o il sistema di gestione delle identità sono stati alterati, se esistono account shadow o token esfiltrati, ogni servizio riportato online può tornare sotto controllo dell’attaccante.
Serve quindi un piano di identity recovery, separato dal recovery applicativo, con procedure per ricostruire un nucleo di identità pulito, ruotare credenziali e chiavi, revocare sessioni e ricreare l’accesso privilegiato, entro un perimetro minimo e verificabile.
Qui resilience e SecOps convergono realmente: SecOps rileva abuso di credenziali e persistenza e la resilienza abilita i percorsi di ripartenza. Senza un’architettura di privilegi a strati, con accessi just-in-time e controllo esteso anche agli amministratori, l’organizzazione resta intrappolata in un paradosso: per ripristinare deve amministrare, ma amministrando riapre le superfici che hanno permesso l’attacco, generando ripristini instabili e nuove interruzioni.
La continuità è una decisione di gestione del rischio
Di fronte a un costo medio globale di una violazione molto elevato (4,4 milioni di dollari nel 2025 secondo l’IBM Cost of a Data Breach Report 2025) si comprende che, anche escludendo i ransomware, l’impatto di una data breach supera l’ambito IT, includendo interruzioni, ripristino, gestione dell’incidente e danni reputazionali e contrattuali.
Ne deriva che, operativamente, la priorità dovrebbe essere di ridurre l’area grigia tra compromissione e ripartenza, facendo evolvere SecOps da rilevamento e risposta a: rilevamento, contenimento e orchestrazione del ripristino.
Farlo non è semplice, perché richiede l’integrazione tra SIEM, XDR o EDR, SOAR e processi ITSM in una catena continua, anche in condizioni di forte pressione operativa. La qualità della risposta si misura nella capacità di mantenere i servizi critici, proteggere i dati e ripristinare la situazione in modo pulito, con tempi prevedibili. Quando esistono davvero servizi prioritizzati, dipendenze mappate, identità recuperabile, backup difendibili, ambiente segregato e procedure testate, un attacco riuscito può essere trasformato in un incidente gestito, con impatto contenuto e continuità sotto controllo.
Resilience e SecOps come governance misurabile
Un passaggio ulteriore è quello di leggere resilience e SecOps come una funzione di Assurance interna, non come un insieme di buone pratiche. In altre parole, non basta “fare sicurezza” o “fare continuità”: serve un impianto che renda verificabile, nel tempo, se l’organizzazione sta rimanendo entro la propria tolleranza al rischio e se i controlli che contano sono effettivamente in esercizio.
Questo passaggio cambia le domande. Non “quali tecnologie abbiamo”, ma “quali scenari di rischio possono diventare impatto materiale, quali soglie rendono il rischio non accettabile e chi ha l’autorità formale per accettare una deroga”.
È qui che SecOps e governance si saldano: le attività operative diventano l’esecuzione di decisioni di rischio predefinite, con responsabilità chiare tra titolari del rischio, proprietari dei servizi e funzioni di controllo.
Ne deriva una conseguenza operativa precisa: il rischio non viene più valutato solo in fase di analisi, ma gestito in modo continuo attraverso metriche, soglie e meccanismi di escalation già definiti.
La governance non interviene solo quando l’incidente è visibile, ma stabilisce in anticipo quali condizioni richiedono contenimento, quali comportano accettazione del rischio e quali impongono interventi correttivi. In questo modo resilience e SecOps non si limitano a reagire agli eventi, ma contribuiscono a mantenere il sistema aziendale entro parametri di rischio controllati e verificabili, trasformando il controllo del rischio in un processo operativo e non solo decisionale.
Resilienza e compliance
Un’ultima considerazione va fatta in relazione alla compliance che, nella prospettiva seguita finora, non rappresenta un capitolo separato né un adempimento documentale da verificare a posteriori. Diventa, invece, la conseguenza operativa di un modello in cui resilience e SecOps sono progettate per produrre evidenze strutturate, continue e verificabili. Questo significa tracciabilità formale delle decisioni, gestione delle eccezioni con responsabilità esplicite e scadenze definite, controllo della filiera digitale con requisiti minimi misurabili per fornitori e servizi critici e indicatori che dimostrino l’efficacia reale dei presidi, non soltanto la loro esistenza formale.
In un’organizzazione matura, il collegamento tra attività operative e requisiti di conformità è esplicito: ogni controllo tecnico rilevante deve avere un riferimento a un rischio identificato, a un requisito normativo o contrattuale e a un titolare responsabile.
Le attività di SecOps diventano così parte integrante del sistema di controllo interno, perché alimentano con dati e metriche i processi di risk management e consentono alla governance di valutare in modo oggettivo se il livello di rischio residuo è coerente con la soglia di tolleranza dichiarata.
Quando questo meccanismo è stabile, resilience e SecOps non sono più percepite come funzioni di supporto tecnico ma come capacità aziendali misurabili, integrate nel modello di controllo e di gestione del rischio.