MTTD, MTTA y MTTR son las tres métricas que miden la velocidad con la que una empresa enfrenta un incidente de ciberseguridad. El MTTD (mean time to detect, tiempo medio de detección) mide cuánto pasa desde que empieza un incidente hasta que se detecta; el MTTA (mean time to acknowledge, tiempo medio de atención) mide cuánto tarda una persona en tomar la alerta y empezar a revisarla; y el MTTR (mean time to respond, tiempo medio de respuesta) mide cuánto tarda el incidente en quedar contenido o resuelto. Mientras más bajas son, menos tiempo tiene un atacante para moverse dentro de tus sistemas.
Juntas responden la pregunta que cualquier director se hace sobre su monitoreo: si algo pasara hoy, ¿cuánto tardaríamos en enterarnos y en frenarlo? Por eso también son la forma más objetiva de comparar proveedores de SOC (centro de operaciones de seguridad) y de revisar si el tuyo cumple lo que promete.
Qué miden MTTD, MTTA y MTTR
En la sala de urgencias de un hospital, la atención tiene tres tramos: primero alguien tiene que notar que el paciente está mal; después un médico tiene que verlo en el triaje; y al final hay que estabilizarlo y darlo de alta. Un buen hospital mide cada tramo por separado, porque cada uno falla por razones distintas. Con los incidentes de ciberseguridad pasa lo mismo:
| Métrica | El reloj empieza | El reloj se detiene | En urgencias |
|---|---|---|---|
| MTTD (detección) | Cuando empieza el incidente: el primer acceso indebido o el correo malicioso que alguien abre. | Cuando se genera una alerta confirmada. | Cuánto tarda alguien en notar que el paciente está mal. |
| MTTA (atención) | Cuando se genera la alerta. | Cuando una persona la toma y empieza a investigar. | La espera hasta que lo ve un médico. |
| MTTR (respuesta) | Cuando se atiende la alerta. | Cuando el incidente queda contenido o resuelto. | El tiempo hasta que lo dan de alta. |
Toma un caso típico: una colaboradora de cuentas por pagar abre un correo falso y entrega su contraseña. El atacante entra a su cuenta esa misma mañana, y la herramienta de monitoreo lo marca como inicio de sesión sospechoso cuatro horas después (detección). Un analista toma la alerta a los 20 minutos (atención) y en otros 40 minutos la cuenta queda bloqueada y la sesión cerrada (respuesta). El atacante tuvo cinco horas dentro, y casi todas se fueron en la detección.
La R del MTTR es la que más confusiones causa. Según quién la reporte, puede significar respond (contener la amenaza: aislar el equipo, bloquear la cuenta), resolve (eliminar la causa y cerrar el caso) o recover (volver a operar con normalidad). Contener una cuenta comprometida puede tomar minutos y recuperar un servidor, horas. Antes de comparar cifras, pregunta siempre cuál de las tres se está midiendo.
Tampoco hay que confundirlo con el RTO (recovery time objective, objetivo de tiempo de recuperación), que es el tiempo máximo que tu negocio tolera sin un sistema. El RTO es una meta que decides en tu plan de recuperación ante desastres (DRP); el MTTR es lo que realmente tardas.
Cómo calcular MTTD, MTTA y MTTR
Las tres son promedios: se suman los tiempos de todos los incidentes de un periodo y se dividen entre el número de incidentes. Con los cuatro incidentes de un mes, el cálculo queda así:
| Incidente | Detección | Atención | Respuesta |
|---|---|---|---|
| Contraseña robada por phishing | 4 h | 20 min | 40 min |
| Malware en una laptop | 30 min | 5 min | 25 min |
| Acceso desde un país inusual | 2 h | 15 min | 1 h 15 min |
| Escaneo de puertos al firewall | 10 min | 10 min | 20 min |
| Promedio del mes | MTTD: 1 h 40 min | MTTA: 12.5 min | MTTR: 40 min |
El promedio tiene un punto ciego: puede esconder justo el caso que importa. Si nueve incidentes se resuelven en 10 minutos y uno tarda dos días, el MTTR se ve aceptable y el incidente grave queda diluido. Por eso conviene pedir también la mediana (el valor del medio), el peor caso del mes y las métricas separadas por severidad: crítica, alta, media y baja.
Qué es un buen tiempo de detección y respuesta
No hay un estándar único, porque depende de lo que se monitorea y de la severidad de cada incidente. Hay, eso sí, una referencia pública que muestra cuánto pesa el tiempo. Según el reporte Cost of a Data Breach 2026 de IBM, las brechas de datos tardaron en promedio 247 días en identificarse y contenerse: 183 para identificarlas y 64 para contenerlas. Las que se cerraron en menos de 200 días costaron en promedio 4.32 millones de dólares, contra 5.65 millones de las que tardaron más.
Ese dato habla de brechas ya consumadas, no de las alertas del día a día. Para tu operación, lo práctico es fijar metas por severidad y medir contra ellas. Un punto de partida razonable, que cada empresa ajusta a su realidad:
| Severidad | Ejemplo | Meta de atención (MTTA) | Meta de contención (MTTR) |
|---|---|---|---|
| Crítica | Ransomware en curso o cuenta de administrador comprometida. | 15 minutos | 1 hora |
| Alta | Malware activo en un equipo. | 30 minutos | 4 horas |
| Media | Inicio de sesión sospechoso sin actividad posterior. | 4 horas | 1 día hábil |
| Baja | Escaneo de puertos bloqueado por el firewall. | 1 día hábil | Según el plan del mes |
El MTTD es el más difícil de fijar como meta, porque no sabes cuándo empezó un incidente hasta que lo investigas. Lo útil es seguir su tendencia: si cada trimestre detectas antes, tu monitoreo está mejorando.
Qué pedirle a tu proveedor de SOC
En urgencias, un buen hospital puede decirte cuánto esperó cada paciente. Tu proveedor debería poder hacer lo mismo con cada alerta. Estas cinco preguntas separan a los proveedores que miden de los que solo prometen:
- ¿Cómo defines cada métrica? Por escrito: en qué momento empieza cada reloj y qué significa la R de su MTTR.
- ¿Qué metas se comprometen en el contrato? El SLA (acuerdo de nivel de servicio) debe tener tiempos por severidad, no solo la frase "respuesta 24/7".
- ¿Qué incluye el reporte mensual? MTTD, MTTA y MTTR por severidad, con la mediana y el peor caso de cada mes.
- ¿Qué acciones ejecutas sin esperar mi aprobación? Si el proveedor puede aislar un equipo o bloquear una cuenta con acciones de contención ya acordadas, el MTTR baja de horas a minutos.
- ¿Cómo cambian los tiempos de noche y en fin de semana? Ahí es donde el MTTA suele crecer si la guardia no es real.
Si tu proveedor actual no puede decirte cuánto tardó en atender cada alerta del mes pasado, ese ya es un dato. Revisamos qué más conviene evaluar antes de contratar en nuestra guía sobre qué es un SOC y cuándo contratarlo como servicio.
Cómo reducir cada tiempo
Cada métrica se mueve con palancas distintas. En urgencias, la espera no se acorta con más camas sino con un mejor triaje; en tu operación pasa algo parecido:
| Métrica | Qué la reduce |
|---|---|
| MTTD | Visibilidad: registros de equipos, correo, identidades y nube reunidos en un solo lugar, con reglas de detección afinadas a tu operación. |
| MTTA | Triaje automático que filtra el ruido y ordena las alertas por gravedad, más una guardia 24/7 que atiende lo importante. |
| MTTR | Procedimientos escritos paso a paso para cada tipo de incidente y acciones de contención automáticas aprobadas de antemano. |
La herramienta que reúne esos registros y genera las alertas es el SIEM (gestión de información y eventos de seguridad). Comparamos las opciones del mercado en nuestro artículo sobre las mejores soluciones SIEM.
La automatización pesa en los tres tiempos. En el mismo reporte de IBM, las organizaciones que usan IA y automatización de forma extensa en seguridad cerraron el ciclo de identificación y contención 65 días antes: 215 contra 280 de las que no las usan.
Los procedimientos, por su parte, se escriben antes del incidente, no durante. Cómo armarlos con un SOC lo detallamos en nuestro plan de respuesta a incidentes para empresas.
Preguntas frecuentes sobre MTTD, MTTA y MTTR
En ciberseguridad, MTTR suele significar mean time to respond (tiempo medio de respuesta): cuánto tarda un incidente en quedar contenido. Algunos proveedores lo usan como tiempo medio de resolución o de recuperación. En mantenimiento industrial significa mean time to repair, el tiempo medio para reparar un equipo, que es otra métrica.
El MTBF (mean time between failures, tiempo medio entre fallas) mide cada cuánto se descompone un equipo. Sirve para planear mantenimiento y disponibilidad de maquinaria o servidores, pero no dice nada sobre qué tan rápido detectas o frenas un ataque.
Es el mean time to contain, tiempo medio de contención: cuánto pasa desde la detección hasta que la amenaza deja de propagarse. Algunos reportes lo separan del MTTR para distinguir entre frenar el incidente y resolverlo por completo.
Cada mes, con un corte por severidad, y revisando la tendencia cada trimestre. Un mes aislado puede engañar por un solo incidente largo; la tendencia muestra si el monitoreo mejora.
Es una alerta que parece un ataque y no lo es. Cuando hay demasiados, los analistas pierden tiempo revisando ruido y las alertas reales esperan más, así que el MTTA sube. Afinar las reglas de detección y usar triaje automático lo corrige.
Sí, aunque con menos precisión. Para calcular el MTTD, el MTTA y el MTTR basta con registrar en cada ticket de seguridad la hora en que empezó el incidente, la hora de la alerta, la hora en que alguien lo tomó y la hora en que quedó contenido.
Un SOC como servicio aporta la visibilidad, el triaje y la guardia 24/7 que reducen los tres tiempos sin que tengas que armar un equipo propio. Así funciona nuestro servicio de SOC.
Levi combina una sólida trayectoria en Coordinación Financiera con una fuerte pasión por la tecnología y la ciberseguridad. Su mentalidad analítica la lleva a investigar a fondo las tendencias, amenazas y soluciones prácticas del entorno digital. También sigue de cerca las novedades de Microsoft, aportando una mirada económica y empresarial poco común en el sector. Escribe de forma clara y concisa para que los temas complejos resulten accesibles a cualquier lector. En su blog encontrarás artículos de ciberseguridad y actualizaciones de Microsoft con recomendaciones aplicables al día a día.
