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

La mancanza di visibilità sulle dipendenze. Spesso le organizzazioni scoprono interconnessioni critiche solo durante un’interruzione del servizio o un attacco. 

I test aiutano a individuare i punti ciechi, a verificare le ipotesi e a sviluppare una “memoria operativa”, trasformando la conformità in una preparazione effettiva. 

Contribuiscono a fornire architetture rinforzate, progetti di riferimento convalidati, strumenti integrati e flussi di lavoro di Recovery testati, in linea con le aspettative normative. 

Collaborazione interfunzionale, esercitazioni frequenti di Recovery, competenze di automazione e un approccio orientato alla missione – non il semplice adempimento di requisiti formali. 

L’approccio pone l’accento sulla capacità di ripristino collaudata, sulla visibilità e sulla continuità operativa: pilastri fondamentali della regolamentazione in stile DORA. 

Per la trascrizione con indicazione dei tempi, guarda il video qui

Sono qui con ⁓ due dirigenti di Pure Storage e Kyndryl e sono molto 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 effettivamente.

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 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 come ⁓ la conformità sia quell’elemento che, se tenete sempre presente e prendete in considerazione fin dalla progettazione, vi permetterà di evitare o almeno di superare con successo alcune di queste storie da incubo. A proposito, se qualcuno ha domande durante il processo, non esiti a farle. Va bene? Allora vi do la parola per presentarvi. Ottimo. Grazie, Danielle. Mi chiamo Yuvraj Mehta.

Sono responsabile della strategia per le soluzioni informatiche presso Pure Storage. Lavoro in Pure Storage ormai da oltre 18 mesi. E ⁓ inizierò proprio con una storia da incubo. ⁓ Era 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 di un’azienda che potete considerare come il modello di cliente che segue alla lettera tutte le checklist di conformità e quant’altro ⁓

ma sono stati colpiti da 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, il momento da storia dell’orrore è arrivato letteralmente quando il responsabile della conformità o la persona

ha detto: «Eravamo conformi. 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 se ne è resa conto, pensando: «Mio Dio, siamo nei guai. Non ci siamo preparati al ripristino e a farlo in modo molto, molto affidabile e molto sicuro».

Questa è la premessa della nostra storia da incubo. Quindi siamo seduti in una “war room” con il CISO, con il team di conformità, con 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 della nostra divisione dedicata alla sicurezza e alla resilienza, che si concentra esclusivamente sulla

creare capacità, metodologie e competenze che consentano ai clienti di riprendersi. Siamo quindi molto concentrati sugli eventi che precedono il «boom»: come un cliente deve progettare, come deve prepararsi, come deve rilevare in modo appropriato per poter avere fiducia nella propria capacità di recupero, in particolare in ambito informatico, perché questo reinventa

l’intero modo di pensare su come affrontare la questione. Tuttavia, ancora oggi, molti dei problemi e degli impatti 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 dalla rapidità dei cambiamenti che osserviamo in relazione agli attacchi informatici di origine umana, progettati per causare il massimo disservizio, 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 menzionato Chris in precedenza in un’altra sessione parallela — quanto tempo fa, Emilio, tre, quattro anni fa? Abbiamo assistito a molti impatti che i nostri clienti hanno dovuto affrontare. Ok.

Quello che mi è rimasto più impresso è stato quando mi trovavo nella sala del consiglio di una banca di primo piano. Non nominerò 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 alle 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 esclusivamente di come raggiungere l’obiettivo “verde”. Il rappresentante dell’ufficio del CIO, responsabile dei dati e del backup, della conformità e dei tassi di successo, è intervenuto subito parlando 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, si basavano su come avevano testato e verificato la procedura. È 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. Condizioni ottimali, perfette. In realtà, ci sono volute più o meno quattro o cinque settimane. Si trattava di uno dei loro processi aziendali critici. L’esito più probabile era che non ci sarebbero riusciti. È uno di quei momenti in cui pensi: «Ho il mio conto in banca con 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 primato in materia di conformità e rispetto delle normative. Non c’era alcun illecito in atto né nulla di fuorviante; il risultato era autentico, era stato dimostrato un approccio diverso per analizzarlo, ma si è rivelato irrealistico. Ma se pensi all’impatto di tutto ciò, è davvero terrificante.

Ho molte altre storie da brivido, ma credo 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, secondo me, l’hai illustrato alla perfezione. Hai un addetto alla conformità, non so se sia successo davvero, ma che arriva e dice: «Siamo in regola». 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 scritto su un foglio di carta. Come possiamo rendere tutto questo più concreto? Quindi analizzeremo ⁓ 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. E la chiave

che noi di Pure, almeno, abbiamo detto ai nostri clienti e ai nostri partner è che uno dei primi passi verso la visibilità è la necessità di semplificare. Semplificare l’intera infrastruttura e tutti gli strumenti. Se si dispone di set di dati, se si ha una rete ⁓ distribuita in silos, si finirà per avere anche molteplici 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 corrisponda effettivamente a 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 proprio stack ⁓ in modo da poter costruire l’intera infrastruttura che si integri con i vari strumenti a disposizione. 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. Si desidera che l’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, in tutto lo stack, quella visibilità richiede, primo, semplicità; secondo, API; e terzo, un’integrazione molto solida tra questi tre livelli.

Quindi, 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 propria tecnologia che ha portato a quella situazione. Quindi, come gestisci la catena di fornitura 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 secondo.

Credo fermamente, avendo lavorato con numerosi clienti in tutto il mondo, che la sfida numero uno 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 limite massimo di tolleranza alle interruzioni di servizio. Vedi, ci saranno molte metriche relative ai backup e agli RTO. Il mondo è cambiato, giusto?

Ora si tratta davvero di assicurarsi che in tutta l’azienda ci sia consapevolezza di quel tempo massimo di interruzione tollerabile 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 li aiutiamo a verificarlo, giusto? Ma poi bisogna comprendere 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

a sostegno di 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 dei 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, indicando: «Ecco i cinque sistemi aziendali che non possono andare in tilt, altrimenti siamo offline»? Quanti di voi sanno quali sono questi sistemi? Sono in grado di nominarli? Tutti voi? Nessuno di voi?

Ok, quindi non molti. Siete in buona compagnia, tra l’altro. ⁓ Qualcuno di voi è stato abbastanza coraggioso da dire: «No, non preoccuparti, non ti avrei messo alle strette e non te l’avrei chiesto», perché la domanda successiva sarebbe stata: «Sapete 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 trova a rispondere solo nel momento della crisi.

Sì. E spesso i clienti scoprono la 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 degli hyperscaler della scorsa settimana. Non ne erano nemmeno a conoscenza perché avveniva 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 tratta nemmeno di un attacco informatico. So di dilungarmi e di appassionarmi 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 controlli adeguati per poter gestire quel rischio. Sì. Non ho una risposta da darti. No, è fantastico. Ok. Parliamo quindi del terzo livello, ovvero le competenze.

Che è davvero importante perché quello che speriamo è che le persone escano da questa conferenza e, se si occupano in qualche modo di 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 detto da 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 su cui si ha visibilità e le dipendenze che sono state identificate – proprio come ha menzionato Allen – siano sottoposti a un processo di verifica continua. Si tratta di sviluppare quella “memoria muscolare”. Torno alla storia da incubo di cui parlavamo prima:

quella banca, che non aveva sviluppato quella “memoria muscolare” relativa alla capacità di ripristino. Quindi, si torna alla vostra organizzazione, giusto? E al vostro personale, che deve sviluppare questa “memoria muscolare” relativa alla capacità di ripristino. 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 di supporto. Quindi, quei processi devono diventare parte

del funzionamento quotidiano o mensile della vostra organizzazione: «Abbiamo questi sistemi, li abbiamo identificati, sappiamo dove si trovano, ma dobbiamo seguire tutti i nostri protocolli». 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 dobbiamo ricorrere a persone esterne 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é hai 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à: so 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, chi sa come procedere con l’analisi e individuare le dipendenze. Ma sai, quando penso alle competenze nella nostra organizzazione, l’enfasi che metto riguarda più che altro 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…

Chris Lovejoy, nell’altra sessione, dire qualcosa che ho annotato e che mi piace. Abbiamo vissuto in un mondo di 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. Quindi è un’attenzione incentrata sulle metriche. Chris diceva che le metriche devono diventare una missione, giusto?

E mi piace molto perché ciò che fa è considerare le competenze da cui dipendiamo per gestire quei servizi aziendali critici, per garantire la fiducia nelle nostre organizzazioni, proprio tenendo conto di quelle competenze. E sta dicendo che deve esserci una trasformazione. Ci deve essere 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 è in circolazione 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’è un aspetto fondamentale, che è la mentalità e l’atteggiamento culturale. Ok. Non dovrebbe essere vista come un parametro di valutazione, ma deve essere una missione.

Ora, il bello di una missione è che si è motivati a realizzarla. Il successo nel raggiungimento del risultato, ha senso? Scusate, vorrei aggiungere una cosa. Riguardo a quanto detto da Allen: la missione non può essere «dobbiamo rispettare questa normativa» o «dobbiamo rispettare 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, qui da noi ci sono normative in ambito sanitario. Il risultato che tutte cercano di promuovere è la resilienza e la capacità di recupero. Quindi, quando ti rivolgi alla tua organizzazione e vuoi costruire una missione attorno a questo, non può essere: «Ehi, ⁓ dobbiamo costruire una missione basata 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 alla gestione dei rischi. Ed è anche noioso. Sì, è noioso, vero? È come dire: «Ehi, quante metriche devo spuntare? Quanti report devo generare per l’autorità di regolamentazione?» Deve 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 dei reparti IT fosse “efficienza”. Come possiamo diventare sempre più efficienti, giusto? Tagliando i costi, ecc. Ma ora non è più così, vero? Deve essere integrato, e non è nemmeno una parola d’ordine. Deve essere parte integrante del sistema. Come possiamo diventare più resilienti? Giusto? E questa dovrebbe essere la missione. Non: «Devo essere conforme a una normativa specifica». Voi due siete ⁓

in un certo senso d’accordo su questo argomento davvero importante, ovvero che la cultura della conformità sta cambiando e deve cambiare probabilmente più in fretta. 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. Quindi farò un’ultima domanda e poi darò la parola al pubblico. Ci restano solo pochi minuti.

Qual è una lezione che hai imparato a tue spese nella tua carriera in questo settore? E come possono gli altri 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 sai che avrai 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 tuo stack tecnologico e nei tuoi stack di dati, giusto? Se non si interviene in modo proattivo in anticipo per identificare i silos,

e non si inizia ad abbatterli in modo tale che, quando si verifica un problema, quei silos non esistano più e tutti lavorino insieme – dalle persone alla tecnologia – per garantire la capacità di ripristino, vi troverete in una situazione davvero difficile quando si presenterà quel problema. È 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 all’interno della propria organizzazione, l’importanza di creare fiducia nei confronti dei clienti, del mercato, delle 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 ha il 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 fa a verificare? La verifica e la conformità, in un certo senso, sono come una linea guida. Non è proprio così,

senza offesa per la conformità, che è 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 di disporre dei controlli giusti per poterlo fare. Lo dirò. Forse qui si vede 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, si 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. Disporre delle competenze è assolutamente una priorità affinché le organizzazioni abbiano successo e raggiungano la maturità in questo settore. 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

è stato fornire uno strumento, un meccanismo, giusto, che le organizzazioni possano prendere in esame, emulare e, se necessario, anche adottare, giusto? Stiamo definendo lo standard su come le organizzazioni e i clienti possano soddisfare queste normative, ma in un modo che colmi 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 capacità di ripristino, tanto per cominciare. 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 ci sentiamo pienamente sicuri nel dire ai nostri clienti e 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 la cosa davvero affascinante di ciò che abbiamo fatto 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, beh, Emilio, c’eri anche tu, giusto? Per ore, giorni. Mesi. Abbiamo lavorato per allineare le capacità

tra le competenze, la tecnologia, la strategia di archiviazione e lo stack di controllo offerto 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 temi comuni che osserviamo. Quindi ciò che abbiamo progettato insieme si basa in gran parte su un’esigenza del cliente e crea un risultato che possiamo offrirgli.

C’è una rapidità e una capacità che soddisfano molti dei requisiti di quei 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, né le funzionalità – senza offesa – quanto piuttosto il rapporto. Questo è il risultato. È il risultato che stiamo cercando di ottenere anche noi. Sì. È un modo perfetto per concludere perché…

Quello che volevo dire a nome di Commvault è grazie a entrambi. Grazie a Pure e a Kyndryl. Voi ragazzi siete davvero i nostri partner fondamentali. 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 collaborazione 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.