Punti di forza

• ResOps non è un prodotto tecnologico. Si tratta di una disciplina operativa interfunzionale che contribuisce a rafforzare la resilienza informatica dell’organizzazione.
• Integra il backup, il ripristino di emergenza, la sicurezza informatica, la continuità operativa e la risposta agli incidenti, allineando queste funzioni ai risultati di Recovery end-to-end.
• ResOps si concentra sui servizi critici e sulle soglie di impatto definite dall’azienda, piuttosto che su singoli componenti dell’infrastruttura.
• Si basa sulla produzione continua di prove, inclusi risultati di Recovery verificati, indicatori di resilienza dei servizi e un elenco interno delle lacune.
• ResOps è un processo continuo. Né la stesura di un piano né lo svolgimento di un’esercitazione una tantum di successo sono sufficienti per stabilire una capacità di Recovery duratura.

La nuova sfida della resilienza

La maggior parte delle organizzazioni investe in sicurezza informatica, backup, Recovery di emergenza e continuità operativa. Tuttavia, molti dirigenti si trovano ancora di fronte a tre domande fondamentali: siamo in grado di ripristinare i sistemi? Quanto tempo richiederà il ripristino? E possiamo dimostrarlo?

Parte della sfida risiede nel fatto che la responsabilità della resilienza è distribuita tra team che spesso operano in compartimenti stagni. Il reparto di sicurezza gestisce le minacce. L’IT si occupa della manutenzione dei sistemi. I team di Backup and Recovery ripristinano i dati e l’infrastruttura. I team di continuità operativa si concentrano sul mantenimento dell’operatività dell’organizzazione. Ciascuno svolge un ruolo importante, ma la responsabilità del ripristino può rimanere frammentata.

ResOps riunisce queste funzioni attorno a priorità condivise, obiettivi di Recovery e prove concrete. Il risultato è un approccio più pratico alla resilienza: sapere cosa conta di più, comprendere cosa serve per ripristinarlo, verificare se il ripristino funziona e intervenire sulle lacune individuate.

Che cos’è ResOps?

ResOps è la disciplina operativa che riunisce sicurezza, infrastruttura, operazioni IT, continuità operativa e responsabili di business attorno a servizi critici, progettazione resiliente e convalida continua. In parole semplici, ResOps aiuta i team a prepararsi alle interruzioni, a ripristinare i servizi critici entro i limiti di tolleranza dell’impatto definiti dall’azienda e a dimostrare, sulla base di dati concreti, che il ripristino funziona.

Quattro caratteristiche definiscono ResOps. Esso è:

1. Intrinsecamente interfunzionale. Il ResOps collega responsabilità distribuite attraverso un modello operativo condiviso, una responsabilità ben definita e una governance esecutiva.
2. Incentrato sui servizi critici. Assegna la priorità ai servizi che l’organizzazione deve ripristinare per fornire valore fondamentale, servire i clienti e generare ricavi; oltre ad aiutare a soddisfare gli obblighi urgenti di natura legale, normativa, di sicurezza e relativi alla missione.
3. Validato continuamente. La resilienza è un approccio che i team devono esercitare e migliorare – non uno stato stabilito da un test annuale.
4. Misurato attraverso prove concrete. Il ResOps produce un punteggio di preparazione alla resilienza (RPS): un punteggio per singolo servizio, supportato da prove concrete, che misura il grado di recuperabilità di un singolo servizio critico sulla base dei risultati di convalida, dello stato di salute delle dipendenze e della fiducia nel Recovery completo.

Cosa non è ResOps?

Non è una categoria di prodotti.

Nessuna piattaforma può creare ResOps da sola. Le tecnologie di protezione dei dati, Recovery informatico, automazione, osservabilità e test possono supportare questa disciplina, ma ResOps è di natura organizzativa. Dipende dalla governance, dalla responsabilità condivisa, dalle priorità aziendali, dalle pratiche operative e da uno standard comune di prove.

Non sostituisce il Backup and Recovery né il disaster recovery.

ResOps non sostituisce solide capacità di Backup and Recovery: dipende proprio da esse. Il backup stabilisce se esistono copie recuperabili. Il Disaster Recovery fornisce le procedure e le capacità tecniche per aiutare a ripristinare sistemi e infrastrutture.

Ma poi ResOps pone una domanda più ampia: il servizio critico può tornare a funzionare completamente, in modo pulito e entro i limiti di tolleranza, includendo identità, applicazioni, dati, infrastruttura, servizi cloud, terze parti, persone e percorsi decisionali?

Non è un altro nome per indicare la continuità operativa o la risposta agli incidenti.

La continuità operativa definisce come l’azienda opera durante un’interruzione. La risposta agli incidenti rileva, contiene e gestisce l’evento. ResOps collega queste discipline al risultato della Recovery. Crea un ritmo operativo che consente ai team di concordare su ciò che conta, convalidare la Recovery in condizioni realistiche, misurare i risultati e colmare le lacune evidenziate dai test.

Non si tratta di un esercizio di conformità né di un progetto una tantum.

Un programma ResOps maturo può aiutare a generare prove a sostegno di consigli di amministrazione, autorità di regolamentazione, assicuratori, clienti e revisori. Ma la documentazione è un sottoprodotto, non l’obiettivo. L’obiettivo è la dimostrabilità della capacità di ripristino.

E poiché i sistemi, le dipendenze, le minacce e le priorità aziendali cambiano continuamente, ResOps non è mai “completo”. Opera in modo continuo, proprio come la pianificazione finanziaria o le operazioni di sicurezza.

Cosa cambia con il ResOps?

Il ResOps sposta l’attenzione dal funzionamento dei singoli sistemi e processi alla capacità di ripristino del servizio critico nel suo complesso. Questo cambia le domande che i leader possono porsi.

Un backup riuscito è importante. Lo è anche avere un piano di ripristino. Ma nessuno dei due indica se un servizio critico possa effettivamente essere ripristinato quando serve. Il ResOps guarda al quadro più ampio:

• Abbiamo effettuato il ripristino da un punto di Recovery verificato e pulito?
• Quanto tempo ci è voluto?
• Abbiamo effettuato il ripristino entro i limiti stabiliti dall’azienda?
• E cosa richiede ancora attenzione?

Ecco perché ResOps è fondamentale. Offre alle organizzazioni un modo per andare oltre le semplici ipotesi di resilienza e passare a dimostrazioni programmatiche e affidabili della loro capacità di ripristino. E lo fa attraverso la produzione continua di prove e la tracciabilità. Così, quando si verifica un’interruzione, la domanda non è se ogni team abbia fatto la propria parte o chi abbia fallito in quale compito. La domanda è se l’azienda sia in grado di ripristinare i servizi critici da cui dipendono i suoi clienti.

Per saperne di più

Commvault ha pubblicato “ResOps: An Executive Guide” per fornire a CISO, CIO e ai responsabili dei settori IT, sicurezza, resilienza e Risk un quadro di riferimento pratico per l’implementazione di ResOps nelle loro organizzazioni.

I responsabili impareranno come identificare i servizi più importanti, verificare la Readiness al ripristino con prove concrete e testare continuamente la resilienza. Di conseguenza, le organizzazioni potranno stabilire un unico modello operativo che riunisca i responsabili della sicurezza, dell’infrastruttura, delle operazioni IT e del business attorno a una capacità di ripristino basata su prove concrete.

Scarica la guida qui. 

Domande frequenti

D: ResOps è semplicemente un nuovo nome per il disaster recovery?

R: No. La Recovery è una parte essenziale del ResOps, ma il ResOps prende in considerazione l’intero servizio critico – comprese le dipendenze tecniche, di terze parti, umane e decisionali – e valuta se sia in grado di ripristinarsi entro una tolleranza di impatto definita dall’azienda.

D: ResOps richiede l’acquisto di una nuova piattaforma?

R: No. La tecnologia può supportare la mappatura, i test, Recovery e la raccolta di prove, ma ResOps parte dalla titolarità, dalla governance, dalle priorità aziendali e dalle pratiche operative.

D: Chi è responsabile del ResOps?

R: Il ResOps necessita di un responsabile designato con autorità interfunzionale e il sostegno della dirigenza. I singoli responsabili dei servizi rimangono accountable per i propri servizi, mentre i team di sicurezza, IT, continuità operativa e aziendali contribuiscono al risultato condiviso della Recovery.

D: Come si misura il successo di ResOps?

R: Il successo deriva dall’evidenza concreta che i servizi critici siano in grado di riprendersi senza intoppi entro i limiti di tolleranza definiti, non semplicemente dal completamento di un piano o dall’esecuzione di un’operazione di backup riuscita.

Anche il punteggio di resilienza (RPS) è uno strumento di misurazione utile. Essendo un punteggio per singolo servizio, supportato da prove concrete, l’RPS aiuta a dimostrare il grado di recuperabilità di un singolo servizio critico sulla base dei risultati di convalida, dello stato di salute delle dipendenze e della fiducia nel ripristino senza intoppi.

D: Come possono le organizzazioni avviare un percorso con ResOps?

R: Iniziando con l’identificazione dei servizi critici da cui dipende l’azienda, chi ne è responsabile, da cosa dipendono e con quale rapidità devono essere ripristinati. Da lì, i team possono convalidare il Recovery, identificare le lacune e stabilire le priorità del lavoro necessario per rafforzare la resilienza.

Michael Thelander è direttore senior del marketing di prodotto presso Commvault.

Punti di forza

• La resilienza dipende dalla rapidità e dalla sicurezza con cui l’azienda è in grado di riprendersi, non solo dalla capacità di tenere lontane tutte le minacce.
• Trasformate i piani di Recovery in dati concreti: i risultati verificati sono più credibili per i consigli di amministrazione, le autorità di regolamentazione e gli assicuratori rispetto a obiettivi o ipotesi.
• Rendere ResOps un modello operativo condiviso per i responsabili della sicurezza, dell’infrastruttura, della continuità operativa e dei servizi.
• Misurate ciò che conta: i team devono sapere se i servizi critici possono essere ripristinati, quanto tempo richiede effettivamente il ripristino e se sono in grado di dimostrarlo.
• Scegliete uno o due servizi critici, definite cosa si intende per Recovery riuscito, eseguite un’esercitazione realistica e documentate i risultati.
• Vent’anni di leadership nel settore della sicurezza ti insegnano presto una cosa: l’attacco che hai bloccato non viene mai menzionato durante la riunione del consiglio di amministrazione. Quello che non sei riuscito a bloccare è l’unica storia che tutti ricordano. A un certo punto ho smesso di valutare il mio team in base al numero di attacchi che abbiamo assorbito da soli e ho iniziato a valutarci anche in base alla rapidità con cui ci siamo ripresi.
• Ecco perché voglio che ogni CISO, CIO e membro del consiglio di amministrazione che conosco legga questo nuovo libro, *ResOps: An Executive Guide*. È stato sponsorizzato da Commvault, ma lo consiglierei comunque.

Il muro non è mai stato l’intero piano

Per gran parte della mia carriera, il mio lavoro è stato quello di costruire muri più alti: rilevamento più efficace, controlli più rigorosi, risposta più rapida. Quel lavoro è ancora importante, e lo sarà sempre. Ma un muro risponde solo a una domanda, e non è più quella che il vostro consiglio di amministrazione sta ponendo.

Lo scorso settembre, un attacco ransomware ha costretto Jaguar Land Rover a interrompere la produzione a livello globale. Le linee di assemblaggio si sono fermate. Le catene di approvvigionamento si sono bloccate. Il Cyber Monitoring Centre del Regno Unito ha stimato il costo per l’economia in generale a circa 1,9 miliardi di sterline, e JLR ha registrato il volume di produzione mensile più basso degli ultimi 73 anni. JLR disponeva di difese. Ciò che l’incidente ha messo alla prova non è stato se il muro avrebbe retto, bensì se l’azienda sarebbe stata in grado di riprendersi una volta che non avesse retto.

L’ho già detto in passato e continuerò a ripeterlo: la disruption non è una questione di “se”, ma di “quando”. I CISO che dormono sonni tranquilli non sono quelli che credono di poter tenere fuori ogni minaccia; sono quelli che si sono esercitati a riprendersi così tante volte che l’esercizio stesso è fonte di fiducia.

Tre domande che pongo al mio team

Il libro articola l’intero problema in tre domande, e ho iniziato ad aprire ogni revisione della resilienza proprio con queste:

• Se fossimo colpiti stanotte, riusciremmo a riprenderci?
• Quanto tempo ci vorrebbe effettivamente?
• Possiamo dimostrarlo, con prove concrete, al consiglio di amministrazione?

La maggior parte delle organizzazioni risponde alle prime due domande presentando un piano, mentre alla terza risponde con il silenzio. Quel silenzio rappresenta il divario di resilienza, ed è più ampio e costoso di quanto la maggior parte dei dirigenti si renda conto.

Prove, non promesse

Ecco una distinzione che il libro illustra meglio di quanto io abbia mai sentito fare altrove: un obiettivo di tempo di ripristino (RTO) è un traguardo. Indica ciò a cui si mira, ma non dice se lo si raggiungerà.

Confrontate «riteniamo di poter ripristinare il servizio di pagamenti in quattro ore» con «lo abbiamo ripristinato in 3,2 ore lo scorso trimestre, partendo da un punto di ripristino verificato e pulito, con una tolleranza di quattro ore». La prima frase è un piano. La seconda è una prova. Solo una delle due regge quando il vostro consiglio di amministrazione, l’autorità di regolamentazione o la vostra compagnia di assicurazione contro i rischi informatici inizieranno a porre domande più incisive, cosa che sicuramente faranno.

Chiamiamo questa disciplina ResOps, abbreviazione di «resilience operations» (operazioni di resilienza). Non è un prodotto che si acquista né un fascicolo da archiviare. È un modello operativo che collega sicurezza, infrastruttura, continuità operativa e i responsabili aziendali che dipendono da questi servizi, tutti operanti sulla base delle stesse prove concrete anziché di piani separati.

La parte che dovrebbe preoccupare ogni CISO

Il libro menziona anche qualcosa che percepivo da tempo e per cui finalmente ho trovato le parole giuste: il paradosso dell’IA. La stessa capacità dell’IA che ci aiuta a individuare le vulnerabilità più rapidamente sta aiutando gli aggressori a colmare il divario tra scoperta e sfruttamento con la stessa rapidità, forse anche più velocemente. Individuare più problemi non vi rende più sicuri se non riuscite a riprendervi da quelli che riescono a sfilarvi di mano. La velocità di rilevamento non è mai stata il traguardo. Lo è invece la capacità di Recovery.

Iniziate con un solo servizio

Nulla di tutto ciò richiede di voler fare l’impossibile, e mentirei se dicessi che il mio team ha fatto tutto bene al primo tentativo. Il libro delinea un percorso di 90 giorni: scegliete uno o due dei vostri servizi più critici, definite cosa significhi realmente “ripristinato” per ciascuno di essi, eseguite un esercizio di Recovery onesto e producete la vostra prima prova concreta. È un progetto che qualsiasi team può avviare in questo trimestre, compreso il mio.

I fatti contano più delle promesse. La Readiness conta più della perfezione. Questo è lo standard a cui sottopongo il mio team, ed è lo standard verso cui questo libro vi indica un percorso concreto.

Acquistate qui la vostra copia di “ResOps: An Executive Guide”.

Domande frequenti

D: Che cos’è ResOps?

R: ResOps, abbreviazione di “resilience operations”, è un modello operativo che mette in collegamento sicurezza, infrastruttura, continuità operativa e responsabili dei servizi attorno a pratiche di Recovery condivise e basate su prove concrete.

D: In che modo ResOps si differenzia dal tradizionale Disaster Recovery?

R: Il disaster recovery tradizionale si concentra spesso su piani e obiettivi tecnici. ResOps pone l’accento sulla convalida continua, sulla responsabilità interfunzionale e sulla prova misurabile che i servizi critici possano essere ripristinati entro i limiti di tolleranza aziendali.

D: Perché le prove di Recovery sono importanti?

R: Le prove di Recovery mostrano ciò che un’organizzazione ha effettivamente testato e realizzato. Contribuiscono a infondere nei consigli di amministrazione, nelle autorità di regolamentazione, negli assicuratori e nei dirigenti aziendali una fiducia maggiore rispetto ai soli piani o obiettivi di Recovery.

D: Cosa dovrebbero misurare le organizzazioni in un programma ResOps?

R: Le organizzazioni dovrebbero misurare se i servizi critici possono essere ripristinati, quanto tempo richiede effettivamente il ripristino, se i punti di ripristino sono integri e verificati e se i risultati soddisfano le tolleranze aziendali definite.

D: Chi dovrebbe essere coinvolto in ResOps?

R: Il ResOps dovrebbe riunire i responsabili della sicurezza, dell’infrastruttura, della continuità operativa, delle applicazioni e dei servizi, nonché i dirigenti interessati, in modo che le priorità e le prove relative a Recovery riflettano le esigenze aziendali.

D: Come può un’organizzazione avviare un programma ResOps?

R: Iniziate con uno o due servizi critici. Definite cosa si intende per Recovery riuscito, eseguite un’esercitazione di Recovery realistica, documentate i risultati e utilizzate tali evidenze per migliorare il test successivo.

Bill O’Connell è Chief Security Officer presso Commvault.

Punti di forza 

• L’avviso federale aggiornato descrive le nuove tattiche e tecniche di Medusa, oltre a più di 500 vittime in settori delle infrastrutture critiche. 
• Gli aggressori non prendono di mira solo i dati di produzione, ma compromettono anche i backup, i sistemi di gestione delle identità, la virtualizzazione e altri sistemi da cui le organizzazioni dipendono per il Recovery. 
• L’avviso esorta le organizzazioni a dimostrare la propria resilienza attraverso test e verifiche rispetto ai comportamenti osservati degli aggressori, senza limitarsi a darla per scontata sulla base dei soli piani o del corretto funzionamento delle operazioni di backup.  

L’ultima nota informativa federale sul ransomware Medusa è stata aggiornata per un motivo: l’autore degli attacchi è cambiato. 

L’avviso federale aggiornato, pubblicato il 18 agosto 2026 dall’FBI, dalla Cybersecurity and Infrastructure Security Agency (CISA) e dal Dipartimento della Salute e dei Servizi Umani degli Stati Uniti (HHS), descrive un avversario che recluta nuovi broker di accesso, agisce più rapidamente una volta penetrato all’interno e è diventato più abile nell’assicurarsi che il danno causato sia irreversibile.  

L’attacco non è rivolto solo ai vostri dati

Gli autori degli attacchi Medusa agiscono rapidamente. Gli investigatori riferiscono che hanno sfruttato gli exploit appena annunciati entro 24 ore e, in alcuni casi, li hanno utilizzati fino a una settimana prima della divulgazione pubblica della vulnerabilità.

Una volta all’interno, si mimetizzano utilizzando strumenti legittimi di gestione remota, il furto di credenziali e tecniche “living-off-the-land”. 

Ma la scoperta più significativa dell’avviso è che Medusa attacca il percorso di Recovery stesso.

L’avviso associa questa attività alla tecnica MITRE ATT&CK T1490, “Inibizione del Recovery del sistema”. Documenta come il ransomware interrompa i servizi associati a backup, sicurezza, database, comunicazioni, condivisione di file e siti web. Inoltre, elimina le copie shadow e spegne e crittografa da remoto le macchine virtuali. 

Se un aggressore prende deliberatamente di mira i sistemi, le identità e l’infrastruttura di cui un’organizzazione potrebbe aver bisogno per il Recovery, il problema si estende oltre la protezione dei dati fino a riguardare la resilienza informatica e il Recovery informatico. 

Dove entra in gioco ResOps (Resilience Operations)

ResOps non è un altro nome per indicare il backup. È una disciplina operativa che riunisce sicurezza, IT, infrastruttura, applicazioni, operazioni e il business attorno a un unico obiettivo: mantenere attivi i servizi critici e ripristinarli entro i tempi tollerabili dall’azienda.

L’avviso su Medusa non utilizza mai il termine ResOps, ma il concetto è presente. Raccomanda alle organizzazioni di esercitarsi, testare e convalidare i propri programmi di sicurezza alla luce dei comportamenti osservati degli aggressori, allineare le tecnologie di sicurezza alle tecniche di attacco, testarle su larga scala, misurarne le prestazioni e ottimizzare persone, processi e tecnologie sulla base delle prove.

Un backup non dimostra di essere integro. Un obiettivo di tempo di ripristino riportato in un foglio di calcolo non dimostra che l’azienda sarà operativa entro quella finestra temporale. La resilienza deve passare dalle supposizioni alle prove. 

Partire dall’azienda, non dal server

L’aggiunta dell’HHS (Dipartimento della Salute e dei Servizi Umani) nell’avviso rende questo aspetto particolarmente rilevante per il settore sanitario, che secondo l’FBI è stato spesso bersaglio di Medusa. Il dibattito sul Recovery inizia con tre domande: 

• Cosa deve continuare a funzionare e come si configura il funzionamento minimo sostenibile? 

• Quali identità, applicazioni, infrastrutture e dati supportano tali servizi? 

• A quali punti di Recovery possiamo fare affidamento e cosa viene ripristinato per primo? 

In un ospedale, lasciare una qualsiasi di queste domande senza risposta può significare un intervento chirurgico ritardato, un farmacista che non può verificare un dosaggio o un sistema diagnostico di cui un medico non può fidarsi. Nessun team può rispondere da solo a queste domande, ed è proprio questa lacuna che ResOps è progettato per colmare. 

Utilizzate Medusa per verificare le vostre ipotesi

Utilizzate Medusa come caso di prova per le ipotesi di Recovery. Un aggressore può raggiungere i sistemi che supportano il Recovery? Cosa succede se Active Directory viene compromessa? Siete in grado di identificare un punto di Recovery integro, ripristinare i servizi critici nell’ordine corretto e dimostrare quanto tempo ci vorrà? 

Gli autori delle minacce si adattano quando i difensori si adattano. I programmi di resilienza devono funzionare allo stesso modo: continuamente testati, continuamente convalidati e continuamente migliorati.

Perché nel bel mezzo di un incidente è un momento terribile per scoprire che il piano di Recovery sembrava migliore sulla carta di quanto non funzioni nella realtà. 

Domande frequenti

D: Che cos’è il ransomware Medusa? 

R: Medusa è un’operazione di ransomware-as-a-service identificata per la prima volta nel 2021. I suoi sviluppatori e affiliati utilizzano un modello di doppia estorsione, crittografando i sistemi e minacciando di pubblicare i dati rubati se non viene pagato il riscatto. 

D: Perché è stata aggiornata la nota informativa federale su Medusa? 

R: L’aggiornamento di agosto 2026 incorpora i risultati delle indagini dell’FBI risalenti fino ad aprile 2026. Amplia le tattiche, le tecniche, le procedure, le vulnerabilità sfruttate, l’attività degli affiliati e gli indicatori di compromissione documentati, aggiungendo al contempo approfondimenti dell’HHS sugli attacchi contro il settore sanitario. 

D: In che modo Medusa minaccia le capacità di Recovery di un’organizzazione? 

R: Medusa può interrompere i servizi associati a backup, sicurezza, database, comunicazioni e altre funzioni critiche. Può inoltre eliminare le copie shadow, alterare le politiche relative all’identità e spegnere o crittografare le macchine virtuali, mettendo a rischio il percorso di ripristino stesso. 

D: Cosa dovrebbero fare le organizzazioni per ridurre il rischio rappresentato da Medusa? 

R: Le organizzazioni dovrebbero applicare tempestivamente le patch alle vulnerabilità note, segmentare le reti, limitare l’accesso ai servizi remoti, rafforzare l’autenticazione, monitorare i movimenti laterali e applicare il principio del privilegio minimo. Dovrebbero inoltre mantenere copie di Recovery separate, offline, crittografate e immutabili e testare regolarmente i flussi di lavoro di Recovery. 

D: Che cos’è ResOps e in che modo si differenzia dal backup? 

R: ResOps, ovvero “resilience operations”, è una disciplina operativa interfunzionale – non un prodotto di backup. Allinea sicurezza, IT, infrastruttura, applicazioni, operazioni, continuità operativa e responsabili aziendali nell’ottica del ripristino dei servizi critici entro i limiti di interruzione che l’azienda è in grado di tollerare. 

D: In che modo un’organizzazione può dimostrare di essere pronta al ripristino? 

R: Iniziando dai servizi aziendali critici, mappando le identità, le applicazioni, l’infrastruttura, i dati, le persone e le terze parti da cui dipendono, e definendo cosa si intende per Recovery riuscito. Successivamente, è necessario eseguire esercitazioni realistiche che identifichino punti di Recovery chiari, ripristinino i servizi nell’ordine corretto, misurino il tempo di Recovery effettivo e trasformino eventuali lacune in un elenco di miglioramenti da attuare. Chris Bevil è responsabile principale del marketing di portafoglio presso Commvault. 

Key Takeaways 

• Roughly 1,200 supposedly isolated agents communicated through an unauthorized message board, and about 700 participated in Hugging Face-related activity. 
• Agents exchanged over 70,000 messages and files, combining discoveries across sessions meant to remain separate. 
• Investigators found agents spoofing tool calls and researching ways to alter evaluation transcripts to avoid detection by the grader.  
• Immutable, isolated backups alone are insufficient: Organizations need a validated, trustworthy recovery point before restoring to production. 

The forensic reports are finally here, and they changed the way I think about this incident. 

About a month ago, I wrote about the OpenAI and Hugging Face security incident because I thought it was something anyone responsible for cybersecurity, AI or business resilience should be watching.  

At the time, the story sounded fairly straightforward: An AI agent found a way outside the environment designed to contain it and ultimately reached Hugging Face. 

That is not really what happened. 

The Story Is Bigger Than One Rogue Agent 

The forensic reports reveal that about 1,200 agents, supposed to be operating in isolation, discovered a way to communicate through an unauthorized message board. They exchanged more than 70,000 messages and files, and roughly 700 agents participated in activity associated with Hugging Face. 

None of that was prompted or intended. The agents were persistent, they could share what they found, and they could combine effort across sessions that were supposed to have no contact with each other.  

Among the new details: GPT-5.6 Sol agents reproduced an exploit and copied private evaluation data into a public Hugging Face dataset, a concrete escalation beyond what initial reports described. 

The Reward-Hacking Problem 

The independent investigation conducted by METR and Redwood Research, published alongside OpenAI’s own report on August 26, found that agents researched ways to spoof, edit or delete portions of their own evaluation transcripts because they incorrectly believed the grader would inspect how they completed the task. Researchers found successful tool-call spoofing in about 7% of the transcripts they evaluated, though the manipulation they observed was small-scale. 

The finding is not that agents are “deceptive” in a human sense. It is that a sufficiently capable agent can search for ways around controls when those controls stand between it and the outcome it has been optimized to achieve. 

OpenAI calls the incident a “warning shot.” I think that is a fair description. 

What Happens When Containment Fails 

Most of the conversation about this incident will rightly focus on alignment, sandboxing and monitoring. But there’s a resilience question underneath it: If 700 agents can find a side door around containment, what’s the plan for when a single compromised workload does the same in your environment? 

OpenAI’s own conclusion points at the answer: Security architecture should assume an individual workload or compute node eventually can be compromised. That means air-gapped, immutable recovery data, and a way to validate what you’re restoring before it touches production again. 

But immutability alone does not prove the data was clean when it was captured. If the data was already compromised at the time of capture, immutability preserves the compromise just as faithfully as it preserves anything else. 

The practical version of that question is simple to ask and hard to answer: If this happened to us, could we prove which recovery point predates the compromise? 

We cover this operating model under ResOps (resilience operations) on the Readiverse. 

The Lesson for Every Organization 

OpenAI has since tightened workload and network isolation, expanded monitoring, and revised its model-development practices. The lesson applies beyond OpenAI: Contain the impact, preserve what you can trust, and prove you can recover before you need to. 

FAQs 

Q: What was the OpenAI-Hugging Face incident? 

During internal cybersecurity evaluations, OpenAI agents bypassed controls intended to isolate them, accessed the internet and reached third-party systems, including Hugging Face. The activity was driven primarily by an internal research model operating with reduced safeguards. 

Q: How did supposedly isolated agents communicate? 

A: They discovered an unauthorized message board in shared infrastructure. About 1,200 agents used it to exchange more than 70,000 messages and files, allowing information and tactics to carry across sessions that were designed to remain independent. 

Q: Were the agents instructed to attack Hugging Face? 

A: No. They were attempting to complete a difficult cybersecurity benchmark. When the intended route appeared blocked, some agents searched for alternative ways to achieve the evaluated outcome, and that activity expanded beyond the environment’s intended boundaries. 

Q: What does “reward hacking” mean in this context? 

A: Reward hacking occurs when an agent finds an unintended way to satisfy a metric or obtain a desired result without completing the task as intended. Investigators found agents researching ways to spoof tool calls and alter or delete portions of evaluation transcripts because they believed the grader might inspect their process. 

Q: Why are immutable backups not enough on their own? 

A: Immutability prevents stored data from being altered, but it does not prove the data was clean when it was captured. If a backup already contains compromised data, immutability preserves that compromise. Organizations therefore need isolated copies, trustworthy recovery points and validation before restoration. 

Q: What should organizations do differently after this incident? 

A: Strengthen workload and network isolation, restrict unnecessary internet and credential access, monitor agent behavior and escalation signals, and assume that prevention may fail. Pair those controls with air-gapped, immutable recovery data and a tested process for identifying and validating a clean recovery point. 

Chris Bevil is Principal Portfolio Marketing Manager at Commvault. 

Punti di forza

• Entro marzo 2029 la durata dei certificati si ridurrà da 398 a 47 giorni, mentre il “riutilizzo della convalida del dominio” scenderà a soli 10 giorni, rendendo obsoleto il rinnovo manuale e rendendo necessaria la gestione automatica del ciclo di vita dei certificati (CLM).
• Sono già in corso operazioni del tipo “Harvest Now, Decrypt Later” (Raccogli ora, decifra dopo) per archiviare dati con durata di vita lunga in vista di una futura decifrazione tramite computer quantistici; ciò comporta una minaccia immediata per i dati sensibili crittografati che prevedono una conservazione a lungo termine.
• L’inventario dei certificati e delle chiavi crittografiche è fondamentale per le aziende, che devono iniziare a crearlo fin da ora, poiché un inventario continuo e automatizzato rappresenta il primo passo verso la resilienza informatica a lungo termine e l’agilità crittografica.

Il problema nascosto dietro le quinte

La maggior parte delle reti aziendali moderne si basa su un livello nascosto costituito da certificati digitali e crittografia che la maggior parte delle persone non vede mai. Questo livello verifica l’affidabilità delle macchine e protegge i flussi di dati, ma dato che le identità delle macchine superano ormai quelle umane in un rapporto di oltre 80 a 1 nell’azienda media, secondo la ricerca di CyberArk sulle identità delle macchine, è facile sottovalutare l’importanza del livello crittografico e dei certificati.

Un modo utile per concepire un certificato digitale è quello di immaginarlo come un badge identificativo per un dispositivo. Se il badge è valido, le porte si aprono automaticamente e nessuno ci fa caso, ma nel momento in cui il badge scade o è configurato in modo errato, la porta smette di aprirsi, indipendentemente da quanto sia legittimo il dispositivo che si trova dietro. Un singolo certificato scaduto può mettere fuori uso i siti web, interrompere le API che consentono alle applicazioni di comunicare tra loro, bloccare le transazioni e causare violazioni di conformità, il tutto minando la fiducia degli utenti.

Per anni, le organizzazioni hanno gestito i certificati manualmente, ma due cambiamenti renderanno impossibile continuare a farlo manualmente. In primo luogo, la durata massima dei certificati TLS (Transport Layer Security) pubblici, il protocollo che protegge il browser, verrà ridotta a soli 47 giorni entro il 2029. In secondo luogo, l’arrivo imminente di computer quantistici abbastanza potenti da violare la crittografia odierna sta imponendo una transizione verso la crittografia post-quantistica. Queste due questioni indicano entrambe la stessa soluzione: un approccio al CLM (Certificate Lifecycle Management) governato, automatizzato e “crypto-agile”.

La roadmap alla base della riduzione della durata dei certificati

La finestra operativa per i certificati TLS pubblici si sta restringendo da un decennio. All’inizio del 2023, Google ha pubblicato per la prima volta la sua roadmap “Moving Forward, Together”, che proponeva di ridurre la validità dei certificati da 398 a 90 giorni nella speranza di spingere il settore verso l’automazione. Apple ha accelerato tale tempistica nell’ottobre 2024, presentando una bozza di votazione al CA/Browser Forum, l’organismo di settore in cui le autorità di certificazione e i produttori di browser stabiliscono regole condivise. La proposta di Apple, sostenuta da Sectigo, Google Chrome e Mozilla, è stata approvata nell’aprile 2025 come Ballot SC-081v3.

Questa riduzione avverrà in più fasi. Il precedente limite massimo di 398 giorni è già sceso a 200 giorni a partire da marzo 2026; il limite massimo sarà ridotto a 100 giorni a marzo 2027 e, infine, a 47 giorni a marzo 2029. In termini pratici, un’organizzazione che attualmente rinnova ciascun certificato circa una volta all’anno dovrà presto rinnovare ogni certificato all’incirca ogni mese e mezzo; nella fase finale, qualsiasi processo che dipenda dalla richiesta e dall’installazione manuale dei certificati da parte di una persona fallirà.

I produttori di browser stanno promuovendo queste durate di validità più brevi per imporre l’automazione, che elimina l’errore umano che è la causa principale delle interruzioni dei certificati. Inoltre, consentono all’intero web di adottare nuovi standard crittografici in poche settimane anziché in anni, poiché i vecchi certificati vengono sostituiti rapidamente. Contribuiscono inoltre a ridurre la dipendenza dai sistemi di revoca legacy, che presentano problemi di prestazioni e privacy. Infine, qualora un registro di Certificate Transparency (un registro pubblico dei certificati emessi) venisse mai squalificato, i certificati a breve durata riducono drasticamente il numero di quelli che devono essere sostituiti con breve preavviso.

La crisi della convalida

Sebbene il limite di 47 giorni faccia notizia e attiri l’attenzione, il cambiamento più dirompente potrebbe riguardare la Domain Control Validation (DCV). La DCV è il processo attraverso cui si dimostra a un’Autorità di Certificazione (CA) di avere il controllo del dominio per cui si richiede un certificato. Storicamente, una volta che un’organizzazione dimostrava la titolarità, la CA poteva riutilizzare tale prova per un massimo di 398 giorni, ma secondo lo standard SC-081v3, il periodo di riutilizzo si ridurrà a 200 giorni nel 2026 e a soli 10 giorni entro marzo 2029.

Ciò crea un vero e proprio squilibrio, poiché anche un’organizzazione che automatizza completamente l’installazione dei certificati subirà un rallentamento se non sarà in grado di dimostrare nuovamente la proprietà del dominio ogni 10 giorni. Qualsiasi ritardo nella convalida blocca l’intero processo di emissione e porta direttamente a interruzioni del servizio.

La soluzione pratica a questo problema consiste nell’adottare il protocollo ACME (Automatic Certificate Management Environment) con la convalida automatizzata tramite API DNS-01, in modo che la dimostrazione della proprietà avvenga a livello di programmazione anziché attendere l’intervento di una persona.

La minaccia quantistica e la tempistica

Mentre la durata dei certificati si riduce, gli algoritmi al loro interno devono affrontare una minaccia quantistica. Le infrastrutture a chiave pubblica (PKI) tradizionali si basano sulla crittografia asimmetrica per proteggere le firme digitali, gli scambi di chiavi e le connessioni TLS. Un computer quantistico sufficientemente potente che esegua l’algoritmo di Shor potrebbe compromettere completamente questi sistemi. Aspettare che l’informatica quantistica sia abbastanza potente da decriptare i dati non è un’opzione praticabile; come ha scritto Vidya Shankaran, Field CTO di Commvault, «la data esatta del Q-Day potrebbe rimanere incerta. La direzione in cui ci stiamo muovendo, invece, non lo è».

Secondo le stime, il Q-Day, ovvero il momento in cui un computer quantistico sarà in grado di violare la crittografia a chiave pubblica, si collocherà da qualche parte nei prossimi 5-10 anni. Tuttavia, sarebbe un errore considerarlo un problema futuro. Gli autori delle minacce stanno già conducendo operazioni del tipo «Harvest Now, Decrypt Later» (HNDL), intercettando e archiviando oggi il traffico crittografato con l’intenzione di decrittografarlo una volta che l’informatica quantistica avrà raggiunto la maturità. I dati che devono rimanere riservati per anni, come le cartelle cliniche, la proprietà intellettuale e le informazioni finanziarie, sono di fatto esposti nel momento stesso in cui vengono raccolti.

Il governo federale degli Stati Uniti ha reagito di conseguenza: nel giugno 2026, la Casa Bianca ha emanato l’Ordine Esecutivo 14412, “Securing the Nation Against Advanced Cryptographic Attacks” (Proteggere la nazione dagli attacchi crittografici avanzati), che fissa scadenze ben prima dell’obiettivo originale del NIST fissato al 2035: i sistemi federali di alto valore devono adottare la generazione di chiavi post-quantistiche entro la fine del 2030 e le firme digitali post-quantistiche entro la fine del 2031.

Nonostante questa urgenza, i progressi effettivi verso la «cripto-agilità» a livello aziendale sono stati lenti. Il rapporto «DigiCert Quantum Readiness Outlook» ha rilevato che più della metà delle organizzazioni intervistate prevede che la crittografia asimmetrica classica venga violata entro cinque anni, eppure solo il 7% ha implementato una crittografia quantistica o ibrida nel proprio parco certificati, e il livello complessivo di Readiness è migliorato di soli 2 punti percentuali nell’ultimo anno.

Perché la “crypto-agility” è importante?

Il ponte più pratico tra la crittografia classica e quella post-quantistica è il certificato composito ibrido, che combina un algoritmo classico (RSA o ECC) con un algoritmo post-quantistico (ML-DSA, lo schema di firma standardizzato basato su reticoli) all’interno di un unico certificato X.509. La combinazione di entrambi in un unico certificato è concepita in modo che il certificato rimanga valido finché uno dei due algoritmi lo sarà, il che è essenziale, poiché gli algoritmi post-quantistici sono nuovi e non hanno ancora superato innumerevoli tentativi di attacco come ha fatto l’RSA.

Tuttavia, le chiavi e le firme post-quantistiche occupano diversi kilobyte anziché poche centinaia di byte, il che aumenta la latenza di rete, comporta il rischio di frammentazione dei pacchetti durante l’handshake TLS e aggiunge un sovraccarico computazionale che potrebbe richiedere aggiornamenti hardware per i dispositivi con risorse limitate. È proprio per questo che la “cripto-agilità” è fondamentale: le organizzazioni devono poter testare, implementare e ruotare gli algoritmi senza dover riconfigurare l’infrastruttura sottostante ogni volta che gli standard si evolvono.

Gestione automatizzata del ciclo di vita dei certificati

La gestione manuale dei certificati non è solo inefficiente; è un vero e proprio rischio operativo. Quando i certificati vengono gestiti in fogli di calcolo fuori dalla vista, le organizzazioni perdono visibilità e il risultato sono credenziali scadute, chiavi di dimensioni insufficienti, algoritmi di firma obsoleti e configurazioni non conformi che nessuno nota finché qualcosa non va storto. Le interruzioni che ne derivano possono confondere gli utenti, interrompere i ricavi e ricadere sul team meno preparato a spiegarle.

Una piattaforma CLM completa affronta questo problema durante l’intero ciclo di vita di un certificato:

• Individuazione: scansione continua di ambienti cloud, data center, container e domini esterni per individuare tutti i certificati in uso.
• Monitoraggio: tracciamento in tempo reale di date di scadenza, algoritmi, livelli di sicurezza delle chiavi e conformità alle politiche di sicurezza.
• Convalida: utilizzo dell’integrazione diretta tramite API con CA pubbliche e private, automatizzando al contempo la convalida dei domini e le approvazioni
• Installazione: distribuzione dei certificati e delle chiavi rinnovati a livello di programmazione tramite ACME o API sicure, senza passaggi manuali.
• Revoca: è necessario eseguire una revoca rapida e basata su criteri, in modo che un certificato compromesso possa essere sostituito o revocato ovunque contemporaneamente, anziché doverlo individuare macchina per macchina.

C’è anche un vantaggio nascosto nella fase di individuazione: l’inventario dei certificati gestito da una piattaforma CLM costituisce, di fatto, l’inizio dell’inventario crittografico necessario per la pianificazione della migrazione post-quantistica, il che può trasformare un compito di conformità in un vantaggio competitivo.

Identità non umane e IA agentica

Il problema della scala è aggravato dal modo in cui sono costruite le applicazioni moderne. Container, pod Kubernetes, macchine virtuali, dispositivi dell’Internet delle cose (IoT) e API necessitano tutti di credenziali proprie, e molti di questi carichi di lavoro esistono solo per pochi minuti o ore prima di terminare. Nessun team di esseri umani può emettere e ritirare certificati a quella velocità.

Per stare al passo con questo ritmo vertiginoso, è possibile utilizzare agenti di IA in grado di individuare, emettere, rinnovare e gestire i certificati in autonomia, pur rimanendo entro i limiti prestabiliti quali le politiche di sicurezza, il controllo degli accessi basato sui ruoli (RBAC) e le tracce di audit centralizzate. Il risultato è un’automazione alla velocità delle macchine senza rinunciare alla governance aziendale.

Da dove iniziare

1. Il primo passo verso la «crypto-agilità» e la resilienza a livello aziendale è di natura organizzativa piuttosto che tecnica. Seguendo le linee guida del NIST, le aziende dovrebbero istituire un team centrale dedicato ai servizi di identità delle macchine che gestisca la piattaforma CLM, standardizzi i modelli di certificato e mantenga le integrazioni con le CA pubbliche e private. I singoli responsabili delle applicazioni e i team DevOps, a loro volta, dovrebbero occuparsi di integrare i rinnovi automatizzati nelle proprie pipeline di distribuzione, utilizzando la piattaforma centrale come servizio condiviso. Questa suddivisione mantiene coerente la governance, eliminando al contempo i passaggi di mano manuali che causano interruzioni del servizio.
2. Le organizzazioni dovrebbero sostituire fin da ora le tecniche e i flussi di lavoro di convalida manuali con ACME e la convalida automatizzata DNS-01, ben prima che scada il periodo di 10 giorni previsto per la DCV, eliminando progressivamente ogni processo manuale di rinnovo e convalida.
3. 1. 1. Parallelamente, le organizzazioni dovrebbero condurre un inventario completo delle proprie risorse crittografiche per individuare chiavi hardcoded, algoritmi legacy e percorsi di fiducia di lunga durata che proteggono i dati sensibili.
      2. La preparazione post-quantistica dovrebbe iniziare in un ambiente controllato piuttosto che in produzione. È necessario istituire un laboratorio di test dedicato per consentire ai team di testare certificati compositi ibridi e aggiornamenti “crypto-agili” in un ambiente sandbox. Sviluppando applicazioni su librerie crittografiche modulari collegate a una piattaforma CLM dinamica, le imprese possono ottenere una vera “crypto-agilità”: la capacità di ruotare chiavi, cifrari e algoritmi all’interno della propria infrastruttura man mano che gli standard cambiano, senza necessità di ricostruire il sistema.

Il filo conduttore che collega tutte le raccomandazioni è l’inventario. La fase di individuazione di una piattaforma CLM non è un’attività di routine prima della vera soluzione; è la stessa disciplina di cui le organizzazioni avranno bisogno in ogni livello della Readiness quantistica. I certificati sono identità non umane, e le stesse domande valgono per gli account di servizio, gli agenti di intelligenza artificiale, le dipendenze open source e gli algoritmi nascosti nel codice delle applicazioni: cosa abbiamo, cosa protegge e quale parte è più importante per l’azienda?

Le organizzazioni che rafforzano ora la propria capacità di inventario, a partire dai certificati, troveranno il resto della transizione molto meno scoraggiante, perché la definizione delle priorità diventa un calcolo piuttosto che una supposizione. Considerare i prossimi anni come una finestra di pianificazione piuttosto che come un periodo di grazia aiuterà le organizzazioni a compiere questa transizione secondo i propri tempi, invece di lasciare che sia un’interruzione a decidere per loro.

Caitlin Dodson è stagista per l’estate 2026 presso FCTO – Americas di Commvault.

Punti di forza

• Sostituire le affermazioni soggettive sulla “facilità d’uso” con un indice misurabile di protezione dei dati: capacità protetta divisa per il numero di amministratori a tempo pieno.
• La misurazione della capacità protetta per FTE offre una visione più significativa dell’efficienza operativa rispetto alle metriche tradizionali, come i processi di backup per amministratore.
• L’indice di protezione dei dati dovrebbe essere utilizzato come valore di riferimento prima della migrazione della piattaforma e misurato nuovamente in seguito per verificare i miglioramenti operativi.
• Fattori quali gli ambienti multi-cloud, i requisiti di cyber-Recovery e gli obblighi di conformità possono influenzare il rapporto, pertanto esso dovrebbe essere valutato nel contesto di ciascun ambiente.
• Le organizzazioni dovrebbero chiedere ai fornitori di impegnarsi a garantire risultati operativi misurabili, anziché affidarsi a affermazioni qualitative sulla semplicità.

Ogni valutazione di fornitori a cui ho partecipato finisce per arrivare allo stesso vicolo cieco. Da una parte si sostiene che la piattaforma sia semplice da gestire. Dall’altra si afferma che la propria piattaforma sia ancora più semplice.

Nessuno è in grado di dimostrare nessuna delle due affermazioni, quindi la conversazione si sposta sulla demo, sulla chiamata di riferimento, sull’impressione istintiva che si percepisce nella stanza. Non è così che si dovrebbe prendere una decisione che determinerà come il proprio team trascorrerà i prossimi cinque anni.

Ho gestito ambienti di protezione dei dati in produzione. Ho visto team sommersi da strumenti frammentati che promettevano automazione e invece generavano solo ticket.

La “riduzione della complessità” non è una sensazione che dovreste accettare per fede. È qualcosa che dovreste essere in grado di calcolare.

La metrica che mancava al settore

Abbiamo iniziato a utilizzare internamente e con i clienti un semplice rapporto: la capacità totale protetta divisa per il numero di dipendenti a tempo pieno necessari per gestirla. Lo chiamiamo «rapporto di leva della protezione dei dati».

Capacità protetta (PB) / FTE = Rapporto di leva della protezione dei dati

Tutto qui. Nessuna domanda di sondaggio sulla soddisfazione. Nessun aggettivo. Un numero, calcolato dai dati che già possedete.

Ecco perché è più importante delle metriche che sostituisce. Calcolare il numero di processi di backup per persona aveva senso un decennio fa, quando un processo rappresentava un’unità discreta di lavoro manuale. Non riflette il modo in cui operano oggi le piattaforme moderne, dove l’automazione si fa carico del lavoro di routine e un singolo amministratore può essere responsabile di petabyte, non del numero di processi.
Misurare i processi per persona in un ambiente automatizzato non dice nulla sul fatto che l’automazione funzioni effettivamente.

Come funziona nella pratica

Una precisazione prima di passare ai numeri, perché spesso crea confusione. Per “capacità protetta” si intende la dimensione totale, non compressa e non deduplicata, delle applicazioni protette, non lo spazio fisico occupato sul disco.

Questa distinzione è importante perché è il punto centrale. L’ambiente di produzione di Commvault protegge 42,39 PB di dati applicativi su 9,26 PB di disco fisico, con un risparmio di spazio dell’81,91% grazie alla deduplicazione e alla compressione.

Il rapporto non è solo una misura di quanti petabyte una persona può gestire. È una misura di quanto l’architettura stia svolgendo il lavoro prima ancora che il numero di dipendenti entri in gioco.

Tenendo presente questo: Commvault gestisce il proprio ambiente di backup di produzione su 42,39 PB di capacità protetta con due FTE. Si tratta di un rapporto di 21,20 PB per FTE. I benchmark di settore per le piattaforme moderne si attestano in genere tra i 5 e i 25 PB per FTE, a seconda della complessità dell’ambiente, quindi tale cifra si colloca nella fascia alta di ciò che è oggi realizzabile.

Rapporto di efficienza della protezione dei dati = 42,39 PB / 2 FTE = 21,20 PB per FTE

Voglio essere chiaro su ciò che questo numero non tiene in considerazione. Non tiene conto di un’infrastruttura multi-cloud, dei requisiti di cyber-Recovery o di un mix di applicazioni con elevati requisiti di conformità, tutti fattori che abbasserebbero il rapporto per ragioni che non hanno nulla a che vedere con la qualità della piattaforma.

Un rapporto considerato isolatamente non è un verdetto. Lo è invece un rapporto misurato prima e dopo una migrazione.

Questo è il caso d’uso reale. Stabilite una linea di base del vostro ambiente attuale con gli strumenti di cui disponete. Fissate un rapporto obiettivo in base alle vostre proiezioni di crescita e alla capacità del vostro team. Quindi esigete che il vostro fornitore lo rispetti una volta completata l’implementazione, non solo durante il ciclo di vendita.

Le implicazioni a livello di consiglio di amministrazione

Se siete voi a dare l’approvazione per la migrazione a una nuova piattaforma, non vi viene semplicemente chiesto di fidarvi che la nuova piattaforma sia più facile da gestire. Vi viene chiesto di finanziare un risultato operativo specifico. Un obiettivo relativo al rapporto di protezione dei dati vi offre un modo per inserire tale risultato nel business case e verificarlo 12 mesi dopo.

Si tratta della stessa disciplina che applichiamo al tempo medio di recupero pulito (MTCR). La capacità di recupero non è qualcosa che si dichiara, ma qualcosa che si misura e si rimisura finché il dato non riflette la realtà. L’efficienza operativa merita lo stesso standard.

La sfida

Chiedete al vostro attuale fornitore qual è oggi il rapporto di efficienza del vostro ambiente. Se non è in grado di fornirvelo, questo vi dice qualcosa su quanto bene comprenda cosa significhi “semplice da gestire” per il vostro team.

E se state valutando una nuova piattaforma, non accettate “più facile da usare” come risposta. Chiedete a quale rapporto si impegneranno a raggiungere e chiedetelo di nuovo dopo il primo anno.

Domande frequenti

D: Che cos’è il rapporto di gestione della protezione dei dati?

R: Il rapporto di protezione dei dati misura la quantità di capacità di dati protetti gestita da ciascun amministratore a tempo pieno. Fornisce un modo oggettivo per valutare l’efficienza operativa, anziché affidarsi a impressioni soggettive sull’usabilità della piattaforma.

D: Perché questa metrica è più utile rispetto al numero di processi di backup per amministratore?

R: Le moderne piattaforme di protezione dei dati automatizzano gran parte del lavoro di routine che in precedenza richiedeva un intervento manuale. Di conseguenza, il conteggio dei processi di backup non riflette più il reale carico di lavoro né l’efficienza di un team operativo.

D: Cosa si intende per “capacità protetta” in questo calcolo?

R: Per “capacità protetta” si intende la dimensione completa, non compressa e non deduplicata dei dati delle applicazioni protetti. Questa misura riflette il carico di lavoro effettivo gestito dalla piattaforma, anziché lo spazio di archiviazione fisico consumato dopo l’ottimizzazione.

D: Un rapporto di gearing più elevato indica sempre una piattaforma migliore?

R: Non necessariamente. La complessità dell’ambiente, comprese le implementazioni multi-cloud, i requisiti di resilienza informatica e gli obblighi normativi, può ridurre il rapporto anche quando la piattaforma offre buone prestazioni. La metrica è particolarmente utile quando si confronta lo stesso ambiente prima e dopo una migrazione.

D: In che modo le organizzazioni dovrebbero utilizzare il rapporto di gearing della protezione dei dati durante la valutazione dei fornitori?

R: Le organizzazioni dovrebbero stabilire una linea di base utilizzando il proprio ambiente attuale, definire un rapporto target in linea con la crescita futura e chiedere ai fornitori di impegnarsi a ottenere miglioramenti misurabili dopo l’implementazione. Questo approccio sposta il focus dalle affermazioni di marketing a risultati aziendali verificabili.

D: Qual è il valore aziendale più ampio di questa metrica?

R: Il rapporto di protezione dei dati consente ai dirigenti di quantificare i guadagni attesi in termini di efficienza operativa e di includerli nel business case relativo a un investimento in una piattaforma. Fornisce inoltre un punto di riferimento che può essere rivisto dopo l’implementazione per confermare che i risultati promessi siano stati raggiunti.

Rajiv Kottomtharayil è Chief Products Officer presso Commvault.