Presentamos MTCR: la métrica que faltaba para la recuperación cibernética

El MTCR mide el tiempo que se tarda en restaurar los sistemas y los datos de forma limpia —libres de malware, corrupción o persistencia— tras un ciberataque. 

El RTO y el 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. 

Requiere verificar las copias de seguridad, buscar amenazas ocultas y validar las cargas de trabajo restauradas, lo cual es mucho más complejo que una simple conmutación por error. 

Los atacantes corrompen cada vez más las copias de seguridad y ocultan su persistencia, lo que convierte la identificación de datos limpios en la fase más larga de Recovery. 

Proporciona a los responsables una métrica realista de la calidad de la Recovery, lo que permite una inversión y una preparación más inteligentes. 

Por favor, vea el vídeo aquí para acceder a una 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 trabaja en estrecha colaboración 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
. Ellos fueron los autores del 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 al
é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 es solo otra métrica técnica, sino el estándar empresarial que ahora debe tener cabida en la

sala de juntas.

Vamos a intentarlo.

Sí, gracias, Danielle.

Y gracias por la estupenda introducción.

Precisamente este año 2025, en el Reino Unido en particular, pero en realidad en todo el mundo,
sobre todo en Europa, hemos sido testigos de una serie de ataques dirigidos contra el sector minorista.

Y hemos visto de primera mano lo difícil que ha sido para esos minoristas 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 de ransomware.

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

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

Y comenzaron 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, ya sabes, casi tres meses, hasta bien entrado agosto, y luego solo
un ataque por fases, una especie de enfoque por fases para volver a poner en marcha los sistemas.

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

Bueno, gran parte de ese tiempo se dedicó a intentar encontrar los datos correctos, los datos limpios.

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 indicativo de lo que queremos comentar
aquí.

La empresa tiene que empezar a plantear un conjunto 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 restauren los sistemas,

sino que también se puedan empezar a hacer promesas sobre el grado de limpieza de esos sistemas, sobre lo limpios
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 que los sistemas vuelvan a estar operativos.

Ya sabes, vale, eso es fascinante.

Nos has dado mucho en qué pensar.

Duncan, déjame ahora volver al principio.

¿Puedes darnos la definición de MTCR?

Explícanos 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 del tiempo que tardan en volver a estar operativos, como decía Darren.

Con datos limpios y con sistemas que puedan funcionar y volver a estar en producción.

La mayoría de las organizaciones se han centrado principalmente en que sus sistemas estén disponibles
en línea, sin comprender que estos ciberataques eliminan los datos y las plataformas

que sustentan esas 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 datos
limpios para introducirlos en ellas.

Y, con bastante frecuencia, en el tipo de ataques que estamos viendo, los datos llevan
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 reducir ese tiempo
medio de 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 va a haber en esa plataforma.

Ya sabes, y normalmente se utiliza la disponibilidad.

¿Cuánto tiempo tardo en realizar la conmutación por error del centro de datos A al centro de datos B ante un
ataque tradicional a 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 la plataforma en funcionamiento.

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, en realidad, está diseñado para abarcar esos diferentes pilares de los sistemas que hay
que poner en funcionamiento 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, caer en lo técnico en esta conversación.

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

Pero creo que esto apunta a un problema organizativo.

Lo que vemos constantemente es que uno de los problemas culturales en torno a la recuperación
de los sistemas, y una de las razones por las que en muchos casos lleva tanto tiempo —como ocurrió en mi

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 labor 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é medida están infectados los sistemas… 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 ver 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 me va a llevar recuperarme?

El objetivo de 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 tenemos 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 se plantee
esa pregunta.

¿Cuánto tiempo tardaremos en recuperar la limpieza de nuestros sistemas?

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

el equipo de seguridad y el de infraestructura.

Realmente creo que ahí radica la genialidad de MTCR, porque se toman 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

explicar lo que ha ocurrido y cómo va el… eh… proceso de Recovery?

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

la agrupación

de activos que se combinan para formar un servicio.

Pero empezaré diciendo que hay un par de temas que hay que abordar y que, muy
a menudo, no se tratan.

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, más
o menos por ahí.

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é

debe cubrir nuestro seguro, por ejemplo, y qué debe integrarse
de forma absoluta.

Así que esa es la primera conversación.

La segunda conversación es, entonces: ¿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 TI.

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 a lo que nos lleva es a lo que llamamos una MVC, una empresa mínimamente viable.

Es decir, qué elementos deben estar presentes 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 estamos operativos?

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 en qué consiste un servicio.

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

Y gracias, Darren.

Y, de nuevo, sin intentar complicarlo demasiado ni profundizar en exceso.

El MTCR es como medir el tiempo medio de recuperación de un proceso empresarial,

un servicio empresarial crítico que, a su vez, se integra para formar 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
comentaban que, si perdemos datos equivalentes a cuatro días, tenemos que tirar, literalmente,

cuatro días de cerveza por el desagüe, ya que 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
MTCR como un lenguaje empresarial común para poder 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
de 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 en ese proceso es realizar 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 impactante 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 que estamos aquí
para resolver.

Es muy interesante.

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

Así que el MTCR no es una medida que se toma al final para evaluar lo bien que 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í, sin duda 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 denomino «antes de la explosión».

Cuando presentamos este concepto a los consejos de administración, empezamos a ver cómo se extiende
por 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 si lo sabemos, 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 ampliar eso, creo que es vital que la empresa entienda cuál
es su MTCR hoy en día, porque esto, a su vez, permite definir adecuadamente su proceso de gestión de riesgos empresariales.

Y no siempre va a 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

un determinado periodo de tiempo, puede incorporar un plan alternativo de continuidad del negocio,
volver al papel… Ya sabes, podría ser el peor de los casos, Darren, pero, como sabes, en este momento,

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

Y este MTCR pretende ser esa capacidad del consejo de administración para dirigirse al CISO y a los equipos
del CISO y preguntar: «¿Cuánto tiempo, siendo realistas, estará inoperativo 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 horrorizada ante la idea de quedarse sin servicios de TI durante todo ese
tiempo.

Pero nunca han planteado esas exigencias a las organizaciones del director de TI (CIO) o del responsable de seguridad de la información (CISO) para decir: «Necesitamos que la
empresa funcione al mínimo 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 sean recuperables 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 punto que mencioné antes, por cierto, es muy importante entender
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
no sea la respuesta que deseas, es si tienes al equipo de infraestructura y al equipo de seguridad

estén presentes en la sala para responderla.

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

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
comportamiento que hoy en día no existe.

Así es.

Estás intentando romper los silos.

Así que cada organización, ya sea el equipo de TI, el de infraestructura o el de operaciones de seguridad, piensa: «Mi
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
líderes la capacidad de explicárselo al director general o al consejo de administración y hablar de lo

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

Por supuesto, eso es fantástico.

Entonces, ¿cómo se relaciona 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 este tema, 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
juntos esos artículos de DORA muchas veces y hemos hablado sobre el cumplimiento normativo.

Una de las cosas que estamos empezando a ver en el panorama del cumplimiento normativo, ya sea
DORA, NIST 2 u otras normativas globales, es esta mención, en primer lugar, a lo que

es la resiliencia y qué significa frente a la seguridad, y, en segundo lugar, las pruebas.

¿Tienes un 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 ser muy explícitas sobre lo que hay que probar.

Incluso he visto algunas menciones a RPO-RTO.

Y, hasta cierto punto, ya sabes, un concepto como este es importante a medida que la gente
empieza a cumplir con 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 ámbito.

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

días en recuperarnos.

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

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

se mencionaran la resiliencia, la Recovery y las pruebas, pero tenemos que asegurarnos de abordarlas
de la forma correcta y con los marcos y contextos adecuados.

Sí, estoy totalmente de acuerdo, Darren.

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

fracasar, ya que se exige demostrar que se puede recuperar dentro de la tolerancia al impacto
empresarial.

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 recuperar 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 deben replantearse 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 operando?

Pues no puedo operar.

Por lo tanto, necesito establecer planes de contingencia que me permitan llevar a cabo subprocesos para, posteriormente, 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
sabes, «¿cuándo fue la última vez que probaron la 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 una de las métricas clave dentro de ese plan de Recovery
cibernético.

Has diseñado los escenarios frente a los que vas a protegerte y de los que te vas a recuperar.

Y luego tienes una medida del MTCR para esos diferentes tipos de ataque.

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

Ya sabes, Darren, tú decías que se trata de cambiar la cultura, y Duncan, tú acababas
de mencionar que muchos…

contratos entre, eh, organizaciones que exigen un tiempo 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 riesgos empresariales y los abogados que redactan los contratos, para que entiendan que el RTO y el RPO no son suficientes, sino que

el nuevo estándar es la recuperación completa.

Y todo el mundo tiene que entender cuál debe ser el resultado final, no las etapas
intermedias que

pueden carecer de 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 torno al MTCR, descubriremos

que, ya sabes, quizá muchas más personas de las que tradicionalmente se
habrían relacionado con la Recovery deberían interesarse y tener voz en esos

talleres.

Precisamente por las razones que has mencionado, Danielle.

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

os animo a todos a consultar 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 líder 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í;
convoque una reunión con esas dos personas, esos dos líderes, y plantee la pregunta: ¿cómo

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

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

Así pues, en caso de catástrofe provocada por un ransomware, ¿con qué rapidez podrían restablecer juntos el
funcionamiento de la empresa y garantizarme 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
respuesta no es fácil.

Requerirá la colaboración entre todos esos equipos.

También requerirá un cambio de mentalidad.

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

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

¿Cuándo podré recuperar datos limpios con Recovery?

Porque en la mayoría de ese tipo de contratos, es el cliente el responsable de
sus datos.

Esos proveedores de infraestructura y esos proveedores de SaaS son responsables de la
infraestructura que da soporte a ese servicio.

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

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

Darren, simplemente no pueden permitirse y nunca serán capaces de recuperar todos los sistemas de
su empresa en un plazo muy breve.

La clave aquí está en establecer prioridades, y solo la propia empresa puede juzgar qué es lo más importante
para ella en una situación de desastre cibernético.

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 a trabajar en él.

Y estoy convencido de que empezaremos a ver cómo se implanta 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 vuestro tiempo hoy.

Gracias, Danielle.