Il vero rischio non è solo subire un attacco. È non riuscire a continuare a lavorare.
Per anni la cybersecurity è stata raccontata soprattutto come una questione di difesa: proteggere il perimetro, bloccare le minacce, installare strumenti, aggiornare sistemi, controllare accessi, filtrare email, monitorare eventi. Tutto corretto. Tutto necessario.
Ma non più sufficiente.
Il problema è che oggi la domanda non può essere solo:
“Siamo protetti?”. La domanda più scomoda, e più utile, è un’altra:
“Se qualcosa va storto, siamo ancora in grado di lavorare?”.
È qui che entra in gioco la
cyber resilience. Non sostituisce la cybersecurity, la completa. Perché nessuna organizzazione può ragionevolmente costruire una difesa perfetta, impermeabile a ogni errore umano, vulnerabilità, fornitore compromesso, credenziale rubata, endpoint non aggiornato o attacco ransomware. La sicurezza resta fondamentale, ma deve essere accompagnata da una capacità altrettanto importante: assorbire l’impatto, contenere il danno, ripristinare i servizi, comunicare correttamente e tornare operativi nel minor tempo possibile.
In altre parole,
la maturità cyber non si misura solo da quanti attacchi vengono bloccati. Si misura anche da cosa succede quando un attacco non viene bloccato.
Dalla protezione alla continuità
Molte aziende continuano a trattare la cybersecurity come un insieme di tecnologie: firewall, antivirus, EDR, MFA, backup, SIEM, vulnerability assessment. Sono componenti indispensabili, ma da sole non garantiscono resilienza. Avere buoni strumenti non significa automaticamente avere un’organizzazione pronta a reagire.
La differenza si vede nei momenti critici. Quando un account viene compromesso, chi decide cosa disabilitare? Quando un endpoint mostra comportamenti sospetti, chi valuta se isolarlo? Quando un servizio non è più disponibile, chi stabilisce la priorità di ripristino? Quando il backup esiste, chi ha verificato davvero che sia integro, recente e ripristinabile nei tempi richiesti dal business? Quando più fornitori sono coinvolti, chi coordina le attività e tiene insieme il quadro?
La cyber resilience nasce esattamente in questo spazio: tra la tecnologia installata e la capacità reale di usarla sotto pressione.
Perché durante un incidente non basta avere strumenti. Serve sapere cosa fare, in che ordine, con quali responsabilità, con quali soglie decisionali e con quale impatto sui servizi aziendali. Il tempo perso nel capire chi deve intervenire è spesso tempo sottratto alla continuità operativa.
Il ransomware ha cambiato la prospettiva
Il ransomware ha reso evidente un punto che molti IT manager conoscono bene: il rischio cyber non riguarda più solo la riservatezza dei dati. Riguarda la capacità stessa dell’azienda di funzionare.
Un attacco può bloccare postazioni di lavoro, file server, sistemi di autenticazione, applicazioni gestionali, ambienti di collaborazione, infrastrutture virtuali, backup, sedi remote, linee operative, fornitori esterni. In alcuni casi non viene cifrato “tutto”, ma viene colpito abbastanza da rendere difficile lavorare. Ed è proprio lì che la resilienza diventa decisiva.
Il tema non è solo recuperare un server. È capire quali servizi devono tornare disponibili per primi. Quali utenti o reparti sono più critici. Quali dati sono affidabili. Quali credenziali sono ancora sicure. Quali endpoint possono essere riammessi in rete. Quali sistemi possono essere ripristinati senza reintrodurre il problema. Quali processi possono continuare in modalità degradata e quali invece devono fermarsi.
La vera domanda non è:
“Abbiamo un backup?”. La vera domanda è:
“Siamo in grado di ripartire in modo sicuro, ordinato e coerente con le priorità del business?”. Il tema di
un backup affidabile e ripristinabile è il punto di partenza, ma non l’arrivo.
Il punto debole è spesso il coordinamento
Quando si parla di sicurezza informatica, si tende a cercare il punto debole nella tecnologia. Una vulnerabilità non patchata. Una password debole. Un endpoint scoperto. Un sistema non monitorato. Tutto vero. Ma nelle crisi reali il punto debole è spesso un altro:
il coordinamento.
Un incidente cyber attraversa confini che in condizioni normali sembrano chiari. Coinvolge infrastruttura, endpoint, identità, rete, service desk, fornitori applicativi, management, legale, comunicazione, privacy, utenti finali. Se questi attori non sono abituati a lavorare insieme, l’incidente diventa rapidamente confuso.
Il service desk riceve segnalazioni, ma non sempre ha istruzioni chiare su cosa comunicare. I tecnici infrastrutturali lavorano al contenimento, ma non sempre hanno visibilità sull’impatto utente. Il management chiede tempi di ripristino, ma non sempre esistono priorità condivise. I fornitori intervengono sui propri perimetri, ma il problema reale è trasversale. Nel frattempo gli utenti cercano scorciatoie, aprono ticket duplicati, chiamano referenti interni, usano canali non ufficiali.
La cyber resilience serve anche a evitare questo effetto domino organizzativo. Non elimina la complessità, ma la rende gestibile. Definisce ruoli, flussi, priorità, responsabilità e modalità di escalation prima che l’incidente avvenga.
NIS2 sposta il tema dal tecnico all’organizzativo
La spinta normativa degli ultimi anni va nella stessa direzione. Con NIS2, la sicurezza non è più solo una responsabilità tecnica confinata all’IT. Diventa un tema di governance, continuità e responsabilità organizzativa. Non basta dimostrare di avere strumenti: bisogna dimostrare di avere processi, misure, capacità di gestione degli incidenti, tracciabilità e consapevolezza del rischio.
Questo cambio di prospettiva è importante. Perché obbliga le aziende a guardare la cybersecurity non come una lista di controlli isolati, ma come una capacità operativa continua. La domanda non è più soltanto se un sistema è protetto, ma se l’organizzazione è in grado di rilevare un incidente, valutarne l’impatto, notificarlo quando necessario, contenerlo e ripristinare i servizi in modo documentato.
È un passaggio culturale prima ancora che tecnologico.
Per un IT manager significa uscire dalla logica del
“ho comprato la soluzione” ed entrare nella logica del
“sono in grado di governare l’evento”. La differenza è enorme, soprattutto quando un incidente avviene fuori orario, durante un picco operativo, in una sede periferica o coinvolgendo più fornitori contemporaneamente.
Backup, patching e monitoraggio non bastano se non sono governati
Ci sono tre parole che ricorrono spesso quando si parla di resilienza: backup, patching, monitoraggio. Sono fondamentali, ma vanno interpretate nel modo corretto.
Un backup non è resilienza se non viene testato, se non è isolato, se non ha tempi di ripristino compatibili con il business, se non è chiaro quali sistemi debbano essere recuperati per primi. Un piano di patching non è resilienza se non tiene conto degli endpoint realmente presenti, delle applicazioni legacy, delle eccezioni, delle finestre operative e dei sistemi che restano fuori controllo. Un sistema di
monitoraggio non è resilienza se genera alert che nessuno governa, se non distingue il rumore dal segnale o se non produce azioni concrete.
La resilienza non nasce dalla presenza degli strumenti. Nasce dalla loro integrazione in un modello operativo.
Per questo il tema non è solo tecnologico. È fatto di inventario, procedure, responsabilità, knowledge base, presidio, documentazione, test periodici, escalation, comunicazione e miglioramento continuo. La tecnologia abilita la resilienza, ma è il governo del servizio a renderla reale.
L’utente finale è parte della resilienza
C’è un aspetto che spesso viene trascurato: durante un incidente, gli utenti finali non sono spettatori. Sono parte del sistema.
Se non ricevono indicazioni chiare, cercheranno soluzioni alternative. Se non sanno cosa fare, apriranno ticket duplicati o useranno canali informali. Se percepiscono silenzio, aumenteranno la pressione sull’IT. Se non capiscono quali servizi sono disponibili e quali no, rischiano di peggiorare la situazione senza volerlo.
La cyber resilience deve quindi includere anche l’esperienza dell’utente durante la crisi. Non nel senso di
“comunicare meglio” in modo generico, ma nel senso operativo del termine: fornire messaggi coerenti, canali chiari, priorità comprensibili, aggiornamenti sintetici, indicazioni su cosa fare e cosa non fare.
Un service desk ben preparato può fare una differenza enorme. Può raccogliere segnali, ridurre il rumore, orientare gli utenti, evitare escalation inutili, documentare l’impatto e mantenere aperto un canale ordinato tra persone e IT. In un incidente cyber, la comunicazione non è un accessorio. È parte della continuità operativa.
La resilienza si costruisce prima
Il momento peggiore per progettare la risposta a un incidente è durante l’incidente.
La cyber resilience va costruita prima, quando c’è il tempo di mappare i servizi critici, definire le priorità, verificare i backup, aggiornare le procedure, testare i ripristini, chiarire ruoli e responsabilità, controllare gli endpoint, ridurre le eccezioni non governate, mettere ordine nella documentazione e stabilire come comunicare.
Non serve immaginare scenari apocalittici. Serve partire dalle domande concrete: quali sistemi non possono fermarsi? Quali servizi devono tornare disponibili entro poche ore? Quali sedi sono più esposte? Quali utenti hanno ruoli critici? Quali fornitori devono essere coinvolti? Quali credenziali vanno protette con maggiore attenzione? Quali asset non sono pienamente sotto controllo? Quali procedure esistono solo nella testa di poche persone?
Le aziende resilienti non sono quelle che non subiscono mai problemi. Sono quelle che hanno già deciso come reagire quando il problema arriva.
Il ruolo dei Managed Services
In questo scenario, i
Managed Services non sono solo un modo per esternalizzare attività IT. Possono diventare una componente fondamentale della cyber resilience, se progettati con questo obiettivo.
Un servizio gestito maturo tiene insieme monitoraggio, service desk, gestione endpoint, presidio, escalation, asset management, documentazione, procedure, reportistica e miglioramento continuo. Non guarda il singolo ticket come un evento isolato, ma come parte di un sistema più ampio: cosa sta succedendo, dove si ripete, quale impatto ha, quali segnali precedenti erano visibili, quali azioni possono ridurre il rischio futuro.
In Gruppo Trade, questo approccio è centrale. La continuità operativa non dipende solo dalla tecnologia disponibile, ma dalla capacità di governare ogni giorno ciò che accade negli ambienti IT: postazioni, utenti, sedi, applicazioni, infrastrutture, fornitori, richieste, incidenti e priorità.
La resilienza non si improvvisa il giorno dell’emergenza. Si costruisce nel modo in cui il servizio viene gestito tutti i giorni.
In sintesi
La cybersecurity resta indispensabile. Ma non basta più pensare solo in termini di protezione.
Le aziende devono chiedersi se sono in grado di continuare a lavorare anche quando qualcosa va storto. Devono sapere quali servizi sono critici, quali dati sono recuperabili, quali sistemi devono ripartire per primi, chi decide, chi interviene, chi comunica e come si misura il ritorno alla normalità.
La cyber resilience è questo: non la promessa che l’incidente non accadrà mai, ma la capacità di ridurne l’impatto e tornare operativi in modo sicuro, ordinato e governato.
Perché il vero rischio non è solo subire un attacco.
È scoprire, nel momento peggiore, di non essere pronti a reagire.
