Los equipos de seguridad no pueden mejorar la velocidad de respuesta hasta que se pongan de acuerdo sobre cuándo comienza y cuándo termina la respuesta. En su análisis de 2026, Mandiant descubrió que el intervalo medio desde el acceso inicial hasta el traspaso a un actor secundario se redujo de más de ocho horas en 2022 a 22 segundos en 2025. Aunque esa cifra mide el traspaso por parte del atacante y no el tiempo de respuesta del SOC, muestra por qué el tiempo medio de respuesta (MTTR) debería tener en cuenta la latencia en la toma de decisiones desde una detección de alta fiabilidad hasta la contención verificada, y no simplemente la rapidez con la que se cierra un ticket.
¿Qué es el tiempo medio de respuesta?
El tiempo medio de respuesta, conocido comúnmente como MTTR, mide el tiempo que tarda un equipo de seguridad en pasar de la detección de una amenaza confirmada o de alta fiabilidad a la contención verificada del riesgo asociado. Resulta más útil cuando refleja el tiempo durante el que un atacante aún puede actuar, en lugar del tiempo que permanece abierto un ticket.
Si se utiliza correctamente, el MTTR pone de manifiesto la lentitud en la toma de decisiones. Si se utiliza de forma inadecuada, fomenta el cierre rápido de los tickets mientras la amenaza sigue activa.
Define el reloj de respuesta antes de calcularlo
No existe una fórmula universal para el MTTR, ya que los equipos utilizan distintos eventos de inicio y finalización. Una definición útil debe ser coherente, auditable y estar vinculada a la reducción del riesgo.
En la mayoría de los informes SOC, el contador debe ponerse en marcha cuando un analista cualificado o un flujo de trabajo de detección identifique un incidente de seguridad de alta fiabilidad que requiera una respuesta. Debe detenerse cuando el equipo verifique que la vía de ataque inmediata ha sido contenida, por ejemplo, desactivando una identidad comprometida, aislando un host, bloqueando una sesión maliciosa o revocando las credenciales expuestas.
| Decisión |
Definición recomendada |
Por qué es importante |
| Inicio del evento |
Detección de alta fiabilidad aceptada para respuesta |
Evita penalizar a los equipos por alertas sin procesar y de baja calidad. |
| Evento de parada |
Se ha comprobado la contención del riesgo activo |
Mantiene el indicador centrado en limitar las oportunidades de los atacantes. |
| Incluir |
Incidentes confirmados y casos que cumplían los criterios y que requerían una intervención |
Hace que la población tenga sentido. |
| Excluir, pero realizar un seguimiento por separado |
Alertas de prueba, duplicados, falsos positivos cerrados y casos pendientes de decisiones empresariales ajenas al asunto |
Evita que el ruido de funcionamiento distorsione el número. |
| Informar junto con |
Mediana, P90, gravedad, entorno y tipo de acción |
Muestra un comportamiento típico y una cola complicada. |
No utilices el cierre definitivo del ticket como evento de finalización, a menos que represente de forma fiable una contención verificada. El cierre puede incluir documentación, trabajos de recuperación, lecciones aprendidas u otras tareas que deben medirse por separado.
Cómo calcular el MTTR
Para un período de referencia determinado:
MTTR = tiempo total transcurrido desde el evento inicial elegido hasta la contención verificada ÷ número de incidentes incluidos
Por ejemplo, si los 20 incidentes incluidos requirieron un total de 100 horas desde su detección por parte de personal cualificado hasta su contención verificada, el MTTR es de cinco horas. El cálculo es sencillo. El rigor radica en utilizar siempre las mismas definiciones de eventos, las mismas reglas de inclusión y las mismas fuentes de datos.
No te limites a indicar solo la media. Unos pocos incidentes complejos pueden elevarla considerablemente, mientras que una media aparentemente buena puede ocultar un grupo peligroso de casos de evolución lenta. Un cuadro de mando práctico incluye:
- Media, mediana y MTTR en el percentil 90.
- MTTR por gravedad, tipo de incidencia, entorno y unidad de negocio.
- El porcentaje de casos que se ajustan al objetivo de servicio documentado de la organización.
- Tiempo dedicado a la clasificación, el análisis, la aprobación, la ejecución y la verificación.
- Una lista de casos atípicos con el motivo del retraso.
Este enfoque permite convertir una cifra clave en información que indica en qué aspectos del flujo de trabajo es necesario prestar atención. Los equipos deben situar el MTTR dentro de un conjunto más amplio de métricas de ciberseguridad, de modo que la velocidad de respuesta se evalúe junto con la detección, la investigación, la corrección y la recuperación.
MTTR y métricas de seguridad relacionadas
El MTTR suele utilizarse de forma inconsistente. Asigna a cada métrica un límite de evento bien definido para que los responsables no confundan una detección más rápida con una contención más rápida.
| Métrica |
Lo que mide |
Uso recomendado |
| Tiempo medio de detección (MTTD) |
Detección de vulnerabilidades o actividades sospechosas |
Evaluar la visibilidad y la eficacia de la detección. |
| Tiempo medio de investigación (MTTI) |
De la detección a una determinación basada en pruebas |
Identificar los cuellos de botella en la investigación. |
| Tiempo medio de respuesta (MTTR) |
Detección precisa para una contención contrastada |
Mide la rapidez con la que se controla el riesgo activo. |
| Tiempo medio de contención (MTTC) |
Una medida específica de contención estrechamente relacionada |
Utilízalo cuando el evento de parada sea explícitamente de contención. |
| Tiempo medio de resolución |
Desde la contención hasta la eliminación de la causa raíz y la adopción de medidas correctoras duraderas |
Realizar un seguimiento de la reducción del riesgo a largo plazo. |
| Tiempo medio de recuperación |
Repercusión del incidente hasta el restablecimiento de la normalidad en las operaciones |
Realizar un seguimiento de la actividad empresarial y la restablecimiento de los servicios. |
Esta distinción refleja el ciclo de vida descrito en las directrices del NIST sobre respuesta a incidentes y las funciones de «Detección», «Respuesta» y «Recuperación» del Marco de Ciberseguridad 2.0 del NIST. Además, permite identificar el problema real. Un tiempo de respuesta prolongado puede deberse a una investigación lenta, a una autoridad de aprobación poco clara o a un proceso de contención poco fiable.
Para conocer el flujo de trabajo general, consulta la sección «Respuesta ante incidentes». Para obtener más detalles sobre la fase de recopilación de pruebas, consulta la sección «Investigación de incidentes».
Por qué un buen MTTR no es una cifra universal
Un MTTR de dos horas no es necesariamente mejor que uno de ocho horas. Un equipo que se enfrente a una violación de identidad verificada y de alta gravedad puede necesitar más validación y coordinación que un equipo encargado de bloquear un dominio malicioso conocido. La combinación de niveles de gravedad, la cobertura de la telemetría, los requisitos de control de cambios, los sistemas críticos para el negocio y las definiciones de incidentes influyen en el resultado.
Compara el MTTR a lo largo del tiempo dentro del mismo diseño de medición. Segmenta los datos antes de comparar equipos o entornos. A continuación, fíjate en la cola: el P90 suele ser donde se hacen evidentes la falta de permisos, las vías de escalación poco claras o los traspasos manuales.
La detección también debe medirse por separado. Mandiant informó de que el tiempo medio de permanencia a nivel mundial aumentó de 11 a 14 días en 2025, mientras que las organizaciones detectaron por primera vez indicios a nivel interno en el 52 % de sus investigaciones, frente al 43 % registrado en 2024. Estas cifras no son puntos de referencia para la respuesta, pero muestran por qué un flujo de trabajo de contención rápido no puede compensar una brecha en la detección.
Cómo mejorar el MTTR sin crear una automatización insegura
El objetivo es reducir el tiempo de que dispone un atacante para actuar, sin dejar de actuar con sensatez. Empieza por identificar en qué fase se pierde tiempo.
- Establece el flujo de trabajo. Registra las marcas de tiempo correspondientes a la calificación, la responsabilidad, la investigación, la aprobación, las medidas adoptadas y la verificación. No deduzcas que hay un retraso basándote únicamente en el estado del ticket. Unos procesos operativos claros del SOC facilitan la identificación de estos traspasos y de las lagunas en la responsabilidad.
- Da prioridad a las señales de ataque de alta fiabilidad. Un mejor contexto ayuda a los analistas a identificar qué casos requieren una actuación inmediata y reduce el tiempo dedicado a validar alertas duplicadas o de escaso valor.
- Autorizar previamente las medidas de contención proporcionales. Definir qué medidas se pueden adoptar de forma inmediata, quién puede aprobar las medidas de mayor impacto y cómo ponerse en contacto con esas personas fuera del horario laboral.
- Automatiza los pasos delimitados y reversibles. Amplía los casos, recopila información contextual, crea incidencias o restringe temporalmente una sesión cuando el nivel de confianza y las medidas de seguridad sean suficientes. Mantén las acciones irreversibles o que puedan afectar al funcionamiento de la empresa sujetas a la revisión adecuada.
- Revisa los casos atípicos. En cada caso que se demore de forma inusual, se debe identificar una causa controlable, como la falta de datos de telemetría, la ambigüedad en la responsabilidad, una cola de aprobación o un traspaso de herramientas.
Para obtener orientación sobre la implementación una vez que el modelo de medición esté en marcha, consulta la sección sobre automatización de la respuesta ante incidentes. Los equipos que necesiten mejorar la priorización entre dominios y el flujo de trabajo de respuesta también pueden consultar el caso de uso de detección y respuesta ante amenazas de Vectra AI.
La perspectiva de « Vectra AI »
El MTTR mejora cuando los responsables de la respuesta pueden comprender rápidamente qué señales indican un ataque activo, hacia dónde se está propagando y qué medidas conviene adoptar. « Vectra AI » ayuda a los equipos de seguridad a integrar la detección de amenazas, la investigación y la respuesta en entornos de red, de identidad y de « cloud », lo que permite un flujo de trabajo de respuesta más fundamentado. La métrica sigue siendo la herramienta de gestión del equipo: hay que definir sus límites, analizar los valores atípicos y utilizarla para mejorar las decisiones, en lugar de limitarse a acelerar el cierre del incidente.
