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

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 confiabilidade. Uma recuperação rápida não faz sentido se as ameaças persistirem. 

Isso exige a verificação dos backups,a busca por ameaças ocultas e a validação das cargas de trabalho restauradas — algo muito mais complexo do que uma simples transição para o sistema de reserva. 

Os invasores corrompem cada vez mais os backups e ocultam seus mecanismos de persistência, tornando a identificação de dados intactos a etapa mais demorada da Recovery. 

Isso oferece aos líderes um indicador realista da qualidade do Recovery, permitindo investimentos e preparativos mais bem direcionados. 

Assista ao vídeoaquipara ver a transcrição com marcação de tempo

Sejam 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 técnico de campo da
A Commvault, que trabalha em estreita colaboração com organizações de diversos setores no desenvolvimento de estratégias de resiliência

estratégias, e Duncan Bradley, líder da área de segurança e resiliência para o Reino Unido e a Irlanda na Kyndryl
. Eles são os autores do artigo original 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.

Utilizamos siglas como RTO e RPO: RTO, meta de tempo de recuperação, e RPO, meta 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 a
ao sucesso do Recovery.

Se os dados recuperados não estiverem limpos e não forem confiáveis, você corre o risco de transformar sua Recovery em
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
em relação ao risco empresarial.

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 fazer parte da

sala de reuniões.

Vamos tentar isso.

Ah, obrigado, Danielle.

E obrigado pela ótima introdução.

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

E pudemos ver em primeira mão o quanto tem sido difícil para esses varejistas manterem contato
com seus clientes e, principalmente, 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.

Isso é só para dar uma ideia do tempo que essa empresa levou
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
incidente, pelo menos para 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 etapas, uma espécie de abordagem gradual para reintroduzir os sistemas.

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

Bem, grande parte desse tempo foi dedicada a tentar encontrar os dados corretos, os dados limpos.

Sistemas confiáveis nos quais a empresa pudesse se apoiar para voltar a interagir com seus
conquistar clientes e gerar receita como varejista.

É 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 possa 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 novamente em operação.

Sabe, tudo bem, isso é fascinante.

Você nos deu muito material para 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, neste
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
negócios que a empresa pudesse compreender.

Trata-se de quanto tempo leva para a empresa voltar 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 on-line
, 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.

Em seguida, é preciso colocar suas plataformas de volta em operação e, então, recuperar os dados
limpos para elas.

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

Portanto, é preciso examinar seus backups e restaurar esses dados limpos no ambiente de produção.

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

Por quanto tempo você pode ficar fora do ar?

Por quanto tempo o serviço 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
meio 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 em funcionamento?

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 realizar o failover do data center A para o data center B e, nesse
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 novamente em funcionamento.

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

Basta medir o tempo que leva para recuperar um banco de dados

isso não significa que aquele processo de negócios volte a funcionar.

E ele foi realmente projetado para abranger esses diferentes pilares dos sistemas que você
é preciso colocá-lo 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 demora tanto em muitos casos, como foi o que aconteceu 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, composta pelas pessoas responsáveis
por Backup and Recovery; obviamente, elas têm um papel a desempenhar, mas não são mais as únicas responsáveis.

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

Uma equipe capaz de identificar, por meio de análises forenses, por exemplo, onde está o backup intacto, onde estão os
com os dados intactos, qual é o grau de infecção dos sistemas — essa é a função da 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 me recuperar?

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

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

Agora temos o MTCR.

Então, o C é importante.

A integridade desses dados é realmente, realmente fundamental.

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 é
É realmente difícil 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
critérios pelos quais as equipes de TI e segurança se avaliam e transformam isso em

algo que pode ser discutido com CEOs e conselhos de administração.

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

Explicar o que aconteceu e como está indo o, hum, processo de Recovery?

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

agrupamento

dos 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 feitas.

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 de 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

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

Então, essa é a primeira conversa.

A segunda questão é, 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 rapidamente todo o investimento no negócio.

Então, o que realmente importa nessa história?

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 compreender os processos de negócios e discutir:
Se voltássemos ao papel, como seria isso?

Mas essa conversa precisa acontecer.

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

Ou seja, o que era necessário naquela época — ou seja, 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 agora vou passar a palavra ao Duncan, que pode nos explicar o que é um serviço.

Como refletimos sobre isso no contexto dos serviços?

E obrigado, Darren.

E, mais uma vez, sem tentar complicar demais nem aprofundar demais.

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

um serviço essencial para os negócios que, por sua vez, contribui para que a empresa se torne minimamente viável como um todo.

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

Ainda hoje, eu estava conversando com uma empresa do setor de bens de consumo, uma cervejaria, e
Eles comentaram que, se perdermos os dados referentes a quatro dias, teremos que literalmente jogar fora

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 esses processos de negócios e, em seguida, utilizar esse
O MTCR como uma linguagem comum de negócios para que possamos dizer: “Certo, dentro do meu processo, preciso”

Bem, esse processo depende de vários tipos diferentes de aplicativos.

Todos eles dependem de serviços essenciais, como a identificação e a capacidade dos
que os clientes façam login na plataforma.

Você tem, então, seus sistemas de back-end, sejam eles 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 dos 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 empresarial funcione.

O MTCR foi projetado para que o proprietário da empresa assuma a responsabilidade por ele.

O primeiro passo nessa jornada é, portanto, fazer uma análise comparativa.

Qual é o MTCR atual deles?

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

Porque o mais chocante no momento é que a maioria das organizações não possui
tecnologia que lhes permita proteger seus backups e conseguir analisá-los

seus backups para extrair dados limpos, e esse é o verdadeiro problema empresarial que viemos
resolvi.

É muito interessante.

Você perguntou: qual é o MTCR atual?

Portanto, o MTCR não é uma medição realizada no final para avaliar o grau de recuperação dos dados.

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

E isso provavelmente acontece porque

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

Você poderia falar um pouco mais sobre isso?

Sim, com certeza posso falar sobre isso.

Antes disso, porém, você levantou uma questão realmente interessante aqui,
que, na minha opinião, precisa ser aprofundado.

Portanto, o MTCR não é apenas algo que se avalia durante a Recovery após um ataque.

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

É o que eu chamo de “antes do estrondo”.

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

Surge então a pergunta: o que é o MTCR, por exemplo, para nossa empresa minimamente viável?

Vamos receber algumas respostas que não queremos ouvir, como, por exemplo, que não sabemos o que é uma empresa minimamente viável
.

Ou, mesmo que saibamos, realisticamente, que 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 é fundamental que a empresa entenda qual
É o seu MTCR hoje, pois isso, portanto, orienta adequadamente seu processo de gestão de riscos de negócios.

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

por um certo período de tempo, ela pode adotar um plano alternativo de continuidade de negócios,
voltar ao papel… sabe, talvez seja o pior cenário, Darren, mas, veja bem, no momento,

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

E esse MTCR tem como objetivo garantir que o conselho de administração tenha a capacidade de se dirigir ao CISO e às equipes
falar com o CISO e perguntar: “Quanto tempo, realisticamente, o sistema ficará fora do ar hoje?”

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

28, 35 e 42 dias são comuns.

A empresa fica, então, totalmente horrorizada com a ideia de ficar sem serviços de TI durante todo esse
tempo.

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

Como você pode projetar esses processos de negócios para que possam ser restaurados em 24 horas?

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

TI, CISO, vocês poderiam 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 sequer pode ser feita a uma ou a qualquer uma dessas

equipes.

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

estejam presentes 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, é muuuito importante antes mesmo de chegarmos perto
da tecnologia.

Do ponto de vista cultural, o que estamos tentando fazer aqui com esse conceito é promover um
um comportamento que ainda não existe hoje.

Isso mesmo.

Você está tentando acabar com os silos.

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

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

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

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 estão realmente passando por isso em termos de Recovery e riscos 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 o DORA e o 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 vai minha reflexão inicial sobre isso: sabe, Danielle, você e eu já analisamos
Analisamos esses artigos da DORA várias vezes juntos 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

É a 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, embora estejam em evolução, ainda fazem referência a questões como a recuperação após desastres.

Elas ainda não são muito claras sobre o que deve ser testado.

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

E, até certo ponto, sabe, esse conceito é importante, na medida em 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 nos limitarmos a medir as antigas métricas de Recovery, não vamos avançar
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 vamos conseguir encontrar nosso backup limpo, e vamos levar 30, 40, 50, 60

dias para nos recuperarmos.

Portanto, precisamos mudar a mentalidade por aqui.

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
abordar esses assuntos da maneira correta e com as estruturas e os contextos adequados.

É, concordo totalmente, Darren.

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

fracassar, pois o requisito estabelece que você precisa provar que é capaz de se recuperar dentro dos limites da sua tolerância ao impacto
nos negócios.

E a maioria das organizações está limitada a esse nível de tolerância ao impacto nos negócios

com base em métricas de disponibilidade ou no antigo plano de recuperação de desastres (DR), que afirma que é possível realizar 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, de certa forma, ressalta 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, assim, conseguir
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 fiz essa pergunta — 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 um plano de recuperação cibernética de forma completa.

E, sem dúvida, esse MTCR precisa ser uma das principais métricas 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, ele 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…
sem falar que muitos…

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

Portanto, não se trata apenas das equipes técnicas, mas também das equipes de gestão
dos profissionais de gestão de riscos corporativos e dos advogados responsáveis pelos contratos, para que compreendam que o RTO e o RPO não são suficientes, mas

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

E todo mundo precisa entender qual deve ser o resultado final, 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 formos avançando com o conceito e realizando workshops sobre
uma postura de risco preferencial, em todas as empresas viáveis e no âmbito do MTCR, espero que

descobriremos que, talvez, muito mais pessoas do que aquelas
que tradicionalmente são associadas à 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 darem uma olhada no relatório completo.

O título é “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 o Duncan e o Darren: vocês abordaram muitos
assuntos de hoje.

Vocês basearam a discussão em um caso real de uma empresa de verdade, o que faz todo o 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 implementar 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 marcar 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, caso soframos 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 restaurar, juntos, as
operações da empresa e me garantir que os dados que estou prestes a começar a usar para administrar o

Os registros da empresa estão em dia?

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

Isso exigirá a colaboração entre essas equipes.

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

E acho que diria algo muito parecido, só 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
A terceirização, em geral, não aborda essa questão da Recovery cibernética.

Quando poderei recuperar dados em bom estado durante a Recovery?

Porque, na maioria desses tipos de contrato, é o cliente quem é 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 sem corrupção
.

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

Darren, simplesmente não há como e eles nunca serão capazes de recuperar todos os sistemas da
empresa em um período muito curto de tempo.

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 desenvolvê-lo em workshops.

E tenho plena certeza de que começaremos a ver isso se espalhar pelo mundo inteiro à medida que formos ajudando
nossas empresas a definir o MVC para cada uma delas.

Muito obrigada pelo tempo que vocês dedicaram hoje.

Obrigado, Danielle.