MTTD y MTTR son las dos métricas con las que se mide el tiempo dentro de un incidente de seguridad. El MTTD (Mean Time To Detect) es cuánto tarda una organización en darse cuenta de que algo está pasando. El MTTR es cuánto tarda en hacer algo al respecto, y ahí empieza la confusión, porque esas cuatro letras se usan para cuatro cosas distintas.
Por qué importan cabe en dos datos. El informe global de amenazas 2026 de CrowdStrike sitúa el tiempo medio de propagación de un ataque de cibercrimen en 29 minutos, con un récord observado de 27 segundos. El Cost of a Data Breach 2026 de IBM sitúa el tiempo medio para identificar una brecha en 183 días.
Veintinueve minutos contra ciento ochenta y tres días. Toda la conversación sobre detección y respuesta vive dentro de ese hueco.
¿Qué es el MTTD?
El MTTD (Mean Time To Detect), o tiempo medio de detección, es el promedio que tarda una organización en identificar un incidente desde el momento en que el incidente empezó. Se calcula sumando el tiempo de detección de todos los incidentes de un periodo y dividiendo entre el número de incidentes.
La palabra clave de esa definición es empezó. Y es donde casi todos los tableros mienten un poco.
Si el reloj arranca cuando el SIEM generó la alerta, lo que estás midiendo es la velocidad de tu equipo para atender alertas, no la velocidad de tu empresa para ver un ataque. El reloj honesto arranca en el primer indicio de compromiso que la investigación forense encuentre después, aunque nadie lo haya visto en su momento. Ese es el número incómodo, y es el que se puede mejorar.
¿Qué es el MTTR y por qué significa cuatro cosas?
Aquí conviene ser muy literal, porque he leído contratos donde el proveedor y el cliente firmaron la misma sigla pensando en tiempos que se diferencian en semanas.
| Sigla | Qué mide | Cuándo se detiene el reloj |
|---|---|---|
| Mean Time To Respond | Reacción | Cuando un analista toma el caso y ejecuta la primera acción real |
| Mean Time To Contain | Contención | Cuando la amenaza deja de propagarse: equipo aislado, cuenta bloqueada, sesión cortada |
| Mean Time To Repair | Remediación técnica | Cuando el sistema afectado queda limpio y operativo |
| Mean Time To Recover | Recuperación del negocio | Cuando el servicio vuelve a la normalidad para el usuario final |
Las cuatro son útiles y miden cosas legítimas. El problema es firmar una sin decir cuál. En ZetTateK, cuando hablamos de MTTR en un acuerdo de servicio nos referimos a respuesta y contención, porque es el tramo que un SOC controla de punta a punta. La recuperación completa depende de respaldos, de proveedores y de decisiones del negocio que ningún analista firma solo.
¿Cómo se calculan con un ejemplo real?
Supongamos cuatro incidentes en un mes. Detectados a las 4 horas, 30 minutos, 12 horas y 6 minutos del compromiso. La suma es 16 horas y 36 minutos, dividida entre cuatro: un MTTD de 4 horas y 9 minutos.
Ese promedio se ve razonable y esconde lo importante: uno de esos incidentes tardó 12 horas. Si el atacante se propaga en 29 minutos, la media de 4 horas no describe el riesgo, lo maquilla. Por eso a los tableros que reviso les pido siempre dos cosas más: el percentil 90 (el tiempo que no superan 9 de cada 10 incidentes) y la segmentación por tipo de incidente, porque un phishing reportado por un usuario y un ransomware con movimiento lateral no pertenecen al mismo promedio.
¿Qué números se consideran normales hoy?
El dato de referencia de la industria viene del informe de IBM de este año, que analizó 602 organizaciones con brechas ocurridas entre marzo de 2025 y febrero de 2026. El ciclo de vida completo de una brecha subió a 247 días: 183 para identificarla y 64 para contenerla. Es la primera subida después de cinco años de descensos.
El costo se mueve con el reloj. Las brechas que se cerraron pasado el día 200 promediaron 5,65 millones de dólares. Las que se cerraron antes, 4,32 millones. Casi un tercio de diferencia, y lo que la explica es el reloj.
Hay un tercer dato del mismo informe que suele pasar desapercibido y que a mí me parece el más útil para justificar un presupuesto: los equipos internos de seguridad descubrieron cerca de 4 de cada 10 brechas y las cerraron unas cinco semanas antes de la media global. Cuando el que avisa es el atacante, y eso pasó en aproximadamente 1 de cada 6 casos, la brecha resultó la más cara de todas.
¿Qué hace bajar el MTTD de verdad?
Ninguna de estas cosas es una compra, todas son una decisión de operación.
- Cobertura real de 24 horas. El cibercrimen no respeta el horario de oficina y elige de noche, el fin de semana o un puente precisamente porque nadie mira. Un turno de oficina no baja el MTTD, lo pospone.
- Telemetría donde hace falta. Endpoint, identidad, nube y correo. Lo que no envía registros no se detecta, y suele ser justo el servidor viejo que nadie quiso tocar.
- Correlación, no alertas sueltas. Tres señales inofensivas por separado son un ataque cuando se leen juntas. De eso se ocupan un SIEM bien afinado y una capa de XDR.
- Automatización de la primera acción. Un playbook de SOAR que aísla un equipo en segundos hace por el MTTR lo que ningún proceso manual va a lograr a las tres de la mañana.
- Búsqueda proactiva. El threat hunting existe precisamente para encontrar lo que no disparó ninguna alerta, que es el material del que están hechos los 183 días.
¿Dónde se rompe la medición?
Cuatro fallas que veo repetirse en auditorías, ordenadas por lo caras que salen.
La primera es el sesgo del sobreviviente. Solo puedes medir los incidentes que detectaste. Los que nunca viste no entran en el promedio y son exactamente los que definen tu exposición. Un MTTD que mejora mientras el volumen de incidentes detectados cae en picado no es una buena noticia, es una alarma.
La segunda es cerrar el reloj del MTTR cuando se cierra el ticket. El ticket se cierra cuando el analista terminó su trabajo, y el negocio se recupera cuando el usuario vuelve a facturar. Casi nunca es el mismo minuto.
La tercera es medir solo la media. Un percentil 90 de 14 horas convive perfectamente con una media de 20 minutos, y el atacante siempre se cuela por el percentil.
La cuarta es no medir nada y suponer. Es más común de lo que parece: la empresa tiene herramientas, tiene contrato con un proveedor y no tiene un solo número escrito sobre cuánto tardó en enterarse la última vez.
Cinco preguntas para tu proveedor de seguridad
- ¿Cuáles son tus MTTD y MTTR medidos el trimestre pasado, y quedan por escrito en el SLA?
- ¿Desde qué instante exacto arranca cada reloj y en cuál se detiene?
- ¿Ese MTTR es respuesta, contención, remediación o recuperación?
- ¿El número es el mismo a las tres de la mañana de un domingo que a las once de un martes?
- ¿Me entregas el percentil 90 y el desglose por tipo de incidente, o solo el promedio?
Si un proveedor no puede contestar las cinco, la conversación sobre precio es prematura.
Preguntas frecuentes
Medir es el primer control
Un cliente me dijo una vez que no medía sus tiempos porque el resultado le iba a dar vergüenza. Le contesté lo que contesto siempre: el número existe igual, lo midas o no, y el atacante ya lo conoce.
Nuestro servicio de SOC 24/7 gestionado reporta MTTD y MTTR por incidente y por trimestre, con el reloj arrancando en el compromiso y no en la alerta. Si todavía no tienes esos dos números, la evaluación de seguridad sin costo es la forma más rápida de conseguir el primero. Puedes revisar los demás términos de este artículo en nuestro glosario de ciberseguridad.
Un atacante necesita 29 minutos. La pregunta no es si tu empresa está protegida, es cuántos minutos tarda en enterarse.
