Trasformare la conformità in resilienza: costruire la fiducia di fronte alla regolamentazione

Mancanza divisibilità sulledipendenze. Spesso le organizzazioni individuano le interconnessioni critiche solo in caso di interruzione del servizio o di attacco. 

Questi test aiutano a individuare i punti ciechi, a verificare le ipotesi e a sviluppare una “memoria muscolare” operativa, trasformando la semplice osservanza delle regole in una vera e propria preparazione. 

Contribuiscono a fornire architetture consolidate, progetti di riferimento convalidati, strumenti integrati e flussi di lavoro di Recovery collaudati, in linea con i requisiti normativi. 

Collaborazione interfunzionale, esercitazioni frequenti di Recovery, competenze nell’automazione e approccio orientato agli obiettivi — non il semplice adempimento di un elenco di requisiti. 

L’approccio pone l’accento sulla comprovata recuperabilità, sulla visibilità e sulla continuità operativa      pilastri fondamentali della normativa in stile DORA. 

Per la trascrizione con l’indicazione dei tempi, guardate il videoqui

Sono qui con  due dirigenti, di Pure Storage e Kyndryl, e sono davvero felice che siate qui. Tra un attimo lascerò che si presentino da soli, ma prima vorrei introdurre l’argomento. Siete qui perché pensate che parleremo di normative e conformità, di come creare ottimi team di conformità, di come spuntare le caselle. Assolutamente no. Non parleremo di nulla di tutto ciò. Quindi, se volete andarvene nei prossimi 20 secondi, sentitevi liberi di farlo. Perché quello di cui parleremo è il motivo per cui quelle normative esistono davvero.

Cosa c’è realmente dietro? Da cosa stiamo cercando di proteggerci? E come lo stiamo affrontando? Negli Stati Uniti e in tutto il mondo assistiamo a un’esplosione di normative, tutte pensate per aiutare le aziende a conquistare la fiducia dei clienti e dei governi riguardo ai prodotti che immettono sul mercato. Eppure, molte persone del settore, sia nell’industria tecnologica che nel mondo della conformità, non colgono il punto.

Quando i clienti inviano i questionari sulla sicurezza, sì, qualcuno controlla per assicurarsi che abbiate spuntato tutte le caselle, ma in realtà non è questo il punto. Quindi lascerò che siano loro a presentarsi. E quando lo faranno, chiederò loro di iniziare raccontandomi una storia da incubo che hanno vissuto nelle loro aziende. Non ditemi ancora come l’avete risolto, perché lo analizzeremo insieme. ✿ Ma cosa è successo e noi…

Entro la fine della sessione, capirete perché e in che modo la conformità sia quell’elemento che, se tenuto sempre presente e integrato fin dalla fase di progettazione, permette di evitare o almeno di superare con successo alcune di queste situazioni da incubo. A proposito, se qualcuno ha domande durante la sessione, non esiti a porle. Ok? Allora vi do la parola per presentarvi. Ottimo. Grazie, Danielle. Mi chiamo Yuvraj Mehta.

Sono responsabile della strategia per le soluzioni di sicurezza informatica presso Pure Storage. Lavoro in Pure Storage ormai da oltre 18 mesi. E ⁓ inizierò proprio con una storia da incubo. ⁓ È successo, in realtà, sei mesi dopo il mio ingresso in Pure Storage e riguardava uno dei nostri clienti del settore dei servizi finanziari. ⁓ Si trattava, e potete considerarli come il modello di cliente che segue alla lettera tutte le checklist di conformità e quant’altro ⁓

Ma sono stati vittime di un attacco ransomware.   E   in sostanza, nel corso di settimane e mesi,   gli aggressori si sono infiltrati nei loro dati e hanno iniziato a crittografarli. Ma quando è arrivato il momento in cui si sono resi conto di essere stati colpiti e si trovavano nella sala operativa, l’incubo è diventato realtà nel momento in cui il responsabile della conformità, o la persona

ha detto: «Abbiamo rispettato le norme. Abbiamo effettuato i controlli. Abbiamo effettuato i controlli». Ma il CISO ha letteralmente commentato: «Tutto questo non ha alcun significato. Non posso recuperare i dati». Esatto. Ed è stato allora che l’intera sala ha sostanzialmente capito: «Mio Dio, siamo nei guai. Non ci siamo preparati al ripristino, e a farlo in modo davvero, davvero affidabile e sicuro».

Questa è la premessa della nostra storia dell’orrore. Quindi siamo seduti in una “war room” con il CISO, il team addetto alla conformità e il team IT, e tutti si guardano l’un l’altro cercando di capire: “Che diavolo facciamo?”. Spaventoso. Grazie mille per essere qui con noi questo pomeriggio. Mi chiamo Allen Downs. In Kyndryl mi occupo di un settore specifico all’interno della nostra divisione dedicata alla sicurezza e alla resilienza, incentrato esclusivamente sulla

creare capacità, metodologie e competenze che consentano ai clienti di riprendersi. Siamo quindi molto concentrati sugli eventi che si verificano immediatamente dopo il “boom”: come un cliente deve pianificare, come deve prepararsi, come deve effettuare un’analisi adeguata per poter avere fiducia nella propria capacità di recupero, in particolare in ambito informatico, poiché questo settore si reinventa

l’intero modo di pensare su come affrontare la questione. Tuttavia, ancora oggi, molti dei problemi e delle conseguenze su cui lavoriamo con i clienti in tutto il mondo sono dovuti a errori umani e a eventi naturali. Questi non sono scomparsi, ma ormai siamo abituati a riprenderci da essi. La vera novità è rappresentata dalla complessità e dal ritmo del cambiamento che osserviamo in relazione agli attacchi informatici di origine umana, progettati per causare il massimo disagio, eccetera, eccetera.

Quando mi hai chiesto di raccontarti una storia da brivido, la cosa è interessante perché lavoro in IBM in questo settore ormai da oltre 30 anni. So di non sembrare così vecchio, quindi è vero, giusto? E in tutto questo periodo con IBM e ora con Kyndryl – partiamo da IBM, come ha accennato Chris in precedenza in un’altra sessione di approfondimento – quanto tempo fa, Emilio, tre o quattro anni fa? Abbiamo assistito a molte ripercussioni che i nostri clienti hanno dovuto affrontare. Ok.

Ciò che mi è rimasto più impresso è quando mi trovavo nella sala del consiglio di una banca di prim’ordine. Non menzionerò nemmeno il Paese, ma eravamo seduti nella sala del consiglio di una banca di primo piano e l’argomento verteva su come poter avere fiducia nella nostra capacità di rendere conto in modo sostenibile all’autorità di vigilanza. Settore bancario. Quindi erano soggetti a regolamentazione. La normativa stava diventando più rigorosa,

con maggiore attenzione e priorità. Ma la discussione verteva su come raggiungere l’obiettivo “verde”. Ok. Quindi la discussione si concentrava sugli indicatori, giusto? Si trattava solo di capire come raggiungere l’obiettivo “verde”. Il rappresentante dell’ufficio del CIO, responsabile dei dati e del backup, della conformità e dei tassi di successo, è stato molto rapido nel parlare del tasso di successo del backup e del numero di

ripristini completati e ha dichiarato con grande sicurezza di poter ripristinare i dati in otto ore. Quelle otto ore sono state inserite nel loro rapporto, nella documentazione presentata all’autorità di vigilanza. Chi di voi ha familiarità con le normative europee saprà che la Banca Centrale Europea ha pubblicato un documento sugli stress test e quindi a tutte queste banche è stato chiesto di rispondere con una posizione ufficiale approvata dal revisore,

il vostro equivalente, immagino in quell’organizzazione, tutto ben definito, giusto? Lavoro fatto. Gli indicatori riportati, ok, basati su come avevano effettuato i test e le simulazioni. È interessante notare che al Chief Risk Officer è stato poi affidato il compito di dimostrarlo. Qualcuno al di fuori del CISO, qualcuno al di fuori dell’ufficio del CIO, qualcuno al di fuori dell’infrastruttura, il RISO, ricordate, il data center, giusto? Il RISO, il personale addetto alle strutture.

Il Chief Risk Officer: «Dimostralo». Ci è stato chiesto di fornire la prova. Nelle condizioni migliori, più perfette. In realtà, ci sono volute più o meno quattro o cinque settimane. Si trattava di uno dei loro processi aziendali critici. Il risultato più probabile era che non ce l’avrebbero fatta. È uno di quei momenti in cui pensi: «Ho il mio conto in banca presso questo cliente, il mio mutuo è con questo cliente. Questi tizi, insomma, hanno i miei risparmi, ok?»

E quello è probabilmente uno dei momenti più impressionanti in cui te ne stai lì e pensi: «Caspita, questo settore non è preparato». A proposito, un’organizzazione conservatrice, storicamente molto orgogliosa del proprio track record in materia di conformità e rispetto delle normative. Non c’era alcun comportamento scorretto o fuorviante, il risultato era autentico; l’approccio alternativo proposto per esaminare la questione si è rivelato irrealistico. Ma se pensi all’impatto di tutto ciò, è davvero terrificante.

Ho molte altre storie da brivido, ma penso che quella sia stata probabilmente quella che mi è rimasta più impressa. È casa mia. Wow. Così ho trasferito il mio conto di risparmio da loro. Ho tenuto lì il mio mutuo. Ho tenuto lì il tuo mutuo.  Scusa. No, ma il punto è che penso che tu l’abbia illustrato alla perfezione. Hai un addetto alla conformità, non so se sia successo davvero, ma che entra e dice: «Siamo conformi». E lui risponde: «E allora? Non puoi recuperare

e i vostri sistemi sono fuori uso e non torneranno online entro il periodo di tempo che avete indicato su un foglio di carta. Come possiamo renderlo concreto? Analizzeremo quindi queste storie e voglio analizzarle in tre modi. Suddividiamole in tre diverse categorie. Cosa c’è davvero dietro la conformità? Categoria uno: visibilità. Categoria due: fiducia e controllo. Categoria tre: competenze.

Parliamo quindi di visibilità. Chi vuole iniziare? Posso iniziare io. Sì. Penso che una delle cose da tenere a mente, quando si ha a che fare con infrastrutture complesse — e ora ancora più complesse con l’IA — sia che non si può garantire la resilienza per ciò che non si vede. Quindi la visibilità è il primo passo, è il punto di partenza. Ed è la chiave

Quello che noi di Pure, almeno, abbiamo detto ai nostri clienti e ai nostri partner è che uno dei primi passi verso la visibilità è la semplificazione. Semplificate l’intera infrastruttura e tutti i vostri strumenti. Se disponete di set di dati, se avete una rete… distribuita in silos, vi ritroverete con una moltitudine di strumenti che si sono sviluppati

anche su quei silos. Quindi, ottenere una visione coerente e completa del proprio set di dati inizia con il consolidamento, inizia con la semplificazione. Quindi: semplificare. Questa è la prima cosa, perché in questo modo si creerà fiducia e si avrà la certezza che ciò che si vede è effettivamente ciò che si ottiene.   Questo è il primo passo. Il secondo passo in termini di visibilità è in realtà l’automazione.

È necessaria l’automazione in tutto il vostro stack — in modo da poter costruire l’intera infrastruttura che si integri con i vari strumenti di cui disponete. Servono quindi strumenti e un’infrastruttura dotata di API robuste in grado di garantire l’integrazione. L’ultimo punto l’ho già detto: l’integrazione. Volete che la vostra infrastruttura di storage o quella di elaborazione

si integrino con i vostri strumenti di sicurezza informatica, giusto? ❓ Con soluzioni come Commvault. Ma poi volete che siano integrabili anche con soluzioni come Kyndryl, le dashboard e le funzionalità fornite da Kyndryl e dal vostro fornitore di servizi. Quindi, nell’intero stack, quella visibilità richiede, in primo luogo, semplicità; in secondo luogo, API; e in terzo luogo, un’integrazione molto solida tra questi tre stack.

Allora, Allen, vorrei che tu aggiungessi a tutto questo la visibilità e il controllo, perché nel tuo esempio, quello della banca, dubito fortemente che quella banca avesse sviluppato internamente tutta la tecnologia che ha portato a quella situazione. Quindi, come gestisci la catena di approvvigionamento in entrata, il controllo, la fiducia, oltre alla probabile mancanza di visibilità che quel team aveva su ciò che stava accadendo? Ma lasciamo da parte questo argomento per un attimo.

Credo fermamente, avendo lavorato con numerosi clienti in tutto il mondo, che la sfida principale che devono affrontare oggi e il loro punto debole siano la consapevolezza e la visibilità. Sì. Credo davvero che questa sia una sfida fondamentale per loro. E tutto inizia, in realtà, con la comprensione da parte del cliente di quale sia il suo livello massimo di tolleranza alle interruzioni di servizio. Vedi, ci saranno molte metriche relative ai backup, agli RTO e agli RTO. Il mondo è cambiato, giusto?

Ora si tratta davvero di assicurarsi che in tutta l’azienda ci sia consapevolezza di quella soglia massima di tolleranza alle interruzioni e di garantire che vi sia una chiara comprensione delle dipendenze esistenti all’interno dell’azienda. Parliamo tutti di “minimum viable company”, giusto? La maggior parte delle aziende dirà: “Conosco la mia minimum viable company”. Noi le aiutiamo a verificarlo, giusto? Ma poi bisogna comprenderne l’impatto.

dell’interruzione di quella “minimum viable company”: è un aspetto in cui i clienti iniziano ad avere difficoltà in termini di impatto finanziario, impatto sul rischio reputazionale, impatto sulla non conformità normativa, per non parlare del fattore fiducia nei confronti dei propri utenti, eccetera, eccetera. Ritengo quindi che vi sia una mancanza di consapevolezza riguardo a: quali sono i miei processi aziendali critici? Quali sono quei servizi aziendali critici che supportano tali processi? Qual è la dipendenza a livello aziendale

che supportano quei servizi aziendali critici? Consapevolezza. Qual è la dipendenza a livello organizzativo? Abbiamo parlato di competenze, giusto? Quali sono le dipendenze a livello di applicazione o di gruppo di livelli applicativi? Qual è la dipendenza a livello di dati? Conosco la dipendenza di un server aziendale critico dai miei dati? Dove si trova? Dove esiste? E magari su AWS. Ok, dove? Quali sono i singoli punti di guasto? Quali sono i singoli punti di rischio? Quindi, secondo me, la consapevolezza

deve permeare ogni singolo livello dell’azienda. Allen, fermati un attimo. Quanti di voi qui presenti, quante delle vostre aziende hanno stilato un elenco o almeno ne hanno discusso in una riunione esecutiva con il consiglio di amministrazione, dicendo: «Ecco i cinque sistemi aziendali che non possono andare in tilt, altrimenti siamo offline»? Quanti di voi sanno quali sono quei sistemi? Sanno nominarli? Tutti voi? Nessuno di voi?

Ok, quindi non molti. Siete in buona compagnia, tra l’altro. ✧ Qualcuno di voi ha avuto il coraggio di dire: «No, non preoccuparti, non ti avrei messo alle strette e non te l’avrei chiesto», perché la domanda successiva sarebbe stata: «Sai qual è la soluzione di riserva se smettono di funzionare? Come si effettua il failover?» È una domanda fantastica e nessuno sa nemmeno da dove cominciare per rispondere. Ma senza quella risposta, non avete visibilità. Ci si ritrova a rispondere solo nel momento della crisi.

Sì. E spesso i clienti si rendono conto della dipendenza solo nel momento della crisi o dopo che l’evento si è verificato, e a quel punto è troppo tardi. Da qui il caso di quel grande rivenditore nel Regno Unito, giusto? Un rivenditore nel Regno Unito. Insomma, a che punto siamo adesso? Sono passati cinque mesi? Se Derek fosse qui, lo saprebbe di sicuro, ma sono fuori gioco da cinque mesi. Ok. Storia interessante. Una grande banca di primo livello è rimasta sorpresa quando ha perso uno dei suoi servizi aziendali critici

a seguito di una delle interruzioni di servizio di un hyperscaler verificatasi la settimana scorsa. Non ne erano nemmeno a conoscenza perché il servizio passava attraverso la catena di fornitura di terze parti. Non si erano resi conto che uno dei servizi aziendali critici dipendeva da un data center situato in Virginia. Ok. Hanno subito un impatto causato da un errore umano. Non si è nemmeno trattato di un attacco informatico. So che mi dilungo e mi appassiono parecchio sull’argomento, ma lavoro con tantissimi clienti che non conoscono la risposta a questa domanda. Ottima domanda

che hai appena posto. Pertanto, a mio avviso, la consapevolezza è fondamentale. Comprendere questo, comprendere le interdipendenze e poi capire qual è il livello massimo di tolleranza che diventa il tuo KPI attorno al quale progetti il processo, sviluppi le competenze e implementi la soluzione con i giusti controlli per poter gestire quel rischio. Sì. Non ho una risposta da darti. No, è fantastico. Ok. Parliamo quindi del terzo livello, ovvero le competenze.

Il che è davvero importante perché quello che speriamo è che le persone, una volta uscite da questa conferenza… e se lavori nel settore della conformità… dicano: «Ok, so cosa devo fare». Devo andare a scoprire quali sistemi sono davvero critici per l’azienda. E non ce ne sono molti, al massimo una mezza dozzina. E devo assicurarmi di capirlo bene. E poi devo capire chi è responsabile del piano per garantire il failover. Quali sono le competenze necessarie per farlo con successo? Allora, Danielle, vorrei rispondere a questa domanda

Ma vorrei aggiungere qualcosa a quanto ha detto Allen, soprattutto riguardo al controllo e alla fiducia, giusto? ☀ La grande sfida, le sfide che Allen ha illustrato, le vediamo ovunque, vero? Soprattutto in termini di consapevolezza, ma non si può costruire la fiducia se non si può verificare, giusto? Il vecchio adagio, vero? Fidati, ma verifica. ☀ E il modo per sviluppare questo insieme di competenze è

garantire che i sistemi di cui si ha visibilità e le dipendenze che sono state individuate, proprio come ha detto Allen, siano sottoposti a un processo di verifica continua. Si tratta di sviluppare quella “memoria muscolare”. Torno alla storia da incubo di cui si è parlato prima nella conversazione:

quella banca, che non aveva sviluppato quella “memoria muscolare” in materia di recuperabilità. Quindi, si torna alla vostra organizzazione, giusto? E al vostro personale, che deve sviluppare questa “memoria muscolare” in materia di recuperabilità. Ne hanno bisogno, e come si fa? È come quando, sai, vai in palestra: se vuoi sviluppare un muscolo, devi andarci ogni giorno o, insomma, avere un meccanismo costante a supporto. Quindi, quei processi devono diventare parte integrante

del funzionamento quotidiano o mensile della tua organizzazione: «Abbiamo questi sistemi, li abbiamo identificati, sappiamo dove si trovano, ma dobbiamo seguire tutte le nostre procedure operative». Dobbiamo fare in modo che questa “memoria muscolare” sia integrata nel nostro personale IT e nel nostro CISO, in modo che, quando succede qualcosa, sappiano come reagire. E non può essere che

Quando succede qualcosa, faremo intervenire persone dall’esterno che ci aiutino, perché quella è una ricetta per il disastro, dato che richiede semplicemente troppo tempo. È come se, sai, non potessi preparare una torta solo perché ci sono dieci persone sedute lì, “quindi le competenze di cui hai bisogno devono essere effettivamente integrate nella tua organizzazione nel corso del tempo; devi avere un piano su come procedere, ma deve poggiare sulle fondamenta della

visibilità: quindi, cosa sto facendo, conosco le dipendenze e poi, ehi, cosa sto ripristinando? Quali sono quelle applicazioni mission-critical che devo assolutamente ripristinare? E poi si mettono a punto quei piani in modo coerente.

Sono d’accordo. È interessante dal punto di vista delle competenze: lo vedo sotto due aspetti. Ci sono le competenze tecniche, ovvero chi sa come procedere per effettuare l’analisi e individuare le dipendenze. Ma sai su cosa pongo l’accento quando penso alle competenze nella nostra organizzazione? Ha più a che fare con una mentalità e una cultura. Va bene. Ha più a che fare con quella mentalità e quella cultura. Ed è proprio questo il cambiamento che deve avvenire. Esatto. Allora, ho sentito che…

Chris Lovejoy, nell’altra sessione, ha detto qualcosa che ho annotato e che mi piace. Viviamo in un mondo dominato dalle metriche e uno dei problemi delle normative è che si tende a ricevere richieste del tipo: «Mostrami i tuoi tassi di successo» e «Mostrami la tua conformità ai KPI», eccetera, eccetera. Si tratta quindi di un’attenzione incentrata sulle metriche. Chris diceva che le metriche devono diventare una missione, giusto?

E mi piace molto perché ciò che fa è concentrarsi sulle competenze da cui dipendiamo per gestire quei servizi aziendali critici, per garantire la fiducia delle nostre organizzazioni, proprio guardando a quelle competenze. E sta dicendo che deve esserci una trasformazione. Deve esserci una mentalità diversa in termini di ciò di cui ci fidiamo, di come ci fidiamo, di come creiamo fiducia, di come convalidiamo le cose.

E adoro questa frase: «fidarsi, ma verificare», giusto? So che circola da molto tempo, ma oggi non è mai stata più rilevante di quanto lo sia stata storicamente, perché quell’insieme di competenze va oltre le semplici metriche, le competenze tecniche, le conoscenze, le abilità, le certificazioni, ecc. Tendiamo ad assumere su questa base, ma c’c’è un aspetto fondamentale in tutto questo, ovvero la mentalità e l’atteggiamento culturale. Ok. Non dovrebbe essere vista come un parametro, ma deve essere una missione.

Ora, il bello di una missione è che si è motivati a portarla a termine. Il successo nel raggiungimento del risultato ha senso, vero? Scusate, vorrei aggiungere una cosa. Riguardo a quanto detto da Allen, la missione non può essere: «Dobbiamo rispettare questa normativa o questa conformità». Deve essere un risultato. E qual è il risultato? Giusto? Sapete, c’è il DORA nell’UE, ci sono normative simili in India, …

in Australia, dove esistono normative in materia di sanità. L’obiettivo che tutte queste normative cercano di promuovere è la resilienza e la capacità di recupero. Quindi, quando vi rivolgete alla vostra organizzazione e volete definire una missione incentrata su questo aspetto, non potete dire: «Ehi, dobbiamo definire una missione incentrata sulla conformità al DORA o al NIST».

Non funziona perché in quel caso si tratta di un approccio molto compartimentato. Diventa una missione forse per il vostro reparto di conformità, forse per quello dedicato al Risk. Ed è anche noioso. Sì, è noioso, vero? È come dire: «Ehi, quante metriche devo spuntare? Quanti rapporti devo generare per la mia autorità di regolamentazione?». Dovrebbe invece essere: «La nostra missione è essere resilienti e riprenderci rapidamente quando succede qualcosa di grave». Tutto qui. Credo che quattro o cinque anni fa,

La parola d’ordine all’interno dell’organizzazione IT era “efficienza”. Come diventare sempre più efficienti, giusto? Tagliando i costi, ecc. Ma ora non è più così, vero? Deve essere una priorità, e non è nemmeno una parola d’ordine. Deve essere parte integrante del nostro modo di operare. Come possiamo diventare più resilienti? Giusto? E questa dovrebbe essere la missione. Non semplicemente “devo essere conforme a una normativa specifica”. Voi due state…

In un certo senso sono d’accordo su questo argomento davvero importante, ovvero che la cultura della conformità sta cambiando e probabilmente deve cambiare più rapidamente. Dobbiamo, sapete, le competenze tecniche sono fondamentali, ma dobbiamo uscire dall’ambito tecnico e tradurre tutto questo in qualcosa che sia importante per le persone, qualcosa per cui le persone vogliano sedersi in una stanza e ascoltare. Quindi… penso che il modo migliore per cambiare la cultura sia partire da noi stessi. Farò quindi un’ultima domanda e poi darò la parola al pubblico. Ci restano solo pochi minuti.

Qual è una lezione che hai imparato a tue spese nel corso della tua carriera in questo settore? E in che modo gli altri possono trarne insegnamento?

È una bella domanda. Penso che… Perché quando ti presenti davanti a un consiglio di amministrazione, come hai giustamente sottolineato, dire che “dobbiamo essere conformi al DORA” è noioso. Mi sono trovato in una situazione in cui è successo e non voglio che si ripeta. Ecco cosa ho imparato ed ecco cosa faremo al riguardo. Penso che l’unica lezione che ho imparato a mie spese sia che se non si abbattono i silos all’interno dell’organizzazione e…

tra i team, in particolare i team chiave di cui sapete che ci sarà bisogno ogni volta che succede qualcosa di grave. E se non si interviene in anticipo per abbattere quei silos, la capacità di ripristino diventa molto più difficile. E quei silos non sono solo quelli tra le persone, giusto? Sono silos… presenti anche nel vostro stack tecnologico e nei vostri stack di dati, giusto? Se non si interviene in modo proattivo in anticipo per identificare i silos,

e se non si inizia a smantellarli in modo tale che, quando si verifica un problema, quei silos non esistano più e tutti lavorino insieme — dalle persone alla tecnologia — per garantire quella capacità di ripristino, vi troverete in una situazione davvero difficile quando quel problema si presenterà. È una domanda davvero interessante. E, sapete, una delle cose che mi ha colpito nel corso degli anni è l’importanza della fiducia.

L’importanza della fiducia nella propria organizzazione, l’importanza di creare fiducia nei confronti dei clienti, fiducia nel mercato, fiducia con l’autorità di regolamentazione, e chi più ne ha più ne metta, giusto? La fiducia è probabilmente uno dei fattori aziendali più importanti. Con la fiducia si cresce. A proposito, se si dispone del giusto livello di fiducia, non si compete sul prezzo, ma sulla reputazione.

Da dove nasce la fiducia? La fiducia nasce — e lo abbiamo già detto prima, e grazie per averlo ribadito perché mi ha fatto riflettere sul fatto che la vera essenza della fiducia è quella che si può verificare. Si può verificare. È irresponsabile fidarsi senza la possibilità di verificare. Moltissime organizzazioni sono cadute in questa trappola. Quindi mi chiedo: come si può verificare? La verifica e la conformità, in un certo senso, sono come una linea guida. Non è proprio così,

Senza offesa, la conformità è fantastica quando è appropriata. È una linea guida, ma la capacità di un’organizzazione di verificare sarà diversa. Ok. Quindi la consapevolezza è così importante. La visibilità è così importante, giusto? La capacità di verificare dipende dal fatto che abbiate i controlli giusti per poterlo fare. Lo dirò. Forse qui sto rivelando la mia età: «Ehi, testate, testate, testate, testate in modo appropriato». E cosa intendo per «testare in modo appropriato»?

Abbattete i silos di cui abbiamo parlato prima. Non testate il silo. Testate ciò che conta per il cliente del cliente. Testate ciò che conta per il consiglio di amministrazione. Ecco perché noi… Sì, e dovrei davvero farlo. Probabilmente vorreste che lo facessi. Ma il punto è che la capacità di testare deve essere adeguata ai criteri di successo dell’organizzazione. Ecco perché concentrarsi sul minimo funzionante, concentrarsi sui servizi aziendali critici, parte da lì.

E, a proposito, è importante sapere quale sia l’impatto rispetto al quale si sta effettuando il test. I pagamenti, in certi casi, possono costare miliardi di dollari al giorno, giusto? Non è un’esagerazione, le camere di compensazione, giusto? E così via. È di questa esposizione che stiamo parlando. Quindi, sapete, la lezione che credo di aver imparato è stata la necessità di poter avere fiducia. Si può avere fiducia, ma bisogna verificare. Per verificare, quindi, servono i controlli che consentano di farlo. Bisogna essere in grado di testare.

E poi, dal punto di vista culturale, servono le competenze. Credo fermamente in quelle tre categorie che hai menzionato prima. Avere visibilità è fondamentale, avere i controlli è essenziale. Avere le competenze è assolutamente una priorità affinché le organizzazioni abbiano successo e raggiungano la maturità in questo ambito. Direi che dipende dalla tua organizzazione, dipende da dove ti trovi. Giusto. Non esiste una soluzione miracolosa. Quello che Commvault, Pure e Kyndryl hanno fatto

L’obiettivo era fornire uno strumento, un meccanismo, esatto, che le organizzazioni possano valutare, emulare e, se necessario, anche adottare, giusto? Stiamo definendo lo standard su come le organizzazioni e i clienti possano soddisfare tali normative, ma in modo da colmare il divario tecnico, quello relativo alle competenze e quello legato alla fiducia, giusto? Quindi stiamo affrontando questi aspetti e abbiamo stabilito uno standard.

Questo soddisferà le esigenze di un’organizzazione? Dipende dall’organizzazione. Sapete, cercare una soluzione miracolosa probabilmente non è il modo giusto di affrontare la resilienza e la recuperabilità in primo luogo. Ma quello che abbiamo fatto è fornire un esempio, giusto? Cioè: «Ehi, ok, questo è un approccio che abbiamo verificato. Abbiamo effettuato test a livello tecnico e a livello di competenze

E siamo pienamente sicuri di poter dire ai nostri clienti e ai nostri partner: «Potete adottare questo approccio e vi aiuterà a ripristinare i dati ogni volta che si verificherà un attacco ransomware». Ecco cosa abbiamo fatto. Se soddisfa le esigenze di un’organizzazione, è un ottimo inizio e saremmo lieti di collaborare anche con loro.

E, per approfondire questo punto, penso che l’aspetto davvero affascinante di ciò che abbiamo realizzato con Commvault, Pure Storage e Kyndryl sia che il nostro punto di partenza è stata la prospettiva del cliente. «Cosa stiamo cercando di risolvere per il cliente? E abbiamo scelto una normativa, in questo caso la DORA. Quindi noi tre ci siamo seduti a discuterne per, diciamo, Emilio, c’eri anche tu, vero? Per ore, giorni. Mesi. Abbiamo lavorato per allineare le capacità 

tra le competenze, la tecnologia, la strategia di archiviazione e lo stack di controllo offerti da Commvault. E siamo riusciti a soddisfare la normativa DORA in vigore all’epoca. In effetti, la DORA trova riscontro in ogni regione del mondo in termini di tematiche comuni che osserviamo. Quindi ciò che abbiamo progettato insieme si basa in gran parte sulle esigenze del cliente e crea un risultato che possiamo offrirgli.

Si tratta di una velocità e di una capacità molto elevate che soddisfano molti dei requisiti dei clienti. Sì. Che siano soggetti a regolamentazione o meno. E penso che, dal punto di vista culturale, come tre organizzazioni, abbia funzionato eccezionalmente bene perché, mentre le tre organizzazioni lavoravano insieme, non era tanto la tecnologia, le caratteristiche o le funzionalità —— senza offesa — quanto piuttosto il rapporto. Questo è il risultato. Questo è l’outcome che anche noi stiamo cercando di risolvere. Sì. È un modo perfetto per concludere perché…

Quello che volevo dire a nome di Commvault è: grazie a entrambi. Grazie a Pure e a Kyndryl. Siete davvero dei partner importanti per noi. Abbiamo lavorato molto duramente per costruire insieme relazioni e fiducia. Questo non significa che siamo perfetti. Non significa che la nostra soluzione sia perfetta, ma significa che mettiamo molta competenza nelle relazioni e nella partnership che creiamo per i clienti. E vi siamo molto grati a entrambi. Quindi grazie mille. Grazie. Grazie per averci ospitato. Grazie! Grazie per averci ospitato.