Presentamos MTCR: la métrica que faltaba para Cyber Recovery

El MTCR mide el tiempo que se tarda en restaurar los sistemas y los datos de forma limpia —«sin malware, sin daños ni persistencia»— tras un ciberataque. 

Los indicadores RTO y RPO miden el tiempo y la pérdida de datos. El MTCR mide la confianza. Una Recovery rápida no tiene sentido si las amenazas persisten. 

Implica comprobar las copias de seguridad,buscar amenazas ocultas y verificar las cargas de trabajo restauradas, lo cual es mucho más complejo que un simple cambio por error. 

Los atacantes corrompen cada vez más las copias de seguridad y ocultan sus mecanismos de persistencia, lo que hace que la identificación de los datos intactos sea la fase más larga del proceso de Recovery. 

Ofrece a los responsables una medida realista de la calidad de la Recovery, lo que permite realizar inversiones y preparativos más acertados. 

Por favor, mira el vídeoaquípara consultar la transcripción con marcas de tiempo

Bienvenidos a nuestro debate sobre una nueva forma de abordar la ciberresiliencia: el «tiempo medio de
«recuperación completa» (MTCR, por sus siglas en inglés).

Me acompañan dos expertos que crearon este concepto de MTCR: Darren Thomson, director técnico de campo en
Commvault, que colabora estrechamente con organizaciones de diversos sectores en materia de resiliencia y

estrategias, y Duncan Bradley, responsable de seguridad y resiliencia para el Reino Unido e Irlanda en Kyndryl
. Fueron ellos quienes escribieron el artículo pionero sobre el MTCR. Y

, durante años, las organizaciones han medido el éxito de la Recovery en función de la rapidez con la que se
pueden restaurar los sistemas.

Utilizamos acrónimos como RTO y RPO: RTO, «objetivo de tiempo de recuperación», y RPO, «objetivo de punto
«de recuperación».

Pero, en el panorama actual de amenazas, sabemos que la velocidad por sí sola no equivale a seguridad ni a la
El éxito de Recovery.

Si los datos que recuperas no están limpios y no son fiables, corres el riesgo de que tu Recovery se convierta en
la continuación de otro ataque.

Hola.

Soy Danielle Sheer, directora de confianza de Commvault.

Dedico gran parte de mi tiempo a ayudar a los consejos de administración y a los ejecutivos a comprender que el riesgo cibernético va
de la mano del riesgo empresarial.

Me hace mucha ilusión moderar el debate de hoy y explicar por qué este nuevo concepto, el MTCR,
No se trata solo de otra métrica técnica, sino del estándar empresarial que ahora debe tener cabida en la

sala de reuniones.

Vamos a intentarlo.

Sí, gracias, Danielle.

Y gracias por la estupenda introducción.

Precisamente este año 2025, sobre todo en el Reino Unido, aunque en realidad en todo el mundo,
Sobre todo en Europa, hemos sido testigos de varios ataques dirigidos al sector minorista.

Y hemos comprobado de primera mano lo difícil que ha sido para esos comerciantes mantener el contacto
con sus clientes y, lo que es más importante, recuperar sus sistemas.

Este año participé personalmente en un ataque concreto que comenzó a mediados de
abril de 2025.

Y solo para que os hagáis una idea del tiempo que tardó esa empresa
en recuperarse.

En abril se produjo, básicamente, un incidente relacionado con un programa de rescate.

Y durante ese periodo, la empresa hizo un gran trabajo, aunque no bastó para detener el
incidente, al menos para aislarlo y frenar su propagación.

En el mes de mayo, se dispusieron a intentar confirmar la naturaleza y el alcance, lo que yo
denomino el «radio de impacto» del ataque.

Y empezaron a informar al exterior.

Y luego, desde mayo hasta principios de agosto, se llevó a cabo la Recovery efectiva de los sistemas.

En otras palabras, tras casi tres meses, ya bien entrado el mes de agosto, se llevó a cabo
un ataque por fases, una especie de enfoque gradual para volver a poner en marcha los sistemas.

¿Por qué se tardó tanto tiempo —prácticamente tres meses— en volver a
¿Cómo poner en marcha el negocio?

Bueno, gran parte de ese tiempo lo dediqué a intentar encontrar los datos correctos, los datos depurados.

Sistemas limpios en los que la empresa pudiera confiar para volver a interactuar con sus
clientes y generar ingresos como minorista.

Y precisamente eso, ese periodo de tres meses, es lo que queremos comentar
aquí.

La empresa tiene que empezar a plantear una serie diferente de preguntas al departamento
de TI para llegar a un punto en el que no solo se puedan hacer promesas sobre la rapidez con la que

se restaurarán los sistemas,

sino que también se puedan empezar a hacer promesas sobre el grado de limpieza de esos sistemas, sobre lo limpios que son
que van a estar.

De lo contrario, me temo que seguiremos viendo, ya sabes, que suelen hacer falta dos, tres y
, a veces, incluso cuatro o cinco meses para volver a poner en marcha los sistemas.

Ya sabes, vale, eso es fascinante.

Nos has dado mucho en qué pensar.

Duncan, déjame volver ahora al principio.

¿Podrías darnos la definición de MTCR?

Explícanos cuáles son los cinco pilares y por qué esa es la forma adecuada de medir el éxito de la Recovery en este
panorama, en este panorama de amenazas.

Sí, claro, Danielle.

Creo que es realmente importante.

Se nos ocurrió el concepto de «tiempo medio de Recovery» (Mean Time to Clean Recovery) para que fuera realmente una métrica
empresarial que la empresa pudiera entender.

Se trata de cuánto tiempo tardan en volver a estar operativos, como decía Darren.

Con datos limpios y con sistemas que puedan funcionar y reanudar la producción.

La mayoría de las organizaciones se han centrado principalmente en garantizar la disponibilidad de sus sistemas
en línea, sin darse cuenta de que estos ciberataques eliminan los datos y las plataformas

que sustentan dichas operaciones.

Así pues, cuando se produce un incidente de Recovery cibernética, se trata más bien de tener que restablecer
todo, desde el primer día hasta el punto de recuperación,

un entorno limpio.

Esto suele llevar días, como decía Darren en el ejemplo del sector minorista.

A continuación, hay que reconstruir todos los servicios básicos.

A continuación, hay que volver a poner en funcionamiento las plataformas y recuperar los datos
limpios en ellas.

Y, con bastante frecuencia, en el tipo de ataques que estamos viendo, los datos conducen a…
contaminados días, si no semanas, antes del ataque.

Por eso hay que revisar las copias de seguridad y volver a incorporar esos datos limpios al entorno de producción.

Este MTCR (tiempo medio de Recovery limpia) está concebido como un indicador empresarial para determinar:

¿Cuánto tiempo puede estar inactivo?

¿Cuánto tiempo estarías inactivo hoy si se produjera el incidente?

Y esto se utiliza para instar a los departamentos de TI y de control de riesgos a que reduzcan ese tiempo
mediante Recovery.

¿En qué se diferencia el MTCR de las medidas tradicionales?

Parece que es una especie de combinación de muchas de las medidas tradicionales en una única medida más amplia.

Bueno, creo que aquí es donde entran en juego los objetivos de tiempo de Recovery.

¿Cuánto tiempo se tarda en volver a poner en marcha ese sistema?

No tiene en cuenta qué tipo de datos habrá en esa plataforma.

Ya sabes, y normalmente se recurre a la disponibilidad.

¿Cuánto tiempo se tarda en realizar la conmutación por error del centro de datos A al centro de datos B y en hacer frente a esa
¿Un ataque tradicional contra la infraestructura?

Recuperar los datos es una tarea mucho más complicada.

No se trata solo de recuperar un conjunto de datos.

Se trata de volver a poner en funcionamiento la plataforma.

Así que, si pensamos en los servicios de identidad, es necesario que la identidad funcione antes de que nadie pueda
acceder a los datos.

El simple hecho de medir cuánto tiempo se tarda en recuperar una base de datos

No significa que ese proceso empresarial vaya a volver a estar operativo.

Y está realmente diseñado para abarcar esos diferentes pilares de los sistemas que existen
qué hay que poner en marcha para que el proceso empresarial vuelva a funcionar.

Y, Danielle, si me lo permites, creo que esto apunta a un problema más amplio.

Así que es muy fácil, ¿eh?, entrar en detalles técnicos en esta conversación.

Y, de hecho, esto supone, en muchos sentidos, una forma de evaluar la organización técnica.

Pero creo que esto apunta a un problema de organización.

Lo que vemos constantemente es que uno de los problemas culturales relacionados con la recuperación
de sistemas, y una de las razones por las que, en muchos casos, lleva tanto tiempo, como me ocurrió a mí

ejemplo—, es que, en realidad, hay dos equipos que deben asumir cierta
responsabilidad en este asunto.

Está, evidentemente, el equipo de infraestructura tradicional, al que pertenecen las personas encargadas de
Backup and Recovery; está claro que tienen una función que desempeñar, pero ya no son los únicos.

También está el equipo de seguridad.

Un equipo que pueda indicarte, por ejemplo mediante análisis forense, dónde se encuentra la copia de seguridad intacta, dónde están los
datos intactos, en qué estado se encuentran los sistemas infectados; eso es un equipo de seguridad.

Así que, cuando esos equipos no colaboran en Recovery, o hablan idiomas diferentes
, o se evalúan a sí mismos de formas distintas, empezamos a vislumbrar un problema

Y todo empieza por la cultura.

Una forma de planteárselo es si tomamos el RPO y el RPO (objetivo de tiempo de Recovery):

¿Cuánto tiempo tardaré en recuperarme?

El objetivo del punto de recuperación: ¿cuántos datos es probable que utilice?

Y si combinamos eso con el ámbito de la informática forense, una disciplina de seguridad.

Ahora contamos con el MTCR.

Así que esto es… la «C» es importante.

La limpieza de esos datos es realmente, realmente fundamental.

Y el punto de partida aquí, sin duda, es que la propia empresa plantee
esa pregunta.

¿Cuánto tiempo tardaremos en recuperar el buen funcionamiento de nuestros sistemas?

Y lo que vemos cada día es que no es una pregunta tan difícil de plantear, pero sí
Es muy difícil responder a eso, sobre todo cuando existe esa brecha cultural entre

el equipo de seguridad y el de infraestructura.

De verdad creo que ahí radica la genialidad de MTCR, porque se parten de una serie de conceptos muy
técnicos con los que los equipos de TI y de seguridad se evalúan a sí mismos, y se convierten en

algo de lo que se puede hablar con los directores generales y los consejos de administración.

Hablando de tu ejemplo, Darren, sobre un minorista en Navidad que ha sufrido un ciberataque
, ¿cómo utilizarías el MTCR si te encontraras ante un consejo de administración para

¿Podrías explicarme qué ha pasado y cómo va el… eh… proceso de Recovery?

Bueno, yo empezaré a responder y luego le cederé la palabra
a Duncan para que lo termine, porque hay una parte de este documento de la que Duncan fue en gran medida responsable y que tiene que ver precisamente

la agrupación

de activos que se combinan para formar un servicio.

Pero empezaré diciendo que hay un par de debates que es necesario abordar y que, muy
A menudo, no se abordan.

Uno de ellos gira en torno a la propensión al riesgo.

Entonces, ¿quiénes somos como empresa?

¿Qué tipo de empresa somos?

Un minorista suele tener una propensión al riesgo baja o media, además
o algo así.

Pero hay que definirlo para que, a medida que avancemos y empecemos a comprender los
riesgos que nos rodean, podamos decidir qué es aceptable y qué

¿Debería cubrirlo nuestro seguro, por ejemplo, y qué es lo que debe incluir?
sin falta.

Así que esa es la primera conversación.

La segunda pregunta es, pues: ¿cuál es la empresa mínima viable en este caso?

Es totalmente irrealista suponer que cualquier organización, independientemente de su presupuesto, vaya a
ser capaz de recuperar rápidamente todos los aspectos del negocio.

Entonces, ¿qué es lo que realmente importa en este negocio?

Esa es una conversación muy, muy profunda e interesante que hay que mantener con la mayoría de las empresas.

La mayoría de las empresas no pueden imaginar un mundo sin tecnologías de la información.

Por eso les resulta muy difícil desentrañar los procesos de negocio y plantearse:
«Si volviéramos al papel, ¿cómo sería esto?».

Pero esa conversación es, en cierto modo, necesaria.

Y eso nos lleva a lo que llamamos una MVC, una empresa mínimamente viable.

Es decir, qué elementos son imprescindibles en el pasado, o en cualquier otro periodo de tiempo que decidamos
.

¿Cuáles son los elementos sin los cuales este negocio no funciona en absoluto, sin los cuales no podemos operar?

Y ese es un debate muy, muy importante.

Lo que puedes empezar a hacer entonces es aplicar el concepto de MTCR a la empresa mínimamente viable.

Y ahora le cedo la palabra a Duncan, que nos puede explicar más o menos en qué consiste un servicio.

¿Cómo abordamos esto en el contexto de los servicios?

Y gracias, Darren.

Y, una vez más, sin intentar complicarlo demasiado ni profundizar en exceso.

El MTCR equivale a medir el tiempo medio de recuperación de un proceso empresarial,

un servicio empresarial esencial que, a su vez, forma parte de la empresa mínima viable en su conjunto.

Así que habrá varios MTCR diferentes para distintos procesos de negocio.

Precisamente hoy mismo estaba hablando con una empresa de bienes de consumo, una cervecera, y
decían que, si perdemos datos equivalentes a cuatro días, tendremos que tirar, literalmente,

cuatro días de cerveza por el desagüe porque no podemos demostrar que sea apta para el consumo y
, por lo tanto, no podemos venderla.

Así que este concepto consiste en desglosar esos procesos de negocio y, a continuación, utilizar ese
El MTCR como lenguaje empresarial común que nos permita decir: «Bien, dentro de mi proceso, necesito

y, a continuación, «ah, este proceso depende de varios tipos de aplicaciones».

Todos ellos dependen de servicios fundamentales, como la identidad o la capacidad de los
clientes para iniciar sesión en la plataforma.

Luego están los sistemas de backend, ya sea en la nube o en las propias instalaciones, los hipervisores y
las soluciones críticas en la nube.

Los sistemas front-end que ejecutan las aplicaciones propiamente dichas y, por último, los sistemas
Acceso de los usuarios: ¿cómo acceden realmente las personas a esa solución? ¿A través de PDA, terminales de punto de venta?

, etcétera?

Todos ellos deben estar disponibles para que ese servicio empresarial funcione.

El MTCR está diseñado para que sea el propio empresario quien se haga cargo de él.

El primer paso de ese proceso es llevar a cabo una evaluación comparativa.

¿Cuál es su MTCR actual?

¿Cuánto tiempo les llevaría actualmente, incluso si pudieran recuperar datos sin daños?

Porque lo más llamativo en este momento es que la mayoría de las organizaciones no cuentan
con la tecnología necesaria que les permita proteger sus copias de seguridad y poder examinar

sus copias de seguridad para extraer datos limpios, que es el verdadero problema empresarial por el que estamos aquí
para resolverlo.

Es muy interesante.

Ha dicho: «¿Cuál es el MTCR actual?».

Así que el MTCR no es una medida que se adopte al final para evaluar en qué medida nos hemos recuperado.

El MTCR se mide a intervalos regulares a lo largo de todo el ataque.

Y eso se debe probablemente a que

Si te precipitas en Recovery, en realidad puedes causar más daño.

¿Podrías hablar un poco sobre eso?

Sí, claro que puedo profundizar en eso.

Pero antes de hacerlo, has planteado una cuestión realmente interesante,
que creo que hay que analizar más a fondo.

Así pues, el MTCR no es solo algo que se mida a lo largo de la fase de Recovery tras un ataque.

Es algo que deberías medir antes de que se produzca la brecha.

Es lo que yo llamo «antes de la explosión», por así decirlo.

Cuando presentamos este concepto a los consejos de administración, empezamos a ver cómo se va extendiendo
en toda la organización.

Y surge la pregunta: ¿qué es el MTCR, por ejemplo, para nuestra empresa mínimamente viable?

Es probable que recibamos algunas respuestas que no queremos oír, como que no sabemos qué es una empresa mínimamente viable
.

O incluso, aunque lo sepamos, siendo realistas, nuestro MTCR en este momento probablemente sea de cuatro meses.

No queremos oír esas respuestas, pero necesitamos oírlas para poder centrarnos
en mejorar.

Y creo que ese es un punto realmente, realmente importante.

Y, Darren, para profundizar en eso, creo que es fundamental que la empresa comprenda cuál
es su MTCR en la actualidad, ya que esto, a su vez, permite definir adecuadamente su proceso de gestión de riesgos empresariales.

Y no siempre será una solución tecnológica la que reduzca ese MTCR.

Muy a menudo, si la empresa sabe que corre el riesgo de quedarse sin un
sistema crítico durante

durante un tiempo determinado, puede incorporar un plan alternativo de continuidad del negocio,
Volver al papel… Ya sabes, podría ser lo peor que pudiera pasar, Darren, pero, ya sabes, ahora mismo,

Las empresas no comprenden los riesgos que están cubriendo.

Y este MTCR está concebido para que el consejo de administración pueda dirigirse al CISO y a sus equipos
y preguntarse: «¿Cuánto tiempo, siendo realistas, estará fuera de servicio hoy?».

Y entonces, si esa cifra es aceptable… He realizado varios estudios de este tipo
y suele ser de…

A menudo son 28, 35 o 42 días.

La empresa se queda entonces totalmente consternada ante la idea de quedarse sin servicios de TI durante todo ese
tiempo.

Pero nunca han planteado esas exigencias a las organizaciones del CIO o del CISO para decir: «Necesitamos que…»
«que la empresa sea mínimamente viable; que estos activos vuelvan a estar operativos en un plazo de 24 horas».

¿Cómo se pueden diseñar esos procesos de negocio para que se puedan restablecer en 24 horas?

Tienen que ser requisitos funcionales o no funcionales de su negocio para poder decir: «Estos
«… son nuestros requisitos».

¿TIC, CISO, podéis ayudarme a cumplirlos?

Y, volviendo al tema que mencioné antes, por cierto, es realmente importante comprender
que, en cierto modo, esa pregunta ni siquiera se puede plantear a uno de esos equipos o a ambos

equipos.

El único momento en el que obtendrás algún tipo de respuesta que tenga sentido, aunque
Aunque quizá no sea la respuesta que esperas, la cuestión es si cuentas con el equipo de infraestructura y el de seguridad.

estén presentes en la sala para responderla.

Porque ninguno de esos equipos por sí solo puede responder a esa pregunta.

Y eso, de nuevo, desde el punto de vista cultural, es muy, muy importante antes incluso de acercarnos a
la tecnología.

Desde el punto de vista cultural, lo que intentamos hacer aquí con este concepto es fomentar un
un comportamiento que hoy en día no existe.

Así es.

Estás intentando acabar con los compartimentos estancos.

Así que cada organización, ya sea el equipo de TI, el de infraestructura o el de operaciones de seguridad, piensa: «Mi
«Cada parte está bien», pero todas esas partes tienen que trabajar juntas.

Y así, el MTCR las une y les hace reflexionar sobre este

concepto de riesgo en el entorno, ya que cada persona tiene un papel que desempeñar en él.

Y creo que es realmente transformador, ya que ofrece a cada uno de esos
a los líderes la capacidad de transmitir al director general o al consejo de administración y hablar de lo que

están viviendo realmente en lo que respecta a la gestión del riesgo empresarial, ¿verdad?

Por supuesto, eso es fantástico.

Entonces, ¿qué relación tiene esto con los requisitos básicos?

No son tan sencillos, pero son requisitos de cumplimiento como DORA y NIST 2.

¿Cómo aborda el MTCR esta cuestión, si es que lo hace?

Bueno, empezaré yo, si te parece bien, Duncan.

Esta es mi reflexión inicial al respecto: ya sabes, Danielle, tú y yo hemos revisado
Hemos leído juntos esos artículos de DORA en numerosas ocasiones y hemos hablado sobre el cumplimiento normativo.

Una de las cosas que estamos empezando a observar en el ámbito del cumplimiento normativo, ya sea
DORA, NIST 2 y otras normativas internacionales; es esta mención, en primer lugar, a lo que

es la resiliencia y qué significa en relación con la seguridad y, en segundo lugar, las pruebas.

¿Tienes algún plan?

¿Has probado el plan de Recovery?

Bueno, creo que esto apunta directamente a cuál debería ser el criterio de evaluación del plan.

Me preocupa un poco que muchas de las normativas que veo, incluso las más recientes
y, en constante evolución, sigan haciendo referencia a conceptos como la recuperación ante desastres.

Siguen sin dar muchas explicaciones sobre lo que hay que demostrar.

Incluso he visto algunas referencias a RPO-RTO.

Y, hasta cierto punto, ya sabes, este tipo de concepto es importante a medida que la gente
empieza a cumplir la normativa y avanza hacia ese tipo de cumplimiento que se basa en gran medida en la resiliencia

.

¿Qué es lo que vamos a medir aquí?

Porque si nos limitamos a medir las antiguas métricas de Recovery, la verdad es que no vamos a avanzar
mucho en este sentido.

Lo que nos va a pasar es que, si sufrimos un ataque, recurriremos a nuestro plan de recuperación ante desastres, lo pondremos en marcha y,
¡Sorpresa, sorpresa!, no encontramos nuestra copia de seguridad válida, y tardamos 30, 40, 50 o 60

días para recuperarnos.

Así que tenemos que cambiar la mentalidad en este sentido.

Y en lo que respecta al cumplimiento normativo, fue muy estimulante comprobar que algunas de las nuevas políticas y calendarios de cumplimiento

Mencionarán la resiliencia, la Recovery y las pruebas, pero tenemos que asegurarnos de que las abordamos de
de la forma correcta y en los marcos y contextos adecuados.

Sí, estoy totalmente de acuerdo, Darren.

Piensa que, si te fijas en muchos de los requisitos del RGPD y en lo que ha dicho el Banco Central Europeo
En cuanto a las pruebas de estrés, la mayoría de las organizaciones se han visto en una situación en la que

fracasar, ya que se exige demostrar que se puede recuperar dentro de los límites de tolerancia al impacto
en el sector.

Y la mayoría de las organizaciones se basan en esa tolerancia al impacto empresarial

en métricas de disponibilidad o en el antiguo plan de recuperación ante desastres, que establece que se puede realizar la conmutación por error del centro de datos A al
centro de datos B en cuatro horas.

No se puede rescatar todo un banco o toda una entidad financiera en cuatro horas, es
imposible.

«Así que creo —y esto pone de relieve la necesidad de este nuevo vocabulario del MTCR—»
que se pueda revisar esa tolerancia empresarial, esa tolerancia al impacto empresarial, para

redefinirla y decir: «Si pierdo mi sistema central, por ejemplo, mi libro mayor,

Ya sabes, ¿cómo sigo actuando?

Pues no puedo operar.

Por lo tanto, necesito elaborar planes de contingencia sobre cómo puedo llevar a cabo subprocesos para luego poder
revertir los cambios una vez que el libro mayor vuelva a estar operativo, en el ejemplo financiero.

Pero, en cuanto a las pruebas, la mayoría de las organizaciones, cuando les hice esa pregunta, «ya»
«¿Cuándo fue la última vez que probaron el proceso de recuperación tras un incidente?», se remiten a su plan tradicional de recuperación ante desastres.

No se refieren a su plan de recuperación cibernética porque la mayoría de las organizaciones aún no han

diseñado ni implementado por completo un plan de recuperación cibernética.

Y, sin duda, este MTCR debe ser uno de los indicadores clave dentro de ese plan de Recovery.
cibernética.

Ha diseñado las situaciones frente a las que vas a protegerte y de las que te vas a recuperar.

Y luego tienes una evaluación del MTCR para esos diferentes tipos de ataque.

En realidad, su objetivo es, como digo, tender un puente entre la empresa, el departamento de TI y el CISO.

Ya sabes, Darren, tú decías que se trata de cambiar la cultura, y Duncan, tú terminabas…
Por no hablar de que muchos…

contratos entre, eh, organizaciones que exigen un plazo de recuperación, y eso no tiene sentido.

Así que no es solo para los equipos técnicos, sino también para los equipos de gestión
de gestión de riesgos empresariales y a los abogados que redactan los contratos, para que comprendan que el RTO y el RPO no son suficientes, sino que

El nuevo estándar es la recuperación total.

Y todo el mundo tiene que entender cuál debe ser el resultado final, no tanto los pasos
intermedios que

pueden no tener sentido, ¿verdad?

Sí, creo que es una observación muy acertada.

Y estoy convencido de que, a medida que avancemos con el concepto y organicemos talleres sobre
La postura de riesgo preferida, en todas las empresas viables y en el marco del MTCR, nos permitirá descubrir

que, ya sabes, quizá muchas más personas de las que tradicionalmente se
que hayan tenido relación con la «Recovery» tengan que participar y tener voz en esos

talleres.

Precisamente por las razones que has mencionado, Danielle.

Así que, para los líderes que estén escuchando,

Os animo a todos a que consultéis el informe completo.

Se titula «Redefiniendo la Recovery cibernética: presentación del tiempo medio de abstinencia (Mean Time to Clean)».

Y tengo una pregunta más para Duncan y Darren: hoy habéis tratado muchos
temas.

Lo habéis basado en una aplicación real para una empresa real, lo cual tiene mucho sentido.

Para los líderes que nos escuchan, ¿por dónde empezamos?

¿Por dónde empezamos ahora mismo?

Leemos el informe y queremos introducir este concepto en nuestras empresas, en nuestros
negocios.

¿Cómo damos el primer paso?

Bueno, en mi caso, como responsable sin conocimientos técnicos, recomendaría convocar una reunión
entre la persona responsable de la infraestructura de la empresa, normalmente el director de sistemas de información (CIO),

y quien sea el responsable de la ciberseguridad en la empresa, normalmente el director de seguridad de la información (CISO), aunque quizá no sea así;
que convoquen una reunión con esas dos personas, esos dos líderes, y les planteen la pregunta: ¿cómo

Rápido, si sufriéramos un ataque catastrófico de ransomware, utilicemos el ransomware

a modo de ejemplo, ya que es muy frecuente y a todos nos afecta.

Así pues, en caso de catástrofe provocada por un ataque de ransomware, ¿con qué rapidez podrían restablecer juntos el
funcionamiento de la empresa y asegurarme de que los datos que estoy a punto de empezar a utilizar para gestionar el

negocio estén a salvo?

Te garantizo que de esa reunión surgirán otras cinco, porque la
La respuesta no es fácil.

Para ello será necesaria la colaboración entre todos esos equipos.

También será necesario un cambio de mentalidad.

Y creo que diría algo muy parecido, salvo que probablemente ampliaría el público
para incluir en esa conversación a personas como su director de riesgos y al departamento de compras.

Porque la mayoría de las organizaciones, cuando analizan si se trata de un contrato de SaaS o de
externalización, suelen pasar por alto esta cuestión de la recuperación cibernética.

¿Cuándo podré recuperar datos sin daños con Recovery?

Porque, en la mayoría de este tipo de contratos, es el cliente quien se hace responsable de
sus datos.

Esos proveedores de infraestructura y esos proveedores de SaaS son responsables de la
infraestructura que sustenta ese servicio.

Así que, ya sabes, son ellos quienes deben asumir la responsabilidad de recuperar sus datos sin problemas.
.

Pero también deben comunicárselo con bastante rapidez a sus responsables para intentar
entender realmente cuál es nuestro MVC, ya que las organizaciones, como has dicho antes,

Darren, simplemente no pueden permitírselo y nunca serán capaces de recuperar todos los sistemas de
su empresa en muy poco tiempo.

La clave aquí está en establecer prioridades, y solo la empresa puede decidir qué es lo más importante
para ella en caso de un ciberataque catastrófico.

Darren, director técnico de Commvault, y Duncan, eh, responsable del área de Seguridad y Resiliencia en Kyndryl.

Muchísimas gracias.

En cuanto a los próximos pasos, espero que pongáis en práctica este concepto de MTCR y ayudéis a los líderes
empresariales para desarrollarlo en talleres.

Y estoy convencido de que empezaremos a ver cómo se va implantando en todo el mundo a medida que ayudemos
a nuestras empresas a definir el MVC específico para cada una de ellas.

Muchísimas gracias por dedicarnos vuestro tiempo hoy.

Gracias, Danielle.