Presentazione dell’MTCR: la metrica mancante per il successo della Recovery informatica

L’MTCR misura il tempo necessario per ripristinare i sistemi e i dati in modo pulito – liberi da malware, danni o residui – dopo un attacco informatico. 

RTO e RPO misurano il tempo e la perdita di dati. L’MTCR misura l’affidabilità. Un Recovery rapido non ha senso se le minacce permangono. 

Richiede la verifica dei backup, la scansione alla ricerca di minacce nascoste e la convalida dei carichi di lavoro ripristinati – un processo di gran lunga più complesso di un semplice failover. 

Gli aggressori corrompono sempre più spesso i backup e nascondono la propria presenza, rendendo l’identificazione dei dati integri la fase più lunga del Recovery. 

Fornisce ai responsabili una metrica realistica della qualità del Recovery, consentendo investimenti e preparativi più oculati. 

Per la trascrizione con indicazione dei tempi, si prega di guardare il video qui

Benvenuti alla nostra discussione su un nuovo modo di concepire la resilienza informatica, il Mean Time to Clean
Recovery o MTCR.

Sono qui con due esperti che hanno ideato il concetto di MTCR: Darren Thomson, CTO sul campo presso
Commvault, che lavora a stretto contatto con organizzazioni di diversi settori in materia di resilienza e

strategie, e Duncan Bradley, responsabile del settore sicurezza e resilienza per il Regno Unito e l’Irlanda presso Kyndryl
. Sono stati proprio loro a redigere il documento originale di leadership di pensiero sull’MTCR. E

da anni, il successo della Recovery nelle organizzazioni viene misurato in base alla rapidità con cui i sistemi possono essere
ripristinati.

Utilizziamo acronimi come RTO e RPO: RTO (Recovery Time Objective, tempo obiettivo di ripristino) e RPO (Recovery Point
Objective, punto obiettivo di ripristino).

Ma nell’attuale panorama delle minacce, sappiamo che la velocità da sola non equivale a sicurezza e non equivale
al successo del Recovery.

Se i dati recuperati non sono puliti e affidabili, si rischia di trasformare la Recovery nella
continuazione di un altro attacco.

Salve.

Sono Danielle Sheer, Chief Trust Officer di Commvault.

Dedico gran parte del mio tempo ad aiutare i consigli di amministrazione e i dirigenti a comprendere come il rischio informatico si intersechi
con il rischio aziendale.

Sono davvero entusiasta di guidare la discussione di oggi e di spiegare perché questo nuovo concetto, l’MTCR,
non è solo un’altra metrica tecnica, ma lo standard aziendale che ora trova il suo posto nella

sala del consiglio.

Proviamo a farlo.

Sì, grazie Danielle.

E grazie per l’ottima introduzione.

Proprio quest’anno, nel 2025, in particolare nel Regno Unito, ma in realtà in tutto il mondo,
specialmente in Europa, abbiamo assistito ad alcuni attacchi mirati al settore retail.

E abbiamo visto in prima persona quanto sia stato difficile per quei rivenditori mantenere il contatto
con i propri clienti e, soprattutto, ripristinare i propri sistemi.

Quest’anno sono stato coinvolto personalmente in un attacco specifico iniziato verso la metà di
aprile del 2025.

E solo per darvi un’idea dei tempi necessari affinché quell’azienda
si riprendesse.

Nel mese di aprile si è verificato essenzialmente un attacco ransomware.

E in quel periodo l’azienda ha fatto un ottimo lavoro nel, se non fermare l’evento
, almeno isolare e arrestarne la diffusione.

Nel mese di maggio, l’azienda si è concentrata sul tentativo di confermare la natura e la portata, ovvero ciò che io
chiamo il “raggio d’azione” dell’attacco.

E hanno iniziato a comunicare con l’esterno.

Da maggio fino all’inizio di agosto si è svolta la vera e propria fase di Recovery dei sistemi.

In altre parole, ci sono voluti quasi tre mesi, fino ad agosto, per
un ripristino graduale dei sistemi, una sorta di approccio per fasi alla loro riattivazione.

Allora, perché tutto quel tempo, sapete, tre mesi, per riportare l’azienda
online?

Beh, gran parte di quel tempo è stato impiegato nel tentativo di trovare i dati giusti, i dati puliti.

Sistemi puliti su cui l’azienda potesse fare affidamento per tornare a interagire con i propri
clienti e generare ricavi come rivenditore.

Ed è proprio questo, quel periodo di tre mesi, a essere indicativo di ciò di cui vogliamo parlare
qui.

L’azienda deve iniziare a porre una serie diversa di domande all’organizzazione
IT per arrivare a un punto in cui non solo si possano fare promesse in termini di rapidità con cui

ripristiniamo i sistemi,

ma si possano anche fare promesse su quanto quei sistemi saranno puliti, su quanto sarà pulita
la loro natura.

Altrimenti, temo che continueremo a vedere, come sappiamo, che in genere ci vogliono due, tre,
a volte persino quattro o cinque mesi per riportare i sistemi online.

Sapete, ok, è affascinante.

Ci hai fornito molti spunti su cui lavorare.

Duncan, ora vorrei tornare all’inizio.

Puoi darci la definizione di MTCR?

Spiegaci i cinque pilastri e perché questa è la strada giusta per noi, in questo
panorama, in questo panorama delle minacce, per misurare il successo della Recovery.

Sì, certo, Danielle.

Penso che sia davvero importante.

Abbiamo ideato il concetto di Mean Time to Clean Recovery proprio per creare una metrica
aziendale comprensibile per l’azienda.

Si tratta di quanto tempo impiegano a tornare operativi, come diceva Darren.

Con dati puliti, con sistemi in grado di funzionare e tornare in produzione.

La maggior parte delle organizzazioni si è concentrata principalmente sulla disponibilità dei propri sistemi online, senza comprendere che questi attacchi informatici rendono inutilizzabili
i dati e le piattaforme

che supportano tali operazioni.

Pertanto, quando si verifica un evento di Recovery, si tratta piuttosto di dover ricreare
tutto, partendo da zero fino al punto di ripristino,

un ambiente pulito.

Spesso ciò richiede giorni, come diceva Darren nell’esempio del settore retail.

A quel punto è necessario ricostruire tutti i servizi fondamentali.

Successivamente, è necessario riportare online le piattaforme e recuperare dati
puliti al loro interno.

E molto spesso, con i tipi di attacchi a cui assistiamo, i dati risultano contaminati già da
giorni, se non settimane, prima dell’attacco.

È quindi necessario esaminare i backup e riportare quei dati puliti in produzione.

Questo MTCR, ovvero il “Mean Time to Clean Recovery” (tempo medio per il ripristino pulito), è concepito come un indicatore aziendale per rispondere alla domanda:

Per quanto tempo potete rimanere fuori servizio?

Per quanto tempo rimarreste fuori servizio oggi se l’evento si verificasse?

E questo dato viene poi utilizzato per stimolare i reparti IT e di CC a ridurre il tempo
medio di Recovery.

In che modo l’MTCR si differenzia dalle misure tradizionali?

Sembra quasi che riunisca molte delle misure tradizionali in un unico indicatore più ampio.

Beh, penso che sia qui che entrano in gioco gli obiettivi relativi al tempo di Recovery.

Quanto tempo ci vuole per riportare in linea quel sistema?

Non tiene conto del tipo di dati che si troveranno all’interno di quella piattaforma.

Sai, in genere si usa come parametro la disponibilità.

Quanto tempo mi ci vuole per effettuare il failover dal data center A al data center B in caso di un
attacco tradizionale all’infrastruttura?

Il recupero dei dati è un'impresa molto più complicata.

Non si tratta solo di recuperare un insieme di dati.

Si tratta di riportare la piattaforma online.

Quindi, se si pensa ai servizi di identità, è necessario che l’identità funzioni prima che chiunque possa
accedere ai dati.

Il semplice fatto di misurare il tempo necessario per ripristinare un database

non significa che quel processo aziendale tornerà operativo.

Ed è davvero progettato per racchiudere quei diversi pilastri dei sistemi che è
necessario rimettere in funzione per far funzionare il processo aziendale.

E Danielle, se mi permetti, penso che questo rimandi a un problema più ampio.

Quindi è molto facile, ehm, seguire un approccio puramente tecnico in questa conversazione.

E in effetti, questo rappresenta sotto molti aspetti un modo per valutare l’organizzazione tecnica.

Ma credo che questo rimandi a un problema organizzativo.

Quello che vediamo continuamente è che uno dei problemi culturali legati al ripristino
dei sistemi, e uno dei motivi per cui in molti casi ci vuole così tanto tempo, come è successo nel mio

esempio, è che in realtà abbiamo a che fare con due team che devono assumersi una
parte di responsabilità in questo ambito.

C’è chiaramente il tradizionale team di infrastruttura, composto dalle persone responsabili
di Backup and Recovery; ovviamente hanno un compito da svolgere, ma non sono più gli unici.

C’è anche un team di sicurezza.

Un team in grado di dirvi, ad esempio tramite analisi forense, dove si trova il backup integro, dove si trovano i
dati integri, quanto sono infetti i sistemi: quello è un team di sicurezza.

Quindi, quando questi team non collaborano alla Recovery, o parlano lingue diverse
, o misurano i propri risultati in modi diversi, iniziamo a vedere un problema

e tutto parte dalla cultura.

Un modo per riflettere su questo è considerare l’RPO e l’RTO (Recovery Time Objective, obiettivo di tempo di ripristino):

Quanto tempo mi ci vorrà per ripristinare i dati?

L’obiettivo del punto di Recovery (RPO), ovvero: quanti dati potrei dover utilizzare?

E tutto questo si combina con l’attività forense, una disciplina della sicurezza.

Ora abbiamo l’MTCR.

Quindi, la “C” è importante.

La pulizia di quei dati è davvero, davvero fondamentale.

E il punto di partenza, di cui senza dubbio discuteremo, è semplicemente chiedere all’azienda di porsi
questa domanda.

In quanto tempo possiamo ripristinare la pulizia dei nostri sistemi?

E quello che vediamo ogni giorno è che non è una domanda così difficile da porre, ma è
davvero difficile rispondere, in particolare quando c’è quel divario culturale tra

il team di sicurezza e quello dell’infrastruttura.

Credo davvero che sia proprio questa la genialità dell’MTCR: si prendono una serie di concetti molto
tecnici su cui i team IT e di sicurezza si confrontano e li si trasforma in

qualcosa di cui si possa discutere con amministratori delegati e consigli di amministrazione.

Per tornare al tuo esempio, Darren, di un rivenditore che a Natale ha subito un attacco informatico
: come useresti l’MTCR se ti trovassi di fronte a un consiglio di amministrazione per

spiegare cosa è successo e come sta procedendo il processo di Recovery?

Beh, inizierò io a rispondere e poi passerò la parola
a Duncan affinché concluda, perché c’è una parte di questo documento di cui Duncan è stato in gran parte responsabile e che riguarda proprio

raggruppamento

di risorse che si combinano per formare un servizio.

Ma inizierò dicendo che ci sono un paio di questioni che devono essere affrontate e che molto
spesso non vengono affrontate.

Una riguarda la propensione al rischio.

Allora, chi siamo come azienda?

Che tipo di azienda siamo?

Un’azienda di vendita al dettaglio, in genere, presenta una propensione al rischio da bassa a media, più
o meno in quel range.

Ma questo aspetto va definito in modo che, man mano che procediamo e iniziamo a comprendere i
rischi che ci circondano, possiamo decidere cosa è accettabile e cosa

dovrebbe essere coperto dalla nostra assicurazione, ad esempio, e cosa dovrebbe invece essere assolutamente integrato
.

Quindi questa è la prima discussione.

La seconda discussione riguarda poi: qual è il modello aziendale minimamente sostenibile in questo caso?

È del tutto irrealistico supporre che un’organizzazione, indipendentemente dal proprio budget, sia
in grado di recuperare rapidamente ogni aspetto dell’attività.

Quindi, cosa conta davvero in questo settore?

È una conversazione molto, molto profonda e interessante da affrontare con la maggior parte delle aziende.

La maggior parte delle aziende non riesce a immaginare un mondo senza IT.

Pertanto, trovano molto difficile analizzare a fondo i processi aziendali e discutere di come sarebbero se tornassimo a utilizzare la carta.

Ma quella conversazione, in un certo senso, deve avvenire.

E questo ci porta a definire ciò che chiamiamo MVC, ovvero una “minimal viable company”.

Cioè, quali elementi devono essere presenti in quel periodo, o qualunque sia la tempistica che decidiamo
.

Quali sono gli elementi senza i quali questa attività non funzionerebbe affatto, senza i quali non saremmo operativi?

E questa è una discussione molto, molto importante.

Quello che potete quindi iniziare a fare è applicare il concetto di MTCR alla “minimal viable company”.

E ora passo la parola a Duncan, che potrà spiegarci in qualche modo cosa costituisce un servizio.

Come possiamo considerare questo aspetto nel contesto dei servizi?

E grazie, Darren.

E, ancora una volta, senza cercare di renderlo troppo complicato o troppo approfondito.

L’MTCR è come misurare i tempi medi di Recovery di un processo aziendale,

un servizio aziendale critico che poi si integra per formare l’azienda minima funzionante complessiva.

Quindi ci saranno diversi MTCR per i diversi processi aziendali.

Proprio oggi stavo parlando con un’azienda di beni di consumo, un produttore di birra, e
mi dicevano che, se perdessimo i dati relativi a quattro giorni, dovremmo letteralmente versare

quattro giorni di birra nello scarico perché non possiamo dimostrare che sia sicura da bere,
e quindi non possiamo venderla.

Quindi, nell’ambito di questo concetto, si tratta di analizzare quei processi aziendali e poi utilizzare quell’MTCR
come linguaggio aziendale comune per poter dire: “Bene, all’interno del mio processo, ho bisogno

quindi… oh, questo processo si basa su diversi tipi di applicazioni.

Tutte si basano su servizi fondamentali, come l’identità e la possibilità per i
clienti di accedere alla piattaforma.

Poi ci sono i sistemi di back-end, sia che si trovino nel cloud o in locale, gli hypervisor e
le soluzioni cloud critiche.

I sistemi front-end che eseguono le applicazioni vere e proprie e poi i sistemi
di accesso degli utenti: in che modo le persone accedono effettivamente a quella soluzione? Tramite PDA, terminali di punto vendita

, ecc.

Tutti questi elementi devono essere disponibili affinché quel servizio aziendale possa funzionare.

L’MTCR è progettato per essere gestito dal titolare dell’azienda.

Il primo passo in questo percorso è quindi effettuare un benchmark.

Qual è il loro MTCR attuale?

Quanto tempo impiegherebbe attualmente, anche se riuscisse a recuperare dati integri?

Perché il dato scioccante, al momento, è che la maggior parte delle organizzazioni non dispone
di una tecnologia che consenta loro di proteggere i propri backup ed essere in grado di interrogare

i propri backup per estrarre dati integri, ed è proprio questo il vero problema aziendale che siamo qui
per risolvere.

È molto interessante.

Hai detto: qual è l’MTCR attuale?

Quindi l’MTCR non è una misurazione effettuata alla fine per valutare quanto bene abbiamo recuperato i dati.

L’MTCR viene rilevato a intervalli regolari durante l’intero attacco.

E questo probabilmente perché

se ci si affretta con il Recovery, si rischia di causare danni ancora maggiori.

Puoi approfondire un po’ questo punto?

Sì, posso certamente approfondire l’argomento.

Prima di farlo, però, hai sollevato un punto davvero interessante,
che secondo me va approfondito ulteriormente.

Quindi, l’MTCR non è solo qualcosa che si misura durante la Recovery a seguito di un attacco.

È qualcosa che dovresti misurare prima della violazione.

È quello che io chiamo “a sinistra dello scoppio”.

Quando presentiamo questo concetto ai consigli di amministrazione, iniziamo a vederlo diffondersi
in tutta l’organizzazione.

E viene posta la domanda: cos’è l’MTCR, ad esempio, per la nostra “azienda minimamente funzionante”?

Potremmo ricevere alcune risposte che non vorremmo sentire, come ad esempio che non sappiamo cosa sia un’azienda minimamente funzionante
.

Oppure, anche se lo sapessimo, realisticamente, il nostro MTCR in questo momento è probabilmente di quattro mesi.

Non vogliamo sentire queste risposte, ma dobbiamo ascoltarle per poterci concentrare
sul miglioramento.

E quindi questo è un punto davvero, davvero importante, credo.

E Darren, per approfondire questo punto, penso che sia fondamentale per l’azienda capire qual
è il proprio MTCR oggi, perché questo poi informa correttamente il processo di gestione del rischio aziendale.

E non sarà sempre una soluzione tecnologica a ridurre quel tempo minimo di ripristino (MTCR).

Molto spesso, se l’azienda sa di avere questo rischio, ovvero di poter rimanere senza un
sistema critico per

un certo periodo di tempo, può predisporre un piano alternativo di continuità operativa,
tornare alla carta; sai, potrebbe essere lo scenario peggiore, Darren, ma, sai, al momento,

le aziende non comprendono i rischi che stanno affrontando.

E questo MTCR è pensato per consentire al consiglio di amministrazione di rivolgersi al CISO e ai suoi team
e chiedere: «Realisticamente, per quanto tempo saremo fuori servizio oggi?».

E poi, se si tratta di un numero accettabile – e ne ho condotti diversi di questo tipo
di studi, e spesso si tratta di…

spesso si tratta di 28, 35, 42 giorni.

L’azienda rimane quindi completamente sgomenta all’idea di dover fare a meno dei servizi IT per tutto quel
tempo.

Ma non ha mai avanzato tali richieste alle organizzazioni del CIO o del CISO dicendo: «Abbiamo bisogno che
l’azienda sia minimamente operativa, che queste risorse tornino online entro 24 ore».

Come si possono progettare quei processi aziendali in modo che siano ripristinabili entro 24 ore?

Devono essere requisiti funzionali o non funzionali della loro azienda per poter dire: “Questi
sono i nostri requisiti.

IT, CISO, potete aiutarmi a soddisfarli?

E, tornando al punto che ho sollevato prima, tra l’altro, ehm, è davvero importante capire
che, in un certo senso, quella domanda non può nemmeno essere rivolta a uno o all’altro di quei

team.

L’unico caso in cui si può ottenere una risposta sensata, anche se
non è quella che si vorrebbe, è se il team dell’infrastruttura e il team della sicurezza

nella stessa stanza a rispondere.

Perché a quella domanda non può rispondere nessuno dei due team.

E questo, ripeto, dal punto di vista culturale, è davvero, davvero importante prima ancora di avvicinarci alla
tecnologia.

Dal punto di vista culturale, ciò che stiamo cercando di fare con questo concetto è promuovere un
comportamento che oggi non esiste.

Esatto.

Si sta cercando di abbattere i silos.

Quindi ogni organizzazione, che si tratti del team IT, di quello dedicato alle infrastrutture o di SecOps, pensa: “La mia
parte va bene”, ma tutte queste parti devono lavorare insieme.

E così MTCR le riunisce e le induce a riflettere su questo

concetto di rischio nell’ambiente, poiché ogni singola persona ha un ruolo da svolgere in questo.

E poi penso che sia davvero trasformativo, in quanto offre a ciascuno di quei
leader la capacità di comunicare con un amministratore delegato o un consiglio di amministrazione e di spiegare ciò che

stanno effettivamente vivendo in termini di Recovery e di rischio aziendale, giusto?

Assolutamente, è fantastico.

Quindi, in che modo si collega ai requisiti di base?

Non sono poi così semplici, ma si tratta di requisiti di conformità come DORA e NIST 2.

In che modo l’MTCR si rapporta a questo, ammesso che lo faccia?

Beh, se per te va bene, Duncan, comincio io.

Ecco la mia riflessione iniziale al riguardo: sai, Danielle, io e te abbiamo esaminato
insieme quelle sezioni del DORA un sacco di volte e abbiamo parlato di conformità.

Una delle cose che stiamo iniziando a osservare nel panorama della conformità, che si tratti
di DORA, NIST 2 o altre normative globali, è questo riferimento, in primo luogo, a cosa sia la

resilienza e cosa significhi in contrapposizione alla sicurezza, e in secondo luogo, i test.

Hai un piano?

Hai testato il piano di Recovery?

Beh, penso che questo rimandi direttamente a quello che dovrebbe essere il parametro di valutazione del piano.

Mi preoccupa un po’ il fatto che molte delle normative che vedo, anche quelle più recenti
e in evoluzione, facciano ancora riferimento a concetti come il disaster recovery.

Non sono ancora molto esplicite su ciò che dovrebbe essere testato.

Ho persino visto qualche riferimento a RPO-RTO.

E quindi, in una certa misura, sapete, si tratta di un concetto importante man mano che le persone
iniziano a conformarsi e ad adottare quel tipo di conformità fortemente basata sulla resilienza

.

in termini di cosa andremo a misurare?

Perché se ci limitiamo a misurare i vecchi indicatori del disaster recovery, non faremo davvero grandi progressi
.

Quello che succederà è che, se subiamo un attacco, ricorreremo al nostro piano di DR,
lo metteremo in atto e, sorpresa sorpresa, non riusciremo a trovare il nostro backup integro, e ci vorranno 30, 40, 50, 60

giorni per ripristinare il sistema.

Quindi dobbiamo cambiare mentalità.

E per quanto riguarda la conformità, è stato davvero stimolante vedere alcune delle nuove politiche e dei nuovi programmi di conformità

menzionassero resilienza, Recovery e test, ma dobbiamo assicurarci di affrontarli
nel modo giusto e con i giusti quadri di riferimento e contesti.

Sì, sono totalmente d’accordo, Darren.

Pensa: se guardi molti dei requisiti del DORA e a ciò che la Banca Centrale Europea
ha detto sugli stress test, la maggior parte delle organizzazioni si è predisposta a

fallire, perché si dice che bisogna dimostrare di poter ripristinare l’operatività entro i limiti della propria tolleranza all’impatto
aziendale.

E la maggior parte delle organizzazioni si basa su quella tolleranza all’impatto aziendale

in base a metriche di disponibilità o al vecchio piano di DR che afferma: “Posso effettuare il failover dal data center A al
data center B in quattro ore”.

Non è possibile ripristinare l’operatività di un’intera banca o di un intero istituto finanziario in quattro ore, è
impossibile.

Quindi penso – e questo in un certo senso evidenzia la necessità di questo nuovo vocabolario dell’MTCR – che
debbano riesaminare quella tolleranza operativa, quella tolleranza all’impatto sul business, per

ridefinirla in modo da poter dire: se perdo il mio sistema centrale, ad esempio il mio registro contabile,

insomma, come faccio a operare?

Beh, non posso operare.

Pertanto, devo predisporre piani di emergenza che mi consentano di ricorrere a processi secondari per poi poter
ripristinare la situazione una volta che il registro contabile torni online, nell’esempio finanziario citato.

Ma, per quanto riguarda i test, la maggior parte delle organizzazioni, quando ho posto loro la domanda: «Quando avete testato il CR l’ultima volta?
», rimandano al loro piano di DR tradizionale.

Non fanno riferimento al loro piano di cyber-Recovery perché la maggior parte delle organizzazioni non ha ancora

progettato e implementato appieno un piano di cyber-Recovery.

E, senza dubbio, questo MTCR deve essere uno degli indicatori chiave all’interno di quel piano di cyber-Recovery
.

Avete progettato gli scenari dai quali vi proteggerete e dai quali vi riprenderete.

E poi si dispone di una misurazione dell’MTCR per quei diversi tipi di attacco.

In realtà serve proprio a colmare, come dicevo, quel divario tra il business, l’IT e il CISO.

Sai, Darren, dicevi che si tratta di cambiare la cultura e, Duncan, stavi
proprio dicendo che molti…

i contratti tra, ehm, le organizzazioni richiedono un tempo di ripristino, e questo non ha senso.

Quindi non è solo per i team tecnici, ma anche per i team di gestione
del rischio aziendale e per gli avvocati che si occupano dei contratti, affinché comprendano che RTO e RPO non sono sufficienti, ma

il nuovo standard è Recovery completo.

E tutti devono capire quale dovrebbe essere il risultato finale, non i singoli passaggi
lungo il percorso che

potrebbero essere irrilevanti, giusto?

Sì, penso che sia un’osservazione davvero valida.

E mi aspetto che, man mano che portiamo avanti questo concetto e organizziamo workshop sulla
posizione di rischio preferita, su tutte le aziende fattibili e sull’MTCR, scopriremo

scopriremo che, forse, molte più persone rispetto a quelle tradizionalmente coinvolte
nel “Recovery” dovranno interessarsi e avere voce in capitolo in quei

workshop.

Proprio per i motivi che hai menzionato, Danielle.

Quindi, per i dirigenti che ci ascoltano,

vi incoraggio tutti a consultare il rapporto completo.

Si intitola «Ridefinire il Recovery informatico: introduzione al Mean Time to Clean Recovery».

E ho un’altra domanda per Duncan e Darren: oggi avete trattato molti
argomenti.

Avete illustrato il tutto con un caso pratico relativo a un’azienda reale, il che è molto sensato.

Per i dirigenti che ci ascoltano, da dove si comincia?

Da dove iniziamo proprio ora?

Abbiamo letto il rapporto e vogliamo introdurre questo concetto nelle nostre aziende, nelle nostre
attività.

Come possiamo iniziare?

Beh, per quanto mi riguarda, in qualità di leader non tecnico, incoraggerei a convocare una riunione
tra chi è responsabile della fornitura delle infrastrutture in azienda, di solito un CIO,

e chi è responsabile della sicurezza informatica in azienda, solitamente un CISO, o forse no;
convochereste una riunione con queste due persone, questi due dirigenti, e porreste la domanda: in che misura

rapidamente, se dovessimo subire un attacco catastrofico da parte di un ransomware – prendiamo il ransomware

come esempio, dato che è molto diffuso e ne siamo tutti colpiti.

Quindi, nel caso di una catastrofe causata da un ransomware, in quanto tempo potreste ripristinare insieme l’attività
e garantirmi che i dati che sto per iniziare a utilizzare per gestire l’

azienda siano integri?

Vi garantisco che da quella riunione ne scaturiranno altre cinque, perché la
risposta non è semplice.

Ci vorrà la collaborazione tra tutti quei team.

Richiederà anche un cambiamento di mentalità.

E penso che direi qualcosa di molto simile, a parte il fatto che probabilmente amplierei il pubblico
per coinvolgere in quella conversazione figure come il Chief Risk Officer e i responsabili degli acquisti.

Infatti, la maggior parte delle organizzazioni, sia che si tratti di un contratto SaaS o di
un contratto di outsourcing, in genere non fa alcun riferimento al recupero informatico.

Quando potrò recuperare dati integri durante il processo di Recovery?

Perché nella maggior parte di questi tipi di contratti, è il cliente ad essere responsabile dei
propri dati.

I fornitori di infrastrutture e i fornitori SaaS sono responsabili dell’infrastruttura
che supporta il servizio.

Quindi, come sapete, spetta a loro assumersi la responsabilità di recuperare i dati integri
.

Ma devono anche diffonderli abbastanza rapidamente ai propri dirigenti aziendali per cercare
di comprendere davvero qual è il nostro MVC perché le organizzazioni, come hai detto prima,

Darren, semplicemente non possono permettersi e non saranno mai in grado di ripristinare l’intero sistema aziendale
in un lasso di tempo molto breve.

La chiave sta nel definire le priorità e solo l’azienda può valutare cosa sia più importante
per loro in una situazione di grave crisi informatica.

Darren, CTO di Commvault, e Duncan, responsabile del settore Sicurezza e Resilienza presso Kyndryl.

Grazie mille.

Per quanto riguarda i prossimi passi, spero che mettiate in pratica questo concetto di MTCR e aiutiate i leader
aziendali a discuterne in un workshop.

E mi aspetto che inizieremo a vederlo diffondersi in tutto il mondo man mano che aiuteremo
le nostre aziende a definire l’MVC più adatto a ciascuna di esse.

Grazie mille per il tempo che ci avete dedicato oggi.

Grazie, Danielle.