Apresentando o MTCR: a métrica que faltava para a Recovery cibernética

O MTCR mede o tempo necessário para restaurar sistemas e dados de forma limpa — livres de malware, corrupção ou persistência — após um ataque cibernético. 

O RTO e o RPO medem o tempo e a perda de dados. O MTCR mede a confiança. Uma recuperação rápida não faz sentido se as ameaças permanecerem. 

Ela exige a verificação de backups, a varredura em busca de ameaças ocultas e a validação das cargas de trabalho restauradas — um processo muito mais complexo do que um simples failover. 

Os invasores corrompem cada vez mais os backups e ocultam sua persistência, tornando a identificação de dados limpos a fase mais demorada da Recovery. 

Ele oferece aos líderes uma métrica realista para a qualidade da Recovery, permitindo investimentos e preparativos mais inteligentes. 

Assista ao vídeo aqui para ver a transcrição com marcação de tempo

Bem-vindos à nossa discussão sobre uma nova maneira de pensar sobre resiliência cibernética: o Tempo Médio para Recuperação Completa
(MTCR).

Estou aqui com dois especialistas que criaram esse conceito de MTCR: Darren Thomson, diretor de tecnologia de campo da
Commvault, que trabalha em estreita colaboração com organizações de diversos setores em estratégias de resiliência e

estratégias, e Duncan Bradley, líder da prática de segurança e resiliência para o Reino Unido e a Irlanda (UKI) na Kyndryl
. Eles são os autores do artigo original de liderança intelectual sobre o MTCR. E

há anos, as organizações vêm avaliando o sucesso da Recovery com base na rapidez com que os sistemas podem ser
restaurados.

Usamos siglas como RTO e RPO: RTO, objetivo de tempo de recuperação; RPO, objetivo de ponto
de recuperação.

Mas, no cenário atual de ameaças, sabemos que a velocidade por si só não significa segurança e não equivale
ao sucesso da Recovery.

Se os dados recuperados não estiverem limpos e não forem confiáveis, você corre o risco de transformar sua Recovery na
continuação de outro ataque.

Olá.

Sou Danielle Sheer, Diretora de Confiança da Commvault.

E dedico grande parte do meu tempo ajudando conselhos administrativos e executivos a compreender como o risco cibernético se relaciona
com o risco de negócios.

Estou muito animada para conduzir a discussão de hoje e explicar por que esse novo conceito, o MTCR,
não é apenas mais uma métrica técnica, mas o padrão empresarial que agora deve estar presente na

sala de reuniões.

Vamos tentar isso.

É, obrigado, Danielle.

E obrigada pela ótima introdução.

Justamente neste ano de 2025, no Reino Unido em particular, mas, na verdade, em todo o mundo,
especialmente na Europa, testemunhamos alguns ataques direcionados ao varejo.

E vimos em primeira mão o quanto tem sido difícil para esses varejistas manterem o envolvimento
com seus clientes e, mais importante ainda, recuperarem seus sistemas.

Este ano, eu me envolvi pessoalmente em um ataque específico que começou por volta de meados de
abril de 2025.

E só para dar uma ideia do tempo que levou para essa empresa
se recuperar.

No mês de abril, ocorreu basicamente um ataque de ransomware.

E, durante esse período, a empresa fez um ótimo trabalho, se não em impedir o
evento, pelo menos em isolá-lo e impedir sua propagação.

No mês de maio, eles passaram a tentar confirmar a natureza e o escopo — o que chamo de
“alcance” do ataque.

E começaram a divulgar informações.

E então, de maio até o início de agosto, ocorreu a Recovery efetiva dos sistemas.

Ou seja, ao longo de quase três meses, até agosto, houve apenas
um ataque em fases, uma espécie de abordagem gradual para reintroduzir os sistemas.

Então, por que todo esse tempo — três meses, basicamente — para colocar a empresa de volta
em operação?

Bem, grande parte desse tempo foi gasta tentando encontrar os dados corretos, os dados limpos.

Os sistemas confiáveis nos quais a empresa pudesse se basear para voltar a interagir com seus
clientes e gerar receitas como varejista.

E exatamente isso, esse período de três meses, é um exemplo do que queremos discutir
aqui.

A empresa precisa começar a fazer um conjunto diferente de perguntas à equipe
de TI para chegar a um ponto em que não apenas se possam fazer promessas sobre a rapidez com que

restaurar os sistemas,

mas também se possa começar a fazer promessas sobre o quão limpos esses sistemas estarão, o quão limpa
será essa infraestrutura.

Caso contrário, temo que continuemos a ver, sabe, normalmente dois, três,
às vezes até quatro ou cinco meses para colocar os sistemas de volta em operação.

Sabe, tudo bem, isso é fascinante.

Você nos deu muito com que trabalhar.

Duncan, deixe-me agora voltar ao início.

Você poderia nos dar a definição do MTCR?

Explique-nos os cinco pilares e por que esse é o caminho certo para nós, nesse
cenário — esse cenário de ameaças —, para avaliar o sucesso da Recovery.

Sim, claro, Danielle.

Então, acho que isso é realmente importante.

Criamos o conceito de “Mean Time to Clean Recovery” (Tempo Médio para Recuperação Completa) para que fosse realmente uma métrica
de negócios que a empresa pudesse entender.

Trata-se de quanto tempo leva para que a empresa volte a operar, como o Darren estava dizendo.

Com dados limpos, com sistemas que possam operar e retomar a produção.

A maioria das organizações tem se concentrado principalmente na disponibilidade de seus sistemas online
, sem compreender que esses ataques cibernéticos comprometem os dados e as plataformas

que dão suporte a essas operações.

Portanto, quando se trata de um evento de Recovery cibernética, trata-se mais de ter que restabelecer
, desde o primeiro dia, até o ponto de Recovery,

um ambiente limpo.

Isso geralmente leva dias, como Darren mencionou no exemplo do varejo.

Em seguida, é preciso reconstruir todos os seus serviços básicos.

Depois, é preciso colocar suas plataformas de volta no ar e, então, recuperar dados
limpos para elas.

E, com bastante frequência, nos tipos de ataques que estamos vendo, os dados ficam contaminados por
dias, se não semanas, antes do ataque.

Portanto, é preciso examinar seus backups e trazer esses dados limpos de volta à produção.

Esse MTCR, ou Tempo Médio para Recovery Limpa, serve como um indicador de negócios para responder:

Por quanto tempo você pode ficar fora do ar?

Por quanto tempo você ficaria fora do ar hoje se o incidente ocorresse?

E isso é usado para desafiar as equipes de TI e de continuidade de negócios a reduzir esse tempo
médio de Recovery.

Então, em que o MTCR difere das métricas tradicionais?

Parece que ele reúne muitas das métricas tradicionais em uma única métrica mais abrangente.

Bem, acho que é aí que entram as metas de tempo de Recovery.

Quanto tempo leva para colocar esse sistema de volta no ar?

Isso não leva em conta que tipo de dados estarão nessa plataforma.

Sabe, normalmente eles usam a disponibilidade como referência.

Quanto tempo leva para eu fazer o failover do data center A para o data center B e lidar com esse
tipo de ataque tradicional à infraestrutura?

Recuperar os dados é uma tarefa muito mais complicada.

Não se trata apenas de recuperar um conjunto de dados.

Trata-se de colocar a plataforma de volta no ar.

Então, se você pensar em serviços de identidade, é preciso que a identidade esteja funcionando antes que alguém possa
acessar os dados.

Apenas medir a rapidez necessária para recuperar um banco de dados

não significa que aquele processo de negócios estará de volta ao ar.

E ele foi realmente projetado para abranger esses diferentes pilares dos sistemas que você
precisa colocar em operação para que o processo de negócios volte a funcionar.

E, Danielle, se me permite, acho que isso aponta para um problema maior.

Então, é muito fácil, hum, seguir a linha técnica nessa conversa.

E, de fato, isso representa, de muitas maneiras, uma forma de avaliar a organização técnica.

Mas acho que isso aponta para um problema organizacional.

O que vemos o tempo todo é que uma das questões culturais em torno da recuperação
de sistemas — e uma das razões pelas quais isso leva tanto tempo em muitos casos, como foi o caso no meu

exemplo — é que, na verdade, estamos lidando com duas equipes que precisam assumir alguma
responsabilidade aqui.

Existe claramente o tipo tradicional de equipe de infraestrutura, cujos membros são responsáveis
pelo Backup and Recovery; obviamente, eles têm um trabalho a fazer, mas não são mais os únicos.

Há também a equipe de segurança.

Uma equipe que pode informar, por meio de análises forenses, por exemplo, onde está o backup íntegro, onde estão os
dados íntegros, qual é o grau de infecção dos sistemas — essa é a equipe de segurança.

Portanto, quando essas equipes não estão trabalhando juntas na Recovery, ou falam línguas diferentes
, ou se avaliam de maneiras diferentes, começamos a perceber um problema

e isso começa com a cultura.

Então, uma maneira de pensar sobre isso é: se você considerar o RPO e o RPO (objetivo de tempo de recuperação),

Quanto tempo vou levar para recuperar?

Objetivo do ponto de recuperação: de quantos dados provavelmente vou precisar?

E você combina isso com a área de perícia digital, uma disciplina de segurança.

Agora temos o MTCR.

Então, o “C” é importante.

A integridade desses dados é realmente, realmente crítica.

E o ponto de partida aqui, sem dúvida, é que vamos discutir: vamos deixar que a empresa faça
essa pergunta.

Em quanto tempo conseguimos restaurar a integridade dos nossos sistemas?

E o que vemos todos os dias é que essa não é uma pergunta tão difícil de fazer, mas sim
muito difícil de responder, especialmente quando existe essa lacuna cultural entre

equipe de segurança e a de infraestrutura.

Eu realmente acho que essa é a genialidade do MTCR, porque você pega uma série de conceitos muito
técnicos pelos quais as equipes de TI e de segurança se avaliam e transforma isso em

algo que se pode discutir com CEOs e conselhos de administração.

Falando do seu exemplo, Darren, de um varejista no Natal que sofreu um ataque cibernético
: como você usaria o MTCR se estivesse diante de um conselho de administração para

explicar o que aconteceu e como está indo o processo de Recovery?

Bem, vou começar a resposta e passar a palavra para o Duncan para que ele a
conclua, porque há uma parte deste artigo pela qual o Duncan foi o principal responsável, relacionada ao

agrupamento

de ativos que se combinam para formar um serviço.

Mas vou começar dizendo que há algumas discussões que precisam ser feitas e que, muitas
vezes, não estão sendo realizadas.

Uma delas diz respeito à propensão ao risco.

Então, quem somos nós como empresa?

Que tipo de empresa somos?

Um varejista, normalmente, apresenta uma propensão ao risco baixa a média, algo
nessa faixa.

Mas isso precisa ser definido para que, à medida que avançamos e começamos a, hum, compreender os
riscos que nos cercam, possamos decidir o que é aceitável e o que

deve ser coberto pelo nosso seguro, por exemplo, e o que deve ser absolutamente integrado
.

Então, essa é a primeira conversa.

A segunda conversa é, então: qual é a empresa minimamente viável nesse contexto?

É completamente irrealista supor que qualquer organização, independentemente do tamanho do orçamento, será
capaz de recuperar tudo no negócio rapidamente.

Então, o que realmente importa nesse negócio?

Essa é uma conversa muito, muito profunda e interessante para se ter com a maioria das empresas.

A maioria das empresas não consegue imaginar um mundo sem TI.

Por isso, elas têm muita dificuldade em desvendar os processos de negócios e discutir:
se voltássemos ao papel, como seria isso?

Mas essa conversa precisa acontecer.

E ela nos leva ao que chamamos de MVC, uma empresa minimamente viável.

Ou seja, o que era necessário naquela época, seja qual for o período que decidirmos
.

Quais são os elementos sem os quais esse negócio simplesmente não funciona, sem os quais não estamos operando?

E essa é uma discussão muito, muito importante.

O que você pode começar a fazer, então, é aplicar o conceito de MTCR à empresa minimamente viável.

E vou passar a palavra agora para o Duncan, que pode nos explicar o que constitui um serviço.

Como pensamos sobre isso no contexto dos serviços?

E obrigado, Darren.

E, mais uma vez, sem tentar complicar demais nem entrar em detalhes excessivos.

O MTCR é como medir o tempo médio de Recovery de um processo de negócios,

um serviço crítico de negócios que, então, contribui para formar a empresa minimamente viável como um todo.

Portanto, haverá vários MTCRs diferentes para diferentes processos de negócios.

Ainda hoje, literalmente, conversei com uma empresa de bens de consumo, uma cervejaria, e
eles comentaram que, se perdermos o equivalente a quatro dias de dados, teremos que literalmente jogar

quatro dias de cerveja no ralo, pois não podemos comprovar que ela é segura para consumo e
, portanto, não podemos vendê-la.

Portanto, esse conceito envolve analisar minuciosamente esses processos de negócios e, em seguida, usar esse
MTCR como uma linguagem de negócios comum para então poder dizer: “Certo, dentro do meu processo, preciso

que, ah, esse processo depende de diversos tipos de aplicativos.

Todos eles dependem de serviços fundamentais, como identidade e a capacidade dos
clientes de fazer login na plataforma.

Você então tem seus sistemas de back-end, seja na nuvem ou no local, seus hipervisores,
suas soluções críticas de nuvem.

Seus sistemas front-end, que executam os aplicativos propriamente ditos, e, em seguida, seus sistemas
de acesso de usuários — onde, na prática, as pessoas acessam essa solução seja por meio de PDAs, pontos de venda

etc.?

Todos esses elementos precisam estar disponíveis para que esse serviço de negócios funcione.

O MTCR foi projetado para que o proprietário da empresa seja o responsável por ele.

O primeiro passo nessa jornada é, então, fazer uma análise comparativa.

Qual é o MTCR atual deles?

Quanto tempo levaria atualmente, mesmo que conseguissem recuperar dados intactos?

Porque o que é chocante no momento é que a maioria das organizações não possui
tecnologia que lhes permita proteger seus backups e ser capaz de analisar

seus backups para extrair dados limpos, o que é o verdadeiro problema de negócios que viemos
resolver.

É muito interessante.

Você perguntou: qual é o MTCR atual?

Portanto, o MTCR não é uma medição feita no final para avaliar o quão bem recuperamos os dados.

O MTCR é calculado em intervalos ao longo de todo o ataque.

E isso provavelmente se deve ao fato de que

se você se apressar na Recovery, pode acabar causando mais danos.

Você poderia falar um pouco mais sobre isso?

Sim, com certeza posso abordar isso.

Antes disso, porém, você levantou um ponto realmente interessante aqui,
que acho que precisa ser aprofundado.

Portanto, o MTCR não é apenas algo que você mediria durante a Recovery após um ataque.

É algo que você deve medir antes da violação.

É o que eu chamo de “antes da explosão”.

Quando apresentamos esse conceito aos conselhos de administração, começamos a ver isso se espalhar
por toda a organização.

E surge a pergunta: o que é o MTCR, por exemplo, para nossa empresa minimamente viável?

Vamos receber algumas respostas que não queremos ouvir, como: “Não sabemos o que é uma empresa minimamente viável
”.

Ou, mesmo que saibamos, realisticamente, nosso MTCR neste momento provavelmente é de quatro meses.

Não queremos ouvir essas respostas, mas precisamos ouvi-las para que possamos nos concentrar
em melhorar.

E esse é um ponto realmente muito, muito importante, eu acho.

E, Darren, para complementar isso, acho que é vital que a empresa entenda qual
é o seu MTCR hoje, porque isso, então, orienta adequadamente seu processo de gestão de riscos.

E nem sempre será uma solução tecnológica que reduzirá esse MTCR.

Muitas vezes, se a empresa souber que corre o risco de ficar sem um
sistema crítico por

um certo período de tempo, ela pode incorporar um plano alternativo de continuidade de negócios,
voltar ao papel — sabe, talvez seja o pior cenário, Darren, mas, sabe, neste momento,

as empresas não compreendem os riscos que estão cobrindo.

E esse MTCR tem como objetivo ser essa capacidade da diretoria de se dirigir ao CISO e às equipes
do CISO e perguntar: “Quanto tempo, realisticamente, ficará fora do ar hoje?”

E então, se esse for um número aceitável — e já realizei vários estudos desse tipo
, e…

28, 35, 42 dias, com frequência.

A empresa fica então totalmente horrorizada com a ideia de ficar sem serviços de TI por esse
período.

Mas nunca impuseram essas exigências às organizações do CIO ou do CISO, dizendo: “Precisamos que a
empresa funcione no mínimo viável, com esses ativos de volta ao ar em 24 horas”.

Como você pode projetar esses processos de negócios para que sejam recuperáveis em 24 horas?

Isso precisa ser um requisito funcional ou não funcional do negócio para que se diga: “Esses
são nossos requisitos.

TI, CISO, vocês podem me ajudar a atendê-los?

E, voltando ao ponto que mencionei anteriormente, aliás, hum, é realmente importante entender
que, de certa forma, essa pergunta nem mesmo pode ser feita a uma ou a ambas essas

equipes.

A única maneira de obter qualquer tipo de resposta que faça sentido — mesmo que
não seja a resposta que você deseja — é se a equipe de infraestrutura e a equipe de segurança

estejam presentes na sala para respondê-la.

Porque a pergunta simplesmente não pode ser respondida por nenhuma dessas equipes isoladamente.

E isso, mais uma vez, do ponto de vista cultural, é extremamente importante antes mesmo de chegarmos perto
da tecnologia.

Culturalmente, o que estamos tentando fazer aqui com esse conceito é promover um
comportamento que ainda não existe hoje.

Isso mesmo.

Você está tentando quebrar os silos.

Então, cada organização — seja a equipe de TI, de infraestrutura ou de SecOps — pensa: “minha
parte está bem”, mas todas essas partes precisam trabalhar juntas.

E, assim, o MTCR as reúne e as faz refletir sobre esse

conceito de risco no ambiente, já que cada pessoa tem um papel a desempenhar nisso.

E acho que isso é realmente transformador, pois dá a cada um desses
líderes a capacidade de explicar ao CEO ou ao conselho de administração o que

eles realmente estão enfrentando em termos de Recovery e Risk nos negócios, certo?

Com certeza, isso é incrível.

Então, como isso se relaciona com requisitos simples?

Não são tão simples assim, mas requisitos de conformidade como DORA e NIST 2.

Como o MTCR se relaciona com isso, se é que se relaciona?

Bem, vou começar, se estiver tudo bem, Duncan.

Então, aqui está minha reflexão inicial sobre isso: sabe, Danielle, você e eu já revisamos
juntos esses artigos da DORA várias vezes e conversamos sobre conformidade.

Uma das coisas que estamos começando a observar no cenário de conformidade — seja
na DORA, no NIST 2 ou em outras regulamentações globais — é essa menção, em primeiro lugar, ao que é

é resiliência e o que ela significa em contraposição à segurança; e, em segundo lugar, os testes.

Você tem um plano?

Você já testou o plano de Recovery?

Bem, acho que isso se refere diretamente ao que deveria ser a métrica do plano.

Estou um pouco preocupado com o fato de que muitas das regulamentações que vejo, mesmo as mais recentes
e em evolução, ainda fazem referência a conceitos como recuperação de desastres.

Elas ainda não são muito explícitas sobre o que deve ser testado.

Já vi até algumas menções a RPO-RTO.

E, até certo ponto, sabe, esse é um conceito importante, à medida que as pessoas
começam a se adaptar e a adotar esse tipo de conformidade que se baseia fortemente na resiliência

.

em termos do que vamos medir aqui?

Porque, se medirmos apenas as antigas métricas de Recovery, não avançaremos
muito nessa questão.

O que vamos descobrir é que, quando formos atacados, recorreremos ao nosso plano de recuperação de desastres, o executaremos e,
surpresa, surpresa, não conseguiremos encontrar nosso backup válido, e levaremos 30, 40, 50, 60

dias para nos recuperarmos.

Portanto, precisamos mudar essa mentalidade.

E, no que diz respeito à conformidade, foi muito revigorante ver algumas das novas políticas e cronogramas de conformidade

mencionassem resiliência, Recovery e testes, mas precisamos garantir que pensemos sobre
esses assuntos da maneira correta e com os tipos certos de estruturas e contextos.

É, concordo totalmente, Darren.

Pense nisso: se você analisar muitos dos requisitos da DORA e o que o Banco Central Europeu
disse sobre testes de estresse, a maioria das organizações se posicionou de forma a

fracassar, pois é exigido que se comprove a capacidade de recuperação dentro dos limites de tolerância ao impacto
nos negócios.

E a maioria das organizações está limitada a essa tolerância ao impacto nos negócios

com base em métricas de disponibilidade ou no antigo plano de recuperação de desastres que afirma ser possível fazer o failover do data center A para
o data center B em quatro horas.

Não dá para recuperar um banco inteiro ou uma instituição financeira inteira em quatro horas, é
impossível.

Então, eu acho — e isso meio que destaca a necessidade desse novo vocabulário do MTCR —
que elas possam reavaliar essa tolerância ao impacto nos negócios para

redefinir e dizer: se eu perder meu sistema central, por exemplo, meu livro-razão,

sabe, como vou operar?

Bem, não consigo operar.

Portanto, preciso estabelecer planos de contingência sobre como posso executar subprocessos para, então, poder
reverter a situação assim que o livro-razão voltar a ficar online, no exemplo financeiro.

Mas, quanto ao que você mencionou sobre testes, a maioria das organizações, quando faço essa pergunta — do tipo
: “quando foi a última vez que vocês testaram a CR?” —, elas se referem ao seu plano tradicional de DR.

Elas não mencionam seu plano de recuperação cibernética porque a maioria das organizações ainda não

elaborou e implementou totalmente um plano de recuperação cibernética.

E, sem dúvida, esse MTCR precisa ser uma das principais métricas dentro desse plano de Recovery
cibernética.

Você elaborou seus cenários contra os quais vai se proteger e se recuperar.

E então você tem uma métrica MTCR para esses diferentes tipos de ataque.

Na verdade, isso existe para tentar, como eu disse, preencher essa lacuna entre os negócios, a TI e o CISO.

Sabe, Darren, você estava dizendo que se trata de mudar a cultura, e Duncan, você acabou
de mencionar que muitos…

contratos entre, hum, organizações exigem um tempo de recuperação, e isso não faz sentido.

Portanto, não é apenas para as equipes técnicas, mas também para as equipes de gestão
de riscos corporativos e para os advogados responsáveis pelos contratos, para que entendam que RTO e RPO não são suficientes, mas

o novo padrão é a recuperação completa.

E todos precisam entender qual deve ser o resultado final, e não apenas as etapas
ao longo do caminho que

podem não fazer sentido, certo?

Sim, acho que essa é uma observação muito pertinente.

E tenho plena certeza de que, à medida que avançarmos com o conceito e realizarmos workshops sobre
a postura de risco preferencial, sobre todas as empresas viáveis e sobre o MTCR, espero que

descobram que, sabe, talvez muito mais pessoas do que aquelas que tradicionalmente estariam
envolvidas na Recovery precisem se interessar e ter voz nessas

oficinas.

Exatamente pelas razões que você mencionou, Danielle.

Portanto, para os líderes que estão ouvindo,

eu encorajo todos vocês a conferirem o relatório completo.

Chama-se “Redefinindo a Recuperação Cibernética: Apresentando o Tempo Médio de Recuperação (Mean Time to Clean Recovery)”.

E tenho mais uma pergunta para Duncan e Darren: vocês abordaram muitos
assuntos hoje.

Vocês basearam a discussão em um caso real de uma empresa de verdade, o que faz muito sentido.

Para os líderes que estão ouvindo: por onde começamos?

Por onde começamos agora mesmo?

Nós lemos o relatório e queremos introduzir esse conceito em nossas empresas, em nossos
negócios.

Como começamos?

Bem, no meu caso, como líder sem formação técnica, eu recomendaria convocar uma reunião
entre quem for responsável pela infraestrutura na empresa, normalmente um CIO,

e quem for responsável pela segurança cibernética na empresa, normalmente um CISO — embora nem sempre seja assim —
, convoque uma reunião com essas duas pessoas, esses dois líderes, e faça a seguinte pergunta: como

rápido, se sofrêssemos um ataque catastrófico de ransomware — vamos usar o ransomware

como exemplo, já que é muito comum e todos nós estamos sendo afetados por ele.

Então, no caso de uma catástrofe envolvendo ransomware, com que rapidez vocês conseguiriam, juntos, restaurar as
operações da empresa e me garantir que os dados que estou prestes a começar a usar para administrar o

negócio estejam limpos?

Garanto a você que outras cinco reuniões surgirão a partir dessa única reunião, pois a
resposta não é fácil.

Isso exigirá colaboração entre essas equipes.

Isso também exigirá uma mudança de mentalidade.

E eu diria algo muito semelhante, exceto que provavelmente ampliaria esse público
para incluir pessoas como o diretor de riscos e o departamento de compras nessa conversa.

Porque a maioria das organizações, ao analisar se se trata de um contrato de SaaS ou de
terceirização, geralmente não aborda essa questão da Recovery cibernética.

Quando poderei recuperar dados limpos durante a Recovery?

Porque, na maioria desses tipos de contrato, é o cliente que é responsável por
seus dados.

Esses provedores de infraestrutura e esses provedores de SaaS são responsáveis pela infraestrutura
que sustenta o serviço.

Então, sabe, são eles que precisam assumir a responsabilidade de recuperar seus dados limpos
.

Mas eles também precisam comunicar isso rapidamente aos líderes de negócios para tentar
entender de verdade qual é o nosso MVC, porque as organizações, como você disse anteriormente,

Darren, simplesmente não têm como e nunca serão capazes de recuperar todos os sistemas da
empresa em um período muito curto.

O ponto-chave aqui é a priorização, e somente a empresa pode avaliar o que é mais importante
para ela em uma situação de desastre cibernético.

Darren, diretor de tecnologia da Commvault, e Duncan, líder da área de Segurança e Resiliência da Kyndryl.

Muito obrigado.

Próximos passos: espero que vocês coloquem esse conceito de MTCR em prática e ajudem os líderes
empresariais a discuti-lo em workshops.

E tenho plena certeza de que começaremos a ver isso surgir em todo o mundo à medida que ajudarmos
nossas empresas a definir o MVC para cada uma delas.

Muito obrigada pelo tempo de vocês hoje.

Obrigado, Danielle.